En los inicios de Kubernetes, administrar un solo clúster era prácticamente un trabajo de tiempo completo. Hoy, los platform engineers de las grandes organizaciones ya no se ocupan de un único clúster: gestionan flotas enteras que pueden incluir decenas o incluso cientos de clústeres distribuidos en distintos entornos, regiones y unidades de negocio.
Como Kubernetes evoluciona a gran velocidad, Google Kubernetes Engine (GKE) publica con frecuencia nuevas versiones con parches de seguridad, mejoras de rendimiento, cambios de API y deprecaciones de funciones. Si bien estos upgrades son indispensables para mantener una plataforma segura y soportada, también suponen un riesgo operativo cuando la nueva versión presenta incompatibilidades con tus workloads. Por otro lado, postergarlos de forma indefinida acumula deuda en seguridad.
GKE Rollout Sequencing cierra esa brecha al sumar un pipeline de upgrades declarativo y automatizado para tus clústeres. Permite a las organizaciones tratar las actualizaciones de clústeres con el mismo rigor que los despliegues de código de aplicación: avanzando por etapas, aplicando tiempos de soak (pausa) y validando a fondo cada nueva versión en los entornos de prueba antes de llevarla a Producción.
Desafíos de los upgrades estándar en GKE
Aun tratándose de un servicio totalmente gestionado como GKE, los upgrades estándar presentan varios obstáculos operativos que pueden frenar a un equipo de DevOps/Platform:
- El riesgo del "todo a la vez": Sin sequencing, todos los clústeres de un Release Channel quedan habilitados para upgrades en cuanto la nueva versión pasa a ser la predeterminada. Esto puede provocar que los entornos Dev y Prod se actualicen en la misma ventana si comparten release channel, sin margen para detectar bugs en los entornos inferiores antes de que afecten a los clientes.
- Control manual: Muchos equipos recurren a las Maintenance Windows o Exclusions para bloquear manualmente los upgrades en Producción mientras hacen pruebas en Desarrollo. Esto exige intervención manual constante, seguimiento y una alta carga cognitiva para el equipo de SRE.
- Dependencias y deprecaciones de API: Kubernetes avanza rápido. Cada versión menor (por ejemplo, de la 1.33 a la 1.34) puede deprecar versiones específicas de API. Si un upgrade alcanza un clúster que ejecuta un Helm chart u operador incompatible, los servicios pueden fallar al iniciar y provocar un downtime prolongado.
- Version drift: Para ir sobre seguro, muchos equipos terminan actualizando los clústeres uno por uno de forma manual. El resultado es version drift: tus entornos quedan corriendo versiones de patch ligeramente distintas, lo que vuelve imposible garantizar que un bug detectado en Producción se pueda reproducir en un entorno inferior.
Por qué importa el Rollout Sequencing
El rollout sequencing aborda estos desafíos al aportar estructura, predictibilidad y automatización al proceso de upgrade. Por eso se está consolidando como el estándar para la gestión de GKE en entornos empresariales:
- Ciclo de vida de infraestructura declarativo: Igual que usas Terraform para tus recursos, Rollout Sequencing te permite definir tu política de upgrades como código. Tú defines la relación upstream y downstream entre clústeres, y el control plane de Google se encarga de la ejecución.
- "Soak Periods" garantizados: Puedes aplicar un tiempo de soak de forma programática (hasta 30 días). Por ejemplo, puedes exigir que una versión corra sin errores en la Staging Fleet durante 7 días antes de habilitarla en la Production Fleet.
- Promoción condicional: Crea una lógica de promoción. Una versión solo avanza a la siguiente etapa si todos los clústeres de la etapa anterior se actualizaron correctamente. Así se levanta una barrera de seguridad que protege tus entornos más críticos.
- Sincronización a escala de fleet: Se apoya en el concepto de fleets, que son agrupaciones lógicas de clústeres de GKE. De este modo, en lugar de configurar 100 clústeres uno por uno, configuras una o varias rollout sequences que rigen toda la estructura organizacional.
Estrategias de rollout: estándar vs. personalizada
Google ofrece dos enfoques para diseñar tu pipeline de upgrades de clústeres, según la estructura de tu equipo y tu tolerancia al riesgo.
Estrategia 1: Secuencia basada en Fleet
Esta estrategia se apoya en el concepto de promoción por entorno completo. Organizas tus clústeres en Fleets según su entorno (por ejemplo, dev-fleet, test-fleet, prod-fleet). Todos los clústeres de todos los grupos de una rollout sequence deben estar en el mismo release channel.
- Cómo funciona: Defines una secuencia compuesta por fleets y estableces el tiempo de soak entre cada grupo. Cuando GKE selecciona una nueva versión para upgrades automáticos en el release channel, tus grupos de clústeres se actualizan en el orden que definiste, lo que te permite validar que los workloads se comporten como esperas con la nueva versión antes de iniciar los upgrades en los clústeres del siguiente grupo de la cadena.
Una rollout sequence basada en fleets
- Ideal para: Organizaciones con agrupaciones de clústeres claras y basadas en entornos.
Estrategia 2: Rollout Sequencing con Custom Stages (Preview)
Para organizaciones más grandes o con necesidades de Canary, los Custom Stages ofrecen un enfoque más quirúrgico. En lugar de mover una fleet entera de una sola vez, usas Cluster Selectors basados en labels.
- Cómo funciona: Puedes crear una Canary Stage dentro de tu Production Fleet. Por ejemplo, puedes etiquetar el 5% de tus clústeres de producción como
canary: true. La rollout sequence actualizará primero esos clústeres. Si se mantienen estables, la secuencia continúa con los clústeres de las demás etapas dentro de la misma production fleet.
Una rollout sequence con custom stages
- Ideal para: Despliegues globales masivos en los que incluso Producción debe actualizarse por oleadas para evitar caídas.
¿Cómo se combina el rollout sequencing con otras funciones de upgrade?
El rollout sequencing es una más dentro de un conjunto de funciones que te dan control sobre la fase de upgrade en el ciclo de vida del clúster.
GKE respeta las maintenance windows y las maintenance exclusions configuradas al actualizar clústeres con rollout sequencing. GKE solo inicia el upgrade de un clúster dentro de su maintenance window. Puedes usar una maintenance exclusion para impedir temporalmente que un clúster se actualice. Si GKE no puede actualizar un clúster por una maintenance window o una exclusion, esa situación puede impedir que los upgrades de un grupo lleguen a completarse.
GKE también pausa los upgrades automáticos de los clústeres de un grupo dentro de una rollout sequence cuando detecta uso de ciertas APIs y funciones deprecadas.
GKE Rollout Sequencing ofrece un framework potente para gestionar upgrades de Kubernetes a escala. Con rollouts por etapas, soak periods y agrupaciones personalizables, las organizaciones pueden reducir de forma significativa el riesgo de los upgrades sin sacrificar velocidad.
Si ya estás evaluando Rollout Sequencing para una prueba de concepto o quieres conocer más sobre esta función, en DoiT te podemos ayudar. Nuestro equipo de más de 100 expertos se especializa en soluciones cloud a medida y está listo para acompañarte en el proceso y optimizar tu infraestructura pensando en compliance y en las demandas futuras.
Conversemos sobre qué estrategia de rollout tiene más sentido para tu compañía, para que tu infraestructura cloud sea robusta, compliant y esté optimizada para el éxito. Contáctanos hoy mismo.