¿Cómo sé cuándo se actualiza mi clúster de GKE?

Toma la versión menor y el canal del clúster y busca esa fila en la página GKE release schedule, que da la fecha de actualización automática por canal. Google aclara que esas fechas son predicciones de mejor esfuerzo y pueden retrasarse, así que planifica sobre una ventana y no sobre un solo día.

¿Puedo evitar que GKE actualice mi clúster?

No de forma permanente. Una ventana de mantenimiento mueve las actualizaciones a las horas que elijas y una exclusión las pausa en un rango de fechas, pero la versión menor llega al fin de soporte y ahí GKE actualiza el clúster sin importar los problemas que bloqueen el cambio. Lo que puedes controlar es cuándo, no si pasa.

¿Qué canal de lanzamiento le conviene a un equipo pequeño?

Regular o Stable para todo lo que toca un cliente, y Rapid solo donde un upgrade roto sea información útil, como un clúster de staging. Extended existe para retener una versión menor más tiempo, y el soporte extendido se cobra distinto del estándar, así que revisa la página de precios de GKE vigente antes de elegirlo.

Calendario de upgrades de GKE: fechas y cómo moverlas

Pregúntale a un equipo pequeño cuándo se va a actualizar solo su clúster de Kubernetes y escucharás una de dos respuestas: "no se actualiza" o "ni idea". Las dos se equivocan igual. GKE publica las fechas. Están en una página que casi nadie abre, y son la diferencia entre un upgrade que cae un domingo tranquilo y uno que cae mientras tu cliente más importante está pagando.

Esto es lo que hacemos la primera semana en el clúster de un cliente: encontrar la fecha, decidir si es una buena fecha y moverla si no lo es. Este es el orden.

Dónde publica GKE el calendario y cómo leerlo

La página se llama GKE release schedule. Es una tabla con una fila por versión menor de Kubernetes y una columna por canal de lanzamiento: Rapid, Regular, Stable y Extended. Para cada versión y canal da la fecha en que la versión queda disponible para clústeres nuevos y la fecha en que GKE empieza a actualizar automáticamente los clústeres existentes. Consultado el 30 de septiembre de 2026.

Hay dos cosas de esa tabla que importan más que los números que tiene. La documentación dice que las fechas son predicciones de mejor esfuerzo, y que la disponibilidad y las fechas de actualización pueden retrasarse según la calificación y la estabilidad de cada versión, así que tómalas como una ventana y no como una cita. Y la separación entre canales es lo que en realidad estás eligiendo:

Rapid toma una versión menor entre una y dos semanas después de que llega a disponibilidad general en el Kubernetes de código abierto, y apunta a actualizar automáticamente uno o dos meses después.
Regular queda en medio, y es el punto de referencia del reloj de soporte que viene abajo: el soporte de una versión menor se cuenta desde el día en que queda disponible en Regular.
Stable recibe una versión tres o cuatro meses después de Regular, y apunta a actualizar automáticamente unos dos meses después. Prioriza estabilidad sobre funciones nuevas.
Extended coincide con Regular en disponibilidad y mantiene soportada la versión menor por más tiempo.

Hay un segundo canal de información que vale la pena guardar: las notas de lanzamiento por canal. Cada una o dos semanas GKE marca versiones de parche concretas como deprecadas dentro de un canal. Las notas de lanzamiento de Google Cloud del 23 de septiembre de 2026 traen la redacción habitual para varias de ellas: una versión deprecada se retira en 90 días, o al final del soporte si eso ocurre antes. Es decir que incluso dentro de un canal, quedarse en una versión de parche exacta es un estado temporal con un reloj de 90 días encima.

El reloj que decide todo: soporte estándar y después extendido

La página de versionado y soporte de GKE plantea el soporte por versión menor, contado desde el día en que la versión queda disponible en el canal Regular. Hay alrededor de 14 meses de soporte estándar, durante los cuales la versión recibe funciones nuevas, correcciones de seguridad y correcciones de errores. Después la versión entra en soporte extendido, que agrega unos 10 meses más de parches de seguridad y está disponible para clústeres inscritos en el canal Extended. Hasta unos 24 meses en total. Consultado el 30 de septiembre de 2026.

La frase que les leemos en voz alta a los clientes es la del final de ese ciclo: cuando termina el soporte extendido, GKE actualiza los clústeres que siguen en la versión menor ya sin soporte, sin importar si hay problemas que bloqueen el cambio. Lo opcional no es el upgrade. Lo opcional es cuándo.

En qué versión están tus clústeres hoy

Antes de tocar cualquier ajuste, levanta el inventario. Un comando por proyecto:

gcloud container clusters list \
  --format="table(name, location, currentMasterVersion, releaseChannel.channel)"

Si la columna del canal sale vacía, el clúster está en No channel, la configuración que la documentación de canales de lanzamiento de Google marca como deprecada y que se retira el 14 de junio de 2027, fecha después de la cual GKE inscribe en el canal Stable los clústeres que queden (consultado el 30 de septiembre de 2026). Escribimos sobre esa fecha límite y el trabajo que obliga a hacer en nuestro artículo sobre el plazo de junio de 2027. Para hoy lo importante es más acotado: un clúster fuera de un canal solo puede usar la versión más tosca de los controles que siguen.

Después lee la política de mantenimiento de cada clúster:

gcloud container clusters describe CLUSTER_NAME \
  --location=LOCATION \
  --format="value(maintenancePolicy)"

Que no devuelva nada es lo más común, y eso ya es el hallazgo. Sin ventana de mantenimiento, GKE puede iniciar una actualización automática a la hora que le convenga.

Ventanas y exclusiones de mantenimiento: los dos ajustes que deciden cuándo

Una ventana de mantenimiento es un bloque de tiempo recurrente que GKE tiene permitido usar. Fuera de esa ventana, GKE no inicia una actualización automática. Ese es el ajuste que saca el upgrade del martes al mediodía para siempre, y se configura en minutos con gcloud container clusters update o desde la configuración del clúster en la consola.

Una exclusión de mantenimiento es la otra mitad: un rango de fechas puntual en el que no quieres que pase nada, por ejemplo la semana de un lanzamiento o el cierre de año. Las exclusiones tienen alcances, y el alcance que puedes usar depende de si el clúster está inscrito en un canal:

No upgrades bloquea todo, plano de control y nodos. Para un clúster fuera de un canal es el único alcance disponible, y tiene un tope de 30 días. Para un clúster en un canal la documentación permite hasta 90 días y recomienda mantenerlo bajo 30.
No minor upgrades deja pasar parches y actualizaciones de nodos, y retiene la versión menor. Solo con canal.
No minor or node upgrades retiene las dos cosas y deja pasar parches. Solo con canal.

Los dos alcances más finos se pueden configurar para correr hasta el fin de soporte de la versión menor del clúster, y se pueden dejar siguiendo esa fecha en lugar de una que tú escribas, así nadie tiene que acordarse de renovarlas. Un clúster admite hasta 20 exclusiones. Revisa los límites vigentes en la página de exclusiones de mantenimiento antes de planear un congelamiento largo.

Una advertencia que le damos a todo cliente: bloquear las actualizaciones menores y de nodos no elimina el trabajo, te lo pasa a ti. La redacción de Google dice que si usas ese alcance tienes que hacer esas actualizaciones por tu cuenta, o GKE va a actualizar el clúster al final del soporte de la versión menor. Un congelamiento sin plan de upgrade detrás es una caída aplazada con fecha.

gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --add-maintenance-exclusion-name=cierre-de-ano \
  --add-maintenance-exclusion-start=2026-12-15T00:00:00 \
  --add-maintenance-exclusion-end=2027-01-05T23:59:59 \
  --add-maintenance-exclusion-scope=no_upgrades

Cambiar de canal sin un upgrade sorpresa

Cambiar el canal es una sola bandera:

gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --release-channel=regular

La bandera es fácil. La dirección es donde los equipos se golpean. Moverse hacia un canal más rápido puede dejar al clúster en la fila para una versión que nadie probó, porque el objetivo de actualización automática del canal de destino ya puede estar adelante de donde está el clúster hoy. Moverse hacia un canal más lento es la dirección más segura, y no devuelve el clúster hacia atrás, porque GKE no baja de versión un clúster para que coincida con el canal. Así que primero lee la tabla del canal de destino y busca dónde cae tu versión menor actual. Si el objetivo de ese canal está dos versiones menores adelante, lo que tienes es una migración y no un cambio de configuración.

Nuestro orden en los proyectos de clientes siempre es el mismo: primero la ventana de mantenimiento, después el cambio de canal. Hecho así, el primer upgrade después del cambio cae dentro de una ventana que alguien eligió.

Qué dejamos configurado primero en el clúster de un cliente

Inventario de todos los clústeres de todos los proyectos, con versión y canal, en una tabla legible para quien no es ingeniero.
La fecha de fin de soporte estándar de cada clúster, tomada de la página de versionado, para que "estamos bien" se convierta en una fecha.
Una ventana de mantenimiento en las horas realmente tranquilas del negocio, en la zona horaria del negocio y no en la de la región del clúster.
El canal elegido por carga de trabajo y no por empresa: Rapid para un clúster de staging, donde un upgrade roto es información útil, Regular o Stable para todo lo que toca un cliente.
Calificar la siguiente versión menor en un clúster de preproducción antes de la fecha de actualización automática de producción, no después.
Agregar PodDisruptionBudgets y suficiente capacidad de surge para que un nodo se vacíe limpio, porque una buena ventana solo sirve si la carga sobrevive a que la muevan.
Mandar las notificaciones de actualización a un lugar donde una persona las lea, y poner las siguientes dos fechas de actualización automática en el calendario de operaciones.

Notas de costo y riesgo

Las ventanas, las exclusiones y el cambio de canal no cuestan nada. Tres cosas alrededor sí. El soporte extendido se cobra distinto del soporte estándar, así que si estás considerando el canal Extended para retener una versión más tiempo, revisa la página de precios de GKE vigente el día que decidas: esa cifra la verificamos por cliente en lugar de repetirla desde un artículo. Los upgrades con surge agregan nodos mientras dura la actualización, una cuenta chica y corta. Y calificar una versión en preproducción cuesta unos días de un clúster, la línea más barata frente a un upgrade de producción que falla.

El riesgo que de verdad muerde es más silencioso que una caída: un clúster que llega a semanas del fin de soporte mientras todos asumen que son problema de alguien más. Ninguna notificación vuelve eso seguro. Una fecha en un calendario compartido sí.

Cómo ayuda Guanacos Tech

Lo hacemos como un trabajo cerrado: el inventario de clústeres, las fechas de soporte, las ventanas de mantenimiento, la decisión de canal por carga de trabajo, una corrida de calificación en preproducción y un runbook de una página para que el siguiente upgrade sea una entrada de calendario y no un incidente. Somos una consultoría independiente y nuestros ingenieros tienen certificaciones de Google, así que recibes el razonamiento detrás de cada ajuste junto con el ajuste.

Si tienes un clúster al que nadie entra desde hace un año, ese es el punto de partida normal y no es para avergonzarse. Mira lo que hacemos en consultoría de Google Cloud. Una llamada de 30 minutos alcanza para decirte a qué fecha va tu clúster y si hay que moverla.

¿Cuándo se va a actualizar solo tu clúster de GKE? Lee el calendario de lanzamientos y mueve la fecha