Compartilhar via

O pod está preso em modo CrashLoopBackOff

Se um pod tiver um CrashLoopBackOff status, ele provavelmente falhou ou encerrou-se inesperadamente, e o log contém um código de saída diferente de zero. Aqui estão vários motivos possíveis pelos quais o pod está preso no modo CrashLoopBackOff.

  1. Falha do aplicativo: o aplicativo dentro do contêiner falha logo após o início, geralmente devido a configurações incorretas, dependências ausentes ou variáveis de ambiente incorretas.
  2. Limites de recursos incorretos: se o pod exceder seus limites de recursos de CPU ou memória, o Kubernetes poderá eliminar o contêiner. Esse problema pode ocorrer se as solicitações de recursos ou os limites forem definidos muito baixos.
  3. ConfigMaps/Secrets ausentes ou configurados incorretamente: se o aplicativo depender de arquivos de configuração ou variáveis de ambiente armazenadas em ConfigMaps ou Segredos, mas estiverem ausentes ou configurados incorretamente, o aplicativo poderá falhar.
  4. Problemas ao carregar imagens: se houver um problema com a imagem (por exemplo, ela está corrompida ou tem uma tag incorreta), o contêiner pode não iniciar corretamente e falhar repetidamente.
  5. Falha nos contêineres de inicialização: se o pod tiver contêineres de inicialização e um ou mais não forem executados corretamente, o pod será reiniciado.
  6. Falhas nas verificações de liveness/readiness: se as verificações de disponibilidade ou preparação estiverem configuradas incorretamente, o Kubernetes poderá detectar o contêiner como não saudável e reiniciá-lo.
  7. Dependências de aplicativo não prontas: o aplicativo pode depender de serviços que ainda não estão prontos, como bancos de dados, filas de mensagens ou outras APIs.
  8. Problemas de rede: configurações incorretas de rede podem impedir que o aplicativo se comunique com os serviços necessários, fazendo com que ele falhe.
  9. Comandos ou argumentos inválidos: o contêiner pode ser iniciado com um argumento, comando ou parâmetro inválido ENTRYPOINT, levando a uma falha.

Para obter mais informações sobre o status do contêiner, consulte Ciclo de Vida do Pod – Estados de contêiner.

Considere as opções a seguir e seus kubectl comandos associados.

Opção comando kubectl
Depurar o próprio pod kubectl describe pod <pod-name>
Depurar os controladores de replicação kubectl describe replicationcontroller <controller-name>
Leia a mensagem de encerramento kubectl get pod <pod-name> --output=yaml
Examinar os registros kubectl logs <pod-name>

Observação

Um pod também pode ter um CrashLoopBackOff status se tiver finalizado a implantação, mas está configurado para continuar reiniciando mesmo que o código de saída seja zero. Por exemplo, se você implantar uma imagem busybox sem especificar nenhum argumento, a imagem será iniciada, executada, concluída e reiniciada em um loop:

$ kubectl run nginx --image nginx
pod/nginx created

$ kubectl run busybox --image busybox
pod/busybox created

$ kubectl get pods --watch
NAME     READY  STATUS             RESTARTS  AGE
busybox  0/1    ContainerCreating  0         3s
nginx    1/1    Running            0         11s
busybox  0/1    Completed          0         3s
busybox  0/1    Completed          1         4s
busybox  0/1    CrashLoopBackOff   1         5s

$ kubectl describe pod busybox
Name:         busybox
Namespace:    default
Priority:     0
Node:         aks-nodepool<number>-<resource-group-hash-number>-vmss<number>/<ip-address-1>
Start Time:   Wed, 16 Aug 2023 09:56:19 +0000
Labels:       run=busybox
Annotations:  <none>
Status:       Running
IP:           <ip-address-2>
IPs:
  IP:  <ip-address-2>
Containers:
  busybox:
    Container ID:   containerd://<64-digit-hexadecimal-value-1>
    Image:          busybox
    Image ID:       docker.io/library/busybox@sha256:<64-digit-hexadecimal-value-2>
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 16 Aug 2023 09:56:37 +0000
      Finished:     Wed, 16 Aug 2023 09:56:37 +0000
    Ready:          False
    Restart Count:  2

Caso você não reconheça o problema após criar mais pods no nó, execute um pod em um único nó para determinar quantos recursos ele realmente utiliza.

Aviso de isenção de responsabilidade para informações de terceiros

Os produtos de terceiros mencionados neste artigo são produzidos por empresas independentes da Microsoft. A Microsoft não oferece nenhuma garantia, implícita ou não, do desempenho ou da confiabilidade desses produtos.

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.