Início / server / Perguntas / 1089638
Accepted
Daigo
Asked: 2022-01-11 23:50:09 +0800 CST

O pod do Kubernetes falha com o status OutOfMemory imediatamente após o agendamento

  • 772

Estou testando meu aplicativo em um cluster Kubernetes bare-metal (versão 1.22.1) e tendo um problema ao iniciar meu aplicativo como um trabalho.

Meu cluster tem dois nós (mestre e trabalhador), mas o trabalhador está isolado. No nó mestre, 21 GB de memória estão disponíveis para o aplicativo.

Tentei iniciar meu aplicativo como três empregos diferentes ao mesmo tempo. Como configurei 16 GB de memória como solicitação de recurso e limite, apenas um único trabalho foi iniciado e os dois restantes estão em estado Pendente. Eu configurei backoffLimit: 0 para o arquivo Jobs.

NAME            READY   STATUS     RESTARTS   AGE
app1--1-8pp6l   0/1     Pending    0          42s
app2--1-42ssl   0/1     Pending    0          45s
app3--1-gxgwr   0/1     Running    0          46s

Após a conclusão do primeiro pod, apenas um dos dois pods em estado pendente deve ser iniciado. No entanto, um foi iniciado e o outro estava em um status OutOfMemory, embora nenhum contêiner tenha sido iniciado no pod.

NAME            READY   STATUS        RESTARTS   AGE
app1--1-8pp6l   0/1     Running       0          90s
app2--1-42ssl   0/1     OutOfmemory   0          93s
app3--1-gxgwr   0/1     Completed     0          94s

Os eventos do Pod OutOfMemory são os seguintes:

Events:
  Type     Reason            Age                   From               Message
  ----     ------            ----                  ----               -------
  Warning  FailedScheduling  3m41s (x2 over 5m2s)  default-scheduler  0/2 nodes are available: 1 Insufficient memory, 1 node(s) were unschedulable.
  Normal   Scheduled         3m38s                 default-scheduler  Successfully assigned test/app2--1-42ssl to master
  Warning  OutOfmemory       3m38s                 kubelet            Node didn't have enough resource: memory, requested: 16000000000, used: 31946743808, capacity: 37634150400

Parece que o Pod está atribuído ao nó, embora não haja espaço suficiente para ele, pois o outro Pod acabou de ser iniciado.

Acho que esse não é um comportamento esperado do Kubernetes, alguém sabe a causa desse problema?

kubernetes

2 respostas

  1. Best Answer

    É um problema conhecido para as 1.22.xversões - você pode encontrar vários tópicos do GitHub e Stackoverflow sobre isso, por exemplo:

    A correção para o problema está incluída na versão 1.23 :

    • Corrige uma regressão em que o Kubelet falhou ao excluir pods já concluídos dos cálculos sobre quantos recursos ele estava usando no momento ao decidir se permitiria mais pods. ( #104577 , @smarterclayton )

    Portanto, atualize seu cluster Kubernetes para a versão estável mais recente.

    Espero que ajude você, mas lembre-se de que outro problema semelhante está aberto no Github, mesmo com a correção aplicada (mencionada aqui cerca de 10 dias atrás - estado para 13 de janeiro de 2022):

    Vinculando aqui para integridade - um sintoma semelhante pode ser exposto após essa correção, conforme descrito em #106884 . O kubelet considera recursos para encerrar pods em uso (eles estão!), mas o agendador ignora o encerramento de pods e agenda novos pods. Como o kubelet agora considera encerrar pods, ele rejeita esses pods reprogramados rapidamente.

    Então, provavelmente a única solução é fazer o downgrade para a versão 1.21.

    • 1

  2. Você pode postar o yaml do pod?

    Eu tive algo semelhante em um dos meus clientes, onde eles tiveram um erro de digitação no limite de memória (860m em vez de 860Mi) vale a pena dar uma olhada

    • 0

relate perguntas