Kubernetes: three probes, three different questions
Startup, readiness and liveness: keeping a health check from amplifying an incident.
A running container does not guarantee that an application can receive traffic. Nor does every error mean that restarting will help. Kubernetes probes answer different questions and should be designed alongside the application.
Startup: has initialization finished?
A startup probe gives an application time to initialize. Until it succeeds, Kubernetes does not run that container’s readiness or liveness probes. This helps distinguish a legitimately slow startup from a stuck process.
Readiness: can it receive traffic?
When readiness fails, the container keeps running, but the pod is not ready to receive traffic through Services selecting ready pods. This temporarily removes an instance without restarting it.
The endpoint should represent the ability to serve requests. Making it depend indiscriminately on every external service could cause a shared dependency to remove all replicas at once.
Liveness: would a restart help?
A failing liveness probe can restart the container after its configured threshold. Its criterion needs to be more specific than something responding slowly. Restarting every instance will not repair an unavailable database and may add load during recovery.
Rehearse a rollout
The GitOps case study proposes three application variants: healthy, slow to start and failing readiness. I would observe which pods receive traffic, how long the rollout takes and what happens when restoring the previous version.
Timing and thresholds should come from application tests. Copying initialDelaySeconds from another service without measuring startup turns an arbitrary value into an operational decision.
Before closing the change
Check each endpoint’s behavior, resource limits and the rollback procedure. Also check whether the new deployment depends on an incompatible migration. Returning to an earlier image does not automatically undo data changes.
The lab’s goal is to explain failure and recovery with evidence before promising availability or uninterrupted deployments.
Reference
Un contenedor ejecutándose no garantiza que una aplicación pueda recibir tráfico. Tampoco todo error implica que reiniciar sea la solución. Las probes de Kubernetes responden preguntas diferentes y conviene diseñarlas junto a la aplicación.
Startup: ¿terminó de arrancar?
Una startup probe permite dar tiempo a una aplicación que necesita inicializarse. Mientras no tiene éxito, Kubernetes no ejecuta sus probes de readiness ni de liveness. Es útil cuando un arranque legítimamente lento no debería confundirse con un bloqueo del proceso.
Readiness: ¿puede recibir tráfico?
Si readiness falla, el contenedor sigue ejecutándose, pero el pod deja de estar listo para recibir tráfico mediante los Services que seleccionan pods preparados. Eso permite apartar temporalmente una instancia sin reiniciarla.
El endpoint debería representar la capacidad de servir solicitudes. Hacerlo depender indiscriminadamente de todos los servicios externos puede provocar que una dependencia compartida retire a todas las réplicas a la vez.
Liveness: ¿tiene sentido reiniciar?
Una probe de liveness fallida puede provocar el reinicio del contenedor después del umbral configurado. Por eso necesita un criterio más específico que “algo respondió lento”. Un reinicio masivo no arregla una base de datos caída y puede añadir carga durante la recuperación.
Diseñar un ensayo de rollout
Para el caso GitOps propongo tres variantes de una aplicación: sana, de arranque lento y con readiness fallida. Observaría qué pods reciben tráfico, cuánto dura el rollout y qué sucede al recuperar la versión anterior.
Los tiempos y umbrales deben salir de pruebas de la aplicación. Copiar initialDelaySeconds de otro servicio sin medir su arranque convierte un valor arbitrario en una decisión operativa.
Lo que comprobaría antes de cerrar el cambio
El comportamiento de cada endpoint, los límites de recursos y el procedimiento de rollback. También revisaría que un nuevo despliegue no dependa de una migración incompatible. Volver a una imagen anterior no revierte automáticamente los cambios de datos.
La meta del laboratorio es explicar un fallo y su recuperación con evidencia, antes de prometer disponibilidad o despliegues sin interrupciones.