Saltar a contenido

Pods en CrashLoopBackOff, Pending e ImagePullBackOff

Troubleshooting a Service

La Regla de Oro: El Objeto Endpoints

Entender esto te ahorrará horas de frustración: Un Service no envía tráfico directamente a los Pods. Cuando creas un Service con un selector, Kubernetes crea automáticamente y en segundo plano un objeto llamado Endpoints (con el mismo nombre que el Service). Este objeto mantiene una lista actualizada de las IPs de los Pods que coinciden con las etiquetas del Service.

[!NOTE] Si el objeto Endpoints está vacío, tu Service está ciego y el tráfico caerá al vacío.

Metodología de Diagnóstico (Paso a Paso)

Sigue este orden exacto durante un examen o incidente real para encontrar la falla en menos de 2 minutos:

Paso 1: Validar la salud de los Pods

El Service solo enviará tráfico a los Pods que estén en estado Running y cuya condición sea Ready. Si la Readiness Probe del Pod está fallando, el Pod es eliminado de los Endpoints del Service inmediatamente.

  • Comando: kubectl get pods (Verifica que la columna READY diga 1/1, no 0/1).

Paso 2: Inspeccionar el Service y los Endpoints

Este es el comando definitivo para saber si el Service encontró a tus Pods.

  • Comando: kubectl describe svc <nombre-del-servicio>
  • Qué buscar: Mira la línea que dice Endpoints. Si dice <none> o está vacía, tienes un problema de etiquetas o Pods caídos. Si ves IPs allí, el problema podría estar en los puertos.

Paso 3: La trampa de las Etiquetas (Label Selectors)

El error más común en Kubernetes es un error tipográfico en las etiquetas. El selector del Service debe coincidir exactamente con las labels del Pod.

  • Comando: kubectl get pods --show-labels
  • Acción: Compara esas etiquetas con la sección Selector que viste en el describe del paso anterior. Un simple error entre app: nginx y app: ngnx romperá todo.

Paso 4: Verificación de Puertos (Port vs. TargetPort)

Si los Endpoints están correctos pero la conexión sigue fallando, revisa la declaración de puertos en el YAML del Service:

  • port: Es el puerto donde el Service está escuchando (el que usas para hacer la petición HTTP).
  • targetPort: Es el puerto donde tu aplicación dentro del contenedor está escuchando. ¡Debe coincidir con la configuración real de tu app!

1. Comandos Rápidos de Batalla

Objetivo Comando a ejecutar
Ver todos los endpoints del clúster kubectl get endpoints
Ver labels de todos los pods kubectl get pods --show-labels
Ver la IP virtual asignada al Service kubectl get svc