Mi clúster ya está en un release channel. ¿Tengo que hacer algo?

Nada urgente, pero confirma en qué canal está y si la ventana de mantenimiento coincide con tu horario real. Los clústeres Autopilot siempre están inscritos en un canal y no se pueden sacar de uno, así que ahí lo único que se elige es cuál canal.

¿Puedo evitar que GKE actualice mi clúster una vez que está en un canal?

Puedes aplazarlo con exclusiones de mantenimiento. Una exclusión con alcance de no actualizaciones menores, o de no actualizaciones menores ni de nodos, aguanta hasta el fin del soporte de esa versión menor, y después GKE actualiza el clúster igual. Es una ventana para planificar, no un bloqueo permanente.

¿Qué canal conviene para un equipo pequeño con un solo clúster de producción?

Stable suele ser la respuesta cuando la madurez pesa más que las funciones nuevas. Regular sirve si sigues de cerca las funciones, Extended da más pista sobre una versión menor, y Rapid es para un clúster de pruebas porque incluye versiones de parche alfa de próximas versiones menores.

GKE: release channels y la fecha de junio de 2027

Un taller de software de doce personas, del tipo con el que solemos trabajar, tiene exactamente un clúster de Kubernetes. Se creó hace tres o cuatro años, corre la API y dos workers en segundo plano, y nadie lo ha tocado desde que el contratista que lo armó terminó el proyecto. Nadie sabe en qué versión está. Nadie lo actualiza, porque actualizar suena riesgoso y nada está fallando.

Ese arreglo ya tiene fecha de vencimiento. Google va a quitar la opción de mantener un clúster de GKE fuera de un release channel, así que el clúster que llevaba tres años quieto va a empezar a moverse. Conviene mucho más decidir cómo se mueve que enterarte un martes por la mañana.

Qué cambió y con qué fechas

Correr un clúster sin inscribirlo en un release channel, lo que GKE llama No channel y antes llamaba Static, es una configuración obsoleta. La documentación de release channels de Google lo dice sin rodeos: la opción solo se permite para clientes existentes y se va a eliminar el 14 de junio de 2027. Los clientes nuevos no pueden crear un clúster así ni cambiar uno para usar esa opción. Después de esa fecha, GKE inscribe en el canal Stable todos los clústeres que queden.

Google repitió la baja en las notas de versión de Google Cloud del 21 de agosto de 2026, apuntando a la nota original del 10 de junio de 2026. Ese punto es el que nos hizo volver a poner el tema en la lista de revisión de proyectos de clientes, consultado el 10 de septiembre de 2026.

Vale la pena releer el final de ese primer párrafo, porque es la parte que se pasa por alto. No existe una versión de esto en la que el clúster se quede donde está. O eliges canal y ventana de mantenimiento, o GKE elige Stable por ti y actualiza en un calendario que no definiste.

A quién le pega en una empresa pequeña o mediana

Si usas GKE Autopilot, el tema ya está resuelto. Los clústeres Autopilot siempre están inscritos en un release channel y no se pueden sacar de uno, y los nuevos caen en el canal Regular por defecto. Lo único que queda por decidir es cuál canal, no si vas a tener uno.

Las empresas que sí tienen que actuar son las que corren clústeres Standard que quedaron fuera de un canal, a propósito o por descuido. En nuestra experiencia casi siempre es una de tres situaciones:

Un clúster fijado a una versión específica hace años porque una actualización rompió algo una vez, y ese candado nunca se volvió a revisar.
Un clúster creado antes de que los release channels fueran lo predeterminado, que sigue arrastrando la configuración vieja.
Un clúster sin dueño, heredado junto con el proyecto, donde el tema de la versión nunca salió a conversación.

Los tres terminan en el mismo punto en junio de 2027. La diferencia es si le dedicas dos horas ahora, cuando te conviene, o una tarde no planificada más adelante.

Qué cambia de verdad un release channel

Un release channel no es solo una etiqueta. Cuando el clúster está suscrito, Google mantiene tanto la versión del plano de control como la de los nodos, y la actualización automática de nodos viene activada por defecto en los clústeres con canal. GKE actualiza esos clústeres en la fecha indicada en la columna Auto Upgrade del calendario de versiones de GKE, o después.

Los cuatro canales se diferencian en qué tan pronto te entregan una versión:

Rapid te da acceso a versiones nuevas lo antes posible, incluidas versiones de parche alfa de próximas versiones menores. Su lugar es un clúster de preproducción donde pruebas funciones apenas salen a disponibilidad general.
Regular equilibra estabilidad y novedad, y le sirve a equipos que necesitan seguir de cerca las funciones nuevas.
Stable es la opción cuando la madurez importa más que las funciones, que es la respuesta normal para un único clúster de producción.
Extended da soporte de largo plazo para una versión menor de Kubernetes, para cuando necesitas más pista sobre una misma versión.

La duración del soporte pesa tanto como el carácter del canal. GKE ofrece al menos 14 meses de soporte estándar para una versión menor, y hasta 24 meses en total con soporte extendido: alrededor de 14 meses de soporte estándar más unos 10 meses adicionales disponibles a través del canal Extended. Los parches de una versión menor siguen disponibles en todos los canales hasta el fin del soporte estándar, salvo en los clústeres del canal Extended, donde la versión menor y sus parches siguen disponibles hasta el fin del soporte extendido.

Qué revisamos primero en el clúster de un cliente

Antes de tocar una sola configuración, recorremos la misma lista corta. En un clúster pequeño toma menos de una hora y es donde aparecen las sorpresas.

Modo y canal actual. Autopilot o Standard, y si es Standard, si ya está en un canal. Describimos el clúster y leemos el release channel en la salida del comando, en lugar de confiar en el recuerdo de cómo se configuró.
Dónde queda la versión menor frente a su ventana de soporte. Un clúster dos o tres versiones menores atrás no es un cambio de configuración, es una secuencia de actualizaciones, y el orden importa.
Qué se lleva por delante una actualización. Las versiones menores eliminan cosas. Las notas de versión de Google Cloud del 4 de septiembre de 2026 registran que Identity Service para GKE dejó de tener soporte a partir de GKE 1.37, es decir que crear clústeres nuevos o actualizar los existentes a esa versión deja de funcionar con ese componente. Revisamos el clúster y los manifiestos buscando cualquier cosa de esa lista antes de agendar nada.
Si las cargas de trabajo sobreviven al drenaje de un nodo. Durante una actualización, GKE drena cada nodo existente respetando PodDisruptionBudget y GracefulTerminationPeriod por hasta una hora. Un Deployment con una sola réplica y sin PodDisruptionBudget es una caída corta esperando la ventana de mantenimiento. Es el punto que más corregimos.
Si alguien se va a enterar. GKE publica notificaciones de actualización y las puedes recibir por Cloud Logging o Pub/Sub. En un clúster sin dueño, nadie está suscrito a nada.

Las versiones de parche también se mueven más rápido de lo que la gente cree. Lee casi cualquier semana de las notas de versión de GKE y vas a encontrar líneas que dicen que tal versión de parche quedó obsoleta en un canal y se eliminará en 90 días, o al terminar su soporte si eso ocurre antes. Quedarse en una versión exacta para siempre no es un plan que la plataforma respalde.

La configuración, en orden

Primero la ventana de mantenimiento, después la inscripción. Al revés, el clúster puede volverse elegible para actualizarse antes de que le hayas dicho a GKE cuándo son bienvenidas las actualizaciones.

Una ventana recurrente usa una hora de inicio y una regla de recurrencia en formato RFC-5545. Las frecuencias semanal y diaria funcionan; SECONDLY, MINUTELY y HOURLY no están soportadas:

gcloud container clusters update CLUSTER_NAME \
  --maintenance-window-start=2026-09-14T22:00:00Z \
  --maintenance-window-end=2026-09-15T04:00:00Z \
  --maintenance-window-recurrence='FREQ=WEEKLY;BYDAY=MO,TU,WE'

El par de inicio y fin solo define cuánto dura la ventana. La regla de recurrencia decide cuándo vuelve. Elige horas en las que alguien del equipo esté disponible, no simplemente la madrugada, porque una actualización que se traba a las 03:00 sin nadie despierto es peor que una a las 20:00 con una persona frente a la laptop.

Después inscribe el clúster. El valor del canal es rapid, regular, stable o, en clústeres Standard, extended:

gcloud container clusters update CLUSTER_NAME --release-channel=stable

Agrega en ambos comandos las banderas de ubicación que use tu proyecto. Si administras clústeres con Terraform u otra herramienta, haz el cambio ahí, para que el siguiente apply no devuelva en silencio la configuración vieja.

Para los periodos en los que de verdad no puedes absorber un cambio, usa una exclusión de mantenimiento en lugar de evitar los canales. Las exclusiones tienen tres alcances: no_upgrades, el predeterminado, que evita cualquier mantenimiento y cualquier cambio durante ese periodo; no_minor_upgrades, que mantiene fija la versión menor para que valides la siguiente o evites cambios de API; y no_minor_or_node_upgrades, que desactiva las actualizaciones menores y las de nodos y te deja esas actualizaciones a ti.

gcloud container clusters update CLUSTER_NAME \
  --add-maintenance-exclusion-name=cierre-de-ano \
  --add-maintenance-exclusion-start=2026-12-15T00:00:00Z \
  --add-maintenance-exclusion-end=2027-01-05T00:00:00Z \
  --add-maintenance-exclusion-scope=no_minor_upgrades

En vez de elegir a mano una fecha de fin, también puedes configurar una exclusión con alcance de no actualizaciones menores, o de no actualizaciones menores ni de nodos, para que siga el fin del soporte de la versión menor del clúster.

Notas de costo y de riesgo

Dos advertencias honestas. La primera: una exclusión es un aplazamiento, no una salida. Las exclusiones de actualizaciones menores y de nodos aguantan hasta el fin del soporte de esa versión menor, y después GKE actualiza el clúster de todos modos. Planifica la actualización dentro del plazo que te compraste.

La segunda: las actualizaciones tocan la factura, aunque sea poco. La configuración de surge controla cuántos nodos se actualizan a la vez mediante maxSurge y maxUnavailable, y los nodos de surge son nodos adicionales que se agregan al node pool por zona durante la actualización. Más surge significa una actualización más rápida y menos disruptiva, con más nodos corriendo por un rato. Si estás evaluando el canal Extended, revisa la página de precios vigente de Google Cloud para ver cómo se cobra el soporte extendido antes de comprometerte, porque esa cifra cambia y no repetimos números que no hayamos verificado ese mismo día.

El riesgo que vale la pena nombrar es el que nadie agenda: un clúster tres versiones menores atrás, actualizado de forma automática en junio de 2027 por una plataforma que se quedó sin paciencia, sin PodDisruptionBudget y con una sola réplica de lo que usan tus clientes. Es una caída evitable con fecha en 2027 y con solución disponible hoy.

Cómo ayuda Guanacos Tech

Lo hacemos como un trabajo acotado: inventariar los clústeres del proyecto, calificar primero la ruta de actualización en un clúster de preproducción, agregar los PodDisruptionBudgets y la configuración de surge que les falta a las cargas de trabajo, definir la ventana de mantenimiento según tu horario real, inscribir el clúster en el canal que corresponda a cuánto cambio puedes absorber, y enviar las notificaciones de actualización a un lugar donde una persona las lea. Al final entregamos un runbook de una página para que la próxima actualización sea aburrida.

Si tienes un clúster al que nadie entra desde hace un año, ese es el punto de partida normal y no es motivo de vergüenza. Mira lo que hacemos en Google Cloud o agenda una llamada y lo revisamos juntos.

Tu clúster de GKE tiene que entrar a un release channel antes de junio de 2027