Liveness vs Readiness en Kubernetes: La verdad para apps frontend

Liveness vs Readiness en Kubernetes para apps frontend y sin dependencias externas suele generar más dudas de las que merece. Aquí va una guía práctica y directa basada en experiencia real para evitar sobreingenierías y tomar decisiones que funcionen desde el primer despliegue.

Lo que solía pensar: seguía al pie de la letra el consejo clásico de siempre separar las sondas readiness y liveness. La idea parecía impecable. Readiness indica al balanceador cuándo el servicio puede recibir tráfico. Liveness avisa a Kubernetes si el proceso está colgado o muerto y debe reiniciarse. Con esa premisa asumía que tenían que ser distintas en todos los casos.

Lo que aprendí en la práctica: si tu aplicación es un frontend estático o un SSR ligero sin dependencias externas como base de datos, redis o colas, puedes usar el mismo endpoint para readiness y liveness y funciona perfectamente. Una ruta simple como slash health o slash ping que devuelva 200 OK cuando el servidor está vivo es suficiente.

Por qué basta con una sola comprobación en frontends sin dependencias: no hay nada que calentar, no existen pools de conexión que esperar, tampoco hay condiciones de carrera entre el arranque y el enrutado de peticiones. El servidor responde estoy vivo y con eso vale.

Resumen rápido: si tu frontend solo necesita estar arriba, no necesitas lógica compleja de health checks ni múltiples rutas.

Cuándo sí conviene separarlas: cuando la app tarda en estar lista por conexiones a servicios externos, cuando puede quedarse bloqueada con el tiempo y necesite reinicios automáticos, o cuando requieres políticas distintas de reintentos y umbrales para cada sonda.

Regla simple para esos escenarios: readiness devuelve 200 únicamente cuando todas las dependencias están listas y estables. Liveness devuelve 200 salvo que el proceso esté colgado o saturado de forma irrecuperable. Piensa en readiness como puedo aceptar tráfico y en liveness como el proceso sigue respirando.

Ejemplo del lado de infraestructura con una o dos rutas: puedes definir readiness consultando la ruta slash health slash readiness en el puerto 3000 con un retardo inicial corto y una frecuencia más alta, por ejemplo 3 segundos de espera inicial y 10 segundos entre comprobaciones. Liveness puede consultar slash health slash liveness con un retardo mayor y una frecuencia más relajada, por ejemplo 10 segundos de espera inicial y 30 segundos entre comprobaciones. En un frontend simple, ambas rutas pueden responder lo mismo y aún así te beneficias de ventanas temporales y umbrales diferentes.

Ejemplo del lado de la app: define dos manejadores GET para slash health slash liveness y slash health slash readiness que respondan 200 con un cuerpo mínimo como status READY. Si tu servicio no tiene dependencias, incluso podrías usar la misma ruta para ambas sondas sin añadir lógica extra.

Conclusión operativa: no sobreingenierices los health checks. Para un frontend sin dependencias, una sola ruta slash health sirve para readiness y liveness. A medida que tu plataforma crezca y conectes bases de datos, cachés o colas asíncronas, separa las sondas y ajusta sus umbrales. Saber cuándo importa es la clave.

En Q2BSTUDIO impulsamos despliegues fiables y sostenibles en Kubernetes integrando buenas prácticas desde el día cero. Somos una empresa de desarrollo de software con foco en aplicaciones a medida y software a medida, inteligencia artificial e ia para empresas, ciberseguridad y pentesting, servicios cloud aws y azure, servicios inteligencia de negocio y power bi, además de automatización con agentes IA. Si buscas llevar tu arquitectura al siguiente nivel, consulta nuestros servicios de software a medida o potencia tu plataforma con nuestros servicios cloud en AWS y Azure. Nuestra experiencia te ayudará a elegir la estrategia correcta para readiness y liveness sin complicar tu pipeline.