Actualiza los clústeres

Cuando instalas una versión nueva de bmctl, puedes actualizar los clústeres existentes que se crearon con una versión anterior. La actualización de un clúster a la versión más reciente de Google Distributed Cloud le proporciona funciones adicionales y correcciones al clúster. También garantiza que tu clúster permanezca compatible. Puedes actualizar clústeres de administrador, híbridos, independientes o de usuario con el comando bmctl upgrade cluster, o puedes usar kubectl.

Para obtener más información sobre el proceso de actualización y las reglas de control de versiones, consulta Ciclo de vida y etapas de las actualizaciones del clúster.

Nota: Cuando actualices Google Distributed Cloud de una versión con un parche de seguridad a la siguiente versión secundaria, te recomendamos que actualices a la versión del parche más alta disponible para asegurarte de tener los parches de seguridad más recientes. Revisa siempre las notas de la versión antes de la actualización para estar al tanto de lo que cambió, incluidas las correcciones de seguridad y los problemas conocidos. No se puede cambiar a una versión inferior del clúster.

Planifica la actualización

En esta sección, encontrarás información y vínculos a información que debes tener en cuenta antes de actualizar un clúster.

prácticas recomendadas

Si deseas obtener información que te ayude a prepararte para actualizar el clúster, consulta Prácticas recomendadas para las actualizaciones de clústeres de Google Distributed Cloud.

Actualiza las comprobaciones preliminares

Las verificaciones previas se ejecutan como parte de la actualización del clúster para validar el estado de los clústeres y los nodos. La actualización del clúster no continúa si las verificaciones previas fallan. Para obtener más información sobre las comprobaciones preliminares, consulta Información sobre las comprobaciones preliminares.

A fin de comprobar si los clústeres están listos para una actualización, ejecuta la verificación previa antes de ejecutar la actualización. Para obtener más información, consulta Verificaciones previas para actualizaciones.

Problemas conocidos

Para obtener información sobre posibles problemas relacionados con las actualizaciones de clústeres, consulta Problemas conocidos de Google Distributed Cloud para equipos físicos y selecciona la categoría de problemas Actualizaciones y actualizaciones.

Configurar opciones de actualización

Antes de iniciar la actualización de un clúster, puedes configurar las siguientes opciones de actualización que controlan el funcionamiento del proceso de actualización:

• Actualizaciones selectivas de grupos de nodo trabajador trabajadores: Actualiza grupos de nodo trabajador específicos por separado del resto del clúster.

• Actualizaciones paralelas: Configura el proceso de actualización para actualizar grupos de nodos o grupos de nodos de forma simultánea.

Estas opciones pueden reducir el riesgo de interrupciones en aplicaciones y servicios esenciales, y reducir de forma significativa el tiempo de actualización general. Estas opciones son especialmente útiles para clústeres grandes con varios nodos y grupos de nodos que ejecutan cargas de trabajo importantes. Para obtener más información sobre lo que hacen estas opciones y cómo usarlas, consulta las siguientes secciones.

Actualizaciones selectivas de grupos de nodo trabajador

De forma predeterminada, la operación de actualización del clúster actualiza todos los nodos y grupos de nodos del clúster. La actualización de un clúster puede ser disruptiva y requerir mucho tiempo, ya que hace que cada nodo se desvíe y todos los Pods asociados se reinicien y reprogramen. En esta sección, se describe cómo puedes incluir o excluir grupos de nodo trabajador seleccionados para que se actualice un clúster y, así, minimizar la interrupción de la carga de trabajo. Esta función se aplica solo a los clústeres independientes, híbridos y de usuario, ya que los clústeres de administrador no permiten grupos de nodo trabajador.

Puedes usar actualizaciones selectivas del grupo de nodos en las siguientes situaciones:

• Para recoger correcciones de seguridad sin interrumpir las cargas de trabajo: Puedes actualizar solo los nodos del plano de control (y los nodos del balanceador de cargas) para aplicar correcciones de vulnerabilidades de Kubernetes sin interrumpir los grupos de nodo trabajador.

• Para confirmar el funcionamiento correcto de un subconjunto actualizado de nodos trabajadores antes de actualizar todos los nodos trabajadores: puedes actualizar los grupos de nodo trabajador de forma selectiva para garantizar que las cargas de trabajo se ejecuten correctamente en un grupo de nodos actualizado antes de actualizar otro grupo de nodos.

• Para reducir el período de mantenimiento: La actualización de un clúster grande puede llevar mucho tiempo y es difícil predecir con precisión cuándo se completará una actualización. La hora de actualización del clúster es proporcional a la cantidad de nodos que se actualizan. Reducir la cantidad de nodos que se actualizan mediante la exclusión de grupos de nodos reduce el tiempo de actualización. Actualizas varias veces, pero los períodos de mantenimiento más pequeños y predecibles pueden ayudar con la programación.

Sesgo de dos versiones secundarias del grupo de nodos de la versión

Para la versión 1.28 y los clústeres posteriores, una versión de grupo de nodo trabajador puede ser de hasta dos versiones secundarias detrás de la versión del clúster (plano de control). Gracias a la compatibilidad con el sesgo de versiones n-2, también puedes omitir una versión de actualización secundaria cuando actualizas un grupo de nodo trabajador de dos versiones secundarias detrás del clúster a la misma versión secundaria que el clúster.

Esta compatibilidad con el sesgo de versiones n-2 para los grupos de nodo trabajador te brinda más flexibilidad para planificar las actualizaciones de tu flota.

Por ejemplo, si tienes un clúster de la versión 1.28, puedes tener grupos de nodo trabajador en las versiones seleccionadas 1.28, 1.16 y 1.15. Para actualizar tu clúster a la versión 1.29, primero debes actualizar cualquier grupo de nodo trabajador 1.15 a una versión compatible para el clúster de versión 1.28 previo a la actualización. No es necesario que actualices los grupos de nodo trabajador de la versión 1.16 a la versión 1.28 para poder actualizar tu clúster a la versión 1.29. Una vez que el clúster se actualizó a la versión 1.29, cuando decides actualizar los grupos de nodo trabajador de la versión 1.16 a la versión 1.29, puedes realizar la actualización en un solo paso y omitir la versión 1.28.

Para obtener más información, incluidas las listas de las versiones de grupos de nodo trabajador compatibles con una versión de clúster determinada, consulta Reglas de control de versiones del grupo de nodos

1.29

En la versión 1.29, la compatibilidad con el sesgo de versiones n-2 para grupos de nodo trabajador tiene disponibilidad general para todos los tipos de clústeres. Esta función está habilitada de forma predeterminada para los clústeres en la versión 1.29.

A medida que realizamos la transición de esta función de la versión preliminar pública a la DG, los clústeres híbridos aún requieren la anotación de vista previa en la siguiente situación. Si tienes un clúster híbrido versión 1.28.x con un grupo de nodo trabajador versión 1.16.y, debes agregar la anotación preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable al clúster antes de actualizarlo a la versión 1.29.z:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.28.400-gke.77
  ...

1.28

Vista previa

Este producto o función está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos y las funciones que se encuentran en la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

La compatibilidad con el sesgo de versiones n-2 para grupos de nodo trabajador está disponible para la versión preliminar en la versión 1.28. Para habilitar esta función de vista previa, agrega la anotación preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable al archivo de configuración del clúster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
...

Si no habilitas esta función de versión preliminar, el sesgo máximo de versiones entre un grupo de nodo trabajador y el clúster es de una versión secundaria.

Si quieres obtener más información sobre las reglas del control de versiones para actualizar grupos de nodos trabajadores de forma selectiva, consulta Reglas de control de versiones del grupo de nodos en Ciclo de vida y etapas de las actualizaciones del clúster.

Actualiza el plano de control del clúster y los grupos de nodos seleccionados

Para actualizar de forma selectiva grupos de nodo trabajador en la actualización inicial del clúster, sigue estos pasos:

1. Para los grupos de nodo trabajador que quieres incluir en la actualización del clúster, realiza uno de los siguientes cambios en la especificación del grupo de nodos:

   • Configura anthosBareMetalVersion en la especificación del grupo de nodos para la versión de actualización objetivo del clúster.
   • Omite el campo anthosBareMetalVersion de la especificación del grupo de nodos o configúralo en la string vacía. De forma predeterminada, los grupos de nodo trabajador se incluyen en las actualizaciones del clúster.

2. Para los grupos de nodo trabajador que deseas excluir de la actualización, configura anthosBareMetalVersion en la versión actual (antes de la actualización) del clúster:

3. Continúa con la actualización como se describe en Inicia la actualización del clúster.

   La operación de actualización del clúster actualiza los siguientes nodos:

   • Nodos del plano de control del clúster.
   • Grupo de nodos del balanceador de cargas, si tu clúster usa uno (spec.loadBalancer.nodePoolSpec). De forma predeterminada, los nodos del balanceador de cargas pueden ejecutar cargas de trabajo normales. No puedes actualizar un grupo de nodos del balanceador de cargas de forma selectiva; siempre se incluye en la actualización inicial del clúster.
   • Grupos de nodos trabajadores que no excluiste de la actualización.

Por ejemplo, supongamos que tu clúster se encuentra en la versión 1.28.0 y tiene dos grupos de nodo trabajador: wpool01 y wpool02. Además, supongamos que deseas actualizar el plano de control y wpool01 a 1.29.100-gke.251, pero deseas que wpool02 permanezca en la versión 1.28.0.

En el siguiente extracto del archivo de configuración del clúster, se muestra cómo puedes modificar la configuración del clúster para admitir esta actualización parcial:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.100-gke.251
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Actualiza los grupos de nodos a la versión actual del clúster

Si excluiste grupos de nodos de una actualización del clúster, puedes ejecutar una actualización del clúster que los haga llegar a la versión del clúster de destino. Los grupos de nodos trabajadores que se excluyeron de una actualización del clúster tienen el campo anthosBareMetalVersion en su especificación NodePool establecido en la versión del clúster anterior (antes de la actualización).

Para actualizar los grupos de nodo trabajador a la versión actual del clúster actualizada, haz lo siguiente:

1. Edita las especificaciones de NodePool en el archivo de configuración del clúster para los grupos de nodos trabajadores que deseas usar en la versión actual del clúster. Establece anthosBareMetalVersion en la versión actual del clúster (posterior a la actualización).

   Si se seleccionan varios grupos de nodo trabajador para la actualización, el valor de spec.nodePoolUpgradeStrategy.concurrentNodePools en la especificación del clúster determina cuántos grupos de nodos se actualizan en paralelo, si corresponde. Si no quieres actualizar grupos de nodo trabajador en simultáneo, selecciona un grupo de nodos a la vez para la actualización.

2. Continúa con la actualización como se describe en Inicia la actualización del clúster.

   La operación de actualización del clúster solo actualiza los grupos de nodos trabajadores excluidos con anterioridad para los que configuraste anthosBareMetalVersion en la versión actual del clúster actualizada.

Por ejemplo, supongamos que actualizaste tu clúster a la versión 1.29.100-gke.251, pero el grupo de nodos wpool02 aún se encuentra en la versión 1.28.0 anterior del clúster previo a la actualización. Las cargas de trabajo se ejecutan de forma correcta en el grupo de nodos actualizado, wpool01, por lo que ahora también debes llevar wpool02 a la versión actual del clúster. Para actualizar wpool02, puedes quitar el campo anthosBareMetalVersion o establecer su valor como la cadena vacía.

En el siguiente extracto del archivo de configuración del clúster, se muestra cómo puedes modificar la configuración del clúster para admitir esta actualización parcial:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.100-gke.251
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: ""
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Revierte la actualización de un grupo de nodos

Vista previa

Este producto o función está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos y las funciones que se encuentran en la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Hay muchas dependencias, como la compatibilidad con kubelet o complementos, que pueden afectar el rendimiento de tus cargas de trabajo. En caso de que encuentres un problema después de actualizar un grupo de nodo trabajador, puedes revertir el grupo de nodos a su versión anterior.

La capacidad de reversión de grupos de nodos está disponible en la Vista previa para los clústeres de la versión 1.29 (clústeres con nodos del plano de control en la versión 1.29). Mientras esta función se encuentra en versión preliminar, debes agregar la anotación preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable al recurso Cluster para habilitarla.

Para revertir una actualización de grupo de nodos, sigue estos pasos:

bmctl

Cuando usas bmctl para revertir la actualización de un grupo de nodos, edita el archivo de configuración del clúster y aplica los cambios con el comando bmctl update:

1. Edita las especificaciones de NodePool en el archivo de configuración del clúster para los grupos de nodo trabajador que deseas revertir a la versión anterior. Configura anthosBareMetalVersion en la versión del clúster anterior (antes de la actualización).

   ...
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: wpool01
     namespace: cluster-user001
   spec:
     clusterName: user001
     anthosBareMetalVersion: 1.28.500-gke.120
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
   

   Si se seleccionan varios grupos de nodo trabajador para la reversión, el valor de spec.nodePoolUpgradeStrategy.concurrentNodePools en la especificación del clúster determina cuántos grupos de nodos se revierten en paralelo. Si no quieres revertir grupos de nodo trabajador de forma simultánea, selecciona un grupo de nodos a la vez para la reversión o actualiza la configuración de nodePoolUpgradeStrategy. Del mismo modo, el valor de spec.upgradeStrategy.parallelUpgrade.concurrentNodes en la especificación NodePool determina cuántos nodos se revierten en paralelo.

2. Usa bmctl update para aplicar los cambios a las especificaciones de NodePool:

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: Es el nombre del clúster que deseas actualizar.

   • ADMIN_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administración (administrador, híbrido o independiente).

   La reversión comienza automáticamente.

3. A medida que se ejecuta la reversión, Google Distributed Cloud realiza las siguientes actividades para cada nodo:

   • Poner el nodo en modo de mantenimiento
   • Ejecuta un trabajo de restablecimiento en el nodo para que quede en un estado limpio.
   • Ejecuta verificaciones previas de la máquina en el nodo.
   • Ejecuta un trabajo de machine-init en el nodo para reinstalarlo en la versión de reversión de destino (antes de la actualización).
   • Quitar el nodo del modo de mantenimiento

   Cuando finaliza una reversión exitosa, el valor de nodePool.status.anthosBareMetalVersion en el recurso NodePool se establece en la versión objetivo de reversión.

No uses bmctl update y kubectl apply -f de manera indistinta cuando edites el archivo de configuración del clúster. Cuando estos comandos se usan de manera indistinta, es posible que el contenido propagado por el encabezado de la especificación del clúster se quite de manera accidental. Por ejemplo, puedes usar bmctl update para actualizar el archivo de configuración del clúster y configurar una duplicación de registro. Luego, se propagó spec.nodeConfig.registryMirrors en el clúster después de la conciliación.

Si luego intentas realizar cambios en el clúster mediante la configuración del clúster con el comando kubectl apply -f, se quita el spec.nodeConfig.registryMirrors que propaga el conciliador en el clúster. Este comportamiento se debe a que la configuración no existe en la especificación de configuración del clúster, pero sí existe en el clúster.

kubectl

Puedes revertir una actualización del grupo de nodos con kubectl para editar el recurso NodePool directamente:

1. Si deseas revertir un grupo de nodo trabajador, abre el recurso NodePool para editarlo:

   kubectl edit nodepool NODE_POOL_NAME \
       --namespace CLUSTER_NAMESPACE \
       --kubeconfig ADMIN_KUBECONFIG
   

   Reemplaza lo siguiente:

   • NODE_POOL_NAME: Es el nombre del grupo de nodos que estás revirtiendo.

   • CLUSTER_NAMESPACE: Es el nombre del espacio de nombres en el que se implementa el grupo de nodos. Este es el espacio de nombres del clúster.

   • ADMIN_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administración (administrador, híbrido o independiente).

2. Cambia el valor de spec.anthosBareMetalVersion a la versión anterior (previa a la actualización).

   ...
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: wpool01
     namespace: cluster-user001
   spec:
     clusterName: user001
     anthosBareMetalVersion: 1.28.500-gke.120
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
   

3. Guarda y cierra el recurso NodePool en el editor.

   La reversión comienza automáticamente.

4. A medida que se ejecuta la reversión, Google Distributed Cloud realiza las siguientes actividades para cada nodo:

   • Poner el nodo en modo de mantenimiento
   • Ejecuta un trabajo de restablecimiento en el nodo para que quede en un estado limpio.
   • Ejecuta verificaciones previas de la máquina en el nodo.
   • Ejecuta un trabajo de machine-init en el nodo para reinstalarlo en la versión de reversión de destino (antes de la actualización).
   • Quitar el nodo del modo de mantenimiento

   Cuando finaliza una reversión exitosa, el valor de nodePool.status.anthosBareMetalVersion en el recurso NodePool se establece en la versión objetivo de reversión.

Actualizaciones paralelas

En una actualización de clúster predeterminada típica, cada nodo del clúster se actualiza de forma secuencial, uno tras otro. En esta sección, se muestra cómo configurar el clúster y los grupos de nodo trabajador para que varios nodos se actualicen en paralelo cuando actualices el clúster. La actualización de nodos en paralelo acelera las actualizaciones de los clústeres de manera significativa, en especial, los que tienen cientos de nodos.

Precaución: Si usas servicios de datos administrados, como Portworx, para administrar cargas de trabajo con estado en los clústeres, te recomendamos que no uses actualizaciones paralelas.

Existen dos estrategias de actualización paralelas que puedes usar para acelerar la actualización del clúster:

• Actualización simultánea de nodos: puedes configurar los grupos de nodo trabajador para que varios nodos se actualicen en paralelo. Las actualizaciones paralelas de nodos se configuran en la especificación del grupo de nodos (spec.upgradeStrategy.parallelUpgrade) y solo los nodos de un grupo de nodo trabajador se pueden actualizar en paralelo. Los nodos del plano de control o los grupos de nodos del balanceador de cargas solo se pueden actualizar de a uno. Para obtener más información, consulta Estrategia de actualización de nodos.

• Actualización simultánea del grupo de nodos: puedes configurar tu clúster para que varios grupos de nodos se actualicen en paralelo. Solo los grupos de nodo trabajador se pueden actualizar en paralelo. Los grupos de nodos del plano de control y del balanceador de cargas solo se pueden actualizar uno a la vez.

Estrategia de actualización de nodos

Puedes configurar grupos de nodo trabajador a fin de que varios nodos se actualicen de forma simultánea (concurrentNodes). También puedes establecer un umbral mínimo para la cantidad de nodos que pueden ejecutar cargas de trabajo durante el proceso de actualización (minimumAvailableNodes). Esta configuración se realiza en la especificación del grupo de nodos. Para obtener más información sobre estos campos, consulta la referencia del campo de configuración del clúster.

Importante: Las actualizaciones paralelas no respetan el Presupuesto de interrupción de Pods (PDB). Si tus cargas de trabajo son sensibles a las interrupciones, te recomendamos que uses el campo minimumAvailableNodes. Puedes especificar la cantidad mínima de nodos que deben permanecer disponibles para ejecutar cargas de trabajo durante el proceso de actualización.

La estrategia de actualización de nodos solo se aplica a los grupos de nodo trabajador. No puedes especificar una estrategia de actualización de nodos para el plano de control o los grupos de nodos del balanceador de cargas. Durante la actualización del clúster, los nodos del plano de control y los grupos de nodos del balanceador de cargas se actualizan de forma secuencial, uno a la vez. Los grupos de nodos del plano de control y los grupos de nodos del balanceador de cargas se especifican en la especificación del clúster (controlPlane.nodePoolSpec.nodes y loadBalancer.nodePoolSpec.nodes).

Cuando configures actualizaciones paralelas para nodos, ten en cuenta las siguientes restricciones:

• El valor de concurrentNodes no puede exceder el 50% de la cantidad de nodos en el grupo de nodos ni el número fijo 15, lo que sea menor. Por ejemplo, si tu grupo de nodos tiene 20 nodos, no puedes especificar un valor superior a 10. Si tu grupo de nodos tiene 100 nodos, 15 es el valor máximo que puedes especificar.

• Cuando usas concurrentNodes junto con minimumAvailableNodes, los valores combinados no pueden exceder la cantidad total de nodos en el grupo de nodos. Por ejemplo, si tu grupo de nodos tiene 20 nodos y minimumAvailableNodes se estableció en 18, concurrentNodes no puede ser mayor que 2. Del mismo modo, si concurrentNodes se establece en 10, minimumAvailableNodes no puede superar este valor.

En el siguiente ejemplo, se muestra un grupo de nodo trabajador np1 con 10 nodos. En una actualización, los nodos se actualizan de 5 a la vez y, al menos, 4 nodos deben permanecer disponibles para que la actualización continúe:

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  - address:  10.200.0.4
  - address:  10.200.0.5
  - address:  10.200.0.6
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  - address:  10.200.0.10 
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 4 

Estrategia de actualización del grupo de nodos

Puedes configurar un clúster para que varios grupos de nodo trabajador se actualicen en paralelo. El campo booleano nodePoolUpgradeStrategy.concurrentNodePools en la especificación del clúster especifica si se deben actualizar o no todos los grupos de nodo trabajador de un clúster de forma simultánea. De forma predeterminada (1), los grupos de nodos se actualizan de forma secuencial, uno tras otro. Cuando configuras concurrentNodePools como 0, cada grupo de nodo trabajador del clúster se actualiza en paralelo.

El plano de control y los grupos de nodos del balanceo de cargas no se ven afectados por esta configuración. Estos grupos de nodos siempre se actualizan de forma secuencial, uno a la vez. Los grupos de nodos del plano de control y los grupos de nodos del balanceador de cargas se especifican en la especificación del clúster (controlPlane.nodePoolSpec.nodes y loadBalancer.nodePoolSpec.nodes).

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

Cómo realizar una actualización paralela

En esta sección, se describe cómo configurar un clúster y un grupo de nodo trabajador para actualizaciones paralelas.

Para realizar una actualización paralela de nodos y grupos de nodos trabajadores en un grupo de nodo trabajador, haz lo siguiente:

1. Agrega una sección upgradeStrategy a la especificación del grupo de nodos.

   Puedes aplicar este manifiesto por separado o como parte del archivo de configuración del clúster cuando realizas una actualización del clúster.

   Por ejemplo:

   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: np1
     namespace: cluster-ci-bf8b9aa43c16c47
   spec:
     clusterName: ci-bf8b9aa43c16c47
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
     - address:  10.200.0.30
     upgradeStrategy:
       parallelUpgrade:
         concurrentNodes: 5
         minimumAvailableNodes: 10
   

   En este ejemplo, el valor del campo concurrentNodes es 5, lo que significa que 5 nodos se actualizan en paralelo. El campo minimumAvailableNodes se establece en 10, lo que significa que, al menos, 10 nodos deben permanecer disponibles para las cargas de trabajo durante la actualización.

   Nota: No puedes especificar una estrategia de actualización de nodos para el plano de control o los grupos de nodos del balanceador de cargas.

2. Agrega una sección nodePoolUpgradeStrategy a la especificación del clúster en el archivo de configuración del clúster.

   ---
   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-user001
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: user001
     namespace: cluster-user001
   spec:
     type: user
     profile: default
     anthosBareMetalVersion: 1.29.100-gke.251
     ...
     nodePoolUpgradeStrategy:
       concurrentNodePools: 0
     ...
   

   En este ejemplo, el campo concurrentNodePools se establece en 0, lo que significa que todos los grupos de nodo trabajador se actualizan al mismo tiempo durante la actualización del clúster. La estrategia de actualización para los nodos de los grupos de nodos se define en las especificaciones de NodePool.

3. Actualiza el clúster como se describe en la sección anterior Actualiza clústeres de administrador, independientes, híbridos o de usuario.

Valores predeterminados de actualizaciones paralelas

Las actualizaciones paralelas están inhabilitadas de forma predeterminada y los campos relacionados con estas actualizaciones son mutables. En cualquier momento, puedes quitar los campos o establecerlos en sus valores predeterminados para inhabilitar la función antes de una actualización posterior.

En la siguiente tabla, se enumeran los campos de actualización paralela y sus valores predeterminados:

Campo	Valor predeterminado	Significado
nodePoolUpgradeStrategy.concurrentNodePools (especificación del clúster)	1	Actualiza los grupos de nodo trabajador de forma secuencial, uno tras otro.
upgradeStrategy.parallelUpgrade.concurrentNodes (especificación de NodePool)	1	Actualiza los nodos de forma secuencial, uno tras otro.
upgradeStrategy.parallelUpgrade.minimumAvailableNodes (especificación de NodePool)	El valor predeterminado de minimumAvailableNodes depende del valor de concurrentNodes. Si no especificas concurrentNodes, minimumAvailableNodes de forma predeterminada es 2/3 del tamaño del grupo de nodos. Si especificas concurrentNodes, minimumAvailableNodes de forma predeterminada es el tamaño del grupo de nodos menos concurrentNodes.	La actualización se detiene una vez que se alcanza minimumAvailableNodes y solo continúa cuando la cantidad de nodos disponibles es mayor que minimumAvailableNodes.

Inicia la actualización del clúster

Esta sección contiene instrucciones para actualizar clústeres.

Nota: Debes actualizar un clúster de administrador antes de actualizar cualquier clúster de usuario asociado. Sin embargo, antes de actualizar el clúster de administrador a 1.29.100-gke.251, asegúrate de que los clústeres de usuario asociados tengan la versión 1.28.0 o superior. bmctl emite un error si detecta que algún clúster de usuario tiene una versión anterior a 1.28.0.

bmctl

Cuando descargas e instalas una versión nueva de bmctl, puedes actualizar tus clústeres de administrador, híbridos, independientes y de usuario creados con una versión anterior. Para una versión determinada de bmctl, un clúster solo se puede actualizar a la misma versión.

1. Descarga el bmctl más reciente como se describe en Descargas de Google Distributed Cloud.

2. Actualiza anthosBareMetalVersion en el archivo de configuración del clúster a la versión de destino de actualización.

   La versión objetivo de la actualización debe coincidir con la versión del archivo bmctl descargado. En el siguiente fragmento del archivo de configuración del clúster, se muestra el campo anthosBareMetalVersion actualizado a la versión más reciente:

   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: cluster1
     namespace: cluster-cluster1
   spec:
     type: admin
     # Anthos cluster version.
     anthosBareMetalVersion: 1.29.100-gke.251
   

3. Usa el comando de bmctl upgrade cluster para completar la actualización:

   bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: el nombre del clúster que se actualizará
   • ADMIN_KUBECONFIG es la ruta al archivo kubeconfig del clúster de administrador.

   La operación de actualización del clúster ejecuta comprobaciones preliminares para validar su estado y el de los nodos. La actualización del clúster no continúa si fallan las comprobaciones preliminares. Para obtener información sobre la solución de problemas, consulta Soluciona problemas de instalación o actualización de clústeres.

   Cuando todos los componentes del clúster se actualizan de forma correcta, la operación de actualización del clúster realiza verificaciones de estado. En este último paso, se verifica que el clúster esté en buenas condiciones de funcionamiento. Si el clúster no pasa todas las verificaciones de estado, estas seguirán ejecutándose hasta que se aprueben. Cuando se aprueban todas las verificaciones de estado, la actualización finaliza de forma correcta.

   Si deseas obtener más información sobre la secuencia de eventos para las actualizaciones del clúster, consulta Ciclo de vida y etapas de las actualizaciones del clúster.

kubectl

Para actualizar un clúster con kubectl, sigue estos pasos:

1. Edita el archivo de configuración del clúster para establecer anthosBareMetalVersion en la versión de destino de la actualización.

2. Para iniciar la actualización, ejecuta el siguiente comando:

   kubectl apply -f CLUSTER_CONFIG_PATH
   

   Reemplaza CLUSTER_CONFIG_PATH por la ruta del archivo de configuración de clúster editado.

   Al igual que con el proceso de actualización con bmctl, las comprobaciones preliminares se ejecutan como parte de la actualización del clúster para validar su estado y el de los nodos. Si las comprobaciones previas fallan, la actualización del clúster se detiene. Para solucionar cualquier error, examina el clúster y los registros relacionados, ya que no se crea ningún clúster de arranque. Para obtener más información, consulta Soluciona problemas de instalación o actualización de clústeres.

Aunque no necesitas la versión más reciente de bmctl para actualizar los clústeres con kubectl, te recomendamos que descargues la versión más reciente de bmctl. Necesitas bmctl para realizar otras tareas, como verificaciones de estado y copias de seguridad, a fin de asegurarte de que el clúster se mantenga en buen estado.

Detén y reanuda las actualizaciones

La función de pausa y reanudación de la actualización te permite pausar la actualización de un clúster antes de que finalice. Cuando se pausa la actualización de un clúster, no se activan nuevas actualizaciones de nodo trabajador hasta que se reanuda.

Esta función está disponible en (vista previa) para los clústeres con todos los nodos del plano de control en la versión secundaria 1.28 o en versiones posteriores. La función tiene disponibilidad general para los clústeres con todos los nodos del plano de control en la versión secundaria 1.29 o posterior.

Es posible que desees detener una actualización por los siguientes motivos:

• Detectaste un problema con las cargas de trabajo del clúster durante la actualización y deseas pausarla para revisar el problema.

• Tienes períodos de mantenimiento breves, por lo que deseas pausar la actualización entre períodos

Mientras la actualización de un clúster está en pausa, se admiten las siguientes operaciones:

• Agrega o quita nodos
• Agrega o quita grupos de nodos
• Aumenta el rango de la red de servicio
• Restablece un clúster a partir de una copia de seguridad

Cuando se agrega un nodo nuevo mientras se pausa una actualización, los trabajos de verificación de la máquina no se ejecutan en él hasta que se reanuda y completa la actualización.

Mientras la actualización del clúster está en pausa, no se admiten las siguientes operaciones:

• Autoridades certificadoras rotativas
• Crea una copia de seguridad de un clúster

No puedes iniciar la actualización de un clúster nuevo mientras está pausada una actualización de clúster activo.

Habilitar la opción para pausar y reanudar la actualización

Google Distributed Cloud 1.29

La función de pausa y reanudación de la actualización está habilitada de forma predeterminada para los clústeres con todos los nodos del plano de control en la versión secundaria 1.29 o superior.

Google Distributed Cloud 1.28

Vista previa

Este producto o función está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos y las funciones que se encuentran en la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Mientras la función de pausa y reanudación de la actualización se encuentra en versión preliminar, puedes habilitarla con una anotación en el recurso del clúster.

Para habilitar la pausa y la reanudación de la actualización, sigue estos pasos:

1. Agrega la anotación preview.baremetal.cluster.gke.io/upgrade-pause-and-resume al archivo de configuración del clúster:

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: baremetal-demo
     namespace: cluster-baremetal-demo
     annotations:
       preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
   spec:
   ...
   

2. Para aplicar el cambio, actualiza tu clúster:

   bmctl update CLUSTER_NAME
   

   El campo nodePoolUpgradeStrategy.pause es mutable. Puedes agregarla y actualizarla en cualquier momento.

Detén una actualización

Para pausar la actualización de un clúster, configura nodePoolUpgradeStrategy.pause como true en la especificación del clúster.

Para pausar la actualización de un clúster activo, sigue estos pasos:

1. Agrega nodePoolUpgradeStrategy.pause al archivo de configuración del clúster y configúralo como true:

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: baremetal-demo
     namespace: cluster-baremetal-demo
     ...
   spec:
     ...
     nodePoolUpgradeStrategy:
       pause: true
     ...
   

   Si usaste bmctl para iniciar la actualización, necesitas una nueva ventana de terminal para realizar el siguiente paso.

2. Para aplicar el cambio, actualiza tu clúster:

   bmctl update CLUSTER_NAME
   

   La operación de actualización está detenida. No se activan nuevas actualizaciones de nodos.

3. Si usaste bmctl para iniciar la actualización y tienes previsto hacer una pausa prolongada, presiona Control + C para salir de bmctl; de lo contrario, mantén bmctl en ejecución.

   La CLI de bmctl no detecta cambios en el estado de pausa de la actualización, por lo que no se cierra automáticamente. Sin embargo, cuando sales de bmctl, se detiene el registro del progreso de la actualización al archivo de registro cluster-upgrade-TIMESTAMP en la carpeta del clúster en la estación de trabajo de administrador y en Cloud Logging. Por lo tanto, te recomendamos que mantengas bmctl en ejecución durante pausas cortas. Si dejas bmctl en ejecución durante un período prolongado mientras la actualización está en pausa, finalmente se agota el tiempo de espera.

Reanuda una actualización en pausa

Para reanudar la actualización de un clúster pausado, configura nodePoolUpgradeStrategy.pause como false en la especificación del clúster o quita nodePoolUpgradeStrategy.pause de la especificación.

Para reanudar la actualización de un clúster que se detuvo, sigue estos pasos:

1. Establece nodePoolUpgradeStrategy.pause en el archivo de configuración del clúster y establécelo en false:

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: baremetal-demo
     namespace: cluster-baremetal-demo
     ...
   spec:
     ...
     nodePoolUpgradeStrategy:
       pause: false
     ...
   

   Como alternativa, puedes quitar el campo pause, ya que su valor predeterminado es false.

2. Para aplicar el cambio, actualiza tu clúster:

   bmctl update CLUSTER_NAME
   

   La operación de actualización se reanudará desde donde se detuvo.

3. Para verificar el estado de la actualización, primero obtén una lista de los recursos que tienen anthosBareMetalVersion en su status:

   kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces
   

   Reemplaza lo siguiente:

   • RESOURCE: Es el nombre del recurso que deseas obtener. Los recursos Cluster, NodePool y BareMetalMachine contienen información de estado anthosBareMetalVersion.

   • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

   En el siguiente ejemplo, se muestra el formato de la respuesta a los recursos personalizados BareMetalMachine. Cada BareMetalMachine corresponde a un nodo de clúster.

   NAMESPACE              NAME         CLUSTER        READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
   cluster-nuc-admin001   192.0.2.52   nuc-admin001   true    baremetal://192.0.2.52   192.0.2.52   1.28.0        1.28.0
   cluster-nuc-user001    192.0.2.53   nuc-user001    true    baremetal://192.0.2.53   192.0.2.53   1.16.2        1.16.2
   cluster-nuc-user001    192.0.2.54   nuc-user001    true    baremetal://192.0.2.54   192.0.2.54   1.16.2        1.16.2
   

4. Para verificar el status.anthosBareMetalVersion (versión actual del recurso), recupera los detalles de los recursos individuales:

   kubectl describe RESOURCE RESOURCE_NAME \
       --kubeconfig ADMIN_KUBECONFIG \
       --namespace CLUSTER_NAMESPACE
   

   En el siguiente ejemplo, se muestran los detalles de BareMetalMachine para el nodo del clúster con la dirección IP 192.0.2.53:

   Name:         192.0.2.53
   Namespace:    cluster-nuc-user001
   ...
   API Version:  infrastructure.baremetal.cluster.gke.io/v1
   Kind:         BareMetalMachine
   Metadata:
     Creation Timestamp:  2023-09-22T17:52:09Z
     ...
   Spec:
     Address:                    192.0.2.53
     Anthos Bare Metal Version:  1.16.2
     ...
   Status:
     Anthos Bare Metal Version:  1.16.2
   

   En este ejemplo, el nodo se encuentra en la versión 1.16.2 de Google Distributed Cloud.