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 para la compatibilidad de versiones. Puedes ver la implementación actual y el programa de asistencia en el programa de actualización de GKE.

Compatibilidad con las versiones

En la actualidad, la comunidad de software de código abierto (OSS) de Kubernetes lanza una versión secundaria con nuevas funciones y mejoras alrededor de 3 meses. A partir de Kubernetes 1.19, OSS admite 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 del parche ad hoc. La comunidad de Kubernetes puede revisar su calendario de compatibilidad de versiones de vez en cuando.

Google proporciona un total de 14 meses de asistencia para cada versión mínima de GKE una vez que la versión está disponible en el canal regular. Los nodos y las versiones de grupos de nodos pueden tener hasta dos versiones secundarias anteriores al plano de control, pero no pueden ser más nuevas que la versión del plano de control debido a la política de sesgo de versiones de SO 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 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 regulares para corregir errores y problemas de seguridad que se informaron. Según la política de asistencia actual de la versión de la comunidad del OSS de Kubernetes, GKE planea mantener las versiones secundarias compatibles durante 14 meses, incluidos los 12 meses posteriores al lanzamiento en el canal regular y un período de mantenimiento de 2 meses.

Al final del período de lanzamiento de 12 meses, GKE proporciona un período de mantenimiento de 2 meses. Durante los 2 meses del período de mantenimiento, no se permitirá la creación de clústeres nuevos para una versión de mantenimiento, pero los clústeres existentes que ejecuten una versión de mantenimiento continuarán en funcionamiento.

Al final del período de mantenimiento, una versión de mantenimiento alcanza el final del ciclo de vida y deja de ser oficial. Las versiones secundarias de GKE que hayan alcanzado el final de su vida útil ya no recibirán parches de seguridad ni correcciones de errores.

Google no puede comprometerse a proporcionar parches o actualizaciones para las versiones de fin de vida útil.

Ten en cuenta que, en raras ocasiones, es posible que sea necesario revisar el período de mantenimiento o el final de la vida útil de las versiones de GKE, debido a los cambios en la política en 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 de parche de GKE al estándar de la industria con versión semántica de Kubernetes (xyz-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 aumenta la versión de Kubernetes de xy a x+1.y.
Versión secundaria de Kubernetes (y)
Kubernetes lanza una versión secundaria nueva aproximadamente cada tres meses. 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 del parche de GKE (-gke.a)
Una actualización de parche con un sufijo -gke.a (como 1.18.6-gke.a) incluye actualizaciones de seguridad o correcciones de errores para GKE, junto con el software de código abierto de Kubernetes. 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 de Google Cloud Console o mediante la herramienta de línea de comandos de gcloud.

Usa la herramienta gcloud para verificar las versiones

A fin de ver qué versiones están disponibles y predeterminadas, ejecuta uno de los siguientes comandos gcloud para el tipo de clúster. Cada pestaña proporciona comandos a fin de verificar las versiones para un canal de versiones específico o cualquier 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)"

Versiones disponibles

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

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)"

Versiones disponibles

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

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)"

Versiones disponibles

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

Sin canal

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

Versión predeterminada

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

Versiones disponibles del plano de control

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

Versiones de nodo disponibles

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

Usa Google Cloud Console para comprobar las versiones

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

  1. En Cloud Console, ve a la página Google Kubernetes Engine.

    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 herramienta 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

¿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 disponible.

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

La compatibilidad 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.

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

El período de mantenimiento significa que una versión pronto ingresará al final del período de vida y solo puede recibir parches de seguridad críticos y errores. Durante el 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 compatibilidad con una versión de Kubernetes en GKE?

Una versión secundaria de Kubernetes deja de ser compatible con GKE cuando alcanza el final de la 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 fin de la vida útil a través de puntos de contacto existentes, como las notas de la versión, los correos electrónicos de los contactos del proyecto y las notificaciones de GKE cuando corresponda. Los clústeres existentes que ejecutan una versión de mantenimiento continuarán funcionando, y la creación de clústeres nuevos para la versión de mantenimiento se inhabilitará.

¿Qué sucederá cuando finalice la vida útil?

Los clientes que ejecuten una versión con fin de ciclo de vida recibirán una notificación por correo electrónico al contacto del proyecto antes del final de su ciclo de vida. GKE también comenzará a actualizar de forma gradual los clústeres y nodos de forma gradual (independientemente de la habilitación de la actualización automática) mediante la ejecución de las versiones finales del ciclo de vida para fines de seguridad y compatibilidad, ya que no habrá nuevos parches de seguridad o correcciones de errores proporcionados para las versiones de fin del ciclo de vida. Antes de interactuar con Cloud Customer Care para los problemas con un clúster o nodos que ejecutan una versión del final de la vida útil, primero debes actualizar tu clúster y nodos a una versión compatible.

¿Cuándo se actualizará exactamente mi clúster después del final de la vida útil?

Es posible que tus clústeres se actualicen de forma automática a versiones compatibles en un plazo de un mes a partir de la fecha de finalización.

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

El SOS de Kubernetes permite omitir la versión en los nodos trabajadores. Por ejemplo, un grupo de nodos se puede actualizar de la versión 1.19.x a la versión 1.21.x y, a la vez, omite la versión 1.20.x. Sin embargo, los planos de control no admiten la omisión de versiones. Por lo tanto, cada versión menor nueva requiere una actualización del plano de control.

Por ejemplo, para actualizar los planos de control de la versión 1.19.x a 1.21.x, los planos de control deben actualizarse primero de la versión 1.19.x a la 1.20.x y, luego, se debe actualizar de 1.20.x a 1.21.x.

De forma alternativa, puedes crear un clúster nuevo con la versión deseada y volver a implementar tus cargas de trabajo.

Como práctica recomendada, te recomendamos que actualices de forma continua tus nodos para que coincidan con la versión del plano de control y evites el sesgo de versión y la omisión de versiones cuando sea posible. Omitir versiones suele implicar un alcance de prueba mayor, que, aunque administrable, requiere más consideración.

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

No. Cada versión de GKE se admite por 14 meses y operar un clúster con un fin de vida útil de GKE proporciona un riesgo significativo de seguridad, confiabilidad y compatibilidad, ya que no se proporcionarán parches de seguridad ni correcciones de errores para de final del ciclo de vida.

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

Te recomendamos que habilites un canal de versiones y habilites las actualizaciones automáticas de nodos para reducir la carga operativa necesaria para actualizar las versiones de GKE. Sin embargo, cuando realices la actualización de forma manual, te recomendamos realizar la actualización no antes de cada seis meses para obtener acceso a características 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 de 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. Obtenga más información en Actualizaciones automáticas.