Quando uma aplicação deixa de responder, reiniciar o pod parece uma solução rápida. Às vezes, o Kubernetes fará isso por conta própria; em outras, a ação manual só apaga pistas úteis e o problema volta alguns minutos depois. Uma investigação curta e ordenada costuma revelar se a falha está na aplicação, na configuração ou nos recursos disponíveis.
Comece pelo estado observado
Confira primeiro o estado do pod e os eventos associados. A saída de kubectl describe pod mostra detalhes como condições, contagem de reinícios e mensagens recentes do controlador ou do nó. Eventos de imagem não encontrada, falha de montagem de volume ou sondagem malsucedida apontam para caminhos de investigação bem diferentes.
Também confirme em que nó o pod está e se os demais pods do mesmo workload apresentam o mesmo comportamento. Uma falha isolada pode indicar uma condição local; várias réplicas com o mesmo sintoma sugerem olhar para uma mudança compartilhada, como a imagem, uma variável de ambiente ou uma dependência externa. O contexto evita tratar toda falha como problema do cluster.
Use os logs como evidência
Leia os logs do contêiner e, se ele já tiver reiniciado, consulte também a execução anterior com kubectl logs –previous. Mensagens de inicialização, erro de conexão ou configuração ausente podem explicar por que o processo encerrou. Se não houver logs, isso também é uma pista: o contêiner talvez nem tenha chegado a iniciar.
Sondas de prontidão e de atividade não significam a mesma coisa. A de prontidão controla se o pod deve receber tráfego; a de atividade ajuda a decidir se o contêiner precisa ser reiniciado. Uma verificação configurada com pouca tolerância pode transformar uma inicialização lenta em reinícios repetidos, então compare os tempos e as condições da sonda com o comportamento real da aplicação.
Verifique recursos e mudanças
Se os eventos indicarem pressão de recursos, examine requests e limits e compare-os com o uso observado. Um contêiner encerrado por falta de memória requer uma análise diferente de um processo que falha ao conectar ao banco de dados. Ajustar limites sem entender o padrão de consumo pode apenas deslocar o problema.
Por fim, relacione o início da falha às mudanças recentes no Deployment, na configuração ou na imagem. Registre o que foi observado antes de reiniciar ou reverter, para que a próxima pessoa não precise reconstruir o incidente do zero. Em Kubernetes, comandos são úteis; a sequência das evidências é o que transforma comandos em diagnóstico.