Como resolver CrashLoopBackOff no Kubernetes
CrashLoopBackOff não é o erro: é o Kubernetes avisando que o container sobe, morre e é reiniciado, com uma espera cada vez maior entre as tentativas, até 5 minutos. A causa está no que o container fez antes de morrer. Estes são os passos para encontrá-la.
1. Ache os pods em CrashLoopBackOff
A coluna RESTARTS mostra quantas vezes o container já reiniciou:
kubectl get pods -A | grep -E "CrashLoopBackOff|Error"2. Veja o log da execução que morreu
O log atual pode estar vazio, porque o container acabou de reiniciar. O --previous mostra o log da execução anterior, a que falhou:
kubectl logs <pod> -n <namespace> --previous
kubectl logs <pod> -n <namespace> -c <container> --previous3. Leia o exit code e os eventos
Em Last State, o describe mostra o motivo (Reason) e o código de saída (Exit Code) do último término. No fim, os eventos mostram falhas de probe e de montagem de volume:
kubectl describe pod <pod> -n <namespace>O que o exit code diz
- Exit Code 1 ou outro código da aplicação: ela terminou com erro. A causa está no log com --previous: variável de ambiente faltando, configuração inválida, banco ou fila fora do ar na inicialização.
- Exit Code 137 com Reason OOMKilled: o container passou do limite de memória.
- Exit Code 137 sem OOMKilled: o processo recebeu SIGKILL, em geral porque a liveness probe falhou e o kubelet matou o container.
- Exit Code 0: o processo terminou sem erro, mas o Deployment espera um processo que não termina. Comum em imagem cujo comando roda e sai.
- Exit Code 126 ou 127: o comando do container não é executável ou não existe (command e args errados).
Causas comuns
- Liveness probe agressiva: initialDelaySeconds ou timeoutSeconds curtos demais para uma aplicação que demora a subir. Use uma startupProbe para cobrir o tempo de inicialização.
- ConfigMap ou Secret com valor errado, ou uma variável que a aplicação exige e não está no pod.
- Dependência fora do ar na inicialização (banco, fila, outro serviço) e a aplicação encerra em vez de tentar de novo.
- Permissão: a imagem precisa rodar como root, ou gravar num diretório que o securityContext deixou só leitura.
Sem terminal, no Kubepier
No Kubepier, o status de cada pod mostra o motivo (CrashLoopBackOff, OOMKilled, Error), os pods com problema e os eventos de aviso sobem para o topo, de qualquer cluster, no navegador ou no celular. No Pro, os logs ao vivo e o shell abrem dali mesmo, e no desktop o diagnóstico com IA explica o CrashLoopBackOff a partir dos eventos e do log.