Un pod está atascado en CrashLoopBackOff. ¿Cómo lo triagas?

Empieza con kubectl describe pod para ver los eventos y el último código de salida, y luego kubectl logs con --previous para leer la salida del contenedor que reventó. El código 137 suele significar una muerte por falta de memoria, así que revisa los límites de memoria; salida 1 o 2 suele significar que la app falló al arrancar, a menudo por una configuración o un secreto que falta o una dependencia inalcanzable. Confirma que la etiqueta de la imagen existe de verdad y comprueba si una liveness probe agresiva está causando el bucle.

kubectl describe pod primero, porque la sección de eventos normalmente te dice de entrada si es un fallo al descargar la imagen, un secreto que falta o una muerte por falta de memoria, y te da el último estado de terminación con el código de salida. Luego kubectl logs con --previous, ya que el contenedor en ejecución ya ha sido reemplazado y sus logs se han ido. La salida 137 es un SIGKILL y nueve de cada diez veces es el límite de memoria, así que comparo el límite con el uso real en vez de adivinar. La salida 1 con una traza de pila es un fallo de arranque de la aplicación, normalmente de configuración. También reviso la liveness probe, porque he visto un servicio Java perfectamente sano entrar en bucle de reinicios simplemente porque necesitaba 40 segundos para calentar y la probe le daba 10. Para depurar con calma escalo el deployment, entro con exec en una copia con el comando sobrescrito a sleep, y lo reproduzco ahí en lugar de pelearme con el temporizador de reinicios.