Readiness, liveness y startup probes: cada señal tiene un trabajo

Una probe no es un chequeo genérico de “todo está bien”

Kubernetes ofrece tres señales para responder preguntas distintas sobre un contenedor: ¿ya terminó de iniciar?, ¿puede recibir solicitudes ahora? y ¿quedó en un estado del que el proceso debe recuperarse mediante reinicio? Diseñar una única ruta de salud y asignarla a las tres señales puede hacer que el clúster retire tráfico o reinicie procesos por razones equivocadas.

La documentación oficial explica el comportamiento deliveness, readiness y startup probes. La distinción clave es la consecuencia de cada respuesta, no el nombre del endpoint que se consulta.

Qué indica cada probe

Readiness y liveness pueden ejecutarse durante el mismo ciclo, pero no son equivalentes. Una lectura negativa de readiness mantiene vivo el proceso y lo retira temporalmente del conjunto de destinos de servicio; una falla de liveness puede provocar su reinicio. Startup sirve para aplicaciones que necesitan más tiempo inicial: mientras no haya tenido éxito, las otras dos no empiezan.

Diseña la señal según la acción que debe disparar

Startup: dale tiempo al inicio real

Usa esta señal cuando el proceso necesita completar una inicialización lenta antes de poder responder a las otras comprobaciones. El margen debe cubrir el peor tiempo de inicio que tu equipo haya observado y aceptado, no una cifra copiada sin medir. Si la probe nunca tiene éxito, Kubernetes también terminará el contenedor de acuerdo con su política.

Readiness: controla disponibilidad para tráfico

La probe debe expresar si la instancia puede servir una solicitud según el contrato de la aplicación. Puede ser útil durante carga inicial, recarga de configuración o una condición temporal de saturación. Piensa con cuidado en dependencias externas: si cada Pod deja de estar listo ante una falla compartida, quizá retires toda la capacidad al mismo tiempo. La señal debe describir la capacidad real de atender, no acumular todas las comprobaciones imaginables.

Liveness: reinicia solo si el proceso no puede recuperarse

La documentación de Kubernetes presenta liveness como una forma de detectar estados como un bloqueo interno. No la conviertas en una prueba de conectividad hacia cada base de datos o API dependiente: una interrupción externa podría causar reinicios repetidos, aumentar carga y agravar el incidente. Un proceso puede seguir vivo aunque temporalmente no admita tráfico; para esa situación está readiness.

Fragmento ilustrativo tomado de la guía oficial

Este fragmento muestra cómo una startup probe retrasa liveness mientras el proceso inicia. El puerto nombrado debe existir en la definición del contenedor; la ruta, el puerto y los umbrales del ejemplo no son valores recomendados para otra aplicación.

ports:
  - name: liveness-port
    containerPort: 8080
livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10
startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

Los nombres de puerto, ruta y valores provienen del ejemplo publicado por Kubernetes. El bloque es una referencia didáctica; no se ejecutó ni validó en este artículo contra una aplicación o clúster. La guía señala que, en ese ejemplo, el producto de umbral y periodo define la ventana máxima de inicio. No conviertas esa ventana en un valor universal.

Qué revisar antes de habilitarlas

• Escribe por separado qué significa “iniciar”, “poder recibir tráfico” y “estar bloqueado” para esta aplicación.
• Haz que los chequeos sean baratos y previsibles; una ruta de salud lenta puede convertirse en carga.
• Alinea intervalos, timeout y umbrales con el tiempo de respuesta y recuperación observados, no con valores por defecto asumidos.
• Observa eventos, reinicios, Pods listos y solicitudes fallidas en un entorno de validación antes de usar las señales en producción.
• Prueba qué ocurre bajo carga y durante fallas de dependencias; verifica que la respuesta sea degradar o retirar tráfico cuando corresponde, no reiniciar en cascada.
• Documenta cómo revertir la configuración y quién decide si un umbral nuevo queda aceptado.

Lo que estas probes no demuestran

Una probe correcta no es por sí sola monitoreo integral, alerta de negocio ni garantía de disponibilidad de extremo a extremo. Readiness informa al plano de control sobre la aptitud del Pod para tráfico de Service; no mide la experiencia completa del cliente. Liveness recupera ciertos estados de proceso, pero un reinicio no corrige un defecto de código, falta de recursos o una dependencia indisponible. Acompaña estas señales con métricas, logs, alertas y pruebas de recorrido acordes al servicio.