Migración sin downtime a nuevos clusters de Kubernetes
Mover toda una plataforma a nuevos clusters es el tipo de cambio que sale mal a las 2 de la mañana. Así lo hice sin downtime: un cutover blue-green a nivel de cluster, un cambio de DNS interno y scale-to-zero como un rollback de un solo comando.
Prepara la migración de la aplicación y de los datos antes del cutover de DNS; luego valida el destino.
Contribución de un vistazo
- Mi responsabilidad
- Movimiento escalonado de workloads/datos, validación del destino y cutover de DNS con rollback.
- Alcance
- Migración a nivel de cluster, con los workloads heredados conservados durante la transición.
- Colaboración y límites
- Coordiné el movimiento de infraestructura en torno a las dependencias de workloads y datos; cada servicio requiere su propia aceptación del cutover.
- Resultado
- Una estrategia de migración por fases, repetible, con una ruta de rollback. No se infiere ninguna garantía universal de tiempo de recuperación ni de disponibilidad.
Reconstruir los clusters es solo la mitad del trabajo. Una vez que los nuevos clusters existen, cada workload todavía tiene que moverse a ellos, y "mover producción a un cluster distinto" es exactamente la frase que lleva a la gente a agendar una ventana de mantenimiento a medianoche. Yo no quería ninguna ventana ni downtime, así que traté todo el asunto como un despliegue blue-green, solo que a nivel de cluster en lugar de un único servicio.
La estrategia: blue-green a nivel de cluster
Los nuevos clusters corrían en paralelo con los heredados. Nada se eliminó hasta que el lado nuevo quedó probado. La secuencia:
- Levantar los workloads en los nuevos clusters mientras los clusters heredados siguen sirviendo todo el tráfico en vivo.
- Hacer el cutover apuntando el DNS interno de cada app migrada a los nuevos clusters. El tráfico cambia en la capa de DNS, no volviendo a desplegar a los servicios que llaman.
- Escalar a cero los workloads heredados en lugar de eliminarlos. Quedan como un rollback en caliente: si algo se ve mal, volver a escalar el lado antiguo y revertir el DNS es una reversión de un solo comando.
- Desmantelar solo tras un período de estabilización, una vez que el lado nuevo haya funcionado limpio el tiempo suficiente como para confiar en él.
Lo que realmente había que mover
Una plataforma es más que sus pods sin estado. La migración cubrió toda la superficie:
- Aplicaciones — los servicios sin estado, vueltos a desplegar en los nuevos clusters.
- Cloud Functions, planificadores y colas de tareas — el pegamento basado en eventos y en cron que es fácil de olvidar hasta que algo deja de dispararse.
- Datos de Firestore — la parte con estado, migrada al nuevo proyecto para que las apps en los nuevos clusters lean del lugar correcto.
- Programaciones de escalado — las ventanas de escalado hacia arriba/abajo para no producción, recreadas para que los nuevos clusters cuesten lo mismo estando inactivos que los antiguos.
Escala a cero, no elimines
La jugada más valiosa en una migración de cluster es mantener los workloads antiguos en cero réplicas en lugar de eliminarlos. Casi no cuesta nada estacionar un despliegue inactivo, y convierte el rollback de una reconstrucción en un comando de escalado de una sola línea más un cambio de DNS. Elimina solo después de que el lado nuevo se haya ganado tu confianza.
Las partes que la gente olvida
La migración no termina cuando el tráfico fluye. Dos tareas de limpieza importaron:
- Monitoreo que todavía sondea los hosts antiguos. Después del cutover, las sondas blackbox estaban revisando los nombres de host internos heredados y mostrando un muro de falsas alertas de "caído". Reapuntarlas a los hosts migrados fue lo que realmente dio por "terminada" la migración.
- Herramientas que quedaron en los clusters heredados. Los agentes de costos y otros add-ons con alcance de cluster tuvieron que desinstalarse de forma limpia (releases de Helm más CRDs y namespaces sobrantes), para que los clusters vacíos estuvieran realmente vacíos antes del desmantelamiento.
Lo que le diría a alguien que empieza con esto
- Trata un movimiento de cluster como blue-green. Corre ambos en paralelo, haz el cutover en la capa de DNS y nunca elimines el lado antiguo hasta que el nuevo esté probado.
- Escala a cero los workloads antiguos, no los elimines. Ese es tu rollback, y mantenerlo es casi gratis.
- Inventaria primero toda la superficie: funciones, planificadores, colas de tareas y datos con estado, no solo los pods obvios.
- Termina el trabajo. Reapunta el monitoreo a los nuevos hosts y limpia los clusters antiguos, o perseguirás alertas fantasma durante semanas.
Decisiones y próximos pasos
Una mirada retrospectiva al enfoque y sus límites. La próxima mejora es una propuesta, no un resultado entregado.
Alternativa y justificación
Un movimiento in situ reduce la capacidad en paralelo; los clusters en paralelo permiten validar el destino antes de desplazar el tráfico.
Contrapartida
La operación en paralelo añade costo temporal, además de riesgos de comportamiento de DNS/caché y de sincronización de estado.
Lo que mejoraría a continuación
Próxima mejora: registrar la aceptación por servicio, el tiempo de rollback y las condiciones para retirar de forma segura la capacidad heredada.