Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Reglas de actualización de versiones

Comprender cómo la versión actual y la de destino afectan la actualización del clúster te ayuda a verificar el sesgo de versiones, el orden de actualización y los requisitos del SO antes de comenzar.

Información de actualización específica de la versión

En la siguiente tabla, se describe la información de actualización específica de la versión. Después de la tabla, puedes encontrar detalles sobre versiones específicas. Las versiones se ordenan de la más reciente a la más antigua. Busca la versión a la que actualizarás para conocer los detalles y las reglas específicos que se aplican a tu clúster.

Versión	Actualiza primero	Versiones del plano de control (CP)	Versiones de grupos de nodos trabajadores	Estado avanzado del clúster	¿Se admiten las funciones heredadas?	Imágenes de SO predeterminadas y obligatorias	Comportamiento de la actualización de nodos de Kubeception	Se agruparon `cert-manager`
1.36	Clúster de administrador	1.36, 1.35, 1.34	1.36, 1.35, 1.34	Obligatorio	Ninguno	`ubuntu_cgv2`, `cos_cgv2`	No compatible	Paquetes
1.35	Clúster de administrador	1.35, 1.34 y 1.33	1.35, 1.34 y 1.33	Obligatorio	Ninguno	`ubuntu_cgv2`, `cos_cgv2` obligatorio (se quitó cgroup v1)	No compatible	Paquetes
1.34	Clúster de administrador	1.34, 1.33, 1.32	1.34, 1.33, 1.32	Obligatorio (sin solicitud de rechazo; conversión automática no avanzada)	Ninguno	`ubuntu_cgv2` (predeterminado), `cos_cgv2`, `ubuntu_containerd`, `cos`	No compatible	Paquetes
1.33	Clúster de administrador	1.33, 1.32, 1.31	1.33, 1.32, 1.31	Predeterminado (conversión automática) (solo se puede inhabilitar de la versión 1.32 a la 1.33)	Ninguno	`ubuntu_cgv2` (predeterminado), `cos_cgv2`, `ubuntu_containerd`, `cos`	No compatible	Se incluye en los clústeres avanzados
1.32	Clúster de administrador	1.32, 1.31, 1.30	1.32, 1.31, 1.30	DG (se admiten actualizaciones; se admiten actualizaciones de nodos independientes y omitidas)	Ninguno	`ubuntu_cgv2` (predeterminado), `cos_cgv2`, `ubuntu_containerd`, `cos`	No compatible (se debe migrar a Controlplane V2)	Paquete para clústeres avanzados
1.31	Clúster de administrador	1.31, 1.30, 1.29	1.31, 1.30, 1.29	Versión preliminar (sin actualización a la versión 1.32; sin actualizaciones de nodos independientes ni omitidas)	Sí (Seesaw, F5, Kubeception, sin alta disponibilidad); se recomienda migrar a las funciones recomendadas; Dataplane V2 es obligatorio	`ubuntu_cgv2` (predeterminado), `cos_cgv2`, `ubuntu_containerd`, `cos`	Los nodos de administrador se actualizan con el administrador; los nodos del plano de control de usuario se actualizan con el clúster de usuario	Sin agrupar
1.30	Clúster de usuario	1.30	1.30, 1.29, 1.28	No disponible	Sí (Seesaw, F5, Kubeception, no HA); se recomienda encarecidamente la migración a las funciones recomendadas	`ubuntu_cgv2` (predeterminado), `cos_cgv2`, `ubuntu_containerd`, `cos`	Nodos de CP y administrador actualizados durante la actualización del clúster de administrador	Sin agrupar
1.29	Clúster de usuario	1.29 y 1.30	1.29, 1.28, 1.16	No disponible	Sí (Seesaw, F5, Kubeception, sin alta disponibilidad)	`ubuntu_cgv2` (predeterminado), `cos_cgv2`, `ubuntu_containerd`, `cos`	Nodos de CP y administrador actualizados durante la actualización del clúster de administrador	Sin agrupar
1.28	Clúster de usuario	1.28, 1.29, 1.30	1.28, 1.16, 1.15	No disponible	Sí (Seesaw, F5, Kubeception, sin alta disponibilidad)	`ubuntu_containerd` (predeterminado), `cos`, `ubuntu_cgv2`, `cos_cgv2`	Nodos de CP y administrador actualizados durante la actualización del clúster de administrador	Sin agrupar

Para todas las versiones, debes actualizar las versiones del grupo de nodos del balanceador de cargas (grupos de nodos con enableLoadBalancer: true) al mismo tiempo y a la misma versión que el plano de control del clúster de usuario.

Información de actualización por versión de actualización

Busca la sección de la versión a la que actualizarás para obtener información específica que necesitas para actualizar a esa versión.

Versión 1.36

Actualiza primero: Clúster de administrador

Reglas de desvío de versiones:

El clúster de administrador en la versión 1.36 puede administrar clústeres de usuario en las versiones 1.36, 1.35 y 1.34.
Versiones del plano de control del clúster de usuario: 1.36, 1.35 o 1.34.
Versiones del grupo de nodos trabajador: 1.36, 1.35 o 1.34.

Estado de clúster avanzado: Los clústeres avanzados son obligatorios.

Omitir actualizaciones de nodos: Se admite.

Funciones heredadas admitidas: No. Bloquea la actualización.

Imágenes de SO predeterminadas y obligatorias: ubuntu_cgv2, cos_cgv2. El valor predeterminado de osImageType para las configuraciones nuevas es ubuntu_cgv2.

Comportamiento de la actualización de nodos de Kubeception: No compatible. Bloquea la actualización.

Herramientas de actualización:

gkectl: Es obligatorio para los clústeres de administrador. Las versiones compatibles son 1.36, 1.37 y 1.38.
Terraform: Se admite si creaste el clúster de usuario con Terraform.
Google Cloud console: Se admite para las actualizaciones de clústeres de usuario.
Google Cloud CLI: Se admite para las actualizaciones de clústeres de usuario.

Requisitos adicionales:

Puedes ejecutar actualizaciones de clústeres de administrador de forma asíncrona con gkectl upgrade admin --async.

Versión 1.35

Actualiza primero: Clúster de administrador

Reglas de desvío de versiones:

El clúster de administrador en la versión 1.35 puede administrar clústeres de usuario en las versiones 1.35, 1.34 y 1.33.
Versiones del plano de control del clúster de usuario: 1.35, 1.34 o 1.33.
Versiones del grupo de nodos trabajador: 1.35, 1.34 o 1.33.

Estado de clúster avanzado: Los clústeres avanzados son obligatorios.

Omitir actualizaciones de nodos: Se admite.

Funciones heredadas admitidas: No. Bloquea la actualización.

Imágenes de SO predeterminadas y obligatorias: ubuntu_cgv2, cos_cgv2 obligatorias (se quitó cgroup v1). El valor predeterminado de osImageType para las configuraciones nuevas es ubuntu_cgv2. Debes migrar los clústeres a cgroup v2 antes de actualizar.

Comportamiento de la actualización de nodos de Kubeception: No compatible. Bloquea la actualización.

Herramientas de actualización:

gkectl: Es obligatorio para los clústeres de administrador. Las versiones compatibles son 1.35, 1.36 y 1.37.
Terraform: Se admite si creaste el clúster de usuario con Terraform.
Consola: Se admite para las actualizaciones de clústeres de usuario.
gcloud CLI: Se admite para las actualizaciones de clústeres de usuario.

Requisitos adicionales:

Puedes ejecutar actualizaciones de clústeres de administrador de forma asíncrona con gkectl upgrade admin --async.

Versión 1.34

Actualiza primero: Clúster de administrador

Reglas de desvío de versiones:

El clúster de administrador en la versión 1.34 puede administrar clústeres de usuario en las versiones 1.34, 1.33 y 1.32.
Versiones del plano de control del clúster de usuario: 1.34, 1.33 o 1.32.
Versiones del grupo de nodos trabajadores: 1.34, 1.33 o 1.32.

Nota: Cuando conviertes un clúster no avanzado en uno avanzado, no se permite la desviación de versión. Debes actualizar el plano de control y todos los grupos de nodos al mismo tiempo.

Estado de clúster avanzado: Los clústeres avanzados son obligatorios.

Omitir actualizaciones de nodos: Se admite.

Funciones heredadas admitidas: No. Bloquea la actualización.

Imágenes de SO predeterminadas y obligatorias: ubuntu_cgv2, cos_cgv2, ubuntu_containerd y cos. El valor predeterminado de osImageType es ubuntu_cgv2.

Comportamiento de la actualización de nodos de Kubeception: No compatible. Bloquea la actualización.

Herramientas de actualización:

gkectl: Es obligatorio para los clústeres de administrador. Es necesario para convertir clústeres no avanzados en clústeres avanzados (obligatorio en la versión 1.34; la versión binaria de gkectl debe coincidir exactamente con la versión de actualización de destino). Las versiones compatibles son 1.34, 1.35 y 1.36.
Terraform: Se admite si creaste el clúster de usuario con Terraform.
console: Se admite para actualizaciones avanzadas de clústeres de usuario.
gcloud CLI: Es compatible con las actualizaciones avanzadas de clústeres de usuario.

Requisitos adicionales:

Se aplican los siguientes requisitos adicionales a las actualizaciones a la versión 1.34:

Los clústeres no avanzados se convierten automáticamente en clústeres avanzados cuando actualizas a la versión 1.34. Para obtener información sobre las reglas específicas de las actualizaciones de clústeres no avanzados a avanzados, consulta Actualiza un clúster a un clúster avanzado.
La versión empaquetada de cert-manager es obligatoria y se actualizó a la versión 1.19, lo que anula las instalaciones personalizadas preexistentes de cert-manager. Para obtener más información sobre las actualizaciones a cert-manager empaquetados, consulta Usa cert-manager empaquetados.
Se actualizó el entorno de ejecución de contenedores de nodos a containerd 2.0. Esto puede tener las siguientes consecuencias:
- containerd 2.0 no admite imágenes heredadas de Docker Image Manifest v2 ni de Schema 1. Asegúrate de que las cargas de trabajo extraigan imágenes de contenedor con el esquema 2 de Docker o un formato compatible con OCI antes de actualizar a la versión 1.34.
- La configuración de la duplicación del registro se migra al formato hosts.toml en containerd 2.0. Si administras configuraciones de duplicación personalizadas o extremos de registro aislados directamente en tus nodos, verifica que tu configuración se alinee con hosts.toml.
- Si usas DaemonSets o secuencias de comandos personalizados que aplican parches a /etc/containerd/config.toml, asegúrate de que no usen opciones de configuración obsoletas de containerd v1, que pueden provocar fallas de inicio de containerd con containerd 2.0.
El valor predeterminado del campo nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate cambió en la versión 1.34.300. Si deseas realizar actualizaciones secuenciales de grupos de nodos en las versiones 1.34.300 y posteriores, configura nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate: 1 en el archivo de configuración del clúster de usuario:
- Para las versiones 1.34.0 a 1.34.200, nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate se establece de forma predeterminada en 1, lo que actualiza un grupo de nodos a la vez de forma secuencial.
- Para las versiones 1.34.300 y posteriores, nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate se establece de forma predeterminada en 0, lo que actualiza todos los grupos de nodos de forma simultánea.
Para obtener más información, consulta Configura la política de actualización del grupo de nodos.
Las verificaciones previas a la actualización validan de forma activa todas las configuraciones de PodDisruptionBudget (PDB) en el clúster. Antes de actualizar, verifica que tus cargas de trabajo no tengan PDB demasiado restrictivos (por ejemplo, maxUnavailable: 0 o minAvailable que coincidan con las réplicas totales) que bloqueen el vaciado de nodos o que las verificaciones previas puedan fallar.
Si se interrumpe una actualización, actualiza directamente a la versión 1.34.300-gke.59 o una posterior. Esta versión evita que se borre el clúster de arranque si necesitas volver a ejecutar gkectl upgrade admin después de una falla. Para obtener más información, consulta Si vuelves a ejecutar gkectl upgrade admin, se borra el clúster de arranque.
Puedes ejecutar actualizaciones de clústeres de administrador de forma asíncrona con gkectl upgrade admin --async para clústeres avanzados, excepto cuando conviertes un clúster no avanzado en uno avanzado.

Versión 1.33

Actualiza primero: Clúster de administrador

Reglas de desvío de versiones:

El clúster de administrador en la versión 1.33 puede administrar clústeres de usuario en las versiones 1.33, 1.32 y 1.31.
Versiones del plano de control del clúster de usuario: 1.33, 1.32 o 1.31.
Versiones de grupos de nodos trabajadores: 1.33, 1.32 o 1.31.

Nota: Cuando conviertes un clúster no avanzado en uno avanzado, no se permite la desviación de versión. Debes actualizar el plano de control y todos los grupos de nodos al mismo tiempo.

Estado de clúster avanzado: Los clústeres avanzados son el tipo de clúster predeterminado y se convierten automáticamente. Se permite la inhabilitación. Para obtener más información, consulta Actualiza y mantén clústeres no avanzados. Si configuras enableAdvancedCluster como false, fallará la creación de clústeres nuevos.

Omitir actualizaciones de nodos: Se admite.

Funciones heredadas admitidas: No. Bloquea la actualización.

Imágenes de SO predeterminadas y obligatorias: ubuntu_cgv2, cos_cgv2, ubuntu_containerd y cos. El valor predeterminado de osImageType es ubuntu_cgv2.

Comportamiento de la actualización de nodos de Kubeception: No compatible. Bloquea la actualización.

Herramientas de actualización:

gkectl: Es obligatorio para convertir clústeres no avanzados en clústeres avanzados (la versión binaria de gkectl debe coincidir exactamente con la versión de actualización de destino). Es obligatorio para los clústeres de administrador. Las versiones compatibles son 1.33, 1.34 y 1.35.
Terraform: Se admite si creaste el clúster de usuario con Terraform.
console: Se admite para actualizaciones avanzadas de clústeres de usuario.
gcloud CLI: Es compatible con las actualizaciones avanzadas de clústeres de usuario.

Requisitos adicionales:

Se aplican los siguientes requisitos adicionales a las actualizaciones a la versión 1.33:

Las actualizaciones de la versión 1.32 a la 1.33 convierten automáticamente los clústeres no avanzados en clústeres avanzados de forma predeterminada. Puedes mantener los clústeres no avanzados. Para obtener más información sobre cómo mantener los clústeres no avanzados, consulta Actualiza y mantén clústeres no avanzados.
Los clústeres avanzados instalan y empaquetan de forma automática cert-manager v1.18, lo que anula las instalaciones personalizadas preexistentes de cert-manager. Para obtener más información sobre las actualizaciones a cert-manager empaquetados, consulta Usa cert-manager empaquetados.
Si actualizas a clústeres avanzados en esta versión, la versión binaria de gkectl debe coincidir exactamente con la versión de actualización de destino cuando conviertas clústeres no avanzados en avanzados. Este requisito solo se aplica durante la actualización a un clúster avanzado. Para todas las demás actualizaciones de tu clúster avanzado, se aplican las reglas de sesgo de versión estándar.
Si se interrumpe una actualización, actualiza directamente a la versión 1.33.700-gke.71 o una posterior. Esta versión evita que se borre el clúster de arranque si necesitas volver a ejecutar gkectl upgrade admin después de una falla.
Puedes ejecutar actualizaciones de clústeres de administrador de forma asíncrona con gkectl upgrade admin --async para clústeres avanzados y clústeres de alta disponibilidad no avanzados si todos los clústeres de usuario ejecutan Controlplane V2. No puedes usar la marca --async cuando conviertes un clúster no avanzado en uno avanzado.

Versión 1.32

Actualiza primero: Clúster de administrador

Reglas de desvío de versiones:

El clúster de administrador en la versión 1.32 puede administrar clústeres de usuario en las versiones 1.32, 1.31 y 1.30.
Versiones del plano de control del clúster de usuario: 1.32, 1.31 o 1.30.
Versiones de grupos de nodos trabajadores: 1.32, 1.31 o 1.30.

Nota: Cuando conviertes un clúster no avanzado en uno avanzado, no se permite la desviación de versión. Debes actualizar el plano de control y todos los grupos de nodos al mismo tiempo.

Estado avanzado del clúster: Compatible.

Omitir actualizaciones de nodos: Se admite.

Funciones heredadas admitidas: No. Bloquea la actualización.

Imágenes de SO predeterminadas y obligatorias: ubuntu_cgv2, cos_cgv2, ubuntu_containerd y cos. El valor predeterminado de osImageType es ubuntu_cgv2.

Comportamiento de la actualización de nodos de Kubeception: No compatible. Bloquea la actualización. Debes migrar a Controlplane V2.

Herramientas de actualización:

gkectl: Es obligatorio para convertir clústeres no avanzados en clústeres avanzados (la versión binaria de gkectl debe coincidir exactamente con la versión de actualización de destino). Es obligatorio para los clústeres de administrador. Las versiones compatibles son 1.32, 1.33 y 1.34.
Terraform: Se admite si creaste el clúster de usuario con Terraform.
console: Se admite para actualizaciones avanzadas de clústeres de usuario.
gcloud CLI: Es compatible con las actualizaciones avanzadas de clústeres de usuario.

Requisitos adicionales:

Se aplican los siguientes requisitos adicionales para las actualizaciones a la versión 1.32:

Esta es la primera versión que permite una actualización opcional a un clúster avanzado de GA con asistencia completa. Puedes elegir las siguientes opciones:
- Actualiza a un clúster no avanzado y mantenlo. Si eliges esta opción, puedes hacer lo siguiente a partir de esta versión:
  - Actualiza el plano de control del clúster de usuario y los grupos de nodo trabajador por separado. Los grupos de nodo trabajador pueden tener hasta 2 versiones secundarias anteriores a la del plano de control.
  - Ejecuta la actualización de forma asíncrona para los clústeres de administrador y de usuario.
- Actualiza a un clúster no avanzado y, luego, conviértelo en un clúster avanzado. Si eliges esta opción, puedes hacer lo siguiente a partir de esta versión:
  - Actualiza el plano de control del clúster de usuario y los grupos de nodo trabajador por separado cuando actualices el clúster no avanzado, pero no cuando lo conviertas en un clúster avanzado. Los grupos de nodo trabajador pueden tener hasta 2 versiones secundarias anteriores a la del plano de control.
  - Ejecuta la actualización de forma asíncrona para los clústeres de administrador y de usuario cuando actualices el clúster no avanzado.
  - Cuando conviertas al clúster avanzado, actualiza a la versión de actualización 1.32.1000-gke.57 o una posterior, ya que incorpora una corrección para un problema conocido que impide que se borre el clúster de arranque.
- Actualiza directamente a un clúster avanzado. Si eliges esta opción, se aplicará lo siguiente a partir de esta versión:
  - Debes actualizar el plano de control y todos los grupos de nodos juntos.
  - Puedes ejecutar la actualización de forma asíncrona para los clústeres de usuario, pero no para los de administrador.
  - Actualiza a la versión de actualización 1.32.1000-gke.57 o una posterior, ya que incorpora una corrección para un problema conocido que impide que se borre el clúster de arranque.
Las siguientes funciones heredadas no son compatibles a partir de esta versión. Para obtener más información, consulta Funciones heredadas:
- Dataplane V1 (Calico). Actualiza a Dataplane V2 antes de actualizar a la versión 1.32.
- Seesaw. Actualiza a un balanceador de cargas alternativo antes de actualizar a la versión 1.32.
- BIG-IP de F5 integrado Actualiza a un balanceador de cargas alternativo antes de actualizar a la versión 1.32.
- Kubeception. Actualiza a un clúster que no sea de Kubeception antes de actualizar a la versión 1.32.
- Clústeres de administrador sin alta disponibilidad. Actualiza a un clúster de administrador de alta disponibilidad antes de actualizar a la versión 1.32.
La versión binaria de gkectl debe coincidir exactamente con la versión de actualización de destino cuando conviertes clústeres no avanzados en avanzados. Este requisito solo se aplica durante la actualización a un clúster avanzado. Para todas las demás actualizaciones de tu clúster avanzado, se aplican las reglas de sesgo de versión estándar.
Si se interrumpe una actualización, actualiza directamente a la versión 1.32.1000-gke.57 o una posterior. Esta versión evita que se borre el clúster de arranque si necesitas volver a ejecutar gkectl upgrade admin después de una falla.
En la versión 1.32 y posteriores, puedes ejecutar actualizaciones de clústeres de administrador de forma asíncrona con gkectl upgrade admin --async para clústeres avanzados y clústeres de alta disponibilidad no avanzados si todos los clústeres de usuario ejecutan Controlplane V2. No puedes usar la marca --async cuando conviertes un clúster no avanzado en uno avanzado.

Versión 1.31

Actualiza primero: Clúster de administrador

Reglas de desvío de versiones:

El clúster de administrador en la versión 1.31 puede administrar clústeres de usuario en las versiones 1.31, 1.30 y 1.29.
Versiones del plano de control del clúster de usuario: 1.31, 1.30 o 1.29.
Versiones del grupo de nodos trabajador: 1.31, 1.30 o 1.29. (No se admite en clústeres avanzados de la versión 1.31).
Para actualizar de la versión 1.29 o 1.30 a la 1.31, debes actualizar todos los clústeres a la versión 1.30 antes de actualizar el clúster de administrador a la 1.31.

Estado avanzado del clúster: Solo versión preliminar. No se puede actualizar a versiones superiores.

Omitir actualizaciones de nodos: Se admite.

Funciones heredadas compatibles: Dataplane V2 obligatorio; Kubeception, Seesaw y F5 siguen siendo compatibles.

Imágenes de SO predeterminadas y obligatorias: ubuntu_cgv2, cos_cgv2, ubuntu_containerd y cos. El valor predeterminado de osImageType es ubuntu_cgv2.

Kubeception: Los nodos de administrador se actualizan con el clúster de administrador; los nodos de CP de usuario se actualizan con el clúster de usuario.

Herramientas de actualización:

gkectl: Es obligatorio para los clústeres de administrador, los clústeres no avanzados y los clústeres avanzados (versión preliminar, para esta versión). Las versiones compatibles son 1.31, 1.32 y 1.33.
Terraform: Se admite para los clústeres de usuario inscritos si creaste el clúster de usuario con Terraform.
Consola: Se admite para las actualizaciones de clústeres de usuario inscritos.
gcloud CLI: Se admite para las actualizaciones de clústeres de usuarios inscritos.

Requisitos adicionales:

Se aplican los siguientes requisitos adicionales para las actualizaciones a la versión 1.31:

En esta versión, se introdujeron los clústeres avanzados en modo de vista previa. En esta versión, no puedes migrar clústeres no avanzados a clústeres avanzados. Puedes crear clústeres nuevos como clústeres avanzados, pero no puedes actualizar estos clústeres avanzados de versión preliminar a una versión posterior. No recomendamos crear clústeres avanzados en esta versión. Para obtener más información sobre las etapas de lanzamiento de productos, como la versión preliminar, consulta Etapas de lanzamiento de productos.
En la versión 1.31 y posteriores, la arquitectura de las actualizaciones cambió a un modelo en el que el clúster de administrador ahora debe ser superior o igual a sus clústeres de usuario. Anteriormente, los clústeres de usuario podían tener hasta dos versiones secundarias más recientes que el clúster de administrador.
Debes actualizar el clúster de administrador antes de actualizar los clústeres de usuario que administra. Los clústeres de administrador pueden administrar clústeres de usuario con la misma versión secundaria o hasta 2 versiones secundarias anteriores. Por ejemplo, un clúster de administrador en la versión 1.31 puede administrar clústeres de usuario en las versiones 1.31, 1.30 y 1.29.
Para actualizar de la versión 1.29 a la 1.31, debes almacenar en etapa intermedia el paquete 1.30 como un paso intermedio. Debes descargar los paquetes 1.30 y 1.31 en la estación de trabajo de administrador para actualizar a la versión 1.31. Para realizar una actualización de omisión de versión de la 1.29 a la 1.31, haz lo siguiente:
1. Actualiza solo el plano de control del clúster de usuario de la versión 1.29 a la 1.30 (deja los grupos de nodo trabajador en la versión 1.29).
2. Actualiza el clúster de administrador de la versión 1.29 a la 1.30.
3. Actualiza el clúster de administrador de la versión 1.30 a la versión de destino 1.31.
4. Actualiza el plano de control del clúster de usuario y los grupos de nodo trabajador juntos a la versión 1.31.
Si usas Kubeception, los nodos del clúster de administrador se actualizan durante la actualización del clúster de administrador, y los nodos del plano de control del clúster de usuario se actualizan durante la actualización del clúster de usuario.
Para actualizar a la versión 1.31, debes habilitar Dataplane V2. Para evitar conflictos de políticas de red y caídas de tráfico durante la migración de CNI, debes guardar y, luego, borrar de forma manual todos los objetos NetworkPolicy y restablecerlos después de la actualización. Para realizar la transición a Dataplane V2, haz lo siguiente:
1. Exporta y guarda todas tus políticas de red personalizadas:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy -A -o wide \
    --field-selector metadata.namespace!=kube-system
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy POLICY_NAME \
    -n NAMESPACE -o yaml > policy.yaml
```
  Reemplaza lo siguiente:
  - USER_CLUSTER_KUBECONFIG: la ruta de acceso del archivo kubeconfig del clúster de usuario
  - POLICY_NAME: el nombre del objeto NetworkPolicy
  - NAMESPACE: Es el espacio de nombres del objeto NetworkPolicy.
2. Borra las políticas de red del clúster:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    delete networkpolicy POLICY_NAME \
    -n NAMESPACE
```
3. Configura enableDataplaneV2: true en el archivo de configuración del clúster de usuario y realiza la actualización a la versión 1.31.
4. Aplica las políticas guardadas después de que se complete la actualización a la versión 1.31 para que Cilium las compile de forma limpia en el filtro de paquetes de Berkeley extendido (eBPF):
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    apply -f policy.yaml
```
Si tienes clústeres de administrador de alta disponibilidad y todos los clústeres de usuario ejecutan Controlplane V2, puedes ejecutar la actualización de forma asíncrona con el comando gkectl upgrade admin --async.
Dataplane V2 es obligatorio para todos los clústeres de usuario. Antes de actualizar un clúster de usuario a la versión 1.31, sigue los pasos que se indican en Habilita Dataplane V2.
Las funciones heredadas no se admiten en la versión 1.32, y puedes reemplazarlas en las versiones 1.30 y 1.31 para evitar problemas cuando actualices a la versión 1.32.

Versión 1.30

Actualiza primero: Clúster de usuario

Reglas de desvío de versiones:

Un clúster de administrador en la versión 1.30, 1.29 o 1.28 puede administrar un clúster de usuario en la versión 1.30.
El clúster de administrador en la versión 1.30 solo puede administrar clústeres de usuario en la versión 1.30. Todos los clústeres de usuario y el clúster de administrador deben alcanzar la versión 1.30 antes de que puedas actualizar el clúster de administrador a la versión 1.31, y debes actualizar el clúster de administrador a la versión 1.31 antes de que cualquier clúster de usuario pueda actualizarse a la versión 1.31.
Versiones del plano de control del clúster de usuario: 1.30.
Versiones del grupo de nodos trabajador: 1.30, 1.29 o 1.28.

Estado avanzado del clúster: No disponible.

Omitir actualizaciones de nodos: Se admite.

Funciones heredadas compatibles: Compatibles. Se recomienda encarecidamente la migración a las funciones recomendadas.

Imágenes de SO predeterminadas y obligatorias: ubuntu_cgv2, cos_cgv2, ubuntu_containerd y cos. El valor predeterminado de osImageType es ubuntu_cgv2.

**Comportamiento de la actualización de nodos de Kubeception:** El plano de control y los nodos de administrador se actualizan durante la actualización del clúster de administrador

Herramientas de actualización:

gkectl: Es obligatorio para los clústeres de administrador. Las versiones compatibles son 1.30, 1.31 y 1.32.
Terraform: Se admite para los clústeres de usuario inscritos si creaste el clúster de usuario con Terraform.
Consola: Se admite para las actualizaciones de clústeres de usuario inscritos.
gcloud CLI: Se admite para las actualizaciones de clústeres de usuarios inscritos.

Requisitos adicionales:

Se aplican los siguientes requisitos adicionales para las actualizaciones a la versión 1.30:

Para esta versión y todas las anteriores, debes migrar todos los clústeres de usuario antes de actualizar el clúster de administrador. El clúster de administrador debe tener la misma versión secundaria o una inferior que cualquier clúster de usuario administrado.
Si usas Kubeception, esto es lo que sucede durante una actualización:
1. Actualiza el clúster de usuario. Debido a que el plano de control del usuario se encuentra dentro del clúster de administrador, la ejecución de gkectl upgrade cluster solo actualiza los grupos de nodos trabajadores.
2. Actualiza el clúster de administrador. La actualización del clúster de administrador actualiza los nodos de administrador y, al mismo tiempo, actualiza de forma automática todos los planos de control de los clústeres de usuario.
Si tienes Controlplane V2, esto es lo que sucede durante la actualización:
1. Actualiza el clúster de usuario. Esto actualiza el plano de control y los grupos de nodo trabajador.
2. Actualiza el clúster de administrador. Esto actualiza los nodos de administrador.
Cuando creas un clúster de usuario nuevo, debes establecer el campo enableControlplaneV2 en true, que es el valor predeterminado, a partir de esta versión. Si configuras el campo enableControlplaneV2 como false, gkectl rechaza el archivo y no creará el clúster.
Si tienes clústeres de administrador de alta disponibilidad y todos los clústeres de usuario ejecutan Controlplane V2, puedes ejecutar la actualización de forma asíncrona con el comando gkectl upgrade admin --async.
Las funciones heredadas no se admiten en la versión 1.32, y puedes reemplazarlas en las versiones 1.30 y 1.31 para evitar problemas cuando actualices a la versión 1.32.

Versión 1.29

Actualiza primero: Clúster de usuario

Reglas de desvío de versiones:

Un clúster de administrador en la versión 1.29, 1.28 o 1.16 puede administrar un clúster de usuario en la versión 1.29.
El clúster de administrador en la versión 1.29 puede administrar clústeres de usuario en las versiones 1.29 y 1.30. Un clúster de administrador en la versión 1.29 no puede administrar clústeres de usuario en la versión 1.31, ya que todos los clústeres deben alcanzar primero la versión 1.30 y el clúster de administrador debe actualizarse a la versión 1.31 antes de que cualquier clúster de usuario pueda actualizarse a la versión 1.31.
Versiones del plano de control del clúster de usuario: 1.29 o 1.30, que es hasta 1 versión secundaria más reciente.
Versiones del grupo de nodos trabajador: 1.29, 1.28 o 1.16.

Estado avanzado del clúster: No disponible.

Omitir actualizaciones de nodos: Se admite.

Funciones heredadas compatibles: Compatibles.

Imágenes de SO predeterminadas y obligatorias: ubuntu_cgv2, cos_cgv2, ubuntu_containerd y cos. El valor predeterminado de osImageType es ubuntu_cgv2.

Comportamiento de la actualización de nodos de Kubeception: El plano de control y los nodos de administrador se actualizan durante la actualización del clúster de administrador

Herramientas de actualización:

gkectl: Es obligatorio para los clústeres de administrador. Las versiones compatibles son 1.29, 1.30 y 1.31.
Terraform: Se admite para los clústeres de usuario inscritos si creaste el clúster de usuario con Terraform.
Consola: Se admite para las actualizaciones de clústeres de usuario inscritos.
gcloud CLI: Se admite para las actualizaciones de clústeres de usuarios inscritos.

Requisitos adicionales:

Los siguientes requisitos adicionales se aplican a las actualizaciones a la versión 1.29:

Los nodos trabajadores pueden tener hasta 2 versiones secundarias anteriores a la del plano de control (n+2).
Puedes omitir una versión secundaria cuando actualizas grupos de nodo trabajador. Por ejemplo, puedes actualizar un grupo de nodo trabajador de la versión 1.28 a la 1.30.
Las verificaciones previas se ejecutan como Pods dentro del clúster de administrador o un clúster de tipo arranque temporal, en lugar de en la estación de trabajo de administrador.
A partir de esta versión, puedes ejecutar una verificación preliminar sin actualizar el clúster con gkectl upgrade cluster --dry-run.
Si tienes clústeres de administrador de alta disponibilidad y todos los clústeres de usuario ejecutan Controlplane V2, puedes ejecutar la actualización de forma asíncrona con el comando gkectl upgrade admin --async.

Versión 1.28

Actualiza primero: Clúster de usuario

Reglas de desvío de versiones:

Un clúster de usuario en la versión 1.28 puede ser administrado por un clúster de administrador en la versión 1.28, 1.16 o 1.15.
El clúster de administrador en la versión 1.28 puede administrar clústeres de usuario en las versiones 1.28, 1.29 y 1.30.
Versiones del plano de control del clúster de usuario: 1.28, 1.29 o 1.30, que es hasta 2 versiones secundarias más recientes.
Versiones del grupo de nodos trabajadores: 1.28, 1.16 o 1.15, que es hasta 2 versiones secundarias inferiores.

Estado avanzado del clúster: No disponible.

Omitir actualizaciones de nodos: Se admite.

Funciones heredadas compatibles: Compatibles.

Imágenes de SO predeterminadas y obligatorias: ubuntu_containerd, cos, ubuntu_cgv2, cos_cgv2. El valor predeterminado de osImageType es ubuntu_containerd.

Comportamiento de la actualización de nodos de Kubeception: El plano de control y los nodos de administrador se actualizan durante la actualización del clúster de administrador

Herramientas de actualización:

gkectl: Es obligatorio para los clústeres de administrador. Las versiones compatibles son 1.28, 1.29 y 1.30.
Terraform: Se admite para los clústeres de usuario inscritos si creaste el clúster de usuario con Terraform.
Consola: Se admite para las actualizaciones de clústeres de usuario inscritos.
gcloud CLI: Se admite para las actualizaciones de clústeres de usuarios inscritos.

Requisitos adicionales:

Se aplican los siguientes requisitos adicionales para las actualizaciones a la versión 1.28:

Debes habilitar kubernetesmetadata.googleapis.com y otorgar roles/kubernetesmetadata.publisher a la cuenta de servicio de supervisión y registro. De lo contrario, las verificaciones previas pueden fallar o es posible que veas errores 403 PERMISSION_DENIED. Habilita la API y otorga el rol a la cuenta de servicio de registro y supervisión existente:
```
gcloud services enable kubernetesmetadata.googleapis.com
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:LOGGING_SA" \
    --role="roles/kubernetesmetadata.publisher"
```
Reemplaza lo siguiente:
- PROJECT_ID: Es el ID del proyecto host de la flota en el que el clúster de usuario es miembro.
- LOGGING_SA: Es la dirección de correo electrónico de tu cuenta de servicio de registro y supervisión.
Aunque técnicamente es posible omitir versiones durante una actualización del grupo de nodos, esta función se introdujo como una función de versión preliminar y no se recomienda para esta versión. Para obtener más información sobre las etapas de lanzamiento de productos, como la versión preliminar, consulta Etapas de lanzamiento de productos.
Los grupos de nodos con un balanceador de cargas empaquetado deben coincidir exactamente con la versión del clúster.
Puedes actualizar varios nodos al mismo tiempo si configuras el campo nodePools[i].updateStrategy.rollingUpdate.maxSurge. Tu clúster de vSphere debe tener suficientes CPU, RAM y direcciones IP disponibles para alojar las VMs de aumento adicionales durante la actualización:
- Establece maxSurge: 1 (predeterminado) para actualizar un nodo a la vez (vaciar, reemplazar, verificar y, luego, repetir).
- Establece maxSurge: N (donde N > 1) para aprovisionar y vaciar hasta N nodos trabajadores al mismo tiempo (por ejemplo, maxSurge: 3 actualiza 3 nodos trabajadores de forma simultánea).
Debes tener al menos 100 GB de espacio libre en el disco de tu estación de trabajo de administrador para actualizarla.
La versión de gkectl que usas para actualizar puede ser hasta dos versiones secundarias más reciente que el clúster actual. No puedes usar una versión secundaria inferior.

Versiones anteriores a la 1.28

Los siguientes requisitos adicionales se aplican a las actualizaciones a versiones anteriores a la 1.28. No hubo versiones de actualización entre la 1.16 y la 1.28:

Versión 1.16:

La diferencia de versiones entre los clústeres de administrador y de usuario, y entre el plano de control y los grupos de nodos, solo puede ser de 1 versión secundaria. Por ejemplo, un clúster de administrador en la versión 1.15 solo puede administrar clústeres de usuario con las versiones 1.15 o 1.16. Un plano de control de clúster de usuario actualizado a la versión 1.16 puede administrar grupos de nodo trabajador que ejecutan la versión 1.15 o 1.16. Un grupo en la versión 1.14 debe actualizarse a la 1.15 antes de que el plano de control pueda pasar a la versión 1.16. Para obtener más información sobre el sesgo de versiones, consulta Reglas de sesgo de versiones.
Los clústeres se inscriben automáticamente en la API de GKE On-Prem cuando se crean o actualizan a la versión 1.16. Con este cambio, puedes ver, supervisar y actualizar clústeres de usuario con la consola, gcloud CLI y Terraform, en lugar de solo la shell de la estación de trabajo de administrador.

Versión 1.14:

Primero, puedes actualizar solo el plano de control del clúster de usuario, de modo que no tengas que vaciar y actualizar cada grupo de nodo trabajador al mismo tiempo.
Durante la actualización, el sistema inspecciona y actualiza de forma automática los archivos kubeconfig del clúster de administrador y de usuario existentes en la estación de trabajo, y renueva las credenciales automáticamente.

Versión 1.13:

Antes de esta versión, podías tener un clúster de administrador sin conexión. Esta versión requiere que registres tu clúster de administrador en Google Cloud. Para obtener información sobre cómo registrar un clúster, consulta Registra un clúster existente.
Para actualizar un clúster a Google Distributed Cloud solo de software para VMware 1.13 o una versión posterior, primero debes actualizar cualquier grupo de nodos de clúster de usuario que aún use Docker Engine a containerd.

Usa `cert-manager` empaquetado

Debes usar el cert-manager empaquetado, que se instala automáticamente en los clústeres avanzados. Cuando migras de un clúster no avanzado a uno avanzado, el cert-manager integrado anula automáticamente cualquier versión de cert-manager instalada por el cliente. Asegúrate de no tener configuraciones o funciones personalizadas críticas aplicadas a tu cert-manager existente antes de actualizar a clústeres avanzados.

Para ver si aplicaste parámetros de configuración o funciones personalizados críticos a tu cert-manager, haz lo siguiente:

Suspender las herramientas de implementación continua Si administras cert-manager con herramientas de GitOps (como el Sincronizador de configuración, ArgoCD o Flux), suspende la sincronización o quita los manifiestos de cert-manager de tu repositorio antes de actualizar. Si un controlador de GitOps intenta conciliar cert-manager con una versión anterior o un manifiesto personalizado mientras se ejecuta la actualización del clúster, se crea un bucle de conciliación que puede detener la actualización del clúster.
No desinstales ni borres de forma manual los Pods, los espacios de nombres ni las CRD de cert-manager antes de actualizar. gkectl administra estas actualizaciones in situ.
Si modificaste las marcas de implementación de cert-manager, los selectores de nodos o los límites de recursos de Pods, reviértelos. Los clústeres avanzados no admiten argumentos binarios personalizados ni anulaciones a nivel de la implementación en cert-manager.
Si usas emisores externos especializados, complementos de webhook de ACME DNS-01 privados o webhooks personalizados, verifica que tus complementos de terceros sean compatibles con la versión de cert-manager empaquetada para la versión a la que actualizas.

Para obtener más información, consulta Actualiza a cert-manager incluido en los clústeres avanzados.

En la siguiente tabla, se enumeran las versiones de actualización que requieren cert-manager empaquetado:

Versión	Estado de los clústeres nuevos	Estado de las actualizaciones de clústeres existentes	¿Se requiere `cert-manager` empaquetado?
1.34+	Obligatorio	Conversión obligatoria (incluida en la versión 1.19)	Es obligatorio para todos los clientes. Los clústeres no avanzados ya no pueden existir.
1.33	Estándar/predeterminado para todos los clústeres nuevos	Se convierte automáticamente en clústeres avanzados de forma predeterminada (v1.18 incluida)	Es obligatorio para casi todos los clústeres, a menos que se inhabilite de forma explícita con `enableAdvancedCluster: false` (solo de la versión 1.32 a la 1.33).
1.32 (DG)	Habilitado de forma predeterminada	Conversión opcional a clústeres avanzados	Es obligatorio si se habilitan los clústeres avanzados.
1.31 (versión preliminar)	Opcional (`enableAdvancedCluster: true`)	No compatible	Es obligatorio si se habilitan los clústeres avanzados.

Para ver qué versión de cert-manager se incluye en cada versión compatible, consulta Versiones de cert-manager incluidas.

Plano de control V2

Cuando Controlplane V2 está habilitado, el plano de control del clúster de usuario se ejecuta en el propio clúster de usuario. En el caso de Controlplane V2, los nodos del plano de control del clúster de usuario se actualizan durante la actualización del clúster de usuario, y los nodos del plano de control del clúster de administrador se actualizan durante la actualización del clúster de administrador.

Funciones heredadas

En la siguiente tabla, se enumeran las funciones heredadas que están bloqueadas en la versión 1.32 y posteriores. Si usas estas funciones, debes migrar a las alternativas recomendadas antes de actualizar a la versión 1.32 o posterior.

| Función heredada (bloqueada en la versión 1.32) | Reemplazar por (recomendado) | Vínculo a las instrucciones de migración | | --- | --- | --- | | Dataplane V1 (Calico) | Dataplane V2 (Cilium/eBPF) | Migra a Dataplane V2| | Kubeception | Controlplane V2 | Migra a Controlplane V2 | | Clúster de administrador sin alta disponibilidad (1 réplica) | Clúster de administrador con alta disponibilidad (3 réplicas) | Migra al clúster de administrador con alta disponibilidad | | Balanceador de cargas Seesaw | MetalLB o ManualLB | Migra a MetalLB o Migra el tipo de balanceador de cargas| | F5 BIG-IP integrado (loadBalancer.kind: "F5BigIP") | ManualLB (vinculado con el controlador F5 Big-IP o CCGI) | Migra a ManualLB |

Para obtener detalles sobre cómo migrar de las funciones heredadas a las recomendadas, consulta Planifica la migración de clústeres a las funciones recomendadas.

Migración de Kubeception y comportamiento de las versiones

Kubeception es una función heredada que se debe migrar a Controlplane V2 antes de que puedas actualizar a la versión 1.32 o posterior.

Las actualizaciones se comportan de manera diferente para los clústeres con Kubeception según tu versión:

Para la versión 1.28: Actualización del plano de control y los nodos de administrador durante la actualización del clúster de administrador
Para la versión 1.29: Actualización del plano de control y los nodos de administrador durante la actualización del clúster de administrador
Para la versión 1.30: El plano de control y los nodos de administrador se actualizan durante la actualización del clúster de administrador. Si usas Kubeception, esto es lo que sucede durante una actualización:
1. Actualiza el clúster de usuario. Debido a que el plano de control del usuario se encuentra dentro del clúster de administrador, la ejecución de gkectl upgrade cluster solo actualiza los grupos de nodos trabajadores.
2. Actualiza el clúster de administrador. La actualización del clúster de administrador actualiza los nodos de administrador y, al mismo tiempo, actualiza de forma automática todos los planos de control de los clústeres de usuario.
Para la versión 1.31: Los nodos de administrador se actualizan con el clúster de administrador; los nodos del plano de control del usuario se actualizan con el clúster de usuario.
Para la versión 1.32 y posteriores, no se admite Kubeception. Debes migrar al plano de control V2 antes de actualizar a la versión 1.32 o posterior.

Para obtener detalles sobre cómo migrar Kubeception a Controlplane V2, consulta Planifica la migración del clúster a las funciones recomendadas.

Sesgo de versiones en comparación con omitir una versión durante la actualización

La desviación de versión es la diferencia permitida en las versiones secundarias entre un clúster de administrador y sus clústeres de usuario administrados, o la diferencia en las versiones secundarias entre el plano de control de un clúster de usuario y los grupos de nodos en el clúster de usuario.

La desviación de versión es diferente de omitir una versión secundaria cuando actualizas.

Solo puedes omitir una versión secundaria cuando actualizas grupos de nodo trabajador, después de actualizar el plano de control. Esto se aplica a los clústeres avanzados y no avanzados, excepto a los clústeres avanzados que ejecutan la versión 1.31 y las versiones anteriores a la 1.28. Por ejemplo, si un grupo de nodo trabajador está en la versión 1.29, actualiza el plano de control del clúster de usuario a la versión 1.30 y, luego, a la 1.31. Después de que el plano de control esté en la versión 1.31, actualiza el grupo de nodo trabajador de la versión 1.29 a la 1.31 directamente, sin actualizar a la versión 1.30. Para obtener más información, consulta Omite una versión cuando actualices grupos de nodos.

Para actualizar a una versión secundaria superior a la siguiente versión secundaria, primero actualiza a la siguiente versión secundaria y, luego, a la versión secundaria superior. No puedes omitir una versión secundaria cuando actualizas los planos de control de los clústeres de administrador y de usuario. Por ejemplo, si deseas actualizar de la versión 1.34.x a la versión 1.36.x, no puedes actualizar directamente. Primero debes actualizar de la versión 1.34.x a la 1.35.x y, luego, a la 1.36.x.

El plano de control de un clúster de usuario puede ser de hasta 2 versiones secundarias más recientes que los grupos de nodo trabajador del clúster. Por ejemplo, si el plano de control de un clúster de usuario está en la versión 1.36, los grupos de nodo trabajador del clúster pueden ser 1.34, 1.35 o 1.36.

¿Qué diferencias de versión se permiten?

Un clúster de administrador puede administrar clústeres de usuario de hasta 2 versiones secundarias anteriores. Por ejemplo, si un clúster de administrador está en la versión 1.31, los clústeres de usuario que administra ese clúster de administrador pueden estar en la versión 1.29, 1.30 o 1.31.

Antes de la versión 1.31, se aplican las siguientes reglas de desvío de versiones:

En las versiones 1.28 a 1.30, los clústeres de usuario pueden ser de hasta 2 versiones secundarias más recientes que su clúster de administrador. Por ejemplo, si un clúster de administrador está en la versión 1.15, los clústeres de usuario que administra ese clúster de administrador pueden estar en la versión 1.15, 1.16 o 1.28. No puedes actualizar un clúster de usuario de la versión 1.28 a la 1.29 hasta que el clúster de administrador se actualice, al menos, a la versión 1.16. Debido a que la versión 1.31 cambia el orden de actualización para requerir primero la actualización del clúster de administrador, un clúster de administrador en 1.29 o 1.30 no puede administrar clústeres de usuario en 1.31 o 1.32. Todos los clústeres de usuario y el clúster de administrador deben alcanzar la versión 1.30 antes de que puedas actualizar el clúster de administrador a la versión 1.31.
En las versiones 1.16 y anteriores, los clústeres de usuario solo pueden ser 1 versión secundaria superior a su clúster de administrador. Por ejemplo, si un clúster de administrador está en la versión 1.15, los clústeres de usuario que administra ese clúster de administrador pueden estar en la versión 1.15 o 1.16.

¿Debo actualizar los clústeres de usuario todos a la vez?

Cuando actualizas clústeres de usuario, puedes elegir una de las siguientes opciones:

Actualiza todo el clúster de usuario con el plano de control y todos los grupos de nodos del clúster al mismo tiempo.
Actualiza el plano de control del clúster de usuario y deja los grupos de nodos en la versión actual.
Actualiza el plano de control del clúster de usuario y, de forma selectiva, los grupos de nodos.

El enfoque que adoptes dependerá de varios factores, como los siguientes:

El entorno (de producción o no producción) en el que se encuentra el clúster.
La duración del período de mantenimiento.
Es la versión del clúster de usuario.

Por ejemplo, es posible que desees actualizar el plano de control del clúster de usuario y todos los grupos de nodos en un entorno de desarrollo. Sin embargo, en un entorno de producción con un período de mantenimiento corto, es posible que desees actualizar solo el plano de control, ya que eso lleva menos tiempo y la actualización del plano de control no debería interrumpir las cargas de trabajo de los usuarios.

Los grupos de nodos del balanceador de cargas (grupos de nodos con enableLoadBalancer: true) deben tener la misma versión que el clúster para cada versión.

Reglas de versión para `gkectl`

La versión de gkectl que puedes usar para la actualización depende de la versión del clúster de destino (es decir, la versión del clúster a la que actualizas). Por lo general, usas la misma versión de gkectl que la versión de destino del clúster. Durante la actualización, se aplican las siguientes reglas:

La versión de gkectl debe ser igual o superior a la versión secundaria de destino del clúster. Por ejemplo, si actualizas un clúster de la versión 1.29 a la 1.30, debes usar gkectl 1.30 o una versión posterior. Las versiones de los parches no importan.
La versión de gkectl puede ser hasta dos versiones secundarias más reciente que la versión actual del clúster. Por ejemplo, para actualizar un clúster 1.28 a 1.29, usa la versión 1.29 o 1.30 de gkectl, pero no la versión 1.31, ya que es tres versiones secundarias superior a la versión del clúster.

La versión binaria de gkectl debe coincidir exactamente con la versión de actualización de destino cuando conviertes clústeres no avanzados en avanzados. Este requisito estricto de versión solo se aplica durante la actualización a un clúster avanzado. Para todas las demás actualizaciones avanzadas de clústeres, se aplican las reglas de desvío de versiones estándar.