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 de 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 la versión 1.16, 1.28 o 1.29. Además, Google Distributed Cloud te permite omitir una versión menor cuando actualizas los 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 menor cuando se actualizan los grupos de nodos se conoce como actualización con omisión de versión.

Las actualizaciones de versiones omitidas son compatibles con los grupos de nodos de Ubuntu y COS, pero no con los de Windows. Además, esta función no está disponible si tienes clústeres avanzados habilitados.

Debido a las restricciones de Kubernetes, el plano de control de un clúster de usuario se debe actualizar una versión menor 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.

En esta página, se explican algunos de los beneficios de una actualización sin versión y se proporcionan pasos para realizar una actualización sin versión mediante cambios en el archivo de configuración y la ejecución de 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 Tareas y roles comunes de los usuarios de GKE Enterprise. En esta página, se da por sentado que tienes cierto conocimiento sobre la planificación y ejecución de mejoras de Google Distributed Cloud, como se describe a continuación:

Beneficios de las actualizaciones sin pasar por versiones

En esta sección, se describen algunos de los beneficios de usar las actualizaciones de omisión de versiones.

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 una 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 largo 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 que omite versiones, lo 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 la realizará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 omites una versión menor cuando actualizas tus grupos de nodos, se reduce la cantidad de actualizaciones necesarias para mantener una versión compatible. Además, no necesitas calificar 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 que omite versiones, no es necesario que aumentes el período de mantenimiento. Omitir una versión secundaria cuando se actualizan los grupos de nodos demora la misma cantidad de tiempo que actualizarlos 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 que omite versiones ahorra tiempo en general y reduce las interrupciones de la carga de trabajo.

Resumen

En resumen, una actualización de omisión de versión 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 tienen una versión no compatible, según la versión del clúster, omitir una versión menor cuando se actualizan los grupos de nodos podría llevar a que tus clústeres tengan una versión compatible con menos actualizaciones.

  • Ahorra tiempo: Omitir una versión menor cuando se actualizan los grupos de nodos tarda la misma cantidad de tiempo que actualizar los grupos de nodos a la siguiente versión menor. Por lo tanto, una actualización sin versión tarda aproximadamente la mitad del tiempo que tarda actualizar los grupos de nodos dos veces. Del mismo modo, con una actualización que omite versiones, solo tienes una ventana de validación, en comparación con dos con actualizaciones normales.

  • Reduce las interrupciones: Los períodos más largos entre las actualizaciones y menos tiempo dedicado a la actualización y validación significan que tus cargas de trabajo se ejecutan 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 de la del campo de nivel superior gkeOnPremVersion. Cuando 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 versión

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

  • Para las versiones 1.30 y anteriores, la versión secundaria del clúster de usuario debe ser superior o igual a la versión secundaria del clúster de administrador. No importa la versión del parche. 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 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 1.31.1.

Cuando quieras actualizar tus clústeres a la versión 1.31, primero debes actualizar todos los clústeres a la versión 1.30. Después de que todos los clústeres estén en la versión 1.30, debes actualizar 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 omisión de versió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 te actualizas, denominada versión de destino:

1.31

Usa esta secuencia especial si el clúster de usuarios está en la versión 1.29, lo que significa que la versión objetivo 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 puede 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 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 fuente. Se necesita la versión intermedia 1.30 porque el plano de control debe actualizarse una versión menor 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 anteriores

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

Supongamos que el plano de control de tu clúster de usuario y todos los grupos de nodos están en la versión secundaria 1.N. En un nivel alto, la actualización de tu clúster de 1.N a 1.N+2 con una actualización de omisión de versión 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 objetivo 1.N+2.

Cómo realizar una actualización sin pasar por una versión

En esta sección, se proporcionan los pasos para realizar una actualización sin pasar por una versión.

Antes de comenzar

  1. Asegúrate de que la versión actual (la versión de origen) del clúster sea 1.16 o superior. 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 versiones posteriores, las verificaciones previas del servidor están habilitadas de forma predeterminada. Asegúrate de revisar las 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 usuarios está en la versión 1.29, lo que significa que la versión objetivo 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 puede 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 para omitir la versión.

  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 ser 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 fuente. 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. Actualiza tu estación de trabajo de administrador nuevamente, 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 en la versión de origen, SOURCE_VERSION.

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

      • Establece 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, este 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 anteriores

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 ser el número de versión completo en 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 objetivo (1.N+2). Selecciona el parche recomendado de la versión menor objetivo. 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 nuevamente, 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 en la versión de origen, SOURCE_VERSION.

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

      • Establece 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, este 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 la estación de trabajo de administrador para ahorrar espacio:

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

¿Qué sigue?