Kubernetes CrashLoopBackOff: diagnóstico seguro paso a paso

CrashLoopBackOff describe el ciclo, no la causa

El contenedor falla y Kubernetes espera antes de intentar iniciarlo otra vez. Ese retraso progresivo evita repetir reinicios sin pausa, pero el estado no explica por sí mismo qué hizo terminar al proceso. La causa puede estar en la aplicación, su configuración, una dependencia, una comprobación de salud o los límites de recursos.

Empieza por recoger evidencia de solo lectura. Sustituye los nombres entre corchetes por los valores de tu entorno y conserva el namespace correcto.

1. Identifica Pod, contenedor y namespace

kubectl get pods -n <namespace> -o wide
kubectl describe pod <pod> -n <namespace>

En la salida de describe, revisa el estado actual y el último estado terminado del contenedor: razón, código de salida, contador de reinicios y eventos recientes. Si el Pod tiene varios contenedores, identifica cuál está reiniciándose antes de interpretar sus logs.

2. Lee la ejecución anterior

kubectl logs <pod> -n <namespace> -c <contenedor> --previous

--previous solicita los logs de la instancia anterior del contenedor. Si el proceso alcanza a iniciar y luego termina, estos mensajes pueden mostrar el error que ya no aparece en la instancia actual. Si no hay logs, revisa eventos, imagen, comando de inicio, volúmenes y configuración: el proceso quizá no alcanzó a escribirlos.

Los logs y las salidas de describe pueden incluir nombres de usuario, rutas o valores sensibles. Anonimiza la información antes de compartirla; no publiques tokens, variables de entorno, nombres de clientes ni direcciones privadas.

3. Relaciona la evidencia con una hipótesis

• Reason: OOMKilled: compara uso, request y límite de memoria con el comportamiento de la aplicación. No aumentes el límite sin medir la capacidad del nodo y los demás contenedores.
• Código de salida distinto de cero: revisa el mensaje de error, argumentos, archivos montados, permisos y dependencias que necesita el proceso para iniciar.
• Eventos de probes fallidas: verifica ruta, puerto, esquema, tiempos de inicio y umbrales. Desactivar una probe puede ocultar la señal sin reparar la causa.
• El proceso termina sin error visible: comprueba si el comando del contenedor está pensado para permanecer activo y si la política de reinicio coincide con el tipo de carga.
• Problemas de imagen o montaje: distingue los errores de descarga o creación del contenedor de una aplicación que sí alcanzó a ejecutarse.

Kubernetes muestra los eventos del Pod y permite consultar los logs de una instancia anterior. La razón OOMKilled apunta a terminación por memoria; confirma los límites y el uso observado antes de cambiar recursos. Un mismo síntoma puede tener causas distintas, así que valida cada hipótesis contra la evidencia del entorno.

4. Cambia una cosa por vez y prepara la reversión

Antes de editar probes, recursos o comandos de inicio, guarda la versión aplicada y define qué señal demostrará que el cambio ayudó. Valida primero en un entorno controlado; en producción, acuerda ventana, respaldo y responsable. Observa reinicios y eventos después del cambio y conserva una forma conocida para volver a la configuración anterior.

Estos comandos son ejemplos de lectura: no se ejecutaron contra un clúster. Evita comenzar con borrado de Pods, reinicios de Deployment o aumentos de límites sin confirmar la causa y el impacto.

Qué puede demostrar esta revisión

El estado, los eventos y los logs ayudan a acotar por qué un contenedor termina; no prueban por sí solos la disponibilidad de toda la plataforma ni reemplazan métricas, trazas y pruebas de la aplicación. Para revisar un caso, comparte una descripción anonimizada del síntoma y del entorno, nunca accesos ni configuraciones privadas.