En esta página, se explica el control de versiones en Google Kubernetes Engine (GKE) y las políticas asistencia de la versión. 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 Acerca de clúster de GKE de GKE.
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 secundaria
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 GKE admite una versión secundaria
Después de que Kubernetes lanza una nueva versión secundaria, GKE primero la introduce 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 nueva versión secundaria 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 a disposición la nueva versión secundaria en el canal regular (comienzo 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 la versión
Es posible que GKE revise el final de la asistencia para las versiones de GKE debido a cambios en la política de la comunidad de OSS de Kubernetes, el descubrimiento de vulnerabilidades o cualquier otro problema técnico que no se pueda resolver de manera razonable. GKE también puede extender las fechas de fin de asistencia durante 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 periódicamente el programa de lanzamientos para reflejar el momento de las actualizaciones automáticas.
Períodos de disponibilidad en el ciclo de vida de la versión secundaria
GKE proporciona los siguientes períodos de disponibilidad para una versión secundaria de Kubernetes:
Consulta la siguiente tabla, en la que se resumen los períodos de disponibilidad y que se describen en detalle en las siguientes secciones:
| Período de disponibilidad | Período aproximado desde la disponibilidad en el canal regular | Qué asistencia proporciona GKE | Acceso a este período de disponibilidad |
|---|---|---|---|
| Período de disponibilidad solo para Rapid | Mes -1 al mes 0 | GKE proporciona versiones de parche con funciones nuevas y correcciones de seguridad y 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 | Mes 1 al mes 14 | GKE proporciona versiones de parche con funciones nuevas y correcciones de seguridad y de errores. | Rápido, Regular, Estable, Extendido y Sin canal |
| Período de asistencia extendido | Meses 15 a 24 | GKE proporciona versiones de parche con correcciones de seguridad. | Solo canal extendido (requiere una tarifa adicional por clúster; consulta Obtén asistencia a largo plazo con el canal extendido) |
Período de disponibilidad solo para Rapid
Primero, GKE lanza una nueva versión secundaria en el canal rápido. Primero, la versión acumula 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 nueva versión secundaria 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 detalles, 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 del canal de versiones en el que estén inscritos, pueden ejecutar una versión secundaria con asistencia estándar. Durante este período, GKE actualiza automáticamente los clústeres de forma periódica a versiones de parche 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 y 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 actualiza automáticamente los clústeres a la siguiente versión secundaria compatible antes del final de la asistencia estándar, según el programa del canal de versiones del clúster. Para obtener más detalles, 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 alcanza el 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 asistencia reciben una notificación por correo electrónico al contacto del proyecto antes del fin de asistencia de una versión. GKE también comienza 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 de final de la asistencia. 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 llegaron al final de la asistencia ya no reciben parches de seguridad ni correcciones de errores. Las versiones de parche de una versión secundaria que llegó al 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 asistencia.
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 las correcciones de seguridad, incluidos los siguientes tipos de correcciones:
- Parches de seguridad críticos, altos y medios para los componentes principales de Kubernetes, el sistema operativo del nodo y los contenedores administrados por Google incluidos en 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 secundaria de forma temporal.
Fin de la asistencia extendida
Al final del período de asistencia extendida, GKE no proporciona parches para las correcciones de seguridad y la versión secundaria se considera sin asistencia. 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 las funciones o APIs obsoletas.
Actualizaciones automáticas al final de la asistencia
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 momento de esta actualización depende del programa del canal de versiones del clúster. Para obtener más detalles, 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 secundaria 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 o actualizaciones para las versiones que se encuentran al final del período de asistencia.
GKE actualiza el clúster de la siguiente manera:
- Plano de control: GKE actualiza automáticamente los planos de control de clúster a las 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 alcanza el final de la asistencia 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.
Identifica los clústeres que ejecutan una versión secundaria después del final de la asistencia estándar
GKE identifica los clústeres que cumplen con las siguientes condiciones:
- El plano de control ejecuta una versión secundaria que alcanzó el final de la asistencia estándar.
- El clúster no está inscrito en el canal extendido.
GKE recomienda que actualices estos clústeres debido a los riesgos asociados con la ejecución de una versión secundaria no compatible. GKE actualiza los clústeres a la siguiente versión secundaria compatible si la versión existente no es compatible con el canal de versiones del clúster.
GKE proporciona esta orientación con una estadística y una recomendación a través del servicio de recomendador. Esta guía no se aplica a los clústeres inscritos en el canal extendido, que pueden seguir ejecutando una versión secundaria hasta el final de la asistencia extendida. Para obtener más información sobre cómo administrar las estadísticas y las recomendaciones del recomendador, consulta Optimiza el uso de GKE con estadísticas y recomendaciones.
Para encontrar clústeres en los que el plano de control ejecuta una versión posterior al final del período de asistencia, puedes usar una de las siguientes opciones:
- Usa la Google Cloud consola.
- Usa gcloud CLI o la API de Recommender y especifica el subtipo del recomendador
CLUSTER_VERSION_END_OF_LIFE.
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 conocer las versiones secundarias compatibles y las fechas de finalización de la asistencia, consulta el programa de lanzamientos de GKE. O bien, cambia tu clúster al canal extendido si deseas seguir usando la versión secundaria existente hasta el final de la asistencia extendida.
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. Estas actualizaciones de parches pueden incluir actualizaciones de Container-Optimized OS para el hito existente de Container-Optimized OS que usa la versión secundaria de GKE. Por lo general, las versiones secundarias de GKE usan un hito durante el período de asistencia estándar hasta el comienzo del período de asistencia extendida.
Sin embargo, el hito de Container-Optimized OS que usa la versión secundaria de GKE llega a su propio final de la compatibilidad, por lo general, durante el período de asistencia extendida para una versión secundaria de GKE. Cuando esto ocurre, GKE compila todas las versiones de parche posteriores de GKE con el próximo hito de Container-Optimized OS. Para obtener más información sobre los ciclos de vida de los hitos, consulta el esquema de versiones de Container-Optimized OS.
Revisa la siguiente situación para comprender cómo se realizan las actualizaciones automáticas y qué decisiones deben tomar los administradores de clústeres cuando GKE ya no puede introducir actualizaciones de Container-Optimized OS en el mismo hito para una versión secundaria de GKE.
El hito de Container-Optimized OS llega al final de la compatibilidad antes del final de la compatibilidad extendida de la versión secundaria.
El hito de Container-Optimized OS llega a su propio fin de la compatibilidad antes del fin de la compatibilidad extendida para la versión secundaria que usa el hito. En este caso, GKE usa el siguiente hito de Container-Optimized OS disponible para futuras actualizaciones de parches. GKE realiza esta actualización antes de que el hito de Container-Optimized OS que usa la versión secundaria alcance el fin de la compatibilidad.
Los administradores del clúster deben evaluar si actualizar los nodos trabajadores del clúster, ya que GKE no actualizará automáticamente estos nodos a la siguiente versión de parche con el nuevo hito. Puedes actualizar los nodos de forma manual a la siguiente versión de parche de GKE, que contiene un nuevo hito. O bien, puedes mantener los nodos ejecutando 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 de parche o secundaria.
Actualizaciones automáticas para el nuevo hito de Container-Optimized OS
La siguiente versión de parche para una versión secundaria de GKE en el período de asistencia extendida usa un hito de Container-Optimized OS más reciente que las versiones de parche anteriores. GKE actualiza automáticamente los clústeres de las siguientes maneras 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:
- GKE no actualiza los nodos a la siguiente versión de parche.
- GKE actualiza los nodos a la siguiente versión secundaria hacia el final de la asistencia extendida, como de costumbre. Para obtener más información, consulta Actualizaciones automáticas al final de la compatibilidad.
Dado que la nueva versión de hito puede introducir cambios que son incompatibles con tus cargas de trabajo, GKE pausa las actualizaciones automáticas de nodos a la siguiente versión de parche. Puedes actualizar manualmente a la nueva versión de parche si determinaste que tus cargas de trabajo son compatibles con el próximo hito de Container-Optimized OS. Si actualizas manualmente tus nodos a una versión de parche que usa el nuevo hito de Container-Optimized OS, GKE reanuda las actualizaciones automáticas de parches de los nodos porque ahora ejecutan el nuevo hito.
Notificación del clúster cuando las versiones de parche nuevas usan el nuevo hito
GKE envía una notificación de clúster para informarte cuando se produce esta situación. Esta notificación se envía cuando la primera versión de parche que usa el nuevo hito de Container-Optimized OS está disponible en el canal Extended.
Cuando recibas esta notificación, evalúa si deseas actualizar manualmente los nodos a la próxima versión de parche o secundaria, o bien no recibir versiones de parche posteriores para esta versión secundaria durante el período de asistencia extendida. Para obtener más información, consulta Las nuevas versiones de parches cambian a un nuevo hito de Container-Optimized OS durante la asistencia extendida.
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 Google Cloud consola 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 .
Haz clic en add_box 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 para verificar las versiones de un canal de versiones específico o sin canal (antes 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 (anteriormente 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.X1.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 versión 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 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 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.
Identifica clústeres con un sesgo de versión no compatible
GKE identifica los clústeres en los que los nodos ejecutan una versión incompatible con el plano de control debido a un sesgo de versiones. GKE recomienda que actualices los nodos que ejecutan esta versión no compatible y proporciona esta orientación con una estadística y una recomendación a través del servicio de recomendador. Para obtener más información sobre cómo administrar las estadísticas y las recomendaciones del recomendador, consulta Optimiza 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 Google Cloud consola.
- Usa gcloud CLI o la API de Recommender y especifica el subtipo del recomendador
CLUSTER_VERSION_SKEW_UNSUPPORTED.
Para obtener instrucciones, consulta cómo ver estadísticas y recomendaciones.
Para implementar esta recomendación, actualiza los nodos que ejecutan una versión secundaria que es más de dos versiones secundarias anterior a la versión del plano de control.
Compatibilidad para omitir versiones secundarias
GKE no permite omitir versiones secundarias para el plano de control del clúster, pero sí puedes omitir 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.