¿Qué son las probes de liveness, readiness y startup, y cuándo se usa cada una?

Question

IT Interview Practice · Accepted Answer

Las probes permiten al kubelet comprobar la salud de un contenedor y actuar según el resultado. Hay tres: **liveness** (¿está vivo, o hay que reiniciarlo?), **readiness** (¿está listo para recibir tráfico?) y **startup** (¿ha terminado ya de arrancar?). Cada una responde una pregunta distinta.

## Las tres probes de un vistazo

```text
LIVENESS   → "¿La app está atascada/en deadlock?"  FALLA → el kubelet REINICIA el contenedor
READINESS  → "¿Puede servir tráfico ahora mismo?"   FALLA → el Pod se saca de los endpoints del Service
                                                       (NO se reinicia)
STARTUP    → "¿Ha terminado el arranque lento?"      corre PRIMERO; mientras corre, liveness y
                                                readiness se posponen
```

## Readiness vs liveness: la distinción clave

```text
Readiness controla el TRÁFICO:
  → un Pod que falla readiness se saca del load-balancer del Service,
    pero sigue en ejecución (p. ej. está calentando una caché o una dependencia está caída)
Liveness controla la VIDA:
  → un Pod que falla liveness se MATA y se reinicia (está roto sin remedio)
Usar liveness cuando querías readiness provoca bucles de reinicio innecesarios.
```

## Definiciones de las probes

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports: [{ containerPort: 8080 }]

startupProbe:            # da tiempo a un arranque lento antes de que entren las demás
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = hasta 5 min para arrancar
        periodSeconds: 10

readinessProbe:          # controla el tráfico
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # reinicia si no está sano
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Mecanismos de las probes

```text
httpGet    → GET a una ruta; 2xx/3xx = pasa       (lo más común en apps web)
tcpSocket  → ¿podemos abrir una conexión TCP?      (para servicios no HTTP)
exec       → ejecuta un comando; exit 0 = pasa     (comprobaciones a medida)
grpc       → health check nativo de gRPC
Parámetros clave: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Por qué existen las startup probes

```text
Las apps de arranque lento (calentamiento de JVM, migraciones grandes) antes te obligaban a poner un
initialDelaySeconds enorme en liveness — lo que luego hacía lento detectar caídas reales.
La startupProbe arregla esto: protege el arranque lento, y SOLO después de que pase
comienzan liveness/readiness con sus tiempos normales (ajustados).
```

```bash
kubectl describe pod app     # ver fallos de probe y razones de reinicio en los eventos
kubectl get pod app          # la columna READY refleja readiness; RESTARTS refleja liveness
```

## Por qué es importante

Las health probes son la forma en que Kubernetes ofrece auto-recuperación y enrutamiento de tráfico seguro, así que entender los tres tipos y cuándo usar cada uno es conocimiento esencial de fiabilidad. La distinción crucial —una que tropieza a muchos ingenieros— es entre **readiness** y **liveness**: readiness controla el **tráfico** (un Pod que falla se saca del load-balancer del Service pero sigue en ejecución, ideal cuando está calentando o una dependencia está caída temporalmente), mientras que liveness controla la **vida** (un Pod que falla se mata y se reinicia, para cuando está en deadlock sin remedio). Confundir ambas —usar una liveness probe donde correspondía readiness— provoca bucles de reinicio innecesarios y caídas, así que saber qué pregunta responde cada probe es directamente práctico. La probe de **startup** resuelve un dolor histórico real: las apps de arranque lento antes forzaban `initialDelaySeconds` enormes en liveness (lo que retrasaba la detección de caídas genuinas), mientras que una startup probe protege la ventana de arranque y deja que liveness/readiness corran con tiempos ajustados y normales solo una vez que el arranque tiene éxito. Entender los mecanismos de probe (`httpGet`, `tcpSocket`, `exec`, `grpc`) y los parámetros de ajuste (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, etc.) te permite configurar las comprobaciones de salud correctamente en lugar de a ojo. Como las probes determinan directamente si los usuarios alcanzan Pods sanos y si los Pods rotos se recuperan automáticamente, acertar con ellas es fundamental para ejecutar workloads fiables y de grado producción en Kubernetes.

Las tres probes de un vistazo

Readiness vs liveness: la distinción clave

Definiciones de las probes

Mecanismos de las probes

Por qué existen las startup probes

Por qué es importante

Preguntas relacionadas