Esta página se ha traducido con Cloud Translation API.

Saltar una versión al actualizar grupos de nodos

En la versión 1.29 y posteriores, Google Distributed Cloud permite que el plano de control de un clúster de usuarios sea hasta dos versiones secundarias superior a los grupos de nodos del clúster. Por ejemplo, si el plano de control de un clúster de usuarios tiene la versión 1.29, los grupos de nodos del clúster pueden tener las versiones 1.16, 1.28 o 1.29. Además, Google Distributed Cloud te permite saltarte una versión secundaria al actualizar grupos de nodos. Siguiendo el ejemplo anterior, puedes actualizar los grupos de nodos que tengan la versión 1.16 directamente a la versión 1.29 y saltarte la actualización a la 1.28. Si se omite una versión secundaria al actualizar grupos de nodos, se denomina actualización con omisión de versión.

En esta página se explican algunas de las ventajas de actualizar una versión y se indican los pasos para hacerlo modificando el archivo de configuración y ejecutando gkectl upgrade cluster.

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 En esta página se da por hecho que tiene cierta experiencia en la planificación y ejecución de actualizaciones de Google Distributed Cloud, tal como se describe en los siguientes artículos:

Limitaciones

Las actualizaciones de versiones omitidas tienen las siguientes limitaciones:

Las actualizaciones de versiones se admiten en los grupos de nodos de Ubuntu y COS, pero no en los grupos de nodos de Windows.
Versión 1.31: esta función no está disponible en los clústeres avanzados.
Versión 1.32 y posteriores: esta función está disponible en clústeres avanzados.
Debido a las restricciones de Kubernetes, el plano de control de un clúster de usuarios debe actualizarse de una versión secundaria a otra. Sin embargo, ten en cuenta que actualizar solo el plano de control lleva mucho menos tiempo y es menos arriesgado que actualizar los grupos de nodos en los que se ejecutan tus cargas de trabajo.

Ventajas de las actualizaciones de versiones omitidas

En esta sección se describen algunas de las ventajas de usar las actualizaciones de versiones omitidas.

Es más fácil mantener los clústeres en una versión compatible

Se publica una nueva versión menor de Google Distributed Cloud cada cuatro meses y cada versión menor tiene un periodo de asistencia de un año. Para que tus clústeres se mantengan dentro del periodo admitido, debes realizar una actualización de versión secundaria aproximadamente cada cuatro meses, tal como se muestra a continuación:

Dic

Ene

Feb

Mar

Abr

May

Jun

Jul

Ago

Sep

Oct

Nov

Dic

Ene

Feb

Mar

Abr

May

Jun

Jul

Ago

Sep

Oct

Nov

Dic

Ene

Feb

Mar

1,14

Cambiar a edición superior

1,15

Cambiar a edición superior

1.16

Cambiar a edición superior

1,28

Cambiar a edición superior

1,29

Cambiar a edición superior

Este requisito supone un problema cuando necesitas un periodo de validación largo para verificar una nueva versión secundaria y un periodo de mantenimiento corto para actualizar tus clústeres a la nueva versión secundaria. Para superar estos retos, puedes usar una actualización de versión omitida, que permite que tus clústeres se mantengan dentro del periodo admitido actualizando un clúster cada ocho meses en lugar de cada cuatro meses. En la siguiente tabla se muestra cómo, si te saltas la actualización a la versión 1.15, solo podrás actualizarla después de ocho meses en lugar de cuatro.

Dic

Ene

Feb

Mar

Abr

May

Jun

Jul

Ago

Sep

Oct

Nov

Dic

Ene

Feb

Mar

Abr

May

Jun

Jul

Ago

Sep

Oct

Nov

Dic

Ene

Feb

Mar

1,14

Cambiar a edición superior

1,15

1.16

Cambiar a edición superior

1,28

1,29

Si te saltas una versión secundaria al actualizar tus grupos de nodos, se reduce el número de actualizaciones necesarias para mantener una versión compatible. Además, no es necesario que especifiques la versión secundaria omitida, ya que solo la usa el plano de control de forma temporal.

Ventana de mantenimiento más corta

Con una actualización de versión omitida, no es necesario que amplíes la ventana de mantenimiento. Saltarse una versión secundaria al actualizar grupos de nodos lleva el mismo tiempo que actualizar los grupos de nodos a la siguiente versión secundaria, ya que cada nodo de un grupo de nodos se vacía y se vuelve a crear una vez. Por lo tanto, una actualización de versión omitida ahorra tiempo en general y reduce las interrupciones de la carga de trabajo.

Resumen

En resumen, una actualización de versión omitida ofrece las siguientes ventajas:

Actualiza los clústeres a una versión compatible: Google Distributed Cloud admite las tres versiones secundarias más recientes. Si tus clústeres tienen una versión no admitida, en función de la versión del clúster, si te saltas una versión secundaria al actualizar los grupos de nodos, tus clústeres podrían pasar a una versión admitida con menos actualizaciones.
Ahorra tiempo: si te saltas una versión secundaria al actualizar grupos de nodos, tardarás lo mismo que si los actualizaras a la siguiente versión secundaria. Por lo tanto, una actualización de versión omitida tarda aproximadamente la mitad del tiempo que se tarda en actualizar los grupos de nodos dos veces. Del mismo modo, con una actualización de versión omitida, solo tienes una ventana de validación, en comparación con las dos que tienes con las actualizaciones normales.
Reducir las interrupciones: los intervalos más largos entre actualizaciones y el menor tiempo dedicado a actualizar y validar significan que tus cargas de trabajo se ejecutan durante más tiempo con menos interrupciones.

Controlar las versiones del plano de control y del grupo de nodos durante una actualización

En el archivo de configuración del clúster de usuarios, el campo nodePools[i].gkeOnPremVersion permite que un grupo de nodos específico use una versión diferente del campo gkeOnPremVersion de nivel superior. Si cambias el valor del campo nodePools[i].gkeOnPremVersion, puedes controlar cuándo se actualiza un grupo de nodos al ejecutar gkectl upgrade cluster. Si no incluyes nodePools[i].gkeOnPremVersion en el archivo de configuración o si asignas al campo una cadena vacía, los grupos de nodos se actualizarán a la misma versión de destino que especifiques en gkeOnPremVersion.

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.

Secuencia de actualización de versiones

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.32 y versiones posteriores

Usa esta secuencia si la versión de destino es 1.32 o posterior. Supongamos que el plano de control de tu clúster de usuarios y todos los grupos de nodos tienen la versión secundaria 1.N. A grandes rasgos, la actualización de tu clúster de la versión 1.N a la 1.N+2 mediante una actualización con salto de versión funciona de la siguiente manera:

Actualiza el clúster de administrador de la versión 1.N a una versión intermedia, 1.N+1.
Actualiza el clúster de administrador de la versión intermedia 1.N+1 a la versión de destino 1.N+2.
Actualiza solo el plano de control del clúster de usuario de la versión de origen, 1.N, a una versión intermedia, 1.N+1. Deja los grupos de nodos en la versión de origen. La versión intermedia es necesaria porque el plano de control debe actualizarse de una versión secundaria a otra.
Actualiza el plano de control y los grupos de nodos a la versión de destino, 1.N+2.

1.31

Usa esta secuencia especial si el clúster de usuario tiene la versión 1.29, lo que significa que la versión de destino es la 1.31. Si un clúster de usuarios tiene la versión 1.29, el clúster de administradores que lo gestiona puede tener la versión 1.27, 1.28 o 1.29.

Si tu clúster de administradores tiene la versión 1.27, actualízalo a la 1.28.
Si tu clúster de administradores tiene la versión 1.28, actualízalo a la 1.29.
Actualiza solo el plano de control del clúster de usuarios de la versión de origen, 1.29, a una versión intermedia, 1.30. Deja los grupos de nodos en la versión de origen. La versión intermedia 1.30 es necesaria porque el plano de control debe actualizarse de una versión secundaria a otra.
Actualiza el clúster de administrador de la versión 1.29 a la versión intermedia 1.30.
Actualiza el clúster de administrador a la versión de destino, 1.31.
Actualiza el plano de control del clúster de usuarios y los grupos de nodos a la versión de destino, 1.31.

1.30 y versiones anteriores

Usa esta secuencia si la versión de destino es 1.30 o inferior.

Supongamos que el plano de control de tu clúster de usuarios y todos los grupos de nodos tienen la versión secundaria 1.N. A grandes rasgos, la actualización de tu clúster de la versión 1.N a la 1.N+2 mediante una actualización con salto de versión funciona de la siguiente manera:

Actualiza solo el plano de control de la versión de origen, 1.N, a una versión intermedia, 1.N+1. Deja los grupos de nodos en la versión de origen. La versión intermedia es necesaria porque el plano de control debe actualizarse de una versión secundaria a otra.
Actualiza el plano de control y los grupos de nodos a la versión de destino 1.N+2.

Realizar una actualización de versión omitida

En esta sección se describen los pasos para realizar una actualización de versión omitida.

Antes de empezar

Asegúrate de que la versión actual (la versión de origen) del clúster sea la 1.16 o una posterior. Asegúrate de comprobar la versión del plano de control (gkeOnPremVersion) y de todos los grupos de nodos (nodePools[i].gkeOnPremVersion).
En la versión 1.29 y posteriores, las comprobaciones previas del lado del servidor están habilitadas de forma predeterminada. Asegúrate de revisar las reglas de tu cortafuegos para hacer los cambios necesarios.
Para actualizar a la versión 1.28 o posterior, debes habilitar kubernetesmetadata.googleapis.com y conceder el rol de gestión de identidades y accesos kubernetesmetadata.publisher a la cuenta de servicio de registro y monitorización. Para obtener más información, consulta los requisitos de las APIs de Google y de IAM.

Realizar la actualización

1.31

Usa esta secuencia especial si el clúster de usuarios tiene la versión 1.29, lo que significa que la versión de destino es la 1.31. Esta secuencia es necesaria porque las reglas de versión cambiaron en la versión 1.31.

Si un clúster de usuarios tiene la versión 1.29, un clúster de administradores que gestione ese clúster de usuarios puede tener la versión 1.27, 1.28 o 1.29.

Si tu clúster de administradores tiene la versión 1.27, sigue los pasos para actualizar tu estación de trabajo de administrador y actualizar tu clúster de administradores a la versión 1.28.
Si tu clúster de administradores tiene la versión 1.28, sigue los pasos para actualizar tu estación de trabajo de administrador y actualizar tu clúster de administradores a la versión 1.29.
Para ahorrar espacio en tu estación de trabajo de administrador, elimina los paquetes descargados:
```
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz
```

Cuando el clúster de administradores y todos los clústeres de usuarios tengan la versión 1.29, podrás iniciar la actualización de versión omitida.

Define la versión de origen (1.29), una versión intermedia (1.30) y la versión de destino (1.31) en las siguientes variables de marcador de posición. Todas las versiones deben ser el número de versión completo con el formato x.y.z-gke.N, como 1.29.700-gke.110.

Versión
Obtiene la versión 1.29 del clúster de usuarios actual. Esta es la versión de origen.	`SOURCE_VERSION`
Elige una versión intermedia 1.30.	`INTERMEDIATE_VERSION`
Elige la versión de destino 1.31. Selecciona el parche recomendado de la versión secundaria 1.31.	`TARGET_VERSION`

Actualiza tu estación de trabajo de administrador a la versión intermedia 1.30, INTERMEDIATE_VERSION. Espera a que aparezca un mensaje que indique que la actualización se ha completado correctamente.

Instala el paquete correspondiente:

gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Vuelve a actualizar tu estación de trabajo de administrador a la versión 1.31 de destino, TARGET_VERSION. Espera a que aparezca un mensaje que indique que la actualización se ha completado correctamente.

Instala el paquete correspondiente:

gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Actualiza solo el plano de control del clúster de usuarios a la versión intermedia de la siguiente manera:
1. Haz los siguientes cambios en el archivo de configuración del clúster de usuarios:
  - Asigna al campo gkeOnPremVersion la versión intermedia: INTERMEDIATE_VERSION.
  - Define todas las versiones del grupo de nodos en nodePools[i].gkeOnPremVersion con la versión de origen, SOURCE_VERSION.
  Después de actualizar el archivo de configuración, debería tener un aspecto similar al siguiente:
```
gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...
```
2. Actualiza el plano de control:
```
gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```
  Sustituye USER_CLUSTER_CONFIG por la ruta del archivo de configuración de tu clúster de usuario.
Asigna al campo bundlePath del archivo de configuración del clúster de administrador la versión intermedia 1.30 del paquete:
```
bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"
```

Actualiza el clúster de administrador a la versión intermedia 1.30:

gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

Asigna al campo bundlePath del archivo de configuración del clúster de administrador la versión 1.31 de destino del paquete:
```
bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"
```

Upgrade the admin cluster to the target 1.31 version:

gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

Actualiza el plano de control y los grupos de nodos a la versión de destino de la siguiente manera:
1. Haz los siguientes cambios en el archivo de configuración del clúster de usuarios:
  - En el campo gkeOnPremVersion, introduzca la versión de destino: TARGET_VERSION.
  - Asigna a todos los nodePools[i].gkeOnPremVersion una cadena vacía.
  Después de actualizar el archivo de configuración, debería tener un aspecto similar al siguiente:
```
gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...
```
2. Actualiza el plano de control y los grupos de nodos:
```
gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```

1.30 y versiones anteriores

Usa esta secuencia si la versión de destino es 1.30 o inferior.

Define la versión de origen (1.N), la versión intermedia (1.N+1) y la versión de destino (1.N+2) en las siguientes variables de marcador de posición. Todas las versiones deben ser el número de versión completo con el formato x.y.z-gke.N, como 1.16.11-gke.25.

Versión
Obtén la versión actual del clúster. Esta es la versión de origen (`1.N`).	`SOURCE_VERSION`
Elige una versión intermedia (`1.N+1`).	`INTERMEDIATE_VERSION`
Elige la versión de destino (`1.N+2`). Selecciona el parche recomendado de la versión secundaria de destino.	`TARGET_VERSION`

Actualiza tu estación de trabajo de administrador a la versión intermedia, INTERMEDIATE_VERSION. Espera a que aparezca un mensaje que indique que la actualización se ha completado correctamente.

Instala el paquete correspondiente:

gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Sustituye ADMIN_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig de tu clúster de administrador.

Vuelve a actualizar tu estación de trabajo de administrador a la versión de destino, TARGET_VERSION. Espera a que aparezca un mensaje que indique que la actualización se ha completado correctamente.

Instala el paquete correspondiente:

gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Actualiza solo el plano de control a la versión intermedia de la siguiente manera:
1. Haz los siguientes cambios en el archivo de configuración del clúster de usuarios:
  - Asigna al campo gkeOnPremVersion la versión intermedia: INTERMEDIATE_VERSION.
  - Define todas las versiones del grupo de nodos en nodePools[i].gkeOnPremVersion con la versión de origen, SOURCE_VERSION.
  Después de actualizar el archivo de configuración, debería tener un aspecto similar al siguiente:
```
gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...
```
2. Actualiza el plano de control:
```
gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```
  Sustituye USER_CLUSTER_CONFIG por la ruta del archivo de configuración de tu clúster de usuario.
Actualiza el plano de control y los grupos de nodos a la versión de destino de la siguiente manera:
1. Haz los siguientes cambios en el archivo de configuración del clúster de usuarios:
  - En el campo gkeOnPremVersion, introduzca la versión de destino: TARGET_VERSION.
  - Asigna a todos los nodePools[i].gkeOnPremVersion una cadena vacía.
  Después de actualizar el archivo de configuración, debería tener un aspecto similar al siguiente:
```
gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...
```
2. Actualiza el plano de control y los grupos de nodos:
```
gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```

Si no tienes ningún otro clúster de usuarios que actualizar, elimina los paquetes de tu estación de trabajo de administrador para ahorrar espacio:

rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

Saltar una versión al actualizar grupos de nodos Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Limitaciones

Ventajas de las actualizaciones de versiones omitidas

Es más fácil mantener los clústeres en una versión compatible

Ventana de mantenimiento más corta

Resumen

Controlar las versiones del plano de control y del grupo de nodos durante una actualización

Reglas de versiones

Secuencia de actualización de versiones

1.32 y versiones posteriores

1.31

1.30 y versiones anteriores

Realizar una actualización de versión omitida

Antes de empezar

Realizar la actualización

1.31

1.30 y versiones anteriores

Siguientes pasos

Saltar una versión al actualizar grupos de nodos