Aula 14: Projeto final de diagnóstico de problemas
Você chegou à última aula, e nela vamos amarrar tudo numa única ferramenta que você vai usar repetidas vezes: um fluxo de diagnóstico organizado — um runbook. Quando algo quebra no cluster, é tentador entrar em pânico e chutar. Em vez disso, trabalhamos como detetives: primeiro reunimos evidências,
Diagnosticar problemas é como ser detetive: você não acusa ninguém antes de reunir evidências. Primeiro veja quem parece suspeito (get), leia os depoimentos (describe e logs), e só então decida quem é o culpado e corrija o problema.
- Diagnóstico de problemas
- Um processo organizado para encontrar a causa de uma falha: reunir evidências (get, describe, logs), formular uma hipótese, corrigir e verificar que o problema desapareceu — em vez de chutar.
- Runbook
- Uma lista fixa e repetível de passos que você segue quando surge uma falha. Ela permite que todo mundo no time diagnostique na mesma ordem e não pule uma etapa crítica sob pressão.
- CrashLoopBackOff
- Um estado do Pod em que o container sobe, trava, e o Kubernetes continua tentando novamente com um atraso cada vez maior entre as tentativas. A causa quase sempre está no código ou na configuração da aplicação — leia com logs --previous.
- ImagePullBackOff
- Um estado em que o Kubernetes não conseguiu baixar (pull) a imagem do container: nome ou tag errados, a imagem não existe no registry, ou faltam credenciais. O motivo aparece nos Events do describe.
- Pending
- Um estado em que o Pod foi aceito mas ainda não foi agendado em nenhum node — geralmente porque não há recursos livres suficientes (CPU/memória), ou nenhum node atende aos seus requisitos.
- Events
- Um registo curto do que o Kubernetes tentou fazer com o Pod (agendou, baixou a imagem, iniciou, falhou). Aparece na parte de baixo do kubectl describe pod e costuma ser a primeira pista da causa.
