¿Cuál es la diferencia entre probes readiness y liveness?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Readiness responde si este pod debe recibir tráfico ahora mismo; fallar lo saca de los endpoints del Service sin tocar el proceso, la respuesta correcta a un arranque lento, una caché en calentamiento o una dependencia temporalmente inalcanzable. Liveness responde si el proceso está atascado sin recuperación; fallar reinicia el contenedor, lo correcto solo para deadlocks y event loops colgados. Las startup probes retienen ambas hasta que una aplicación lenta ha arrancado. Una liveness probe que comprueba una base de datos convierte un parpadeo de la base de datos en una tormenta de reinicios en toda la flota.

Ejemplo

Un servicio de pagos define una startup probe con presupuesto de 2 minutos para el calentamiento de la JVM, una readiness probe en /ready que comprueba el pool de conexiones y el estado de un circuit breaker, y una liveness probe en /live que solo comprueba que el servidor HTTP responde. Cuando la base de datos hizo failover durante 20 segundos, los pods pasaron a no listos y el tráfico se pausó en lugar de que cada pod se reiniciara y perdiera sus cachés calientes.

Errores frecuentes

• Apuntar liveness a una comprobación de dependencia y amplificar caídas con reinicios.
• No tener readiness probe, de modo que un despliegue envía tráfico a pods aún arrancando.
• Poner el mismo timeout ajustado en todas las probes sin medir el tiempo real de arranque.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.