Un pod en Kubernetes queda en CrashLoopBackOff justo después de un deploy. ¿Cómo lo diagnosticás paso a paso?

CrashLoopBackOff no es la causa, es un síntoma. El contenedor arranca, termina, y kubelet lo reinicia con un backoff exponencial de hasta 5 minutos. Lo que hay que encontrar es por qué termina.

Pasos:

• kubectl describe pod <pod>

  : revisar Last State, Reason, Exit Code y los eventos al final.

• kubectl logs <pod> --previous

  : muestra los logs del contenedor que murió, no del que está arrancando.
• Interpretar el exit code:
  
  • 137 / OOMKilled: supera el límite de memoria. Hay que ajustar los limits o revisar una fuga.
  • 1 u otro código de la app: error de la aplicación, como una variable faltante, una conexión a la base rechazada o una migración fallida.
  • 126 / 127: comando no ejecutable o no encontrado, por ejemplo un ENTRYPOINT mal escrito o una imagen de otra arquitectura.
  • 0: el proceso termina "bien" pero no queda en primer plano.
• Revisar las probes: una liveness con path, puerto o initialDelay incorrectos mata un contenedor sano. En los eventos aparece como "Liveness probe failed".
• Revisar las dependencias: ConfigMaps y Secrets referenciados, volúmenes, permisos (runAsNonRoot, filesystem de solo lectura).

• kubectl get events --sort-by=.lastTimestamp

  para tener contexto del namespace.

Si el contenedor muere demasiado rápido para inspeccionarlo, se puede usar

kubectl debug

con una copia del pod y otro comando. Como fue tras un deploy, comparo con la versión anterior (

kubectl rollout history

). Si hay impacto, hago

kubectl rollout undo

y después investigo con calma.

Mirar solo kubectl logs sin --previous y no ver nada útil. Ignorar el exit code y las probes, o borrar el pod esperando que se arregle solo.