Las sondas de Kubernetes no garantizan que tu aplicacion funcione, solo que este viva

El panel de control de Kubernetes muestra verde en todas las replica, pero en el otro lado del cable nadie puede finalizar una compra. Si en las ultimas horas has visto un despliegue exitoso seguido de fallos silenciosos en la logica de negocio, no es una coincidencia. Es el error fundamental de confundir lo que Kubernetes puede verificar con lo que realmente importa para el usuario.

El contrato de la orquestacion

Las sondas de Kubernetes tienen un trabajo muy especifico y limitado. Una sonda de liveness comprueba si el proceso se ha quedado colgado o necesita un reinicio. La de readiness determina si el contenedor esta listo para recibir trafico HTTP o TCP. La de startup espera a que la inicializacion termine antes de activar las otras dos.

Ninguna de estas sondas ejecuta logica de negocio. Que un endpoint /healthz devuelva un 200 OK significa que el proceso responde, no que pueda autenticar a un usuario, escribir en la base de datos o conectar con una cola de mensajes. El contrato de estas sondas es con el plano de control: mantener un numero determinado de replica activas y enrutables. No es un contrato con la funcionalidad de la aplicacion.

Fallos ocultos tras una luz verde

El problema aparece cuando los arquitectos asumen, implícitamente, que si el dashboard dice que todo esta bien, la aplicacion funciona. La realidad es que hay seis patronicos comunes donde la sonda pasa pero el servicio falla:

• La sonda de readiness verifica la conexion TCP, pero la dependencia externa (base de datos, cache) es inaccesible. El trafico llega al pod, pero la peticion real cae.
• Se verifica la conexion a la base de datos con un SELECT 1, pero el retraso en la replicacion hace que las lecturas sean obsoletas o hay un bloqueo que impide escrituras.
• El balanceador de carga marca la instancia como sana porque responde en el puerto de salud, pero la ruta de la transaccion real devuelve un 500.
• El interruptor automatico (circuit breaker) esta cerrado porque la tasa de error no ha superado el umbral, aunque transacciones individuales esten fallando.
• El trabajo de copia de seguridad termina con exito (salida 0), pero los datos no son restaurables.
• El servicio de identidad responde a la sonda de liveness, pero la logica de validacion de tokens falla en silencio bajo ciertas condiciones de error.

En cada caso, la sonda responde a una pregunta barata y rapida: "esta el proceso vivo?". La pregunta cara y lenta es: "ha completado la operacion prevista?". Kubernetes no esta disenado para responder a la segunda. Intentar forzarlo es una mala decision de arquitectura.

El abismo entre categorias

Imagina este escenario: un despliegue se activa. Todas las sondas de readiness pasan. El controlador de despliegue informa exito. La latencia esta dentro del SLO. Cuarenta minutos después, llegan los tickets. El flujo de pago esta roto. Los usuarios ven un spinner infinito. La causa no es que el contenedor este caido, sino que la conexion a la cola de cumplimiento se ha estropeado por un cambio de politica de red que nadie relaciono con este servicio.

Añadir mas sondas de readiness no soluciona esto, porque el fallo vive en la capa de resultado de negocio, no en la de participacion en la orquestacion. Cerrar esa brecha requiere una estrategia de arquitectura de nube que mida directamente lo que importa al usuario, no confiar ciegamente en que el plano de control de Kubernetes lo sabe todo. La simplicidad de las sondas de Kubernetes es correcta por disenio; el error esta en sobrestimar su alcance.