DevOpsQuest
0 XP

DEVOPSQUEST

Minha Trilha
Módulo 8 · Kubernetes e Helm

Troubleshooting de Pods: CrashLoopBackOff, ImagePullBackOff e Pending

Avançado 35 min+25 XPKuberneteskubectl

Objetivos desta aula

  • Diagnosticar CrashLoopBackOff passo a passo
  • Resolver ImagePullBackOff e erros de imagem
  • Entender Pods presos em Pending
  • Interpretar OOMKilled e probes falhando

Todo mundo que opera Kubernetes já viu um Pod vermelho no get pods. A boa notícia: os status de erro são poucos e previsíveis. Aprenda os quatro principais e você resolve a maioria dos casos.

CrashLoopBackOff: o contêiner inicia e morre, repetidamente. Ordem de investigação: kubectl logs <pod> --previous mostra por que ele morreu da última vez; kubectl describe pod mostra se foi a aplicação (exit code) ou o kubelet (probe, OOM). Causas comuns: variável de ambiente faltando, banco inacessível, comando errado na imagem.

ImagePullBackOff: o cluster não consegue baixar a imagem. Quase sempre é: nome/tag errado (typo), registry privado sem imagePullSecret, ou limite de requisições do Docker Hub. O describe mostra o erro exato.

Pending: o Pod nem começou. O describe diz o motivo: nenhum nó tem CPU/memória suficiente (aumente o cluster ou reduza requests), PVC não atendido, ou regras de afinidade impossíveis.

OOMKilled: o contêiner passou do limite de memória (resources.limits.memory) e o kernel o matou. Soluções: aumentar o limite, ou investigar vazamento de memória na aplicação. Veja com describe no campo Last State.

Probes falhando: se a liveness probe falha, o Pod reinicia em loop; se a readiness falha, ele fica fora do Service. Teste o endpoint da probe de dentro: kubectl exec -it <pod> -- curl localhost:8080/healthz.

Monte o hábito: status → describe (Events) → logs --previous. Essa sequência, nessa ordem, resolve a enorme maioria dos casos sem adivinhação.

Documente cada incidente novo no seu repositório de notas: status, causa raiz e correção. Em seis meses você terá seu próprio manual de plantão.

Na prática

Diagnóstico dos quatro status clássicos

bash

kubectl get pods -n app
# CrashLoopBackOff:
kubectl logs api-xxx -n app --previous
# ImagePullBackOff:
kubectl describe pod api-xxx -n app | grep -A5 Events
# Pending:
kubectl describe pod api-xxx -n app | grep -i "insufficient\|pvc"
# OOMKilled:
kubectl describe pod api-xxx -n app | grep -i -A3 "last state"

Limites de memória no Deployment

yaml

resources:
  requests:
    memory: "128Mi"   # garantido para o agendador
    cpu: "100m"
  limits:
    memory: "256Mi"   # passou disso = OOMKilled
    cpu: "500m"

Por que isso importa

Esses quatro status cobrem a maior parte dos incidentes de Kubernetes em qualquer empresa.

Erro comum

Aumentar o limite de memória sem investigar o vazamento — o problema volta maior alguns dias depois.

Dica de produção

Configure alertas para Pods reiniciando muito (kube_pod_container_status_restarts_total) antes que os usuários percebam.

Pergunta de entrevista

Um Pod está em CrashLoopBackOff logo após um deploy. Como você investiga?

Glossário

CrashLoopBackOff
Contêiner morrendo e reiniciando em loop.
ImagePullBackOff
Falha ao baixar a imagem do registry.
OOMKilled
Contêiner morto por exceder o limite de memória.
imagePullSecret
Credencial que permite baixar imagens privadas.

Conexão com o CloudShop

O Boss do reino Kubernetes é um Pod em CrashLoopBackOff por causa de uma variável de ambiente ausente.

Quiz da aula

  1. 1. Primeiro comando para investigar CrashLoopBackOff:

  2. 2. ImagePullBackOff em registry privado geralmente é falta de:

  3. 3. OOMKilled significa:

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima