APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Pending, ImagePullBackOff e CrashLoopBackOff descrevem situações diferentes. Começa por estado, eventos e última terminação para localizar a fase da falha. Num container reiniciado, logs da execução atual podem omitir a causa anterior; kubectl logs com --previous e container e namespace corretos pode recuperá-la quando disponível. ImagePullBackOff exige ler o erro de obtenção de imagem: referência, credenciais, rede e registry podem explicar causas diferentes. Um evento denied torna autorização de pull uma investigação prioritária. Evita mudar probes de uma aplicação cujo container ainda nem foi obtido.
Aplicação guiada
OOMKilled orienta a análise para memória, limites e consumo, sem provar sozinho se existe fuga ou apenas dimensionamento insuficiente. Correlaciona carga e release e avalia impacto de uma mitigação no nó. Liveness pode reiniciar containers; readiness indica aptidão para tráfego; startup probe permite tratar arranque lento antes de ativar as outras verificações. Para scheduling, requests precisam de caber num nó elegível. Dois nós com 700m livres cada não alojam um Pod que pede 1000m dividindo-o entre ambos. Mantém evidência e critérios de estabilidade depois de recuperar serviço.
kubectl logs recon-7 -c app -n fundos --previous consulta a execução anterior. Compara os logs com kubectl describe pod recon-7 -n fundos, em vez de reiniciar repetidamente sem guardar a causa.
Armadilhas comuns
Confundir sintomas com causa; remover limites indiscriminadamente; usar readiness para esperar restart; somar capacidade de nós para um único Pod.
Tópicos relacionados: Nós e plano de controlo · Cluster, contexto e manutenção
Escolhe a próxima observação pela fase da falha e pelo estado registado.
Referência: Debug Pods · CKA Kubernetes v1.35