Gestión de versiones y asistencia de GKE

En esta página se explica el control de versiones en Google Kubernetes Engine (GKE) y las políticas de asistencia para versiones. Con el tiempo, GKE actualiza los clústeres a versiones más recientes de Kubernetes. Para obtener más información sobre cómo funcionan las actualizaciones, consulta el artículo Acerca de las actualizaciones de clústeres de GKE.

Puedes consultar el calendario de lanzamiento y de asistencia de las versiones actuales en el calendario de lanzamientos de GKE.

Compatibilidad con versiones

La compatibilidad de GKE con las versiones secundarias de Kubernetes se basa en las políticas de código abierto de Kubernetes. GKE admite una versión secundaria proporcionando versiones de parche de la misma versión secundaria y, de forma periódica, actualizando automáticamente los clústeres a esos parches más recientes.

Cómo admite Kubernetes una versión secundaria

La comunidad de software libre de Kubernetes lanza una versión secundaria con nuevas funciones y mejoras tres veces al año. Cada ciclo de lanzamiento dura aproximadamente 15 semanas.

Kubernetes admite cada versión secundaria durante 14 meses. Los errores graves y las vulnerabilidades de seguridad que se detecten en una versión secundaria compatible se corregirán con el lanzamiento de una versión de parche específica. La comunidad de Kubernetes revisa a veces su calendario de asistencia de versiones, según sea necesario. Para obtener más información, consulta el periodo de asistencia.

Cómo admite GKE una versión secundaria

Cuando Kubernetes lanza una nueva versión secundaria, GKE primero introduce esa versión en el canal Rápido. GKE proporciona versiones de parche durante ese tiempo, pero, como el canal Rápido ofrece las versiones más recientes de GKE, estas versiones se excluyen del ANS de GKE y pueden contener problemas para los que no se conozcan soluciones alternativas.

Después de la disponibilidad inicial en el canal Rápido, GKE promociona la nueva versión secundaria al canal Habitual. GKE ofrece un total de 24 meses de asistencia para una versión secundaria después de que se haya puesto a disposición para crear clústeres en el canal Regular. Esta asistencia incluye unos 14 meses de asistencia estándar y aproximadamente 10 meses adicionales de asistencia ampliada, que se ofrece a través del canal Extended. Para ver la disponibilidad de versiones secundarias específicas, consulta la programación de lanzamientos de GKE.

Ciclo de vida de las versiones secundarias de GKE

El ciclo de vida de una versión secundaria de GKE incluye los siguientes pasos clave:

  1. Kubernetes lanza una nueva versión secundaria.
  2. GKE pone la nueva versión secundaria a disposición de los usuarios en el canal Rápido.
  3. GKE pone la nueva versión secundaria a disposición de los usuarios en el canal Regular (inicio del periodo de asistencia estándar).
  4. Durante el periodo de asistencia estándar, GKE proporciona parches para la versión secundaria que incluyen nuevas funciones, correcciones de seguridad y correcciones de errores.
  5. La versión secundaria alcanza el final del periodo de asistencia estándar tras aproximadamente 14 meses en total y entra en el periodo de asistencia ampliada. Después de este periodo, GKE proporciona parches de seguridad para los clústeres del canal ampliado.
  6. La versión secundaria llega al final del periodo de asistencia ampliada, lo que significa que no recibirá más parches de seguridad.

Ajustes de la disponibilidad de versiones

GKE puede revisar el final de la asistencia para las versiones de GKE debido a cambios en la política de la comunidad de software libre de Kubernetes, al descubrimiento de vulnerabilidades u otros problemas técnicos que no se puedan resolver de forma razonable. GKE también puede ampliar las fechas de finalización del soporte en periodos empresariales clave, como el Black Friday y el Cyber Monday.

GKE ofrece al menos 14 meses de asistencia estándar y hasta 24 meses de asistencia ampliada.

Para obtener las últimas versiones disponibles, consulta las notas de la versión de GKE. GKE actualiza periódicamente la programación de lanzamientos para reflejar los tiempos de las actualizaciones automáticas.

Periodos de disponibilidad del ciclo de vida de la versión secundaria

GKE ofrece los siguientes periodos de disponibilidad para una versión secundaria de Kubernetes:

Periodos de asistencia. GKE admite una versión secundaria durante un total de 24 meses.

En la siguiente tabla se resumen los periodos de disponibilidad, que se describen con detalle en las secciones siguientes:

Periodo de disponibilidad Intervalo de tiempo aproximado desde la disponibilidad del canal Normal Qué asistencia ofrece GKE Acceso a este periodo de disponibilidad
Periodo de disponibilidad solo para Rapid Mes -1 a mes 0 GKE proporciona versiones de parche con nuevas funciones, correcciones de seguridad y correcciones de errores. Sin embargo, estas versiones están excluidas del ANS de GKE y pueden contener problemas para los que no se conocen soluciones alternativas. Solo canal rápido
Periodo de asistencia estándar Del mes 1 al mes 14 GKE proporciona versiones de parche con nuevas funciones, correcciones de seguridad y correcciones de errores. Rápido, Periódico, Estable, Ampliado y Sin canal
Periodo de asistencia ampliado Meses del 15 al 24 GKE proporciona versiones de parche con correcciones de seguridad. Canal ampliado (requiere una tarifa adicional por clúster; consulta Obtener asistencia a largo plazo con el canal ampliado)

Periodo de disponibilidad solo para el modelo Rápido

GKE lanza primero una nueva versión secundaria en el canal Rápido. La versión acumula primero el uso y demuestra su estabilidad en los clústeres de este canal antes de ascender al canal Regular. Solo los clústeres registrados en el canal Rápido pueden ejecutar una nueva versión secundaria durante este periodo de disponibilidad.

Este periodo suele durar entre 1 y 2 meses, pero el tiempo exacto depende de cada versión secundaria. Para obtener más información, consulta la programación estimada de los canales de lanzamiento.

Periodo de asistencia estándar

El periodo de asistencia estándar de una versión secundaria de GKE comienza cuando la versión se lanza en el canal Regular. Todos los clústeres de GKE, independientemente de si están registrados en un canal de lanzamiento, pueden ejecutar una versión secundaria con asistencia estándar. Durante este periodo, GKE actualiza automáticamente los clústeres de forma periódica a nuevas versiones de parche, que incluyen nuevas funciones, correcciones de seguridad y correcciones de errores.

GKE actualiza los clústeres automáticamente de la siguiente manera:

  • Rápido, Periódico, Estable o Sin canal: actualizaciones automáticas a otras versiones secundarias admitidas o a versiones de parche de la misma versión secundaria.
  • Ampliación: GKE solo actualiza automáticamente a versiones de parche más recientes de la misma versión secundaria.

En el caso de los clústeres que no estén registrados en el canal de lanzamiento ampliado, GKE actualizará automáticamente los clústeres a la siguiente versión secundaria admitida antes de que finalice el periodo de asistencia estándar, según la programación del canal de lanzamiento del clúster. Para obtener más información, consulta la programación estimada de los canales de lanzamiento. Sin embargo, GKE no actualiza los clústeres durante este periodo si usan funciones o APIs obsoletas. Puedes usar una exclusión de mantenimiento para evitar temporalmente que GKE actualice tu clúster a la siguiente versión secundaria.

Fin de la asistencia estándar (antes, fin del ciclo de vida)

Una vez finalizado el periodo de asistencia estándar, la versión secundaria llega al final de la asistencia estándar (antes conocido como final del ciclo de vida) y deja de estar disponible para todos los clústeres que no estén registrados en el canal ampliado.

Se notifica a los clientes que usan una versión cuya asistencia ha finalizado mediante un correo enviado a la persona de contacto del proyecto antes de que finalice la asistencia de una versión. GKE también empieza a actualizar automáticamente los nodos de forma gradual (independientemente de si la actualización automática está habilitada) que ejecutan versiones no compatibles por motivos de seguridad y compatibilidad, ya que no se proporcionan nuevos parches de seguridad ni correcciones de errores para las versiones que han llegado al final de su ciclo de vida. Antes de ponerte en contacto con el servicio de Atención al Cliente de Cloud para resolver cualquier problema con un clúster o nodos que ejecuten una versión no admitida, primero debes actualizar el clúster y los nodos a una versión admitida.

Las versiones secundarias de GKE que han llegado al final del periodo de asistencia ya no reciben parches de seguridad ni correcciones de errores. Las versiones de parche de una versión secundaria que ha llegado al final de su ciclo de asistencia no se admiten y no están disponibles. GKE actualiza automáticamente todos los clústeres que no están registrados en el canal Extended. Para obtener más información, consulta Actualizaciones automáticas al final del periodo de asistencia.

Periodo de asistencia ampliada

Una vez finalizado el periodo de asistencia estándar, la versión secundaria pasa al periodo de asistencia ampliada (del mes 15 al 24). Durante este periodo, GKE proporciona parches para corregir problemas de seguridad, incluidos los siguientes tipos de correcciones:

  • Parches de seguridad de gravedad media, alta y crítica para los componentes principales de Kubernetes, el sistema operativo de los nodos y los contenedores gestionados por Google incluidos en la versión del clúster de GKE.
  • En el caso de Container-Optimized OS, el final del periodo de asistencia del sistema operativo del nodo puede producirse antes del final del periodo de asistencia ampliado de la versión secundaria de GKE o introducir cambios incompatibles. Para obtener más información sobre cómo sigue ofreciendo asistencia GKE, consulta Actualizaciones de Container-Optimized OS durante el periodo de asistencia ampliado.

Hacia el final del periodo de asistencia ampliada, GKE empieza a actualizar los clústeres a la siguiente versión secundaria. GKE no actualizará los clústeres si utilizan funciones o APIs obsoletas. Puedes usar una exclusión de mantenimiento para impedir temporalmente que GKE actualice tu clúster a la siguiente versión secundaria.

Fin de la asistencia ampliada

Al finalizar el periodo de asistencia ampliada, GKE no proporciona ningún parche para las correcciones de seguridad y la versión secundaria se considera no compatible. GKE actualiza los clústeres que aún ejecutan la versión secundaria no admitida a la siguiente versión secundaria, independientemente de si el clúster usa funciones o APIs obsoletas.

Actualizaciones automáticas al finalizar el periodo de asistencia

GKE programa actualizaciones automáticas de los clústeres de una versión secundaria a la siguiente compatible antes de que la versión secundaria llegue al final del periodo de asistencia. El momento de esta actualización depende de la programación del canal de lanzamiento del clúster. Para obtener más información, consulta la programación estimada de los canales de lanzamiento. Por ejemplo, los clústeres registrados en el canal Estable se actualizan a la siguiente versión secundaria más cerca del final del periodo de asistencia estándar que los clústeres registrados en el canal Rápido.

Durante el periodo de asistencia estándar y el periodo de asistencia ampliado de los clústeres registrados en el canal ampliado, puedes evitar que se actualice a esta versión secundaria con una exclusión de mantenimiento. GKE no actualizará los clústeres que usen funciones o APIs obsoletas.

Sin embargo, al final del periodo de asistencia estándar o del periodo de asistencia ampliada de los clústeres registrados en el canal ampliado, GKE actualiza automáticamente los clústeres a la siguiente versión secundaria admitida para asegurarse de que el clúster siga funcionando correctamente, esté disponible y sea seguro.

Cada versión de GKE tiene 14 meses de asistencia estándar y 24 meses de asistencia total, incluida la asistencia ampliada. No puedes mantener tu clúster en una versión indefinidamente, ya que operar un clúster con una versión de GKE no admitida conlleva riesgos importantes de seguridad, fiabilidad y compatibilidad, ya que GKE no proporciona parches de seguridad ni correcciones de errores para las versiones que ya no se admiten. GKE no puede comprometerse a proporcionar parches ni actualizaciones para las versiones que han llegado al final de su ciclo de vida.

GKE actualiza el clúster de la siguiente manera:

  • Plano de control: GKE actualiza automáticamente los planos de control de los clústeres a versiones compatibles cuando la versión del plano de control deja de estar disponible para la creación de nuevos clústeres.
  • Nodos: GKE actualiza automáticamente los nodos que ejecutan una versión no compatible después de que la versión haya llegado al final de su ciclo de vida para asegurar el buen estado del clúster y la alineación con la política de diferencia de versiones de GKE. Los nodos que ejecutan versiones no compatibles suelen programarse para que se actualicen automáticamente a una versión compatible en el plazo de un mes a partir de la fecha de finalización del soporte. Es posible que los nodos que ejecutan versiones no admitidas no se actualicen inmediatamente cuando finalice el ciclo de vida de la versión, y los plazos reales pueden variar a discreción de Google.

Identificar clústeres que ejecutan una versión secundaria posterior al final del periodo de asistencia estándar

GKE identifica los clústeres que cumplen las dos condiciones siguientes:

GKE recomienda que actualices estos clústeres debido a los riesgos asociados a ejecutar una versión secundaria no admitida. GKE actualiza los clústeres a la siguiente versión secundaria admitida si la versión actual no se admite en el canal de lanzamiento del clúster.

GKE ofrece estas directrices con información valiosa y recomendaciones a través del servicio Recommender. Estas directrices no se aplican a los clústeres registrados en el canal ampliado, que pueden seguir ejecutando una versión secundaria hasta el final del periodo de asistencia ampliado. Para obtener más información sobre cómo gestionar las estadísticas y las recomendaciones de Recommender, consulta Optimizar el uso de GKE con estadísticas y recomendaciones.

Para encontrar clústeres en los que el plano de control esté ejecutando una versión posterior al final del periodo de asistencia, puedes usar uno de los siguientes métodos:

  • Usa la consola Google Cloud .
  • Usa gcloud CLI o la API Recommender especificando el CLUSTER_VERSION_END_OF_LIFE subtipo de recomendador.

Para obtener instrucciones, consulta cómo ver estadísticas y recomendaciones.

Para implementar esta recomendación, actualiza el plano de control de tu clúster a una versión secundaria compatible. Para consultar las versiones secundarias admitidas y las fechas de fin de asistencia, consulta la programación de lanzamientos de GKE. También puedes cambiar tu clúster al canal Extended si quieres seguir usando la versión secundaria actual hasta que finalice el periodo de asistencia ampliado.

Actualizaciones de Container-Optimized OS durante el periodo de asistencia ampliado

Durante el periodo de asistencia ampliada de una versión secundaria de GKE, GKE proporciona actualizaciones de parches para el clúster. Estas actualizaciones de parches pueden incluir actualizaciones de Container-Optimized OS a la versión de Container-Optimized OS que se esté usando en la versión secundaria de GKE. Las versiones secundarias de GKE suelen usar un hito durante el periodo de asistencia estándar y al principio del periodo de asistencia ampliada.

Sin embargo, la versión de Container-Optimized OS que usa la versión secundaria de GKE llega al final de su periodo de asistencia, normalmente durante el periodo de asistencia ampliado de una versión secundaria de GKE. Cuando esto ocurre, GKE crea todas las versiones de parche de GKE posteriores con la siguiente versión de Container-Optimized OS. Para obtener más información sobre los ciclos de vida de las versiones, consulta el esquema de versiones de Container-Optimized OS.

Consulta la siguiente situación para saber cómo se realizan las actualizaciones automáticas y qué decisiones deben tomar los administradores de clústeres cuando GKE ya no pueda introducir actualizaciones de Container-Optimized OS en la misma versión secundaria de GKE.

El hito de Container-Optimized OS llega al final del periodo de asistencia antes de que finalice el periodo de asistencia ampliado de la versión secundaria

El hito de Container-Optimized OS llega al final de su propio periodo de asistencia antes del final del periodo de asistencia ampliado de la versión secundaria que usa el hito. En este caso, GKE usa la siguiente versión de Container-Optimized OS disponible para futuras actualizaciones de parches. GKE realiza esta actualización antes de que se alcance el hito de Container-Optimized OS que usa la versión secundaria y que marca el final de la asistencia.

Los administradores de clústeres deben evaluar si actualizar los nodos de trabajador del clúster, ya que GKE no actualizará automáticamente estos nodos a la siguiente versión con parche con el nuevo hito. Puedes actualizar manualmente los nodos a la siguiente versión de parche de GKE, que contiene un nuevo hito. También puedes mantener los nodos con la misma versión de parche de GKE para no usar el nuevo hito. Sin embargo, los nodos no recibirán parches de seguridad hasta que se actualicen a la siguiente versión o parche secundario.

Actualizaciones automáticas de la nueva versión de Container-Optimized OS

La siguiente versión de parche de una versión secundaria de GKE en el periodo de asistencia ampliado usa un hito más reciente de Container-Optimized OS de versiones de parche anteriores. GKE actualiza automáticamente los clústeres de las siguientes formas cuando la nueva versión de parche se convierte en un destino de actualización automática:

  • Actualizaciones del plano de control:
    • GKE actualiza el plano de control a la siguiente versión de parche, como de costumbre.
  • Actualizaciones de nodos:

Como la nueva versión de hito puede introducir cambios que sean incompatibles con tus cargas de trabajo, GKE pausa las actualizaciones automáticas de los nodos a la siguiente versión de parche. Puedes actualizar manualmente a la nueva versión del parche si has determinado que tus cargas de trabajo son compatibles con la siguiente versión de Container-Optimized OS. Si actualizas manualmente tus nodos a una versión de parche que usa la nueva versión de Container-Optimized OS, GKE reanudará las actualizaciones automáticas de los parches de los nodos, ya que ahora ejecutan la nueva versión.

Notificación de clúster cuando las nuevas versiones de parche usan el nuevo hito

GKE envía una notificación de clúster para informarte cuando se produzca esta situación. Esta notificación se envía cuando la primera versión de parche que usa la nueva versión de Container-Optimized OS está disponible en el canal Extended.

Cuando recibas esta notificación, evalúa si quieres actualizar manualmente los nodos a la siguiente versión parcheada o secundaria, o si no quieres recibir versiones parcheadas posteriores de esta versión secundaria durante el periodo de asistencia ampliada. Para obtener más información, consulta Cambio a una nueva versión de parche de Container-Optimized OS durante el periodo de asistencia ampliado.

Gestionar versiones de esquemas

GKE añade una versión de parche de GKE al estándar del sector con versiones semánticas de Kubernetes(x.y.z-gke.N):

Versión principal de Kubernetes (x)
Las versiones principales suelen incrementarse si se introducen cambios incompatibles con versiones anteriores en la API pública. Una versión principal incrementa la versión de Kubernetes de x.y a x+1.y.
Versión secundaria de Kubernetes (y)
Kubernetes publica una nueva versión secundaria tres veces al año. Cada ciclo de lanzamiento tiene una duración aproximada de 15 semanas. Las APIs obsoletas se pueden quitar con una nueva versión secundaria, por ejemplo, con 1.22. Una versión secundaria incrementa la versión de Kubernetes de 1.y a 1.y+1. Por ejemplo, Kubernetes 1.32 es la versión secundaria que sigue a Kubernetes 1.31.
Versión de parche de Kubernetes (z)
Cada semana suelen estar disponibles nuevos lanzamientos de parches de Kubernetes (como 1.32.6) para usarlos con GKE. Las versiones de parche se lanzan de forma incremental en cada zona.
Versión de parche de GKE (-gke.N)
Una versión de parche con el sufijo -gke.N (como 1.32.6-gke.N) puede incluir actualizaciones de seguridad y correcciones de errores para GKE junto con el software de Kubernetes de código abierto. Estas actualizaciones o correcciones son necesarias para la compatibilidad y la interoperabilidad con Google Cloud.

Comprobar las versiones disponibles y predeterminadas

Para obtener información sobre las versiones disponibles, consulta las notas de la versión de GKE.

También puedes consultar qué versiones de Kubernetes están disponibles y cuáles son las predeterminadas en una zona determinada desde la Google Cloud consola o mediante la CLI de Google Cloud.

Usa la Google Cloud consola para comprobar las versiones

Para ver las versiones predeterminadas y disponibles, sigue estos pasos:

  1. Ve a la página Google Kubernetes Engine en la Google Cloud consola.

    Ir a Google Kubernetes Engine

  2. Haz clic en Crear.

  3. Elige el modo de clúster Estándar y, a continuación, haz clic en Configurar.

  4. En la sección Tipo de ubicación, elige un tipo de ubicación y la ubicación prevista para tu clúster.

  5. En la sección Versión del plano de control, selecciona un canal de lanzamiento. Se mostrarán todas las versiones disponibles para ese canal. La versión predeterminada se selecciona automáticamente.

Usar la CLI de gcloud para comprobar las versiones

Para ver qué versiones están disponibles y cuáles son las predeterminadas, ejecuta uno de los siguientes comandos gcloud para tu tipo de clúster. En cada pestaña se proporcionan comandos para comprobar las versiones de un canal de lanzamiento específico o de ningún canal (antes, estático).

Rápido

Para ver las versiones predeterminadas y disponibles en el canal de lanzamiento Rapid, ejecuta los siguientes comandos:

Versión predeterminada

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=RAPID" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Versiones disponibles

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=RAPID" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Haz los cambios siguientes:

Normal

Para ver las versiones predeterminadas y disponibles en el canal de lanzamiento Regular, ejecuta los siguientes comandos:

Versión predeterminada

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=REGULAR" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Versiones disponibles

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=REGULAR" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Haz los cambios siguientes:

Estable

Para ver las versiones predeterminadas y disponibles en el canal de lanzamiento Stable, ejecuta los siguientes comandos:

Versión predeterminada

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=STABLE" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Versiones disponibles

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=STABLE" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Haz los cambios siguientes:

Ampliada

Para ver las versiones predeterminadas y disponibles en el canal de lanzamiento Extended, ejecuta los siguientes comandos:

Versión predeterminada

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=EXTENDED" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Versiones disponibles

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=EXTENDED" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Haz los cambios siguientes:

No tiene canal

Para ver las versiones predeterminadas y disponibles de ningún canal (antes estático), ejecuta los siguientes comandos:

Versión predeterminada

gcloud container get-server-config \
   --format="yaml(defaultClusterVersion)" \
   --location=COMPUTE_LOCATION

Versiones del plano de control disponibles

gcloud container get-server-config \
   --format="yaml(validMasterVersions)" \
   --location=COMPUTE_LOCATION

Versiones de nodo disponibles

gcloud container get-server-config \
   --format="yaml(validNodeVersions)" \
   --location=COMPUTE_LOCATION

Haz los cambios siguientes:

Especificar la versión del clúster

Esta sección solo se aplica a los clústeres creados en el modo Estándar.

Cuando creas o actualizas un clúster con la interfaz de línea de comandos gcloud, puedes especificar una versión del clúster con la marca --cluster-version. Puedes usar una versión específica, como 1.9.7-gke.N. También puedes usar un alias de versión:

  • latest: especifica la versión de Kubernetes más alta admitida que está disponible en GKE en la zona o región del clúster.
  • 1.X: especifica la versión de parche + gke.N válida más reciente de la versión secundaria 1.X.
  • 1.X.Y: especifica el parche gke.N válido más alto de la versión de parche 1.X.Y.
  • -: en el caso de los planos de control de clústeres, especifica la versión predeterminada de Kubernetes para los planos de control. En el caso de las actualizaciones de nodos, especifica la versión en la que se ejecuta el plano de control del clúster.

Si creas o actualizas un clúster especificando la versión como latest, no se realizarán actualizaciones automáticas. Habilita las actualizaciones automáticas de nodos para asegurarte de que los nodos de tu clúster estén actualizados con la versión estable más reciente.

Especificar la versión del nodo

Esta sección solo se aplica a los clústeres creados en el modo Estándar. En los clústeres de Autopilot, los nodos se actualizan automáticamente a la versión del plano de control y no puedes especificar una versión.

Cuando creas o actualizas un grupo de nodos, puedes especificar su versión. De forma predeterminada, los nodos ejecutan la misma versión de GKE que el plano de control. Los nodos no pueden tener más de dos versiones secundarias anteriores a los planos de control.

Salvo en casos excepcionales, las versiones de los nodos siguen estando disponibles aunque la versión del clúster ya no lo esté.

Política de diferencia de versiones de GKE

La política de diferencia de versiones de GKE asegura que un clúster de GKE mantenga la compatibilidad entre el plano de control y los nodos. En un clúster de GKE, los nodos pueden tener la misma versión que el plano de control o una versión hasta dos versiones secundarias anterior a la del plano de control.

Los nodos no pueden ejecutar versiones más recientes que la versión del plano de control. Por ejemplo, si el plano de control del clúster ejecuta la versión 1.31, los nodos pueden ejecutar las versiones 1.31, 1.30 o 1.29, pero no la 1.28 ni versiones anteriores. La versión de los nodos no puede ser más reciente que la versión del plano de control debido a la política de diferencia de versiones de Kubernetes OSS.

Para garantizar la compatibilidad y la fiabilidad, los nodos deben usar una versión compatible, independientemente de si siguen una desviación de versión válida.

Identificar clústeres con una diferencia de versión no admitida

GKE identifica los clústeres en los que los nodos ejecutan una versión que no es compatible con el plano de control debido a la diferencia de versiones. GKE te recomienda que actualices los nodos que ejecutan esta versión no compatible. Para ello, te ofrece una estadística y una recomendación a través del servicio Recommender. Para obtener más información sobre cómo gestionar las estadísticas y las recomendaciones de Recommender, consulta el artículo Optimizar el uso de GKE con estadísticas y recomendaciones.

Para encontrar clústeres con una diferencia de versión no admitida, puedes usar una de las siguientes formas:

  • Usa la consola Google Cloud .
  • Usa gcloud CLI o la API Recommender especificando el CLUSTER_VERSION_SKEW_UNSUPPORTED subtipo de recomendador.

Para obtener instrucciones, consulta cómo ver estadísticas y recomendaciones.

Para implementar esta recomendación, actualiza los nodos que ejecuten una versión secundaria que sea más de dos versiones secundarias anterior a la versión del plano de control.

Compatibilidad con la omisión de versiones secundarias

GKE no permite omitir versiones secundarias del plano de control del clúster, pero sí versiones de parche. Los nodos de trabajo pueden saltarse versiones secundarias. Por ejemplo, un grupo de nodos se puede actualizar de la versión 1.32 a la 1.34 sin pasar por la versión 1.33.

Para actualizar un clúster a varias versiones secundarias, actualiza el plano de control a una versión secundaria cada vez y actualiza los nodos de trabajo a la misma versión cada vez. Por ejemplo, para actualizar el plano de control de la versión 1.32 a la 1.34, primero actualízalo de la versión 1.32 a la 1.33. Después, actualiza los nodos de trabajo para que coincidan con la versión del plano de control y, a continuación, repite el proceso para actualizar de la versión 1.33 a la 1.34.

Si actualizas los nodos de trabajo para que coincidan con las versiones, evitarás que se produzca una desviación de versión no admitida. Te recomendamos que evites saltarte versiones siempre que sea posible. Si se omiten versiones de nodos de trabajo, suele implicar un mayor alcance de las pruebas, que, aunque se puede gestionar, requiere más atención.

También puedes crear un clúster con la versión que quieras y volver a implementar tus cargas de trabajo.