Deployments sin downtime con Kubernetes: Cómo configurar correctamente los Rolling Updates
Un Rolling Update mal configurado puede provocar downtime incluso con Kubernetes. Mostramos los errores más frecuentes y cómo evitarlos.
Por qué los Rolling Updates por sí solos no son suficientes
Los Rolling Updates de Kubernetes reemplazan Pods de forma gradual, pero sin una configuración adecuada de Readiness Probes, Graceful Shutdown y Pre-Stop Hooks, pueden producirse interrupciones igualmente.
Los tres pilares del Zero-Downtime
- Readiness Probes: Kubernetes necesita saber cuándo un nuevo Pod está listo para recibir tráfico. Sin Readiness Probe, el tráfico se envía a Pods que aún están arrancando.
- Graceful Shutdown: Los Pods antiguos deben completar las peticiones en curso antes de ser terminados. La señal SIGTERM debe ser manejada correctamente por su aplicación.
- Pre-Stop Hooks: Un breve sleep (5-10 segundos) en el Pre-Stop Hook da tiempo al Load Balancer para sacar el Pod de la rotación antes de que se apague.
Estrategia de despliegue
- maxSurge: Establecer entre 25-50%, lo que permite a Kubernetes iniciar nuevos Pods antes de eliminar los antiguos.
- maxUnavailable: Establecer en 0, lo que garantiza que nunca haya menos Pods disponibles del número deseado.
- minReadySeconds: Establecer entre 10-30 segundos para evitar un rollout demasiado rápido ante errores progresivos.
Pruebe su configuración
Recomendamos probar los despliegues regularmente bajo carga. Herramientas como k6 o Locust pueden enviar peticiones de forma continua durante un despliegue; cada error 5xx revela una brecha en su configuración de Zero-Downtime.
¿Preguntas sobre este tema?
Le asesoramos con gusto sobre las tecnologías y soluciones descritas en este artículo.
Contactar