Lección 14: Proyecto final de diagnóstico de fallos
Llegaste a la última lección, y en ella unimos todo en una sola herramienta que usarás una y otra vez: un flujo de diagnóstico ordenado, un runbook. Cuando algo se rompe en el clúster, es tentador entrar en pánico y adivinar. En cambio, trabajamos como detectives: primero reunimos evidencia, solo de
El diagnóstico de fallos es como ser detective: no acusas a nadie antes de reunir evidencia. Primero ves quién parece sospechoso (get), lees el testimonio (describe y logs), y solo entonces decides quién es culpable y lo arreglas.
- Diagnóstico de fallos
- Un proceso ordenado para encontrar la causa de un fallo: reunir evidencia (get, describe, logs), formular una hipótesis, arreglar, y verificar que el problema desapareció, en lugar de adivinar.
- Runbook
- Una lista fija y repetible de pasos que sigues cuando aparece un fallo. Permite que todo el equipo diagnostique en el mismo orden y no se salte un paso crítico bajo presión.
- CrashLoopBackOff
- Un estado del Pod en el que el contenedor arranca, falla, y Kubernetes sigue reintentando con un retraso cada vez mayor entre intentos. La causa casi siempre está en el código o la configuración de la app: léela mediante logs --previous.
- ImagePullBackOff
- Un estado en el que Kubernetes no logró descargar la imagen del contenedor: un nombre o tag incorrecto, la imagen falta en el registro, o faltan credenciales. La razón aparece en los Events de describe.
- Pending
- Un estado en el que el Pod fue aceptado pero todavía no se programó en ningún nodo, generalmente porque no hay suficientes recursos libres (CPU/memoria), o ningún nodo cumple sus requisitos.
- Events
- Un registro breve de lo que Kubernetes intentó hacer con el Pod (programado, imagen descargada, iniciado, fallido). Aparece al final de kubectl describe pod y suele ser la primera pista de la causa.
