Un Pod puede estar en estado Running y aun así no estar disponible para recibir tráfico.

También puede estar ejecutando una aplicación completamente funcional y comenzar a reiniciarse porque un health check está mal configurado.

En Kubernetes existen tres tipos principales de probes:

1Startup
2Liveness
3Readiness

Aunque su configuración es similar, responden preguntas completamente diferentes.

 1Startup
 2   |
 3   v
 4¿La aplicación ya terminó de iniciar?
 5
 6Liveness
 7   |
 8   v
 9¿La aplicación sigue funcionando
10o necesita ser reiniciada?
11
12Readiness
13   |
14   v
15¿La aplicación está preparada
16para recibir tráfico?

Confundir estas responsabilidades puede transformar una falla pequeña en un incidente mucho mayor.

En este cuarto artículo de nuestra serie de Kubernetes Troubleshooting vamos a investigar:

• readiness probes;

• liveness probes;

• startup probes;

• HTTP, TCP, exec y gRPC probes;

• timeouts y thresholds;

• Pods Running pero NotReady;

• restart loops provocados por probes;

• aplicaciones que tardan demasiado en iniciar;

• dependencias externas en health checks;

• cascading failures;

• cómo diseñar probes que ayuden en lugar de empeorar un incidente.

Primero: las tres probes no hacen lo mismo

Esta es la diferencia más importante de todo el artículo.

 1                        Container
 2                           |
 3          +----------------+----------------+
 4          |                |                |
 5          v                v                v
 6       Startup          Liveness         Readiness
 7          |                |                |
 8   ¿Terminó de        ¿Sigue vivo?     ¿Puede recibir
 9     iniciar?                            tráfico?
10          |                |                |
11        FAIL             FAIL             FAIL
12          |                |                |
13          v                v                v
14       Restart          Restart       Remove from
15                                      normal Service
16                                         traffic

Una readiness failure no debería reiniciar el contenedor.

Una liveness failure sí puede provocar que el kubelet termine el contenedor y aplique su restart policy.

Una startup probe protege aplicaciones que necesitan tiempo adicional para iniciar.

1. Readiness probe

La readiness probe responde:

¿Este contenedor está preparado para recibir tráfico ahora?

Supongamos que tenemos tres Pods:

1                Service
2                   |
3          +--------+--------+
4          |        |        |
5          v        v        v
6        Pod A    Pod B    Pod C
7        Ready    Ready   NotReady

El tráfico normal del Service debe dirigirse hacia los endpoints considerados ready.

Pod C puede continuar:

1Running

pero no estar:

1Ready

Esto es completamente válido.

Un ejemplo de readiness

1readinessProbe:
2  httpGet:
3    path: /ready
4    port: 8080
5  initialDelaySeconds: 5
6  periodSeconds: 5
7  timeoutSeconds: 2
8  failureThreshold: 3

Conceptualmente:

 1GET /ready
 2    |
 3    +--- Success
 4    |       |
 5    |       v
 6    |     Ready
 7    |
 8    +--- Failure
 9            |
10            v
11         NotReady
12            |
13            v
14    No normal Service traffic

El proceso continúa ejecutándose.

Pod Running pero 0/1 Ready

Un escenario común:

1kubectl get pods -n production

muestra:

1NAME                    READY   STATUS    RESTARTS
2api-7bd95fcb85-rx7mw    0/1     Running   0

Esto nos dice algo importante:

1Container
2   |
3   +--- Running
4   |
5   +--- Not Ready

Comenzamos con:

1kubectl describe pod \
2  api-7bd95fcb85-rx7mw \
3  -n production

Busca Events como:

1Readiness probe failed:
2HTTP probe failed with statuscode: 503

o:

1dial tcp 10.244.2.15:8080:
2connect: connection refused

¿Qué está comprobando realmente la readiness probe?

Revisa el workload:

1kubectl get deployment api \
2  -n production \
3  -o yaml

Busca:

1readinessProbe:

Y responde:

1¿Path correcto?
2¿Port correcto?
3¿Protocol correcto?
4¿La aplicación ya escucha?
5¿El timeout es suficiente?
6¿La respuesta HTTP es válida?
7¿El endpoint depende de otros sistemas?

También podemos probar el endpoint manualmente.

Desde el Pod:

1kubectl exec \
2  -n production \
3  <pod> -- \
4  curl -v http://127.0.0.1:8080/ready

Si la imagen no contiene curl, podemos utilizar un debugging container o Pod.

Readiness y EndpointSlices

Cuando un Pod deja de estar ready, Kubernetes refleja este estado en los backends utilizados por Services.

Podemos investigarlo:

1kubectl get endpointslices \
2  -n production \
3  -l kubernetes.io/service-name=api-service \
4  -o yaml

Busca condiciones como:

1conditions:
2  ready: false

Esto conecta dos partes importantes de nuestra serie:

 1Readiness Probe
 2      |
 3      v
 4Pod NotReady
 5      |
 6      v
 7EndpointSlice condition changes
 8      |
 9      v
10Normal Service traffic stops

2. Liveness probe

La liveness probe responde una pregunta diferente:

¿La aplicación sigue suficientemente viva como para continuar ejecutándose?

Un ejemplo:

1livenessProbe:
2  httpGet:
3    path: /live
4    port: 8080
5  periodSeconds: 10
6  timeoutSeconds: 2
7  failureThreshold: 3

Si falla repetidamente hasta alcanzar failureThreshold:

 1Liveness fails
 2      |
 3      v
 4Failure threshold reached
 5      |
 6      v
 7kubelet stops container
 8      |
 9      v
10Restart policy applies
11      |
12      v
13Container starts again

Esto puede ser útil para aplicaciones que entran en estados irrecuperables, como determinados deadlocks.

Pero también puede ser peligroso.

Cuando liveness se convierte en el problema

Imaginemos que una aplicación está bajo carga elevada.

Normalmente:

1/ live -> 20 ms

Pero durante el pico:

1/live -> 1.5 seconds

Nuestra configuración tiene:

1timeoutSeconds: 1
2failureThreshold: 3

Entonces:

 1Traffic increases
 2      |
 3      v
 4Application slows
 5      |
 6      v
 7Liveness times out
 8      |
 9      v
10Pod restarted
11      |
12      v
13Less capacity
14      |
15      v
16Remaining Pods receive more traffic
17      |
18      v
19They become slower
20      |
21      v
22More liveness failures
23      |
24      v
25More restarts

Acabamos de crear una cascading failure.

La aplicación estaba degradada.

La configuración de health checks convirtió la degradación en una pérdida progresiva de capacidad.

3. Startup probe

La startup probe existe especialmente para aplicaciones que necesitan tiempo significativo para inicializarse.

Por ejemplo:

 1Container starts
 2      |
 3      v
 4Load configuration
 5      |
 6      v
 7Initialize runtime
 8      |
 9      v
10Warm caches
11      |
12      v
13Application ready

Esto podría tardar:

190 seconds

Si una liveness probe comienza demasiado pronto, Kubernetes podría matar el proceso mientras todavía está iniciando.

Sin startup probe

 1Container starts
 2      |
 3      v
 4Application starting...
 5      |
 6      v
 7Liveness begins
 8      |
 9      v
10FAIL
11      |
12      v
13Restart
14      |
15      v
16Application starting...
17      |
18      v
19FAIL

Resultado:

1CrashLoopBackOff

aunque la aplicación podría haber iniciado correctamente si hubiera tenido tiempo suficiente.

Con startup probe

1startupProbe:
2  httpGet:
3    path: /startup
4    port: 8080
5  periodSeconds: 10
6  failureThreshold: 30

Aquí tenemos aproximadamente:

110 seconds × 30 failures = 300 seconds

de ventana antes de considerar que startup falló.

Mientras la startup probe no haya tenido éxito:

1Startup probe
2      |
3      +--- checking
4      |
5Liveness disabled
6Readiness disabled

Una vez que startup pasa:

1Startup succeeds
2      |
3      +------------+
4      |            |
5      v            v
6  Liveness     Readiness
7   begins        begins

initialDelaySeconds vs startupProbe

Podríamos simplemente configurar:

1livenessProbe:
2  initialDelaySeconds: 120

pero una startup probe expresa mejor nuestra intención.

Con un delay fijo:

1Always wait 120 seconds

Con startupProbe:

 1Check startup
 2     |
 3     +--- ready after 20 seconds
 4     |         |
 5     |         v
 6     |     continue immediately
 7     |
 8     +--- still starting
 9               |
10               v
11            keep checking

Esto permite proteger aplicaciones lentas sin necesariamente esperar el máximo en cada inicio.

4. Investigar restart loops provocados por probes

Supongamos:

1kubectl get pods -n production

muestra:

1NAME                    READY   STATUS             RESTARTS
2api-6b8cff746c-r27ft    0/1     CrashLoopBackOff   8

No debemos asumir inmediatamente que la aplicación está haciendo crash por sí sola.

Ejecutamos:

1kubectl describe pod \
2  api-6b8cff746c-r27ft \
3  -n production

y encontramos:

1Warning  Unhealthy
2Liveness probe failed

Ahora nuestra hipótesis cambia.

Revisa:

1kubectl logs \
2  api-6b8cff746c-r27ft \
3  -n production \
4  --previous

y la configuración:

1kubectl get deployment api \
2  -n production \
3  -o yaml

Investiga la timeline

Queremos entender:

 1Container starts
 2       |
 3       v
 4When does probe start?
 5       |
 6       v
 7How long does app need?
 8       |
 9       v
10How often does probe run?
11       |
12       v
13How long until failure?
14       |
15       v
16Why does endpoint fail?

Una configuración como:

1livenessProbe:
2  httpGet:
3    path: /health
4    port: 8080
5  initialDelaySeconds: 3
6  periodSeconds: 2
7  timeoutSeconds: 1
8  failureThreshold: 2

puede ser extremadamente agresiva para determinadas aplicaciones.

5. Los parámetros que debemos entender

initialDelaySeconds

Tiempo antes de comenzar determinadas probes después de iniciar el contenedor.

1initialDelaySeconds: 10

No debería utilizarse como sustituto automático de una startup probe para workloads con tiempos de arranque variables.

periodSeconds

Frecuencia de ejecución.

1periodSeconds: 10

Una frecuencia demasiado agresiva puede generar overhead innecesario.

timeoutSeconds

Cuánto esperamos por el resultado de una probe.

1timeoutSeconds: 2

Un timeout demasiado pequeño puede generar falsos negativos durante períodos de carga.

failureThreshold

Número de fallas consecutivas necesarias para considerar que la probe falló.

1failureThreshold: 3

Con:

1periodSeconds = 10
2failureThreshold = 3

el fallo no ocurre simplemente después de exactamente 30 segundos en todos los casos, pero esos valores nos ayudan a entender la tolerancia aproximada de la configuración.

successThreshold

Número de éxitos consecutivos requeridos para volver al estado exitoso.

Para readiness puede ser mayor que uno.

Para liveness y startup debe permanecer en:

11

6. HTTP probes

Una HTTP probe puede verse así:

1readinessProbe:
2  httpGet:
3    path: /ready
4    port: 8080
5    scheme: HTTP

Es útil cuando nuestra aplicación expone health endpoints específicos.

Podemos reproducir la comprobación:

1curl -v http://<pod-ip>:8080/ready

Investiga:

1HTTP status
2response time
3connection errors
4TLS
5redirect behavior
6application logs

7. TCP probes

Una TCP probe comprueba si puede establecerse una conexión al puerto.

1livenessProbe:
2  tcpSocket:
3    port: 8080

Conceptualmente:

1Can kubelet establish TCP connection?
2             |
3        +----+----+
4        |         |
5       YES        NO

Pero esto no significa necesariamente que la aplicación esté funcionando correctamente a nivel lógico.

Un proceso puede aceptar TCP:

1TCP connection -> OK

pero estar devolviendo:

1HTTP 500

a todas las peticiones.

Por eso debemos elegir la probe según lo que realmente queremos comprobar.

8. Exec probes

También podemos ejecutar un comando dentro del contenedor:

1livenessProbe:
2  exec:
3    command:
4      - /bin/sh
5      - -c
6      - test -f /tmp/healthy

Esto permite comprobaciones específicas del proceso.

Pero tiene trade-offs.

Cada ejecución requiere ejecutar procesos dentro del contenedor, por lo que probes exec demasiado frecuentes pueden generar overhead, especialmente en clusters densos.

Utilízalas cuando realmente aporten valor.

9. gRPC probes

Kubernetes también soporta probes nativas para workloads gRPC.

Por ejemplo:

1livenessProbe:
2  grpc:
3    port: 50051
4  initialDelaySeconds: 10

Esto evita tener que crear obligatoriamente un endpoint HTTP únicamente para comprobar un servicio gRPC.

Sin embargo, existen diferencias de configuración respecto a HTTP/TCP probes.

Por ejemplo, las probes gRPC no utilizan named ports de la misma manera que HTTP/TCP.

Siempre debemos validar la configuración correspondiente al protocolo utilizado.

10. ¿Debe liveness comprobar la base de datos?

Este es uno de los errores de diseño más importantes.

Supongamos que:

1/live
2  |
3  +--- application
4  +--- PostgreSQL
5  +--- Redis
6  +--- payment API

Ahora PostgreSQL tiene un incidente.

 1PostgreSQL unavailable
 2       |
 3       v
 4/live fails
 5       |
 6       v
 7Every application Pod
 8fails liveness
 9       |
10       v
11Every Pod restarts
12       |
13       v
14Application capacity collapses

Reiniciar los Pods no repara PostgreSQL.

Estamos utilizando liveness para reaccionar ante una dependencia externa que el restart del proceso no puede solucionar.

Una mejor separación

Podríamos diseñar:

1/live
2  |
3  +--- Is my process internally healthy?
4
5/ready
6  |
7  +--- Can I currently serve useful traffic?

Por ejemplo:

 1Database unavailable
 2       |
 3       v
 4Readiness fails
 5       |
 6       v
 7Pod removed from traffic
 8       |
 9       v
10Container remains alive

Pero incluso aquí debemos ser cuidadosos.

11. El peligro de incluir todas las dependencias en readiness

Supongamos que tenemos:

1API
2 |
3 +-- PostgreSQL
4 +-- Redis
5 +-- External Payment API

y readiness requiere que las tres estén disponibles.

El Payment API tiene un pequeño incidente.

 1Payment API down
 2      |
 3      v
 4Every API Pod becomes NotReady
 5      |
 6      v
 7Service has zero ready backends
 8      |
 9      v
10Entire API unavailable

Pero quizá:

1GET /products
2GET /profile
3GET /orders

podrían continuar funcionando.

Al diseñar readiness debemos preguntarnos:

¿Esta dependencia realmente hace que todo el Pod sea incapaz de servir tráfico útil?

La respuesta depende de la arquitectura de la aplicación.

12. Probes deben ser baratas

Un health endpoint no debería ejecutar una consulta costosa cada pocos segundos.

Evita algo como:

 1/readiness
 2    |
 3    v
 4Complex DB query
 5    |
 6    v
 7Multiple downstream calls
 8    |
 9    v
10Storage operation

multiplicado por:

1500 Pods
2×
3probe every 5 seconds

Podemos terminar creando tráfico significativo simplemente para comprobar la salud del sistema.

Una buena probe debería normalmente ser:

1fast
2cheap
3predictable
4purpose-specific

13. Observar métricas de probes

Los Events son un excelente punto de partida:

1kubectl get events \
2  -n production \
3  --sort-by='.lastTimestamp'

Busca:

1Unhealthy
2Readiness probe failed
3Liveness probe failed
4Startup probe failed

Pero los Events no sustituyen métricas históricas.

Queremos correlacionar:

 1Probe failures
 2      +
 3Restart count
 4      +
 5CPU
 6      +
 7Memory
 8      +
 9Latency
10      +
11Traffic
12      +
13Deployment

Por ejemplo:

110:00 Deployment
210:03 Traffic increases
310:05 CPU saturation
410:06 Liveness failures
510:07 Restarts increase
610:08 Available replicas decrease
710:09 5xx spike

Eso cuenta una historia mucho más completa.

14. Logs

Cuando una probe falla:

1kubectl logs <pod> \
2  -n production

y si el contenedor reinició:

1kubectl logs <pod> \
2  -n production \
3  --previous

Correlaciona el timestamp del Event con los logs de aplicación.

Podemos descubrir:

1probe timeout
2      |
3      v
4same timestamp
5      |
6      v
7long GC pause

o:

1readiness 503
2      |
3      v
4connection pool exhausted

o:

1startup failure
2      |
3      v
4database migration still running

15. Metrics + traces

Las probes nos dicen si una instancia está disponible.

No necesariamente nos dicen por qué está degradada.

Supongamos:

1Readiness failures increasing

y las métricas muestran:

1CPU normal
2Memory normal
3Latency high

Un trace podría mostrar:

1API                    20 ms
2 |
3 +-- Inventory         15 ms
4 |
5 +-- Database        4.2 sec

Ahora sabemos qué dependencia está degradando la aplicación.

Health checks son una señal.

Logs, métricas y traces proporcionan contexto.

16. Rolling updates y readiness

Readiness es especialmente importante durante deployments.

 1Old Pods
 2   |
 3   +--- Ready
 4
 5New Pod starts
 6   |
 7   v
 8NotReady
 9   |
10   v
11Initialize
12   |
13   v
14Ready
15   |
16   v
17Receives traffic

Sin una readiness probe útil, Kubernetes puede considerar disponible una aplicación antes de que realmente esté preparada para procesar requests correctamente.

Esto puede provocar errores únicamente durante deployments.

17. Readiness Gates

En escenarios más avanzados Kubernetes permite añadir condiciones adicionales a la evaluación de readiness mediante:

1readinessGates:

Conceptualmente:

1Containers Ready
2       +
3Custom condition Ready
4       |
5       v
6Pod Ready

Esto permite integrar señales externas o controllers dentro de la decisión de readiness.

No es necesario para la mayoría de workloads, pero puede ser útil cuando la disponibilidad depende de algo que una probe dentro del contenedor no representa adecuadamente.

18. Cuando una probe falla solo en un nodo

Supongamos:

1node-01
2  Pods -> probes OK
3
4node-02
5  Pods -> probes FAIL

Ahora debemos considerar que quizá la aplicación no es la causa.

Compara:

1kubectl get pods \
2  -n production \
3  -o wide

Después:

1kubectl describe node node-02

Posibles causas:

1node CPU saturation
2networking issue
3CNI issue
4kubelet problem
5disk pressure
6packet loss

El blast radius ayuda a identificar la capa.

19. Qué revisar en kubectl describe

Durante troubleshooting:

1kubectl describe pod <pod> \
2  -n <namespace>

revisa:

1State
2Last State
3Ready
4Restart Count
5Conditions
6Liveness
7Readiness
8Startup
9Events

También:

1kubectl get pod <pod> \
2  -n <namespace> \
3  -o yaml

permite inspeccionar la configuración completa de las probes.

20. Un diseño práctico

Una configuración podría verse así:

 1startupProbe:
 2  httpGet:
 3    path: /startup
 4    port: 8080
 5  periodSeconds: 5
 6  failureThreshold: 30
 7
 8livenessProbe:
 9  httpGet:
10    path: /live
11    port: 8080
12  periodSeconds: 10
13  timeoutSeconds: 2
14  failureThreshold: 3
15
16readinessProbe:
17  httpGet:
18    path: /ready
19    port: 8080
20  periodSeconds: 5
21  timeoutSeconds: 2
22  failureThreshold: 3

Pero estos valores no son una receta universal.

Deben elegirse utilizando datos reales sobre:

1startup time
2normal response time
3load behavior
4recovery time
5dependency behavior
6traffic patterns

Copiar una configuración de otro servicio puede ser peor que no entender el problema.

Troubleshooting flow

Podemos resumir el proceso:

 1                 Pod problem
 2                     |
 3                     v
 4            Is container Running?
 5                     |
 6                     v
 7               Is Pod Ready?
 8                     |
 9          +----------+----------+
10          |                     |
11         NO                    YES
12          |                     |
13          v                     v
14   Readiness Events       Restarting?
15          |                     |
16          v                     v
17 Probe endpoint works?    Liveness / Startup?
18          |                     |
19          v                     v
20 Path / port / timeout    Probe timing
21 dependency / overload    startup duration
22          |                     |
23          +----------+----------+
24                     |
25                     v
26           Metrics + Logs + Events
27                     |
28                     v
29              Check dependencies
30                     |
31                     v
32                Root cause
33                     |
34                     v
35                  Change
36                     |
37                     v
38                 Validate

Command reference

 1# Pod state
 2kubectl get pods \
 3  -n <namespace>
 4
 5kubectl get pods \
 6  -n <namespace> \
 7  -o wide
 8
 9# Pod details and probe Events
10kubectl describe pod <pod> \
11  -n <namespace>
12
13# Full configuration
14kubectl get pod <pod> \
15  -n <namespace> \
16  -o yaml
17
18kubectl get deployment <deployment> \
19  -n <namespace> \
20  -o yaml
21
22# Logs
23kubectl logs <pod> \
24  -n <namespace>
25
26kubectl logs <pod> \
27  -n <namespace> \
28  --previous
29
30# Events
31kubectl get events \
32  -n <namespace> \
33  --sort-by='.lastTimestamp'
34
35# EndpointSlices
36kubectl get endpointslices \
37  -n <namespace> \
38  -l kubernetes.io/service-name=<service> \
39  -o yaml
40
41# Metrics
42kubectl top pods \
43  -n <namespace>
44
45kubectl top pod <pod> \
46  -n <namespace> \
47  --containers
48
49# Deployment history
50kubectl rollout history \
51  deployment/<deployment> \
52  -n <namespace>
53
54# Test endpoint
55curl -v http://<pod-ip>:<port>/ready
56curl -v http://<pod-ip>:<port>/live
57
58# Debug when the image lacks tools
59kubectl debug <pod> \
60  -n <namespace> \
61  -it \
62  --image=ubuntu

Qué no hacer

No respondas automáticamente:

1Readiness failing
2       |
3       v
4Restart Pod

Ni:

1Liveness failing
2       |
3       v
4Increase timeout

Ni:

1Slow startup
2       |
3       v
4Set initialDelaySeconds = 300

Primero debemos entender qué ocurre.

 1Failure
 2   |
 3   v
 4Understand probe purpose
 5   |
 6   v
 7Reproduce probe
 8   |
 9   v
10Correlate Events
11   |
12   v
13Check metrics + logs
14   |
15   v
16Identify application/dependency issue
17   |
18   v
19Adjust probe or application
20   |
21   v
22Validate under real load

Conclusión

Las probes no son simplemente health checks.

Son mecanismos que cambian el comportamiento del cluster.

 1Readiness failure
 2       |
 3       v
 4Traffic changes
 5
 6Liveness failure
 7       |
 8       v
 9Container lifecycle changes
10
11Startup failure
12       |
13       v
14Container lifecycle changes

Por eso una probe incorrecta puede ser más peligrosa que no tener una probe bien entendida.

El objetivo es que cada probe responda una pregunta específica:

1Startup:
2¿terminó de iniciar?
3
4Liveness:
5¿reiniciar este proceso puede recuperarlo?
6
7Readiness:
8¿puede esta instancia recibir tráfico útil ahora?

Y antes de agregar una dependencia a una probe, debemos preguntarnos:

¿Qué acción ejecutará Kubernetes cuando esta dependencia falle, y esa acción realmente ayuda?

Esta pregunta evita muchos health checks peligrosos.

En el siguiente artículo investigaremos Kubernetes Nodes:

• NotReady;

• MemoryPressure;

• DiskPressure;

• PIDPressure;

• kubelet;

• container runtime;

• node networking;

• Pods concentrando fallas en un solo nodo;

• cómo determinar cuándo el problema dejó de ser del workload y pasó a ser del host.