Google Cloud ha anunciado que su servicio GKE ahora ofrece actualizaciones del plano de control en dos pasos con disponibilidad general, lo que permite a los clientes separar la actualización del binario del software de la migración del formato de datos y mantener una ventana de reversión (rollback) abierta durante los cambios de versiones menores.

Por qué GKE necesitaba una vía más segura

Actualizar un plano de control de Kubernetes de una versión menor a la siguiente siempre ha conllevado riesgos. Pasar de la 1.33 a la 1.34 no solo reemplaza los binarios, sino que también reescribe las estructuras de datos subyacentes. Si la nueva versión contiene un error, el clúster no puede simplemente revertirse; los administradores deben restaurar instantáneas (snapshots) de la base de datos antigua o reconstruir todo el clúster, un proceso lento y propenso a errores.

Cómo funciona la actualización en dos pasos

El nuevo flujo divide la actualización en dos fases distintas:

  • Paso 1 – Actualización de binarios (modo emulado). GKE cambia los binarios del plano de control a la versión de destino mientras preserva el formato de datos antiguo. Debido a que no se escriben nuevas estructuras de datos, el clúster permanece seguro para una reversión durante toda esta fase.
  • Paso 2 – Finalización. Tras un periodo de espera configurable, GKE convierte los datos almacenados al nuevo formato. Una vez finalizada esta conversión, revertir los cambios requeriría el mismo esfuerzo de restauración de instantáneas que el proceso de dos pasos fue diseñado para evitar.

La separación crea una "ventana de observación" (soak window) en la que los operadores pueden observar los binarios actualizados en producción sin comprometerse con la migración de datos irreversible.

La ventana de observación en la práctica

GKE supervisa automáticamente las métricas de salud clave durante el periodo de observación: latencia de la API, tasas de error y salud de los pods. Si el servicio detecta anomalías, detiene el despliegue, dejando el clúster en el estado de "solo binarios" donde todavía es posible realizar una reversión. Google cita una tasa de éxito del 99,999 % para las actualizaciones que siguen este patrón.

Para los clústeres que utilizan la función de actualización automática de GKE, la plataforma orquestará toda la secuencia de dos pasos sin intervención manual. Los usuarios que prefieren tener un control total pueden invocar el proceso a través de la Cloud CLI o Terraform.

Ejecución de una actualización manual en dos pasos

Una actualización manual típica con una ventana de seguridad de 48 horas se ve así:

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

Para inspeccionar el estado actual:

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

Si surge un defecto durante el periodo de observación, el administrador puede emitir un comando de reversión (rollback) y volver a la versión anterior sin pérdida de datos. Cuando el clúster demuestre ser estable, la actualización puede completarse anticipadamente con el comando complete-control-plane-upgrade.

Límites y requisitos

  • La función se aplica a los clústeres de GKE que ejecutan la versión 1.33 o posterior.
  • Solo se puede actualizar una versión menor a la vez; no se admite el salto de versiones.
  • Tanto los clústeres Autopilot como los regionales permanecen disponibles durante todo el proceso de dos pasos.

Posibles desventajas

Separar las actualizaciones de binarios y de datos añade un paso adicional al cronograma de actualización, lo que puede ampliar la ventana general para las organizaciones que necesitan cambios de versión rápidos. El periodo de observación también depende de comprobaciones de salud automatizadas; los equipos que ejecutan cargas de trabajo altamente personalizadas podrían necesitar complementar la monitorización de GKE con sus propias herramientas de observabilidad para detectar regresiones en casos límite.

Qué esperar a continuación

Google no ha revelado una hoja de ruta para extender el modelo de dos pasos a las actualizaciones de versiones mayores, que en muchos casos aún requieren la recreación completa del clúster. Los observadores estarán atentos a anuncios sobre redes de seguridad similares para las actualizaciones de los node-pools y cualquier integración con canalizaciones de CI/CD de terceros que pueda automatizar las comprobaciones de la ventana de observación.

Conclusión: Al desacoplar las actualizaciones de binarios de las migraciones de datos, GKE ofrece a los ingenieros de plataformas una ventana de reversión práctica para los cambios de versiones menores, reduciendo el coste operativo del mantenimiento del clúster y manteniendo el tiempo de inactividad al mínimo.