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

Por el momento, 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.

A partir de Kubernetes 1.19, OSS es compatible con cada versión secundaria durante 12 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 puede revisar su calendario de compatibilidad de versiones cada tanto.

Google proporciona un total de 14 meses de asistencia para cada versión secundaria de GKE una vez que la versión está disponible en el canal regular. Los nodos y las versiones de los grupos de nodos pueden tener hasta dos versiones secundarias anteriores que el plano de control, pero no pueden ser más recientes 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.

Después de 12 meses, una versión secundaria compatible ingresará en un período de mantenimiento de 2 meses antes de alcanzar el final del ciclo de vida.

Ciclo de vida de la versión secundaria de GKE

La primera fase del ciclo de vida de la versión secundaria comienza con el lanzamiento de una versión de GKE compatible. Los clústeres que ejecutan una versión secundaria compatible recibirán parches con regularidad para corregir errores y problemas de seguridad que se hayan informado. Según la política actual de asistencia de la versión de la comunidad de OSS de Kubernetes, GKE planea mantener las versiones secundarias compatibles durante 14 meses, incluidos los 12 meses después del lanzamiento en el canal regular, seguidos un período mantenimiento de 2 meses. Durante el período de mantenimiento, no se permitirá la creación de grupos de nodos nuevos para una versión de mantenimiento, pero los grupos de nodos existentes que ejecuten una versión de mantenimiento continuarán en funcionamiento.

Al final del período de mantenimiento, una versión secundaria llega al final del ciclo de vida y oficialmente deja de ser compatible y de estar disponible. Las versiones secundarias de GKE que llegaron al final del ciclo de vida ya no recibirán parches de seguridad ni correcciones de errores. Las versiones de parches de una versión secundaria que alcanzó el final del ciclo de vida no son compatibles y no están disponibles.

A partir de la versión 1.19 de GKE, GKE actualiza los nodos que ejecutan una versión no compatible después de que la versión alcance el final del ciclo de vida para garantizar el estado del clúster y la alineación con la política de sesgo de la versión de código abierto. 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.

Google no se compromete a brindar parches o actualizaciones para las versiones que se encuentran al final del ciclo de vida.

Ten en cuenta que, en raras ocasiones, es posible que sea necesario revisar el período de mantenimiento o el final del ciclo de vida de las versiones de GKE, debido a los cambios en la política de la comunidad de OSS de Kubernetes, o el descubrimiento de vulnerabilidades, u otros problemas técnicos que no se pueden resolver de manera razonable. Para obtener las últimas versiones disponibles, consulta las notas de la versión de GKE.

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.19 es la versión secundaria posterior a Kubernetes 1.18.
Versión de parche de Kubernetes (z)
Las actualizaciones nuevas de parches de Kubernetes (como 1.18.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.18.6-gke.N) incluye actualizaciones de seguridad o 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 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=REGION_OR_ZONE

Versiones disponibles

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

Reemplaza lo siguiente:

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=REGION_OR_ZONE

Versiones disponibles

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

Reemplaza lo siguiente:

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=REGION_OR_ZONE

Versiones disponibles

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

Reemplaza lo siguiente:

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=REGION_OR_ZONE

Versiones disponibles del plano de control

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

Versiones disponible del nodo

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

Reemplaza lo siguiente:

Usa la consola de Google Cloud para verificar las versiones

Para ver cuáles son las versiones disponibles y predeterminadas, sigue los pasos siguientes:

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

    Ir a Google Kubernetes Engine

  2. Haz clic en Crear.

  3. Selecciona 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 deseada para tu clúster.

  5. 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.

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 de manera automática.

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.

Preguntas frecuentes sobre la compatibilidad de versiones

¿Cuándo comienza el período de asistencia para cada versión secundaria?

La asistencia con una versión secundaria de Kubernetes comienza cuando está disponible por primera vez para la creación de clústeres nuevos en el canal de versiones regular.

¿Durante cuánto tiempo es compatible con GKE una versión secundaria de Kubernetes?

GKE proporciona 14 meses de asistencia para cada versión secundaria de Kubernetes que esté disponible. Las versiones recibirán parches para detectar errores y problemas de seguridad durante todo el período de asistencia.

¿Cuál es la diferencia entre el período de mantenimiento y final del ciclo de vida de una versión secundaria de GKE?

El período de mantenimiento significa que se espera que una versión ingrese pronto al final del ciclo de vida. Durante el período de final del ciclo de vida, la versión secundaria de GKE no recibirá parches de seguridad, correcciones de errores ni funciones nuevas.

¿Cuándo finaliza la asistencia para una versión de Kubernetes en GKE?

Una versión secundaria de Kubernetes deja de ser compatible con GKE cuando alcanza el final del ciclo de vida, después de 14 meses de asistencia.

¿Qué sucede en la fecha de inicio del mantenimiento?

GKE notificará a los clientes sobre las próximas versiones de mantenimiento y final del ciclo de vida a través de puntos de contacto existentes como: notas de la versión, correos electrónicos para contactos del proyecto y notificaciones de GKE, cuando corresponda. Los grupos de nodos existentes que ejecutan una versión de mantenimiento continuarán funcionando, y la creación de grupos de nodos nuevos para la versión de mantenimiento se inhabilitará.

¿Qué sucede en la fecha de final del ciclo de vida?

Los clientes que ejecutan una versión de final del ciclo de vida recibirán una notificación por correo electrónico al contacto del proyecto antes del final del ciclo de vida la 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 de final del ciclo de vida por razones de seguridad y compatibilidad, ya que no se proporcionarán nuevos parches de seguridad ni correcciones de errores para las versiones de final del ciclo de vida. 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 de final del ciclo de vida, primero debes actualizar el clúster y los nodos a una versión compatible.

¿Cuándo se actualizará automáticamente mi clúster?

Los planos de control de clúster se actualizarán de forma automática a las versiones compatibles cuando la versión del plano de control ya no esté disponible para la creación de clústeres nuevos.

Los nodos que ejecutan versiones no compatibles se programarán para una actualización automática a una versión compatible dentro de un mes de la fecha de final del ciclo de vida.

¿Puedo omitir versiones de GKE durante una actualización del clúster?

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

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.23 a la 1.25, primero debes actualizarlo de la versión 1.23 a la 1.24 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.24 a la 1.25.

La actualización de los nodos trabajadores para que coincidan con las versiones 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.

¿Puedo dejar mi clúster en una versión de Kubernetes de forma indefinida?

No, cada versión de GKE es compatible por 14 meses y operar un clúster con una versión de GKE de final del ciclo de vida tiene un riesgo de seguridad, confiabilidad y compatibilidad significativo, ya que no se proporcionarán parches de seguridad ni correcciones de errores para las versiones de final del ciclo de vida.

¿Con qué frecuencia debería actualizar una versión de Kubernetes para mantener la asistencia?

Te recomendamos que optes por un canal de versiones y habilites las actualizaciones automáticas de nodos para ayudar a reducir la carga operativa relacionada con la actualización de versiones de GKE. Sin embargo, cuando realices la actualización de forma manual, recomendamos que la actualización se realice en un plazo máximo de seis meses para obtener acceso a las funciones nuevas y permanecer en una versión compatible.

¿Cuál es la política de lanzamiento para los planos de control de GKE?

Los planos de control del clúster siempre se actualizan de forma periódica, sin importar si tu clúster está inscrito en un canal de versiones o si la actualización automática de nodos está inhabilitada. Obtén más información en Actualizaciones automáticas.