Descripción general de la actualización

En esta página, se proporciona una descripción general del proceso de actualización y la información sobre la diferencia de versiones para los clústeres de Google Distributed Cloud (solo software) para VMware. Esta información debería ayudarte a planificar el orden en el que actualizarás 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 tareas pendientes que te ayudará a planificar la actualización, consulta Prácticas recomendadas para la actualización.

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

Diferencias entre los clústeres avanzados

Cuando se habilitan los clústeres avanzados, hay algunas diferencias con las actualizaciones, en particular en la vista previa de los clústeres avanzados en la versión 1.31. Para ver las diferencias de actualización, busca la palabra advanced en este documento. Para ver una tabla con todas las diferencias, consulta Diferencias cuando se ejecutan 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 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. Este requisito estricto de versión solo se aplica durante la transición a un clúster avanzado. Para todas las actualizaciones posteriores en tu clúster avanzado, se aplicarán las reglas estándar de sesgo de versión.
  • No se permite el sesgo de versiones: Cuando actualizas un clúster de no avanzado a 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 para 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 usuario debe ser mayor o igual que la versión secundaria del clúster de administrador. La versión del parche no importa. Por ejemplo, si un clúster de usuario está en la versión 1.30.1, el clúster de administrador se puede actualizar a una versión de parche superior, como la 1.30.3.

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

Cuando quieras actualizar tus clústeres a la versión 1.31, primero debes llevar todos tus clústeres a la versión 1.30. Después de que todos los clústeres estén en la versión 1.30, actualiza el clúster de administrador a la versión 1.31. Después de eso, puedes actualizar los clústeres de usuario a la misma versión de parche 1.31 que el clúster de administrador.

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

  • La versión de 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 1.29 o 1.30. Sin embargo, no puedes usar la versión 1.31 de gkectl porque es tres versiones secundarias más alta que 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.

    • De forma predeterminada, tu clúster se actualizará a un clúster avanzado 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 estricto de versión solo se aplica durante la transición a un clúster avanzado. Para todas las actualizaciones posteriores en tu clúster avanzado, se aplicarán las reglas estándar de sesgo de versión.

Si es necesario, consulta Descarga 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 en este documento.

Se bloquearon las funciones heredadas en las actualizaciones

Dataplane V2 es obligatorio para todos los clústeres de usuarios. 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 siguientes funciones heredadas se bloquean durante la actualización del clúster a la versión 1.32:

  • Configuración del balanceador de cargas F5 Big IP integrado
  • Clúster de administrador sin alta disponibilidad
  • Clúster de usuario de Kubeception
  • Balanceador de cargas 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 actualizas los clústeres de administrador y de usuario depende de la versión del clúster a la que se actualiza, denominada versión de destino:

1.31 y versiones más altas

Cuando la versión de destino sea 1.31 o posterior, debes actualizar tu clúster de administrador antes de actualizar los clústeres de usuario que administra el clúster de administrador. 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 incluso si planeas usar la consola de Google Cloud , Google Cloud CLI o Terraform para actualizar los clústeres de usuarios.

  2. Actualiza el clúster de administrador.

  3. Actualiza los clústeres de usuario de a uno por vez.

    • De manera opcional, puedes actualizar el plano de control de un clúster de usuario por separado de los grupos de nodos en el clúster de usuario. Para obtener más información, consulta Actualiza grupos de nodos.

      • Versión 1.31: No está disponible en clústeres avanzados.
      • Versión 1.32 y posteriores: Disponible en clústeres avanzados.

    • De manera opcional, puedes omitir una versión secundaria cuando actualices grupos de nodos. Para obtener más información, consulta Cómo omitir una versión cuando actualizas grupos de nodos.

      • Versión 1.31: No está disponible en clústeres avanzados.
      • Versión 1.32 y posteriores: Disponible en clústeres avanzados.

    Una vez que todos los grupos de nodos de un clúster de usuario tengan la misma versión que el plano de control del clúster de usuario, el clúster de usuario se habrá actualizado por completo.

1.30 y versiones más bajas

Cuando la versión de destino sea 1.30 o inferior, debes actualizar todos los clústeres de usuario antes de actualizar el clúster de administrador que los administra.

  1. Actualiza la estación de trabajo de administrador. Te recomendamos que lo hagas incluso si planeas usar la consola de Google Cloud , Google Cloud CLI o Terraform para actualizar los clústeres de usuarios.

  2. Actualiza los clústeres de usuario de a uno por vez.

    • En la versión 1.14 y en las posteriores, puedes actualizar de forma opcional el plano de control de un clúster de usuario por separado de los grupos de nodos en el clúster de usuario.

    • En la versión 1.16 y en las posteriores, puedes omitir una versión secundaria cuando actualices grupos de nodos. Para obtener más información, consulta Cómo omitir una versión cuando actualizas grupos de nodos.

    Una vez que todos los grupos de nodos de un clúster de usuario tengan la misma versión que el plano de control del clúster de usuario, el clúster de usuario se habrá actualizado por completo.

    Un clúster de administrador no puede tener una versión secundaria más reciente que cualquiera de los clústeres de usuario que administra. Si alguno de tus clústeres de usuario tiene la misma versión secundaria que el clúster de administrador, no podrás actualizar el clúster de administrador.

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

La diferencia de versiones y las reglas de versiones para las actualizaciones cambiaron en la versión 1.28 y posteriores. Para obtener más información, consulta la sección Desviación de versión en este documento.

Orden en que se actualizan los nodos

El orden en el que se actualizan los nodos del plano de control del clúster de administrador, los nodos del plano de control del clúster de usuario y los nodos trabajadores 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.

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.

Kubeception

Cuando Controlplane V2 no está habilitado, el plano de control del clúster de usuario se ejecuta en uno o más nodos del clúster de administrador. Esta configuración se conoce como kubeception. En el caso de los clústeres de kubeception, la versión de actualización determina el comportamiento de la actualización de nodos:

Actualiza la versión Comportamiento de la actualización de nodos
1.32 y versiones más altas No se admiten los clústeres de Kubeception. Debes migrar todos los clústeres de usuario a Controlplane V2 antes de actualizar a la versión 1.32.
1.31
  • Los nodos del clúster de administrador se actualizan durante la actualización del clúster de administrador.
  • Los nodos del plano de control del clúster de usuario se actualizan durante la actualización del clúster de usuario.
1.30 y versiones más bajas Tanto los nodos del plano de control del clúster de usuario como los 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 más altas

Cuando la versión objetivo sea 1.31 o posterior, primero debes actualizar el clúster de administrador y, luego, los clústeres de usuario.

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

1.30 y versiones más bajas

Cuando la versión objetivo sea 1.30 o inferior, primero actualiza todos los clústeres de usuario y, luego, actualiza el clúster de administrador. Puedes actualizar el clúster de administrador cuando el plano de control y los grupos de nodos de todos los clústeres de usuario tengan al menos una versión secundaria superior a la del clúster de administrador.

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 usuario

Cuando actualizas clústeres de usuario, puedes optar por actualizar el clúster de usuario en su totalidad (lo que significa que puedes actualizar el plano de control y todos los grupos de nodos en el clúster) o puedes actualizar el plano de control del clúster de usuario y dejar los grupos de nodos en la versión actual. El enfoque que adoptes dependerá de varios factores, como los siguientes:

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

Por ejemplo, en un entorno de desarrollo, es posible que desees mantener el proceso sencillo y actualizar el plano de control del clúster de usuario y todos los grupos de nodos. 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, con planos de control de alta disponibilidad (HA), la actualización del plano de control no debería interrumpir las cargas de trabajo de los usuarios. Cuando el plano de control esté en la versión 1.28 o una posterior, puedes omitir una versión secundaria cuando actualices los grupos de nodos.

  • Versión 1.31: No está disponible en clústeres avanzados.
  • Versión 1.32 y posteriores: Disponible en clústeres avanzados.

Actualiza grupos de nodos de forma selectiva

En ciertas situaciones, es posible que desees actualizar algunos grupos de nodos en 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 ejecute tus cargas de trabajo menos críticas. Una vez que te convenzas de que tus cargas de trabajo se ejecutan correctamente en la versión nueva, puedes actualizar grupos de nodos adicionales, hasta que, finalmente, se actualicen todos. Para obtener más información, consulta Actualiza grupos de nodos.

Cómo omitir una versión secundaria cuando se actualizan grupos de nodos

Si tus clústeres están en la versión 1.16 o una posterior, puedes omitir una versión secundaria cuando actualices los grupos de nodos. Realizar una actualización de versión omitida reduce a la mitad el tiempo que tardaría en actualizar secuencialmente los grupos de nodos en dos versiones. Además, las actualizaciones de versiones omitidas te permiten aumentar el tiempo entre las actualizaciones necesarias para permanecer en una versión compatible. Reducir la cantidad de actualizaciones disminuye las interrupciones de la carga de trabajo y el tiempo de verificación. Para obtener más información, consulta Cómo omitir una versión cuando actualizas grupos de nodos.

Elige una herramienta para actualizar los clústeres de usuarios

Google Distributed Cloud te ofrece una variedad de herramientas para actualizar clústeres de usuarios.

  • La herramienta de línea de comandos gkectl, que ejecutas en tu estación de trabajo de administrador Antes de la actualización, debes modificar el archivo de configuración del clúster de usuario para establecer la versión de destino del plano de control del clúster y, de manera opcional, de los grupos de nodos. Especificas este archivo en la línea de comandos para 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 son compatibles con los clústeres avanzados.

  • La Google Cloud consola, Google Cloud CLI o Terraform que puedes ejecutar desde cualquier computadora que tenga conectividad de red a 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 creaste el clúster de usuario con Terraform.

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

      Incluso si decides usar gkectl para la actualización, te recomendamos que inscribas el clúster en la API de GKE On-Prem para obtener información sobre los clústeres con la consola o gcloud CLI.

La herramienta que uses dependerá de cómo planees actualizar los clústeres de usuario:

  • Actualiza el clúster en su totalidad: Puedes usar gkectl, la Google Cloud consola, Google Cloud CLI o Terraform para actualizar un clúster de usuario (el plano de control junto con todos los grupos de nodos).

  • Actualiza solo el plano de control: Puedes usar gkectl, gcloud CLI o Terraform para actualizar el plano de control de un clúster de usuario por separado de los grupos de nodos. La consola no admite la actualización solo del plano de control.

  • Actualiza grupos de nodos de forma selectiva después de actualizar el plano de control: Puedes usar gkectl, gcloud CLI o Terraform para actualizar grupos de nodos específicos después de actualizar el plano de control.

  • Actualiza el plano de control y uno o más grupos de nodos al mismo tiempo: Solo gkectl admite este caso de uso.

Sesgo de versiones

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

Además, la diferencia de versión es la diferencia en versiones secundarias entre el plano de control de un clúster de usuario y los grupos de nodos en el clúster de usuario.

En un entorno de varios clústeres, comprender el sesgo de versiones compatibles y las reglas de versiones para las actualizaciones puede ayudarte a planificar el orden en el que actualizas los clústeres.

Retraso de versiones de clústeres de administrador y de usuario

Un clúster de administrador puede administrar clústeres de usuario que se encuentran en diferentes versiones. Esta función te permite actualizar una flota de clústeres de usuario según un programa que funcione para tu organización.

1.31 y versiones más altas

En la versión 1.31 y versiones posteriores, el clúster de administrador puede ser hasta 2 versiones secundarias más recientes que sus clústeres de usuario. 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 las versiones 1.29, 1.30 o 1.31.

En términos generales, si 1.n es la versión secundaria del clúster de administrador, los clústeres de usuario pueden estar en 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 estén en 1.n o 1.n-1.

1.29 - 1.30

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

En la versión 1.29 y versiones posteriores, 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.31, los clústeres de usuario que administra ese clúster de administrador pueden estar en la versión 1.31, 1.32 o 1.33.

En términos generales, si 1.n es la versión secundaria del clúster de administrador, los clústeres de usuario pueden estar en 1.n, 1.n+1 o 1.n+2. Los clústeres de usuario en 1.n+2 no se pueden actualizar a la siguiente versión secundaria hasta que el clúster de administrador se actualice al menos una versión secundaria.

1.28

En la versión 1.28, los clústeres de usuario pueden ser 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 las versiones 1.15, 1.16 o 1.28. Los clústeres de usuario en la versión 1.28 no se pueden actualizar a la versión 1.29 hasta que el clúster de administrador se actualice al menos a la versión 1.16.

1.16 y versiones más bajas

En la versión 1.16 y versiones anteriores, los clústeres de usuario solo pueden ser 1 versión secundaria más reciente 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 o 1.16.

En términos generales, si 1.n es la versión secundaria del clúster de administrador, los clústeres de usuario pueden estar en 1.n o 1.n+1. Los clústeres de usuario 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 usuario.

Sesgo de versión del plano de control y del grupo de nodos del clúster de usuario

1.29 y versiones más altas

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

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

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

1.28

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

1.16 y versiones más bajas

En la versión 1.16 y versiones anteriores, el plano de control de un clúster de usuario 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 está en la versión 1.16, los grupos de nodos del clúster pueden estar en la versión 1.15 o 1.16.

En términos generales, si 1.n es la versión secundaria de un plano de control de clúster de usuario, los grupos de nodos del clúster pueden estar en 1.n o 1.n-1. Los clústeres de usuario 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 versión para las actualizaciones del clúster de administrador y del plano de control del clúster de usuario

Las reglas de versiones para las actualizaciones de clústeres de administrador y planos de control de clústeres de usuario son las mismas. Puedes actualizar directamente a cualquier versión que se encuentre en la misma versión secundaria o en la próxima versión secundaria. Por ejemplo, puedes actualizar de la versión 1.33.0 a la 1.33.1 o de la versión 1.32.1 a la 1.33.0. Las versiones de los parches no afectan las reglas de la versión de actualización.

Si quieres actualizar a una versión que no forma parte de la próxima versión secundaria, debes actualizar a través de una versión de cada actualización secundaria entre tu versión actual y la deseada. No se admite omitir una versión secundaria. Por ejemplo, si deseas actualizar de la versión 1.31.x a la versión 1.33.x, no puedes actualizar de forma directa. Primero debes actualizar de la versión 1.31.x a la 1.32.x y, luego, actualizar a la versión 1.33.x.

En términos generales, solo se admiten las actualizaciones de 1.n a 1.n+1 para las actualizaciones de clústeres de administradores y las actualizaciones del plano de control de clústeres de usuarios.

Reglas de versión para actualizaciones de grupos de nodos

En la versión 1.28 y en las posteriores, puedes omitir una versión secundaria cuando actualices un grupo de nodos en un clúster de usuario. Por ejemplo, si el plano de control de un clúster de usuario está en la versión 1.33 y un grupo de nodos está en 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 los parches no afectan las reglas de versión de actualización.

En términos generales, si el plano de control de un clúster de usuario está en 1.n, puedes actualizar los grupos de nodos que están en 1.n-2 directamente a 1.n. Omitir una versión inferior cuando se actualizan los grupos de nodos podría reducir la cantidad de tiempo que se tarda en realizar dos actualizaciones de grupos de nodos (para actualizar de 1.n-2 a 1.n-1 y, luego, a 1.n). Esta es otra razón por la que podrías preferir actualizar el plano de control de un clúster de usuario por separado de los grupos de nodos que se ejecutan en él.

  • Versión 1.31: No está 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 de parche más reciente siempre que sea posible para garantizar que los clústeres tengan las correcciones de seguridad más recientes. Las versiones de parche no afectan las reglas de actualización ni la diferencia de versiones. Para 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 actualizar de 1.32.0 a 1.32.1 y de 1.32.1 a 1.32.3.

¿Qué sigue?

Revisa las prácticas recomendadas para la actualización y crea un plan para actualizar tus clústeres.