Omite una versión cuando actualizas grupos de nodos

En la versión 1.29 y versiones posteriores, Google Distributed Cloud permite que el plano de control de un clúster de usuario sea hasta dos 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.29, los grupos de nodos del clúster pueden estar en las versiones 1.16, 1.28 o 1.29. Además, Google Distributed Cloud te permite omitir una versión secundaria cuando actualizas grupos de nodos. Con el ejemplo anterior, puedes actualizar los grupos de nodos que están en la versión 1.16 directamente a la versión 1.29 y omitir la actualización a la versión 1.28. Omitir una versión secundaria cuando se actualizan grupos de nodos se conoce como actualización con omisión de versión.

En esta página, se explican algunos de los beneficios de una actualización de versión omitida y se proporcionan los pasos para realizarla. Para ello, se deben realizar cambios en el archivo de configuración y ejecutar gkectl upgrade cluster.

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. En esta página, se supone que tienes cierta familiaridad con la planificación y ejecución de actualizaciones de Google Distributed Cloud, como se describe en los siguientes recursos:

Limitaciones

Las actualizaciones de versiones omitidas tienen las siguientes limitaciones:

  • Las actualizaciones de versiones omitidas son compatibles con los grupos de nodos de Ubuntu y COS, pero no con los 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 usuario se debe actualizar una versión secundaria a la vez. Sin embargo, ten en cuenta que actualizar solo el plano de control lleva mucho menos tiempo y es menos riesgoso que actualizar los grupos de nodos en los que se ejecutan tus cargas de trabajo.

Beneficios de las actualizaciones que omiten versiones

En esta sección, se describen algunos beneficios de usar las actualizaciones de versión omitidas.

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

Cada cuatro meses, se lanza una nueva versión secundaria de Google Distributed Cloud, y cada versión secundaria tiene un período de asistencia de un año. Para que tus clústeres permanezcan dentro del período compatible, debes realizar una actualización de versión secundaria aproximadamente cada cuatro meses, como se muestra a continuación:

Dic

Ene

Feb

Mar

Abr

Mayo

Jun

Jul

Ago

Sep

Oct

Nov

Dic

Ene

Feb

Mar

Abr

Mayo

Jun

Jul

Ago

Sep

Oct

Nov

Dic

Ene

Feb

Mar
1.14 Actualización
1.15 Actualización
1.16 Actualización
1.28 Actualización
1.29 Actualización

Este requisito impone desafíos cuando necesitas un período de validación prolongado para verificar una nueva versión secundaria y un período de mantenimiento corto para actualizar tus clústeres a la nueva versión secundaria. Para superar estos desafíos, puedes usar una actualización de versión omitida, que permite que tus clústeres permanezcan dentro del período admitido actualizando un clúster cada ocho meses en lugar de cada cuatro meses. En la siguiente tabla, se muestra cómo omitir la actualización a la versión 1.15 significa que solo actualizarás después de ocho meses en lugar de cuatro.

Dic

Ene

Feb

Mar

Abr

Mayo

Jun

Jul

Ago

Sep

Oct

Nov

Dic

Ene

Feb

Mar

Abr

Mayo

Jun

Jul

Ago

Sep

Oct

Nov

Dic

Ene

Feb

Mar
1.14 Actualización
1.15
1.16 Actualización
1.28
1.29

Si te saltas una versión secundaria cuando actualizas tus grupos de nodos, se reduce la cantidad de actualizaciones necesarias para mantenerte en una versión compatible. Además, no es necesario que califiques la versión secundaria omitida, ya que el plano de control solo la usa de forma temporal.

Período de mantenimiento más corto

Con una actualización de versión omitida, no es necesario que amplíes tu período de mantenimiento. Omitir una versión secundaria cuando se actualizan los grupos de nodos lleva la misma cantidad de tiempo que actualizar los grupos de nodos a la siguiente versión secundaria, ya que cada nodo de un grupo de nodos se agota 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 en la carga de trabajo.

Resumen

En resumen, una actualización de versión omitida proporciona los siguientes beneficios:

  • Actualiza los clústeres a una versión compatible: Google Distributed Cloud admite las tres versiones secundarias más recientes. Si tus clústeres se encuentran en una versión no compatible, según la versión del clúster, omitir una versión secundaria al actualizar los grupos de nodos podría llevar tus clústeres a una versión compatible con menos actualizaciones.

  • Ahorra tiempo: Omitir una versión secundaria cuando actualizas grupos de nodos lleva la misma cantidad de tiempo que actualizar los grupos de nodos a la siguiente versión secundaria. Por lo tanto, una actualización de versión omitida tarda aproximadamente la mitad del tiempo que tardaría actualizar los grupos de nodos dos veces. Del mismo modo, con una actualización de versión omitida, solo tienes un período de validación, en comparación con los dos que tienes con las actualizaciones normales.

  • Reducción de interrupciones: Los intervalos más largos entre las 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.

Controla 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 usuario, 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, controlas cuándo se actualiza un grupo de nodos cuando ejecutas gkectl upgrade cluster. Si no incluyes nodePools[i].gkeOnPremVersion en el archivo de configuración o si estableces el campo en una cadena vacía, los grupos de nodos se actualizan a la misma versión de destino que especificas en gkeOnPremVersion.

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.

Secuencia de actualización de versiones omitidas

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 realizas la actualización, denominada versión de destino:

1.32 y versiones más altas

Usa esta secuencia si la versión de destino es 1.32 o posterior. Supongamos que el plano de control del clúster de usuario y todos los grupos de nodos están en la versión secundaria 1.N. En un nivel general, la actualización del clúster de 1.N a 1.N+2 con una actualización de versión omitida funciona de la siguiente manera:

  1. Actualiza el clúster de administrador de la versión 1.N a una versión intermedia, 1.N+1.
  2. Actualiza el clúster de administrador de la versión intermedia 1.N+1 a la versión de destino 1.N+2.
  3. Actualiza solo el plano de control del clúster de usuario desde la versión de origen, 1.N, a una versión intermedia, 1.N+1. Dejar los grupos de nodos en la versión de origen Se necesita la versión intermedia porque el plano de control debe actualizarse una versión secundaria a la vez.
  4. 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 está en la versión 1.29, lo que significa que la versión de destino es 1.31. Cuando un clúster de usuario está en la versión 1.29, un clúster de administrador que administra el clúster de usuario podría estar en la versión 1.27, 1.28 o 1.29.

  1. Si tu clúster de administrador está en la versión 1.27, actualízalo a la versión 1.28.
  2. Si tu clúster de administrador está en la versión 1.28, actualízalo a la 1.29.
  3. Actualiza solo el plano de control del clúster de usuario 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. Se necesita la versión intermedia 1.30 porque el plano de control debe actualizarse una versión secundaria a la vez.
  4. Actualiza el clúster de administrador de la versión 1.29 a la versión intermedia, 1.30.
  5. Actualiza el clúster de administrador a la versión de destino, 1.31.
  6. Actualiza el plano de control del clúster de usuario y los grupos de nodos a la versión de destino, 1.31.

1.30 y versiones más bajas

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

Supongamos que el plano de control del clúster de usuario y todos los grupos de nodos están en la versión secundaria 1.N. En un nivel general, la actualización del clúster de 1.N a 1.N+2 con una actualización de versión omitida funciona de la siguiente manera:

  1. 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. Se necesita la versión intermedia porque el plano de control debe actualizarse una versión secundaria a la vez.
  2. Actualiza el plano de control y los grupos de nodos a la versión de destino 1.N+2.

Realiza una actualización de versión omitida

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

Antes de comenzar

  1. Asegúrate de que la versión actual (la versión de origen) del clúster sea la versión 1.16 o posterior. Asegúrate de verificar la versión del plano de control (gkeOnPremVersion) y de todos los grupos de nodos (nodePools[i].gkeOnPremVersion).

  2. En la versión 1.29 y posteriores, las verificaciones previas del servidor están habilitadas de forma predeterminada. Asegúrate de revisar tus reglas de firewall para realizar los cambios necesarios.

  3. Para actualizar a la versión 1.28 y versiones posteriores, debes habilitar kubernetesmetadata.googleapis.com y otorgar el rol de IAM kubernetesmetadata.publisher a la cuenta de servicio de supervisión y registro. Para obtener más información, consulta Requisitos de la API de Google y de IAM.

Realiza la actualización

1.31

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

Cuando un clúster de usuario está en la versión 1.29, un clúster de administrador que lo administra podría estar en la versión 1.27, 1.28 o 1.29.

  1. Si tu clúster de administrador está en la versión 1.27, sigue los pasos para actualizar tu estación de trabajo de administrador y actualizar tu clúster de administrador a la versión 1.28.

  2. Si tu clúster de administrador está en la versión 1.28, sigue los pasos para actualizar tu estación de trabajo de administrador y actualizar tu clúster de administrador a la versión 1.29.

  3. Para ahorrar espacio en tu estación de trabajo de administrador, quita los paquetes descargados:

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

Cuando el clúster de administrador y todos los clústeres de usuario estén en la versión 1.29, puedes comenzar la actualización de versión omitida.

  1. 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 tener el número de versión completo en el formato x.y.z-gke.N, como 1.29.700-gke.110.

    Versión
    Obtén la versión 1.29 del clúster de usuario 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

  2. 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 realizó correctamente.

  3. Instala el paquete correspondiente:

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

  4. Vuelve a actualizar tu estación de trabajo de administrador, pero esta vez a la versión de destino 1.31, TARGET_VERSION. Espera a que aparezca un mensaje que indique que la actualización se realizó correctamente.

  5. Instala el paquete correspondiente:

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

  6. Actualiza solo el plano de control del clúster de usuario a la versión intermedia de la siguiente manera:

    1. Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:

      • Configura el campo gkeOnPremVersion en la versión intermedia, INTERMEDIATE_VERSION.

      • Establece todas las versiones del grupo de nodos en nodePools[i].gkeOnPremVersion a la versión de origen, SOURCE_VERSION.

      Después de actualizar el archivo de configuración, debería ser 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

      Reemplaza USER_CLUSTER_CONFIG por la ruta de acceso del archivo de configuración del clúster de usuario.

  7. Establece el campo bundlePath en el archivo de configuración del clúster de administrador en la versión intermedia 1.30 del paquete:

    bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"

  8. 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

  9. Establece el campo bundlePath en el archivo de configuración del clúster de administrador en la versión 1.31 de destino del paquete:

    bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"

  10. Upgrade the admin cluster to the target 1.31 version:

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

  11. Actualiza el plano de control y los grupos de nodos a la versión de destino de la siguiente manera:

    1. Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:

      • Configura el campo gkeOnPremVersion en la versión objetivo, TARGET_VERSION.

      • Establece todos los nodePools[i].gkeOnPremVersion en una cadena vacía.

      Después de actualizar el archivo de configuración, debería ser 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 más bajas

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

  1. 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 tener el número de versión completo en el formato x.y.z-gke.N, como 1.16.11-gke.25.

    Versión
    Obtiene 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

  2. 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 realizó correctamente.

  3. Instala el paquete correspondiente:

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

    Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.

  4. Actualiza tu estación de trabajo de administrador de nuevo, pero esta vez a la versión de destino, TARGET_VERSION. Espera a que aparezca un mensaje que indique que la actualización se realizó correctamente.

  5. Instala el paquete correspondiente:

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

  6. Actualiza solo el plano de control a la versión intermedia de la siguiente manera:

    1. Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:

      • Configura el campo gkeOnPremVersion en la versión intermedia, INTERMEDIATE_VERSION.

      • Establece todas las versiones del grupo de nodos en nodePools[i].gkeOnPremVersion a la versión de origen, SOURCE_VERSION.

      Después de actualizar el archivo de configuración, debería ser 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

      Reemplaza USER_CLUSTER_CONFIG por la ruta de acceso del archivo de configuración del clúster de usuario.

  7. Actualiza el plano de control y los grupos de nodos a la versión de destino de la siguiente manera:

    1. Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:

      • Configura el campo gkeOnPremVersion en la versión objetivo, TARGET_VERSION.

      • Establece todos los nodePools[i].gkeOnPremVersion en una cadena vacía.

      Después de actualizar el archivo de configuración, debería ser 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 otros clústeres de usuarios para actualizar, quita los paquetes de tu estación de trabajo de administrador para ahorrar espacio:

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

¿Qué sigue?