Descripción general de la actualización

En esta página se ofrece una descripción general del proceso de actualización y de la información sobre la diferencia de versiones de Google Distributed Cloud (solo software) para clústeres de VMware. Esta información debería ayudarte a planificar el orden en el que vas a actualizar los clústeres en un entorno de varios clústeres. Para obtener información más detallada sobre la planificación, incluida una lista de comprobación que te ayudará a planificar la actualización, consulta las prácticas recomendadas para las actualizaciones.

Esta página está dirigida a administradores y operadores de TI que gestionan el ciclo de vida de la infraestructura tecnológica subyacente. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud

Diferencias entre los clústeres avanzados

Cuando se habilitan los clústeres avanzados, hay algunas diferencias con las actualizaciones, sobre todo en la vista previa de los clústeres avanzados de la versión 1.31. Para ver las diferencias de la actualización, busca la palabra advanced en este documento. Para ver una tabla con todas las diferencias, consulta Diferencias al ejecutar clústeres avanzados.

Actualización automática a clústeres avanzados en la versión 1.33

  • Asegúrate de que la versión de gkectl: la versión de gkectl debe ser la misma que la de destino. Por ejemplo, si actualizas un clúster no avanzado de la versión 1.32 a un clúster avanzado de la versión 1.33.0-gke.799, la versión de gkectl debe ser 1.33.0-gke.799. Este requisito estricto de la versión solo se aplica durante la transición a un clúster avanzado. En todas las actualizaciones posteriores de tu clúster avanzado, se aplicarán las reglas de desviación de versión estándar.
  • No se permite la diferencia de versiones: al actualizar de un clúster no avanzado a uno avanzado, no puedes actualizar el plano de control y los grupos de nodos por separado. Debes actualizar el plano de control y todos los grupos de nodos a la versión 1.33 al mismo tiempo.

Reglas de versiones

Las reglas de las actualizaciones dependen de la versión secundaria del clúster.

  • En las versiones 1.30 y anteriores, la versión secundaria del clúster de usuarios debe ser igual o superior a la versión secundaria del clúster de administrador. La versión del parche no importa. Por ejemplo, si un clúster de usuarios tiene la versión 1.30.1, el clúster de administradores se puede actualizar a una versión de parche superior, como la 1.30.3.

  • En las versiones 1.31 y posteriores, la versión del clúster de administrador, incluida la versión del parche, debe ser igual o posterior a la versión del clúster de usuario. Por ejemplo, si un clúster de administradores tiene la versión 1.31.1, la versión más alta a la que se puede actualizar el clúster de usuarios es la 1.31.1.

Si quieres actualizar tus clústeres a la versión 1.31, primero debes actualizar todos tus clústeres a la versión 1.30. Una vez que todos los clústeres tengan la versión 1.30, actualiza el clúster de administrador a la versión 1.31. Después, puedes actualizar los clústeres de usuarios a la misma versión de parche 1.31 que el clúster de administrador.

Reglas de versión de 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 al que vas a actualizar). Normalmente, se usa 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 gkectl no puede ser una versión secundaria inferior a la versión secundaria del clúster de destino. Por ejemplo, si vas a actualizar un clúster de la versión 1.29 a la 1.30, no puedes usar la versión 1.29, ya que es inferior a la versión del clúster de destino.gkectl Las versiones de parche no importan. Por ejemplo, puedes usar la versión gkectl 1.29.0-gke.1456 para actualizar a una versión de parche superior, como la 1.29.1000-gke.94.

  • La versión gkectl no puede ser más de dos versiones secundarias superior a la versión actual del clúster. Por ejemplo, si actualizas un clúster de la versión 1.28 a la 1.29, la versión de gkectl puede ser la 1.29 o la 1.30. Sin embargo, no puedes usar la versión 1.31 de gkectl porque es tres versiones secundarias superior a la versión del clúster.

  • Si actualizas el clúster a un clúster avanzado, la versión de gkectl debe ser la misma que la versión de destino. Por ejemplo, si actualizas un clúster no avanzado de la versión 1.32 a un clúster avanzado de la versión 1.33.0-gke.799, la versión de gkectl debe ser 1.33.0-gke.799.

    • Tu clúster se actualizará a clúster avanzado de forma predeterminada en la versión 1.33. Esto significa que, para las actualizaciones de 1.32 a 1.33, la versión de gkectl debe ser la misma que la versión actualizada.

    • Este requisito de versión estricto solo se aplica durante la transición a un clúster avanzado. En todas las actualizaciones posteriores de tu clúster avanzado, se aplicarán las reglas de desviación de versión estándar.

Si es necesario, consulta Descargar gkectl para obtener una versión compatible de gkectl.

Para obtener información sobre las diferencias de versión entre los clústeres de administrador y de usuario, consulta la sección Diferencia de versión de este documento.

Funciones antiguas bloqueadas en las actualizaciones

Dataplane V2 es obligatorio para todos los clústeres de usuarios. Antes de actualizar un clúster de usuarios a la versión 1.31, sigue los pasos que se indican en Habilitar Dataplane V2.

Las siguientes funciones antiguas se bloquean durante la actualización del clúster a la versión 1.32:

  • Configuración integrada del balanceador de carga F5 Big IP
  • Clúster de administrador sin alta disponibilidad
  • Clúster de usuarios de Kubeception
  • Balanceador de carga de Seesaw

Debes migrar tus clústeres a las funciones recomendadas antes de actualizar a la versión 1.32.

Secuencia de actualización

La secuencia en la que actualices los clústeres de administrador y de usuario depende de la versión a la que vayas a actualizar, denominada versión de destino:

1.31 y versiones posteriores

Si la versión de destino es la 1.31 o una posterior, debes actualizar el clúster de administrador antes de actualizar los clústeres de usuarios que gestiona. En los siguientes pasos se describe la secuencia de actualización.

  1. Actualiza la estación de trabajo de administrador. Te recomendamos que lo hagas aunque tengas previsto usar la consola, la CLI de Google Cloud o Terraform para actualizar los clústeres de usuario. Google Cloud

  2. Actualiza el clúster de administrador.

  3. Actualiza los clústeres de usuarios de uno en uno.

    • También puedes actualizar el plano de control de un clúster de usuarios por separado de los grupos de nodos del clúster de usuarios. Para obtener más información, consulta Actualizar grupos de nodos.

      • Versión 1.31: no disponible en clústeres avanzados.
      • Versión 1.32 y posteriores: disponible en clústeres avanzados.

    • Si quieres, puedes saltarte una versión secundaria al actualizar grupos de nodos. Para obtener más información, consulta Saltar una versión al actualizar grupos de nodos.

      • Versión 1.31: no disponible en clústeres avanzados.
      • Versión 1.32 y posteriores: disponible en clústeres avanzados.

    Cuando todos los grupos de nodos de un clúster de usuarios tienen la misma versión que el plano de control del clúster de usuarios, el clúster de usuarios se actualiza por completo.

1.30 y versiones anteriores

Si la versión de destino es la 1.30 o una anterior, debes actualizar todos los clústeres de usuarios antes de actualizar el clúster de administradores que los gestiona.

  1. Actualiza la estación de trabajo de administrador. Te recomendamos que lo hagas aunque tengas previsto usar la consola, la CLI de Google Cloud o Terraform para actualizar los clústeres de usuario. Google Cloud

  2. Actualiza los clústeres de usuarios de uno en uno.

    • En la versión 1.14 y posteriores, puedes actualizar el plano de control de un clúster de usuarios por separado de los grupos de nodos del clúster de usuarios.

    • En la versión 1.16 y posteriores, puedes omitir una versión secundaria al actualizar grupos de nodos. Para obtener más información, consulta Saltar una versión al actualizar grupos de nodos.

    Cuando todos los grupos de nodos de un clúster de usuarios tienen la misma versión que el plano de control del clúster de usuarios, el clúster de usuarios se actualiza por completo.

    Un clúster de administradores no puede tener una versión secundaria superior a la de ninguno de los clústeres de usuarios que gestiona. Si alguno de tus clústeres de usuarios tiene la misma versión menor que el clúster de administrador, no podrás actualizar este último.

  3. Cuando todos los clústeres de usuarios tengan al menos una versión secundaria posterior a la del clúster de administrador, puedes actualizar este último de forma opcional.

Las reglas de sesgo y de versión para las actualizaciones han cambiado en la versión 1.28 y posteriores. Para obtener más información, consulta la sección Diferencia de versiones de este documento.

Orden en el que se actualizan los nodos

El orden en el que se actualizan los nodos de plano de control del clúster de administrador, los nodos de plano de control del clúster de usuario y los nodos de trabajador del clúster de usuario depende de la versión de destino y de si Controlplane V2 está habilitado en el clúster de usuario.

Controlplane V2

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

Kubeception

Si Controlplane V2 no está habilitado, el plano de control del clúster de usuarios se ejecuta en uno o varios nodos del clúster de administrador. Esta configuración se denomina "kubeception". En el caso de los clústeres kubeception, la versión de actualización determina el comportamiento de la actualización de nodos:

Actualizar versión Comportamiento de la actualización de nodos
1.32 y versiones posteriores No se admiten clústeres de Kubeception. Debes migrar todos los clústeres de usuarios a Controlplane V2 antes de actualizar a la versión 1.32.
1.31
  • Los nodos del clúster de administración se actualizan durante la actualización del clúster de administración.
  • Los nodos del plano de control del clúster de usuarios se actualizan durante la actualización del clúster de usuarios.
1.30 y versiones anteriores Tanto los nodos de plano de control del clúster de usuarios como los nodos de plano de control del clúster de administrador se actualizan durante la actualización del clúster de administrador.

Actualizaciones del clúster de administrador

1.31 y versiones posteriores

Si la versión de destino es la 1.31 o una posterior, primero debes actualizar el clúster de administrador y, después, los clústeres de usuario.

Puedes usar gkectl o la CLI de gcloud para actualizar los clústeres de administrador.

1.30 y versiones anteriores

Si la versión de destino es la 1.30 o una anterior, actualiza primero todos los clústeres de usuarios y, después, el clúster de administrador. Puedes actualizar el clúster de administradores cuando el plano de control y los grupos de nodos de todos los clústeres de usuarios tengan una versión secundaria superior a la del clúster de administradores.

Solo gkectl admite la actualización de clústeres de administrador. Los clientes de la API de GKE On-Prem no admiten la actualización de clústeres de administrador.

Actualizaciones de clústeres de usuarios

Cuando actualizas clústeres de usuarios, puedes actualizar todo el clúster (es decir, el plano de control y todos los grupos de nodos del clúster) o solo el plano de control del clúster de usuarios y dejar los grupos de nodos en la versión actual. El enfoque que elijas dependerá de varios factores, como los siguientes:

  • El entorno (de producción o no de producción) en el que se encuentra el clúster.
  • La duración de la ventana de mantenimiento.
  • La versión del clúster de usuarios.

Por ejemplo, en un entorno de desarrollo, puede que quieras simplificar el proceso y actualizar tanto el plano de control del clúster de usuarios como todos los grupos de nodos. Sin embargo, en un entorno de producción con una ventana de mantenimiento breve, puede que solo quieras actualizar el plano de control, ya que lleva menos tiempo y, con los planos de control de alta disponibilidad, la actualización del plano de control no debería interrumpir las cargas de trabajo de los usuarios. Cuando el plano de control tenga la versión 1.28 o una posterior, puedes saltarte una versión secundaria al actualizar grupos de nodos.

  • Versión 1.31: no disponible en clústeres avanzados.
  • Versión 1.32 y posteriores: disponible en clústeres avanzados.

Actualizar grupos de nodos de forma selectiva

En determinadas situaciones, puede que quieras actualizar algunos grupos de nodos de un clúster de usuario, pero no todos. Por ejemplo, después de actualizar el plano de control, puedes actualizar un grupo de nodos que tenga poco tráfico o que ejecute tus cargas de trabajo menos críticas. Cuando te asegures de que tus cargas de trabajo se ejecutan correctamente en la nueva versión, puedes actualizar más grupos de nodos hasta que todos los grupos de nodos se hayan actualizado. Para obtener más información, consulta Actualizar grupos de nodos.

Saltar una versión secundaria al actualizar grupos de nodos

Si tus clústeres tienen la versión 1.16 o una posterior, puedes saltarte una versión secundaria al actualizar los grupos de nodos. Si se realiza una actualización de versión omitida, el tiempo que se tarda en actualizar secuencialmente los grupos de nodos dos versiones se reduce a la mitad. Además, las actualizaciones de versiones omitidas te permiten aumentar el tiempo entre las actualizaciones necesarias para mantenerte en una versión compatible. Reducir el número de actualizaciones disminuye las interrupciones de la carga de trabajo y el tiempo de verificación. Para obtener más información, consulta Saltar una versión al actualizar grupos de nodos.

Elige una herramienta para actualizar los clústeres de usuarios

Google Distributed Cloud te ofrece varias herramientas para actualizar los clústeres de usuarios.

  • La herramienta de línea de comandos gkectl, que se ejecuta en la estación de trabajo del administrador. Antes de actualizar, debes modificar el archivo de configuración del clúster de usuarios para definir la versión de destino del plano de control del clúster y, opcionalmente, de los grupos de nodos. Este archivo se especifica en la línea de comandos de gkectl.

    Si tienes habilitado el clúster avanzado, debes usar gkectl para la actualización. Los clientes de la API de GKE On-Prem no se admiten en clústeres avanzados.

  • La Google Cloud consola, la CLI de Google Cloud o Terraform, que puedes ejecutar desde cualquier ordenador que tenga conectividad de red con la API de GKE On-Prem. Estas herramientas estándar son clientes de la API de GKE On-Prem, que se ejecuta en la infraestructura de Google Cloud .

    • Solo puedes usar Terraform para la actualización si has creado el clúster de usuario con Terraform.

    • Si tu clúster de usuario se creó con gkectl, debe registrarse en la API GKE On-Prem para usar la consola o la CLI de gcloud en la actualización. En la versión 1.16 y posteriores, los clústeres creados con gkectl se registran en la API de GKE On-Prem de forma predeterminada. En el caso de los clústeres creados en versiones anteriores, puedes registrar el clúster después de crearlo.

      Aunque decidas usar gkectl para la actualización, puede que quieras registrar el clúster en la API GKE On-Prem para obtener información sobre los clústeres mediante la consola o la CLI de gcloud.

La herramienta que utilices dependerá de cómo tengas previsto actualizar los clústeres de usuarios:

  • Actualizar el clúster en su conjunto: puedes usar gkectl, la consola de Google Cloud , la interfaz de línea de comandos de Google Cloud o Terraform para actualizar un clúster de usuario (el plano de control junto con todos los grupos de nodos).

  • Actualizar solo el plano de control: Puedes usar gkectl, la interfaz de línea de comandos gcloud o Terraform para actualizar el plano de control de un clúster de usuarios por separado de los grupos de nodos. La consola no admite la actualización solo del plano de control.

  • Actualizar selectivamente los grupos de nodos después de actualizar el plano de control: puedes usar gkectl, la CLI de gcloud o Terraform para actualizar grupos de nodos específicos después de actualizar el plano de control.

  • Actualizar el plano de control y uno o varios grupos de nodos al mismo tiempo: solo gkectl admite este caso práctico.

Diferencia de versiones

La diferencia de versión es la diferencia entre las versiones secundarias de un clúster de administrador y sus clústeres de usuario gestionados. En las siguientes secciones, la versión del clúster de usuario hace referencia a la versión del plano de control y de los grupos de nodos en conjunto.

Además, la diferencia de versiones es la diferencia entre las versiones secundarias del plano de control de un clúster de usuarios y los grupos de nodos del clúster de usuarios.

En un entorno de varios clústeres, conocer la diferencia de versiones admitida y las reglas de versiones para las actualizaciones puede ayudarte a planificar el orden en el que actualizas los clústeres.

Diferencia de versión entre el clúster de administradores y el de usuarios

Un clúster de administrador puede gestionar clústeres de usuarios que tengan versiones diferentes. Esta función te permite actualizar una flota de clústeres de usuarios según una programación que se adapte a tu organización.

1.31 y versiones posteriores

En la versión 1.31 y posteriores, el clúster de administrador puede tener hasta dos versiones secundarias más que sus clústeres de usuario. Por ejemplo, si un clúster de administrador tiene la versión 1.31, los clústeres de usuario que gestione pueden tener las versiones 1.29, 1.30 o 1.31.

Por lo general, si 1.n es la versión secundaria del clúster de administradores, los clústeres de usuarios pueden tener la versión 1.n-2, 1.n-1 o 1.n. El clúster de administrador no se puede actualizar a la siguiente versión secundaria hasta que todos los clústeres de usuario tengan la versión 1.n o 1.n-1.

1.29 - 1.30

La diferencia de versiones es la misma que en la versión 1.28. En la versión 1.29, esta función pasó a la fase de disponibilidad general.

En la versión 1.29 y posteriores, los clústeres de usuarios pueden tener hasta dos versiones secundarias superiores a las de su clúster de administrador. Por ejemplo, si un clúster de administrador tiene la versión 1.31, los clústeres de usuario gestionados por ese clúster de administrador pueden tener las versiones 1.31, 1.32 o 1.33.

Por lo general, si 1.n es la versión secundaria del clúster de administrador, los clústeres de usuarios pueden tener la versión 1.n, 1.n+1 o 1.n+2. Los clústeres de usuarios con la versión 1.n+2 no se pueden actualizar a la siguiente versión secundaria hasta que el clúster de administrador se actualice al menos a una versión secundaria.

1,28

En la versión 1.28, los clústeres de usuarios pueden tener hasta dos versiones secundarias más que su clúster de administrador. Por ejemplo, si un clúster de administrador tiene la versión 1.15, los clústeres de usuario gestionados por ese clúster de administrador pueden tener las versiones 1.15, 1.16 o 1.28. Los clústeres de usuarios con la versión 1.28 no se pueden actualizar a la versión 1.29 hasta que el clúster de administradores se actualice al menos a la versión 1.16.

1.16 y versiones anteriores

En la versión 1.16 y anteriores, los clústeres de usuarios solo pueden tener una versión secundaria superior a la de su clúster de administrador. Por ejemplo, si un clúster de administrador tiene la versión 1.15, los clústeres de usuario que gestione pueden tener la versión 1.15 o 1.16.

Por lo general, si 1.n es la versión secundaria del clúster de administrador, los clústeres de usuario pueden tener la versión 1.n o 1.n+1. Los clústeres de usuarios no se pueden actualizar a la siguiente versión secundaria hasta que el clúster de administrador tenga la misma versión secundaria que el clúster de usuarios.

Diferencia de versión entre el plano de control y el grupo de nodos de un clúster de usuarios

1.29 y versiones posteriores

La diferencia de versiones es la misma que en la versión 1.28. En la versión 1.29, esta función pasó a la fase de disponibilidad general.

En la versión 1.29 y posteriores, el plano de control de un clúster de usuarios puede tener hasta dos versiones secundarias más que los grupos de nodos del clúster. Por ejemplo, si el plano de control de un clúster de usuario tiene la versión 1.33, los grupos de nodos del clúster pueden tener las versiones 1.31, 1.32 o 1.33.

En términos generales, si 1.n es la versión secundaria del plano de control de un clúster de usuarios, los grupos de nodos del clúster pueden tener la versión 1.n, 1.n-1 o 1.n-2. Los planos de control de los clústeres de usuarios no se pueden actualizar a la siguiente versión secundaria hasta que todos los grupos de nodos tengan la versión 1.n o 1.n-1.

1,28

En la versión 1.28, el plano de control de un clúster de usuarios puede tener hasta dos versiones secundarias más que los grupos de nodos del clúster. Por ejemplo, si el plano de control de un clúster de usuario es 1.28, los grupos de nodos del clúster pueden ser 1.15, 1.16 o 1.28. Los planos de control de los clústeres de usuarios no se pueden actualizar a la versión 1.29 hasta que todos los grupos de nodos estén en la versión 1.28 o 1.16.

1.16 y versiones anteriores

En la versión 1.16 y anteriores, el plano de control de un clúster de usuarios solo puede ser 1 versión secundaria superior a los grupos de nodos del clúster. Por ejemplo, si el plano de control de un clúster de usuario tiene la versión 1.16, los grupos de nodos del clúster pueden tener la versión 1.15 o 1.16.

En términos generales, si 1.n es la versión secundaria del plano de control de un clúster de usuarios, los grupos de nodos del clúster pueden tener la versión 1.n o 1.n-1. Los clústeres de usuarios no se pueden actualizar a la siguiente versión secundaria hasta que todos los grupos de nodos tengan la misma versión secundaria que el plano de control.

Reglas de versiones para las actualizaciones del plano de control de clústeres de administrador y de usuario

Las reglas de las versiones para las actualizaciones del plano de control de los clústeres de administrador y de usuario son las mismas. Puedes actualizar directamente a cualquier versión que esté en la misma versión secundaria o en la siguiente. Por ejemplo, puedes actualizar de la versión 1.33.0 a la 1.33.1 o de la 1.32.1 a la 1.33.0. Las versiones de parche no afectan a las reglas de la versión de actualización.

Si vas a actualizar a una versión que no forma parte de la siguiente versión secundaria, debes actualizar a través de una versión de cada versión secundaria entre tu versión actual y la versión de destino. No se admite saltar una versión secundaria. Por ejemplo, si quieres actualizar de la versión 1.31.x a la 1.33.x, no puedes hacerlo directamente. Primero debes actualizar de la versión 1.31.x a la 1.32.x y, después, a la 1.33.x.

Por lo general, solo se admiten actualizaciones de 1.n a 1.n+1 para las actualizaciones de clústeres de administrador y de planos de control de clústeres de usuarios.

Reglas de versiones para las actualizaciones de grupos de nodos

En la versión 1.28 y posteriores, puedes saltarte una versión secundaria al actualizar un grupo de nodos de un clúster de usuario. Por ejemplo, si el plano de control de un clúster de usuarios tiene la versión 1.33 y un grupo de nodos tiene la versión 1.31, puedes omitir la versión 1.32 y actualizar el grupo de nodos directamente a la versión 1.33. Las versiones de parche no afectan a las reglas de las versiones de actualización.

Por lo general, si el plano de control de un clúster de usuarios está en la versión 1.n, puedes actualizar directamente a 1.n los grupos de nodos que estén en la versión 1.n-2. Si te saltas una versión secundaria al actualizar los grupos de nodos, puede que se reduzca el tiempo en comparación con si realizas dos actualizaciones de grupos de nodos (para pasar de 1.n-2 a 1.n-1 y, después, a 1.n). Este es otro motivo por el que puede que prefieras actualizar el plano de control de un clúster de usuarios por separado de los grupos de nodos que se ejecutan en el clúster de usuarios.

  • Versión 1.31: no disponible en clústeres avanzados.
  • Versión 1.32 y posteriores: disponible en clústeres avanzados.

Actualizaciones de versiones de parches

Te recomendamos que actualices a la versión más reciente del parche siempre que sea posible para asegurarte de que tus clústeres tienen las correcciones de seguridad más recientes. Las versiones de parche no afectan a las reglas de actualización ni a la diferencia de versiones. En una versión secundaria determinada, puedes actualizar a cualquier versión de parche superior. Es decir, puedes actualizar un clúster de la versión 1.33.X a la versión 1.33.Y siempre que Y sea mayor que X. Por ejemplo, puedes cambiar de 1.32.0 a 1.32.1 y de 1.32.1 a 1.32.3.

Siguientes pasos

Consulta las prácticas recomendadas para actualizar y crea un plan para actualizar tus clústeres.