Tu Pod está en estado Running: ¿por qué está caída la aplicación?

Es una de las situaciones más engañosas al diagnosticar Kubernetes y también una de las más comunes:

El Pod está Running.
El Pod está Ready.
No hay reinicios.
Y aun así, la aplicación está caída.

Ejecutas kubectl get pods y Kubernetes responde:

NAME                              READY   STATUS    RESTARTS
payments-api-7d8f9c6d8f-x2k4p   1/1     Running   0

Todo parece sano, pero los usuarios reciben 502 Bad Gateway. Entonces, ¿qué está pasando?

El problema de mirar solo los Pods

kubectl get pods es útil, pero también puede dar una falsa sensación de seguridad. Que un Pod esté Running no significa necesariamente que la aplicación sea accesible.

Una solicitud puede recorrer varios componentes antes de llegar al contenedor:

Usuario
  ↓
DNS
  ↓
Balanceador de carga
  ↓
Ingress
  ↓
Service
  ↓
Endpoints / EndpointSlices
  ↓
Pod
  ↓
Contenedor

Si alguna capa está mal configurada, la aplicación puede quedar inaccesible mientras el Pod sigue pareciendo sano. Por eso, al diagnosticar, la primera pregunta no debería ser “¿mi Pod está corriendo?”, sino: “¿dónde se detiene la solicitud?”

Empieza por el Service

Supongamos que la aplicación tiene un Service de Kubernetes:

kubectl get svc payments-api

Podrías ver algo como esto:

NAME           TYPE        CLUSTER-IP      PORT(S)
payments-api   ClusterIP   10.100.42.15    80/TCP

El Service existe. Bien. Pero eso no significa que tenga backends. Revisa sus endpoints:

kubectl get endpoints payments-api

Un resultado sano podría verse así:

NAME           ENDPOINTS
payments-api   10.0.12.45:8080,10.0.18.21:8080

¿Y si aparece esto?

NAME           ENDPOINTS
payments-api   <none>

El Service existe. Los Pods pueden existir. Pero el Service no tiene endpoints: no tiene ningún backend al que enviar tráfico.

Cómo puede ocurrir

Una causa común es que las etiquetas de los Pods no coincidan con el selector del Service. Por ejemplo, el Pod podría tener:

metadata:
  labels:
    app: payments

Mientras que el Service busca:

spec:
  selector:
    app: payment-api

A primera vista los valores se parecen, pero para Kubernetes son distintos. El selector no encuentra el Pod y el Service queda sin endpoints ni backends; el resultado visible puede ser un 502 o un 503.

Un proceso de diagnóstico por capas

1. Revisa los Pods

kubectl get pods -o wide

Observa STATUS, READY, RESTARTS y en qué nodo corre cada Pod. Si los Pods no están sanos, investígalos primero.

2. Revisa el Service

kubectl get svc
kubectl describe svc payments-api

Confirma que exista, que exponga el puerto esperado y que su tipo sea el correcto. Presta especial atención al selector.

3. Revisa los endpoints

kubectl get endpoints payments-api
kubectl get endpointslices \
  -l kubernetes.io/service-name=payments-api

Si no hay endpoints, no reinicies el Pod todavía. La pregunta más concreta es: ¿por qué el Service no está seleccionando mis Pods? Revisa sus etiquetas y compáralas con el selector:

kubectl get pods --show-labels
kubectl describe svc payments-api

4. Prueba el Service desde dentro del clúster

Si hay endpoints, prueba la aplicación desde la red interna del clúster. Por ejemplo, puedes iniciar un Pod temporal con curl, si la política de tu entorno lo permite:

kubectl run tmp-debug \
  --rm -it \
  --image=curlimages/curl \
  -- sh

Desde esa shell, prueba el nombre DNS del Service:

curl -i http://payments-api

Esto ayuda a separar un problema de red interno de uno en Ingress o en el balanceador externo. Si el Service responde desde dentro pero falla la solicitud externa, el problema probablemente está más arriba en el recorrido: revisa Ingress, balanceador, DNS y TLS.

El modelo mental importante

El diagnóstico mejora cuando dejas de tratar el clúster como un solo sistema y sigues las capas:

Clientes externos / DNS
          ↓
   Balanceador de carga
          ↓
       Ingress
          ↓
       Service
          ↓
 Endpoints / EndpointSlices
          ↓
          Pod
          ↓
      Contenedor

Cuando algo falla, tu trabajo no es adivinar: es identificar qué capa dejó de comportarse como se esperaba.

Un ciclo de diagnóstico en cinco pasos

1. Observa. ¿Qué está fallando exactamente? Empieza por la evidencia, no por una solución.
2. Ubica la capa. ¿El problema está en la aplicación, el Pod, Service, Ingress, balanceador, DNS, nodo o red?
3. Formula una hipótesis. Por ejemplo: “El Service no tiene endpoints porque su selector no coincide con las etiquetas del Pod”.
4. Prueba la hipótesis. Usa el comando o experimento más pequeño que pueda confirmarla o descartarla: kubectl get endpoints payments-api.
5. Verifica la corrección. No te detengas después de aplicar el cambio; confirma que el recorrido de la solicitud volvió a funcionar.

La lección

Que un Pod de Kubernetes esté Running no es una comprobación de salud de la aplicación. Es solo una pieza de información.

En vez de preguntar “¿qué le pasa a mi Pod?”, pregunta: “¿dónde se detiene la solicitud?” Esa pregunta suele acercarte a la respuesta mucho más rápido.

Sobre la guía de Kubernetes

Estoy trabajando en una referencia práctica: Kubernetes Troubleshooting Field Guide: 50 Production Incidents and How to Diagnose Them. La idea es documentar incidentes reales con una estructura consistente: síntomas → investigación → evidencia → diagnóstico → resolución → prevención.

El objetivo no es crear otra referencia llena de comandos para memorizar, sino una guía para responder: “Producción está fallando, ¿qué reviso ahora?”.

Si trabajas con Kubernetes, ¿qué problema te ha hecho perder más tiempo?

Referencias técnicas

• Kubernetes: Services — cómo seleccionan Pods y dirigen tráfico.
• Kubernetes: EndpointSlices — representación de los backends asociados a un Service.
• Kubernetes: depurar un Service — revisar selectores, endpoints y conectividad.