Un Pod muestra CrashLoopBackOff. ¿Qué significa y cómo empiezas a depurar?
Opciones
- El contenedor falla y se reinicia sin parar; lee
logs --previous(Opción correcta) - El nodo se quedó sin disco y no puede arrancar pods
- La imagen aún se está descargando del registry
- El Service no tiene dirección IP, así que el Pod no arranca
Respuesta
El contenedor arranca y falla sin parar; Kubernetes reintenta con esperas crecientes. Revisa kubectl logs --previous y kubectl describe pod
Por qué
CrashLoopBackOff = el contenedor arranca, termina con un error, Kubernetes lo reinicia y espera más tras cada fallo.
Causas típicas: error de la aplicación al arrancar (mala configuración, variable de entorno que falta), no conecta con la base de datos, comando incorrecto, falta de memoria (OOMKilled) o un liveness probe que falla.
Pasos: kubectl logs <pod> --previous (salida de la ejecución caída), kubectl describe pod <pod> (eventos y código de salida), revisa los valores de ConfigMap y Secret y los límites de recursos.
Recuerda
CrashLoopBackOff: lee logs --previous y describe.