Control 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 asistencia de la versión. Puedes ver el lanzamiento y el programa de asistencia de las versiones actuales en el programa de lanzamientos de GKE.

Compatibilidad con las 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 recurrente, actualizando automáticamente los clústeres a esos parches más recientes.

Cómo Kubernetes admite una versión menor

La comunidad de software de código abierto (OSS) de Kubernetes lanza una versión secundaria con funciones y mejoras nuevas tres veces al año. Cada ciclo de lanzamiento tiene una duración aproximada de 15 semanas.

Kubernetes admite cada versión secundaria durante 14 meses. Los errores principales y las vulnerabilidades de seguridad que se encuentran en una versión secundaria compatible se corrigen con el lanzamiento de una versión de parche ad hoc. La comunidad de Kubernetes a veces revisa su calendario de compatibilidad de versiones según sea necesario. Para obtener más información, consulta Período de asistencia.

Cómo admite una versión secundaria GKE

Después de que Kubernetes lanza una nueva versión secundaria, GKE la presenta primero en el canal Rápido. GKE proporciona versiones de parches durante ese período, pero como el canal rápido proporciona las versiones de GKE más recientes, estas versiones se excluyen del ANS de GKE y pueden contener problemas sin soluciones alternativas conocidas.

Después de la disponibilidad inicial en el canal rápido, GKE promueve la versión secundaria nueva al canal regular. GKE proporciona hasta un total de 24 meses de asistencia para una versión secundaria después de que esta esté disponible para la creación de clústeres nuevos en el canal Regular. Esta asistencia incluye alrededor de 14 meses de asistencia estándar y aproximadamente 10 meses adicionales de asistencia extendida disponibles con el canal Extended. Para ver la disponibilidad de versiones secundarias específicas, consulta el Programa de lanzamientos de GKE.

Ciclo de vida de la versión secundaria de GKE

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

Kubernetes lanza una versión secundaria nueva.
GKE pone la nueva versión secundaria a disposición en el canal rápido.
GKE pone la nueva versión secundaria a disposición en el canal regular (inicio del período de asistencia estándar).
Durante el período de asistencia estándar, GKE proporciona parches para la versión secundaria que incluyen funciones nuevas, correcciones de seguridad y correcciones de errores.
La versión secundaria alcanza el final de la asistencia estándar después de aproximadamente 14 meses en total y entra en el período de asistencia extendida. Después de este tiempo, GKE proporciona parches de seguridad para los clústeres en el canal extendido.
La versión secundaria llega al final de la asistencia extendida, lo que significa que ya no recibirá parches de seguridad.

Ajustes de la disponibilidad de las versiones

Es posible que GKE revise el final de la compatibilidad con versiones de GKE debido a cambios en la política de la comunidad de OSS de Kubernetes, el descubrimiento de vulnerabilidades o otros problemas técnicos que no se puedan resolver de manera razonable. GKE también podría extender las fechas de finalización de la asistencia en períodos comerciales clave, como el Black Friday y el Cyber Monday.

GKE proporciona al menos 14 meses de asistencia estándar y hasta un total de 24 meses de asistencia con la asistencia extendida.

Para obtener las últimas versiones disponibles, consulta las notas de la versión de GKE. GKE actualiza el programa de lanzamientos con frecuencia para reflejar los tiempos de las actualizaciones automáticas.

Períodos de disponibilidad en el ciclo de vida de las versiones secundarias

GKE proporciona los siguientes períodos de disponibilidad para una versión secundaria de Kubernetes:

Períodos de asistencia GKE admite una versión secundaria durante un total de 24 meses.

Consulta la siguiente tabla que resume los períodos de disponibilidad, que se describen en detalle en las siguientes secciones:

Período de disponibilidad	Período aproximado de disponibilidad del canal regular	Qué asistencia proporciona GKE	Acceso a este período de disponibilidad
Período de disponibilidad solo para la versión rápida	Del mes -1 al mes 0	GKE proporciona versiones de parche con funciones nuevas, correcciones de seguridad y correcciones de errores. Sin embargo, estas versiones se excluyen del ANS de GKE y pueden contener problemas sin soluciones alternativas conocidas.	Solo en el canal rápido
Período de asistencia estándar	Del mes 1 al mes 14	GKE proporciona versiones de parche con funciones nuevas, correcciones de seguridad y correcciones de errores.	Rápido, Regular, Estable, Extendido, Sin canal
Período de asistencia extendida	Del mes 15 al mes 24	GKE proporciona versiones de parches con correcciones de seguridad.	Solo en el canal extendido (requiere GKE Enterprise o una tarifa adicional por clúster, consulta Obtén asistencia a largo plazo con el canal extendido)

Período de disponibilidad solo para el canal rápido

GKE lanza primero una nueva versión secundaria en el canal rápido. Primero, la versión acumula el uso y demuestra estabilidad en los clústeres de este canal antes de ascender al canal regular. Solo los clústeres inscritos en el canal rápido pueden ejecutar una versión secundaria nueva durante este período de disponibilidad.

Por lo general, este período dura entre 1 y 2 meses, pero el tiempo exacto depende de cada versión secundaria. Para obtener más información, consulta el Programa estimado para los canales de lanzamiento.

Período de asistencia estándar

El período de asistencia estándar para 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 la inscripción en el canal de versiones, pueden ejecutar una versión secundaria en la compatibilidad estándar. Durante este período, GKE actualiza automáticamente los clústeres con frecuencia a versiones de parches nuevas, que incluyen funciones nuevas, correcciones de seguridad y correcciones de errores.

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

Rápido, regular, estable, sin canal: Actualizaciones automáticas a otras versiones secundarias compatibles o versiones de parche de la misma versión secundaria.
Extendido: GKE solo se 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 inscritos en el canal de versiones extendido, GKE actualizará automáticamente los clústeres a la siguiente versión secundaria compatible antes del final de la asistencia estándar, según la programación del canal de versiones del clúster. Para obtener más información, consulta el Programa estimado para los canales de lanzamiento. Sin embargo, GKE no actualiza los clústeres durante este período si usan APIs o funciones obsoletas. Puedes usar una exclusión de mantenimiento para evitar que GKE actualice tu clúster a la siguiente versión menor de forma temporal.

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

Después del período 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 ser compatible y de estar disponible para todos los clústeres que no estén inscritos en el canal extendido.

Los clientes que ejecutan una versión de fin de la asistencia reciben una notificación por correo electrónico al contacto del proyecto antes del fin de la asistencia de una versión. GKE también comenzará a actualizar de forma gradual los nodos de actualización automática (sin importar la habilitación de la actualización automática) que ejecuten versiones no compatibles por razones de seguridad y compatibilidad, ya que no se proporcionarán nuevos parches de seguridad ni correcciones de errores para las versiones que ya no son compatibles. Antes de interactuar con la Atención al cliente de Cloud para cualquier problema con un clúster o nodos que ejecuten una versión sin asistencia, primero debes actualizar el clúster y los nodos a una versión compatible.

Las versiones secundarias de GKE que alcanzaron el final de la compatibilidad ya no reciben parches de seguridad ni correcciones de errores. Las versiones de parches de una versión secundaria que alcanzó el final de la compatibilidad no son compatibles y no están disponibles. GKE actualiza automáticamente todos los clústeres que no están inscritos en el canal extendido. Para obtener más información, consulta Actualizaciones automáticas al final de la compatibilidad.

Período de asistencia extendida

Después de que finaliza la asistencia estándar, la versión secundaria llega al período de asistencia extendida (del mes 15 al mes 24). Durante este período, GKE proporciona parches para correcciones de seguridad, incluidos los siguientes tipos de correcciones:

Parches de seguridad de nivel medio, alto y crítico para los componentes principales de Kubernetes, el sistema operativo del nodo y los contenedores administrados por Google que se incluyen con la versión del clúster de GKE
En el caso de Container-Optimized OS, es posible que el fin de la compatibilidad del sistema operativo del nodo ocurra antes del fin de la asistencia extendida para la versión secundaria de GKE o que se ingresen cambios incompatibles. Para obtener más información sobre cómo GKE sigue brindando asistencia, consulta Actualizaciones de Container-Optimized OS durante el período de asistencia extendida.

Cerca del final del período de asistencia extendida, GKE comienza a actualizar los clústeres a la siguiente versión secundaria. GKE no actualizará los clústeres si usan funciones o APIs obsoletas. Puedes usar una exclusión de mantenimiento para evitar que GKE actualice tu clúster a la siguiente versión menor de forma temporal.

Fin de la asistencia extendida

Al final del período de asistencia extendida, GKE no proporciona parches para 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 compatible a la siguiente versión secundaria, independientemente del uso que haga el clúster de funciones o APIs obsoletas.

Actualizaciones automáticas al final de la compatibilidad

GKE programa actualizaciones automáticas para los clústeres de una versión secundaria a la siguiente versión secundaria compatible antes de que la versión secundaria alcance el final de la compatibilidad. El tiempo de esta actualización depende del programa del canal de versiones del clúster. Para obtener más información, consulta el Programa estimado para los canales de lanzamiento. Por ejemplo, los clústeres inscritos en el canal estable se actualizan a la siguiente versión secundaria más cerca del final de la asistencia estándar que los clústeres inscritos en el canal rápido.

Durante el período de asistencia estándar y el período de asistencia extendida para los clústeres inscritos en el canal extendido, puedes evitar esta actualización de versión menor con una exclusión de mantenimiento, y GKE no actualizará los clústeres que usen funciones o APIs obsoletas.

Sin embargo, al final de la asistencia estándar o de la asistencia extendida para los clústeres inscritos en el canal extendido, GKE actualiza automáticamente los clústeres a la siguiente versión secundaria compatible para garantizar que el clúster siga siendo eficiente, disponible y seguro.

Cada versión de GKE es compatible con 14 meses de asistencia estándar y 24 meses de asistencia total, incluida la asistencia extendida. No puedes mantener tu clúster en una versión de forma indefinida, ya que operar un clúster con una versión de GKE no compatible conlleva un riesgo significativo de seguridad, confiabilidad y compatibilidad, ya que GKE no proporciona parches de seguridad ni correcciones de errores para las versiones que ya no son compatibles. GKE no puede comprometerse a proporcionar parches ni actualizaciones para las versiones que se encuentran al final de la asistencia.

GKE actualiza el clúster de la siguiente manera:

Plano de control: GKE actualiza automáticamente los planos de control de clústeres a versiones compatibles cuando la versión del plano de control ya no está disponible para la creación de clústeres nuevos.
Nodos: GKE actualiza automáticamente los nodos que ejecutan una versión no compatible después de que la versión alcanzó el final de la compatibilidad para garantizar el estado del clúster y la alineación con la política de sesgo de la versión de GKE. Por lo general, los nodos que ejecutan versiones no compatibles se programan para una actualización automática a una versión compatible dentro de un mes de la fecha de finalización de la asistencia. Es posible que los nodos que ejecutan versiones no compatibles no se actualicen de inmediato cuando finalice la versión, y los tiempos reales pueden variar a discreción de Google.

Actualizaciones de Container-Optimized OS durante el período de asistencia extendida

Durante el período de asistencia extendida de una versión secundaria de GKE, GKE proporciona actualizaciones de parches para el clúster, que pueden incluir actualizaciones de Container-Optimized OS.

La versión LTS de Container-Optimized OS llega al final de la compatibilidad antes que la versión menor.

Es posible que la versión LTS de Container-Optimized OS llegue al final de la compatibilidad antes del final de la compatibilidad extendida para la versión menor que usa la versión. En este caso, GKE usa la siguiente versión LTS de Container-Optimized OS disponible para futuras actualizaciones de parches, si es posible. GKE realiza esta actualización antes de que la versión LTS de Container-Optimized OS que usa la versión secundaria de los nodos alcance el fin de la compatibilidad. Los administradores de clústeres deben evaluar si actualizar a la siguiente versión de parche de GKE, que contiene una nueva versión LTS del Container-Optimized OS, o permanecer en la misma versión de parche de GKE para no recibir actualizaciones en el sistema operativo del nodo y, al mismo tiempo, no recibir parches de seguridad para los componentes principales de Kubernetes incluidos en la versión del clúster de GKE.

La próxima versión LTS de Container-Optimized OS presenta cambios incompatibles con la versión menor existente.

La próxima versión LTS de Container-Optimized OS podría introducir cambios incompatibles con los componentes del sistema de GKE, y GKE no puede proporcionar una versión de parche con actualizaciones del sistema operativo del nodo. Los administradores del clúster deben evaluar si actualizar a la siguiente versión secundaria de GKE o considerar las mismas compensaciones que se describen en el párrafo anterior.

Esquema del control de versiones

GKE agrega una versión del parche de GKE al estándar de la industria con versiones semánticas de Kubernetes (x.y.z-gke.N):

Versión principal de Kubernetes (x): Por lo general, las versiones principales se incrementan si se ingresan 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 lanza una versión secundaria nueva tres veces al año. Cada ciclo de lanzamiento tiene una duración aproximada de 15 semanas. Las API obsoletas se pueden quitar con una versión secundaria nueva, 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 posterior a Kubernetes 1.31.
Versión de parche de Kubernetes (z): Las actualizaciones nuevas de parches de Kubernetes (como 1.32.6) para usar con GKE suelen estar disponibles cada semana. Las actualizaciones de parches se implementan en cada zona de manera incremental.
Versión de parche de GKE (-gke.N): Una actualización de parche con un sufijo -gke.N (como 1.32.6-gke.N) puede incluir actualizaciones de seguridad y correcciones de errores para GKE junto con el software Kubernetes ascendente de código abierto. Estas actualizaciones o correcciones son necesarias para la compatibilidad y la interoperabilidad con Google Cloud.

Comprueba 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 comprobar cuáles son las versiones disponibles y predeterminadas de Kubernetes en una zona específica desde la consola de Google Cloud o mediante Google Cloud CLI.

Usa la consola de Google Cloud para verificar las versiones

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

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

Ir a Google Kubernetes Engine
Haz clic en Crear.
Selecciona el modo de clúster Estándar y, a continuación, haz clic en Configurar.
En la sección Tipo de ubicación, elige un tipo de ubicación y la ubicación deseada para tu clúster.
En la sección Versión del plano de control, selecciona un canal de versiones. Se enumeran todas las versiones disponibles actualmente para ese canal. La versión predeterminada se selecciona de forma automática.

Usa la CLI de gcloud para verificar las versiones

A fin de ver qué versiones están disponibles y son predeterminadas, ejecuta uno de los siguientes comandos de gcloud para el tipo de clúster. Cada pestaña proporciona comandos a fin de verificar las versiones de un canal de versiones específico o sin canal (estático).

Rápido

Para ver las versiones predeterminadas y disponibles en el canal de versiones 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

Reemplaza lo siguiente:

COMPUTE_LOCATION: Una ubicación de Compute Engine.

Normal

Para ver las versiones predeterminadas y disponibles en el canal de versiones 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

Reemplaza lo siguiente:

COMPUTE_LOCATION: Una ubicación de Compute Engine.

Estable

Para ver las versiones predeterminadas y disponibles en el canal de versiones 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

Reemplaza lo siguiente:

COMPUTE_LOCATION: Una ubicación de Compute Engine.

Extendido

Para ver las versiones predeterminadas y disponibles en el canal de versiones 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

Reemplaza lo siguiente:

COMPUTE_LOCATION: Una ubicación de Compute Engine.

Sin canal

Para ver las versiones predeterminadas y disponibles sin canal (estático), ejecuta los siguientes comandos:

Versión predeterminada

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

Versiones disponibles del plano de control

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

Versiones disponible del nodo

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

Reemplaza lo siguiente:

COMPUTE_LOCATION: Una ubicación de Compute Engine.

Especifica 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 CLI de 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 compatible más nueva disponible en GKE en la zona o región del clúster.
1.X: especifica la versión más nueva del parche válido y la actualización del parche gke.N en la versión secundaria 1.X
1.X.Y: especifica el parche gke.N válido más nuevo en la versión de parche 1.XY.
-: en los planos de control de clústeres, especifica la versión predeterminada de Kubernetes para los planos de control. Para las actualizaciones de nodos, especifica la versión que está en ejecución en el plano de control del clúster.

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

Especifica 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 la versión de los planos de control.

En raras excepciones, las versiones de los nodos permanecen disponibles, incluso si la versión del clúster ya no está disponible.

Política de sesgo de versión de GKE

La política de sesgo de versiones de GKE garantiza 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 coincidir con la versión del plano de control o ejecutar hasta dos versiones secundarias anteriores 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 siguientes versiones: 1.31, 1.30 o 1.29, pero no 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 sesgo de versiones de OSS de Kubernetes.

Para garantizar la compatibilidad y la confiabilidad, los nodos deben usar una versión compatible, sin importar el sesgo de versión válido.

Compatibilidad para omitir versiones secundarias

GKE no permite omitir versiones secundarias del plano de control del clúster. Sin embargo, puedes omitir las versiones de parche. Los nodos trabajadores pueden omitir versiones secundarias. Por ejemplo, un grupo de nodos se puede actualizar de la versión 1.32 a la 1.34 mientras se omite la versión 1.33.

Para actualizar un clúster a través de varias versiones secundarias, actualiza tu plano de control una sola versión secundaria a la vez y actualiza tus nodos trabajadores 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 debes actualizarlo de la versión 1.32 a la 1.33 y, luego, actualizar los nodos trabajadores para que coincidan con la versión del plano de control y, luego, repetir el proceso para actualizar de la versión 1.33 a la 1.34.

La actualización de los nodos trabajadores para que coincidan con las versiones sin compatibilidad te ayuda a evitar el sesgo de versiones. Te recomendamos que evites omitir versiones cuando sea posible. Omitir las versiones de nodos trabajadores suele implicar un alcance de prueba más grande que, aunque es administrable, requiere más consideración.

Como alternativa, puedes crear un clúster nuevo con la versión que desees y volver a implementar tus cargas de trabajo.