¿Cuál es la diferencia entre una liveness probe y una readiness probe, y en qué se equivoca la gente?

Una readiness probe controla si un pod recibe tráfico; una liveness probe controla si el kubelet reinicia el contenedor. El error clásico es apuntar la liveness a una dependencia aguas abajo, de forma que una base de datos lenta reinicia todos los pods en bucle y convierte una caída parcial en una total. La liveness solo debería comprobar que el proceso está vivo y no bloqueado. Usa una startup probe para aplicaciones que arrancan despacio.

La readiness decide si el pod está en los endpoints del servicio, la liveness decide si el kubelet mata y reinicia el contenedor. El fallo que he visto de verdad es un equipo que hizo que el endpoint de liveness comprobara la base de datos. La base de datos se puso lenta, todos los pods fallaron la liveness más o menos a la vez, el deployment entero entró en bucle de reinicios, y en vez de lecturas degradadas nos quedamos sin nada, más una avalancha de conexiones frías al volver. La liveness debería ser casi aburrida: ¿puede el proceso servir un handler trivial, no está atascado el bucle de eventos? Todo lo relativo a dependencias pertenece a la readiness, porque sacar un pod de la rotación es reversible y barato. La otra cosa que siempre reviso son los tiempos. Si la app tarda 45 segundos en calentar cachés, o usas una startup probe o ajustas initialDelaySeconds y failureThreshold para que encajen, porque si no has construido una máquina que nunca puede terminar de arrancar.