Um pod está preso em CrashLoopBackOff. Como você faz a triagem?

Comece com kubectl describe pod para ver os eventos e o último código de saída, depois kubectl logs com --previous para ler a saída do container que quebrou. Código de saída 137 normalmente significa um OOM kill, então cheque os limites de memória; saída 1 ou 2 normalmente significa que a aplicação falhou na inicialização, muitas vezes uma config ausente, um secret ou uma dependência inalcançável. Confirme que a tag da imagem realmente existe e cheque se uma liveness probe agressiva está causando o loop.

kubectl describe pod primeiro, porque a seção de eventos normalmente te diz de cara se é falha de pull da imagem, um secret ausente ou um OOM kill, e te dá o último estado de término com o código de saída. Depois kubectl logs com --previous, já que o container que estava rodando já foi substituído e os logs dele sumiram. Saída 137 é um SIGKILL e nove em cada dez vezes é o limite de memória, então eu comparo o limite com o uso real em vez de chutar. Saída 1 com um stack trace é falha de inicialização da aplicação, normalmente config. Eu também checo a liveness probe, porque eu já vi um serviço Java perfeitamente saudável entrar em crash loop puramente porque precisava de 40 segundos para aquecer e a probe dava 10. Para depurar com calma eu escalo o deployment, faço exec numa cópia com o comando sobrescrito para sleep, e reproduzo ali em vez de brigar com o cronômetro de reinício.