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 agrega funciones y correcciones adicionales a tu clúster. También garantiza que tu clúster permanezca compatible. Puedes actualizar los clústeres de administrador, híbrido, independiente o de usuario con el comando bmctl upgrade cluster o 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 de clústeres.

Esta página está destinada a administradores, arquitectos 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.

Nota: Cuando actualices Google Distributed Cloud de una versión con un parche de seguridad a la próxima versión secundaria, te recomendamos que actualices a la versión más reciente del parche para que te asegures 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 admite el cambio a una versión inferior del clúster.

Planifica la actualización

En esta sección, se incluye información y vínculos a información que debes tener en cuenta antes de actualizar un clúster. Para obtener más información sobre las actualizaciones, incluidas las reglas de control de versiones para clústeres y grupos de nodos, consulta Ciclo de vida y etapas de las actualizaciones de clústeres.

Prácticas recomendadas

Para obtener información que te ayude a prepararte para una actualización de clúster, consulta Prácticas recomendadas para las actualizaciones de clústeres de Google Distributed Cloud.

Verificaciones previas a la actualización

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 verificaciones previas, consulta Comprende las verificaciones previas.

Para verificar si los clústeres están listos para una actualización, ejecuta la verificación preliminar antes de ejecutar la actualización. Para obtener más información, consulta Verificaciones previas a la actualización.

Problemas conocidos

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

Configura las opciones de actualización

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

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

• Actualizaciones en paralelo: 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 las aplicaciones y los servicios críticos, y reducir significativamente el tiempo de actualización general. Estas opciones son especialmente útiles para clústeres grandes con numerosos 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 nodos trabajadores

De forma predeterminada, la operación de actualización del clúster actualiza todos los nodos y grupos de nodos del clúster. Una actualización de clúster puede ser disruptiva y llevar mucho tiempo, ya que cada nodo se vacía y todos los pods asociados se reinician y se reprograman. En esta sección, se describe cómo puedes incluir o excluir grupos de nodos trabajadores seleccionados para una actualización de clúster para minimizar las interrupciones de la carga de trabajo. Esta función solo se aplica a los clústeres de usuario, híbridos y autónomos, ya que los clústeres de administrador no permiten grupos de nodos trabajadores.

Puedes usar actualizaciones de grupos de nodos selectivos en las siguientes situaciones:

• Para aplicar 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 nodos trabajadores.

• Para confirmar el funcionamiento correcto de un subconjunto actualizado de nodos trabajadores antes de actualizar todos los nodos trabajadores: Puedes actualizar tus grupos de nodos trabajadores de forma selectiva para asegurarte de 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. El tiempo de actualización del clúster es proporcional a la cantidad de nodos que se actualizarán. Si excluyes los grupos de nodos, se reduce la cantidad de nodos que se actualizan, lo que reduce el tiempo de actualización. Realizas actualizaciones varias veces, pero los períodos de mantenimiento más pequeños y predecibles pueden ayudarte con la programación.

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

En el caso de los clústeres de la versión 1.28 y versiones posteriores, la versión de un grupo de nodos trabajadores puede tener hasta dos versiones secundarias anteriores a la versión del clúster (plano de control). Con la compatibilidad con el sesgo de versiones de n-2, también puedes omitir una versión de actualización menor de lanzamiento cuando actualizas un grupo de nodos trabajadores de dos versiones secundarias anteriores al clúster a la misma versión secundaria que el clúster.

Esta compatibilidad con el sesgo de versión n-2 para los grupos de nodos trabajadores te brinda más flexibilidad para planificar las actualizaciones de tu flota.

Por ejemplo, si tienes un clúster de la versión 1.30, puedes tener grupos de nodos trabajadores en las versiones 1.30, 1.29 y 1.28 seleccionadas.

Antes de poder actualizar un clúster, todos los grupos de nodos trabajadores deben tener una versión que sea compatible con la versión actual del clúster y la versión de destino.

Por ejemplo, si tienes un clúster en la versión 1.29 y grupos de nodos trabajadores en las versiones 1.29, 1.28 y 1.16, debes actualizar los grupos de nodos de la versión 1.16 a la versión 1.28 o 1.29 antes de poder actualizar el clúster a la versión 1.30.

Para obtener más información, incluidas las listas de versiones de grupos de nodos trabajadores compatibles con una versión determinada del clúster (aplicable a la versión 1.29 y versiones anteriores), consulta Reglas de control de versiones de grupos de nodos.

1.30

En la versión 1.30, la compatibilidad con la versión n-2 de los grupos de nodos trabajadores es de disponibilidad general para todos los tipos de clústeres. Esta función está habilitada de forma predeterminada para los clústeres de la versión 1.30.

Los grupos de nodos de cualquier versión de parche de las versiones secundarias 1.28 y 1.29 se pueden actualizar a cualquier versión de parche de 1.30, si la versión del grupo de nodos es la misma o inferior a la del clúster.

1.29

En la versión 1.29, la compatibilidad con la versión n-2 de los grupos de nodos trabajadores es la versión GA para todos los tipos de clústeres. Esta función está habilitada de forma predeterminada para los clústeres de la versión 1.29.

A medida que llevamos esta función de la versión preliminar pública a la versión general, 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 de la versión 1.28.x con un grupo de nodos trabajadores de la 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 la versión n-2 para grupos de nodos trabajadores está disponible en la versión preliminar de 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 la versión preliminar, el sesgo de versiones máximo entre un grupo de nodos trabajadores y el clúster es de una versión menor.

Para obtener más información sobre las reglas de control de versiones para actualizar de forma selectiva los grupos de nodos de trabajo, consulta Reglas de control de versiones de grupos de nodos en Ciclo de vida y etapas de las actualizaciones de clústeres.

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

Para actualizar de forma selectiva los grupos de nodos trabajadores en la actualización inicial del clúster, haz lo siguiente:

1. En el caso de los grupos de nodos trabajadores que deseas incluir en la actualización del clúster, realiza uno de los siguientes cambios en la especificación de NodePool:

   • Establece anthosBareMetalVersion en la especificación de NodePool en la versión de actualización de destino del clúster.
   • Omite el campo anthosBareMetalVersion de la especificación de NodePool o configúralo en la cadena vacía. De forma predeterminada, los grupos de nodos trabajadores se incluyen en las actualizaciones de clústeres.

2. Para los grupos de nodos trabajadores que deseas excluir de la actualización, establece anthosBareMetalVersion en la versión actual (anterior a 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 de forma selectiva un grupo de nodos del balanceador de cargas, ya que siempre se incluye en la actualización inicial del clúster.
   • Los grupos de nodos trabajadores que no se excluyeron de la actualización

Por ejemplo, supongamos que tu clúster está en la versión 1.29.0 y tiene dos grupos de nodos trabajadores: wpool01 y wpool02. Además, supongamos que deseas actualizar el plano de control y wpool01 a la versión 1.30.100-gke.96, pero deseas que wpool02 permanezca en la versión 1.29.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.30.100-gke.96
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.30.100-gke.96
  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.29.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 de clúster, puedes ejecutar una actualización de clúster que los actualice a la versión de destino. Los grupos de nodos trabajadores que se excluyeron de una actualización de clúster tienen el campo anthosBareMetalVersion en su especificación NodePool establecido en la versión anterior del clúster (antes de la actualización).

Para actualizar los grupos de nodos trabajadores a la versión actual y actualizada del clúster, 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 actualizar a la versión actual del clúster. Establece anthosBareMetalVersion en la versión actual del clúster (después de la actualización).

   Si se seleccionan varios grupos de nodos trabajadores 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 los hay. Si no deseas actualizar los grupos de nodos trabajadores de forma simultánea, selecciona un grupo de nodos a la vez para actualizarlo.

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 previamente excluidos para los que configuraste anthosBareMetalVersion a la versión actual y actualizada del clúster.

Por ejemplo, supongamos que actualizaste tu clúster a la versión 1.30.100-gke.96, pero el grupo de nodos wpool02 aún está en la versión anterior del clúster, 1.29.0. Las cargas de trabajo se ejecutan correctamente en el grupo de nodos actualizado, wpool01, por lo que ahora también quieres actualizar wpool02 a la versión actual del clúster. Para actualizar wpool02, puedes quitar el campo anthosBareMetalVersion o establecer su valor en 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.30.100-gke.96
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.30.100-gke.96
  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

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 nodos trabajadores, puedes revertirlo a su versión anterior.

Esta función no se encuentra en la misma fase de lanzamiento para todas las versiones de clústeres compatibles:

1.30

Para los clústeres de la versión 1.30 (clúster con nodos de plano de control en la versión 1.30), la función de reversión del grupo de nodos es de versión general y está habilitada de forma predeterminada.

1.29

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 función de reversión de grupos de nodos está disponible en versión beta para los clústeres de la versión 1.29 (clúster con nodos de plano de control en la versión 1.29). Mientras esta función está en versión preliminar, debes agregar la siguiente anotación al recurso Cluster para habilitarla:

preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable

1.28

La función de reversión del grupo de nodos no está disponible para los clústeres con la versión menor 1.28 o versiones anteriores.

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

bmctl

Cuando usas bmctl para revertir una actualización de un grupo de nodos, editas el archivo de configuración del clúster y aplicas 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 nodos trabajadores que deseas revertir a la versión anterior. Establece anthosBareMetalVersion en la versión anterior (previa a la actualización) del clúster.

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

   Si se seleccionan varios grupos de nodos trabajadores 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 los grupos de nodos trabajadores 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 en la especificación 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. El comando bmctl update cluster se cierra de inmediato, pero la reversión sigue progresando. No realices ninguna otra operación en el clúster mientras la reversión esté en curso.

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

   • Coloca el nodo en modo de mantenimiento.
   • Ejecuta un trabajo de restablecimiento en el nodo para que vuelva a un estado inicial.
   • Ejecuta las verificaciones previas a la activación de la máquina en el nodo.
   • Ejecuta un trabajo de inicialización de la máquina en el nodo para volver a instalarlo en la versión de reversión (previa a la actualización) objetivo.
   • Quita el nodo del modo de mantenimiento.

   Al final de una reversión correcta, el valor de nodePool.status.anthosBareMetalVersion en el recurso NodePool se establece en la versión de reversión objetivo.

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

Si, luego, intentas realizar cambios en el clúster con la configuración del clúster con el comando kubectl apply -f, se quitará el spec.nodeConfig.registryMirrors propagado por el agente de conciliación en el clúster. Este comportamiento se produce porque la configuración no existe en la especificación de configuración del clúster, pero sí en el clúster.

kubectl

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

1. Para revertir un grupo de nodos 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 revertirás.

   • 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 (antes de la actualización).

   ...
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: wpool01
     namespace: cluster-user001
   spec:
     clusterName: user001
     anthosBareMetalVersion: 1.29.600-gke.108
     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. No realices ninguna otra operación en el clúster mientras la reversión esté en curso.

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

   • Coloca el nodo en modo de mantenimiento.
   • Ejecuta un trabajo de restablecimiento en el nodo para que vuelva a un estado inicial.
   • Ejecuta las verificaciones previas a la activación de la máquina en el nodo.
   • Ejecuta un trabajo de inicialización de la máquina en el nodo para volver a instalarlo en la versión de reversión (previa a la actualización) objetivo.
   • Quita el nodo del modo de mantenimiento.

   Al final de una reversión correcta, el valor de nodePool.status.anthosBareMetalVersion en el recurso NodePool se establece en la versión de reversión objetivo.

Actualizaciones en paralelo

En una actualización de clúster típica y predeterminada, cada nodo del clúster se actualiza de manera secuencial, uno tras otro. En esta sección, se muestra cómo configurar el clúster y los grupos de nodos 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 clústeres significativamente, en especial para los clústeres que tienen cientos de nodos.

Precaución: Si usas servicios de datos administrados, como Portworx, para ayudar a administrar cargas de trabajo con estado en tus clústeres, te recomendamos que no uses actualizaciones simultáneas.

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

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

• Actualización simultánea de grupos de nodos: Puedes configurar tu clúster para que varios grupos de nodos se actualicen en paralelo. Solo los grupos de nodos trabajadores 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 nodos trabajadores para 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 de NodePool. Para obtener más información sobre estos campos, consulta la referencia de campos de configuración de clústeres.

Importante: Las actualizaciones en paralelo 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 nodos trabajadores. No puedes especificar una estrategia de actualización de nodos para grupos de nodos del balanceador de cargas o del plano de control. Durante una 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 en paralelo para los 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 superar la cantidad total de nodos en el grupo de nodos. Por ejemplo, si tu grupo de nodos tiene 20 nodos y minimumAvailableNodes está configurado en 18, concurrentNodes no puede superar los 2. Del mismo modo, si concurrentNodes se establece en 10, minimumAvailableNodes no puede superar los 10.

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

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 nodos trabajadores 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 nodos trabajadores de un clúster de forma simultánea. De forma predeterminada (1), los grupos de nodos se actualizan de manera secuencial, uno tras otro. Cuando estableces concurrentNodePools en 0, cada grupo de nodos trabajadores del clúster se actualiza en paralelo.

El plano de control y los grupos de nodos de balanceo de cargas no se ven afectados por este parámetro de 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 en paralelo

En esta sección, se describe cómo configurar un clúster y un grupo de nodos trabajadores para las actualizaciones en paralelo.

Para realizar una actualización en paralelo de los grupos de nodos y los nodos trabajadores en un grupo de nodos trabajadores, haz lo siguiente:

1. Agrega una sección upgradeStrategy a la especificación de NodePool.

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

   A continuación, se presenta un 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 los grupos de nodos del plano de control ni 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.30.100-gke.96
     ...
     nodePoolUpgradeStrategy:
       concurrentNodePools: 0
     ...
   

   En este ejemplo, el campo concurrentNodePools se establece en 0, lo que significa que todos los grupos de nodos trabajadores se actualizan de forma simultánea durante la actualización del clúster. La estrategia de actualización de los nodos en 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, independiente, híbrido o de usuario.

Valores predeterminados de la actualización en paralelo

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

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

Campo	Valor predeterminado	Significado
nodePoolUpgradeStrategy.concurrentNodePools (Especificación del clúster)	1	Actualiza los grupos de nodos trabajadores 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 es, de forma predeterminada, 2/3 del tamaño del grupo de nodos. Si especificas concurrentNodes, minimumAvailableNodes será, de forma predeterminada, el tamaño del grupo de nodos menos concurrentNodes.	La actualización se detiene una vez que se alcanza minimumAvailableNodes y solo continúa una vez que 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.30.100-gke.96, asegúrate de que los clústeres de usuario asociados estén en la versión 1.29.0 o superior. bmctl emite un error si descubre que un clúster de usuario tiene una versión inferior a 1.29.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. Configura tus credenciales de usuario como credenciales predeterminadas de la aplicación (ADC):

   gcloud auth application-default login
   

   Sigue las indicaciones para seleccionar tu Cuenta de Google para ADC. Para obtener más información, consulta Configura credenciales predeterminadas de la aplicación.

2. Descarga la versión más reciente de bmctl como se describe en Descargas de Google Distributed Cloud.

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

   La versión de destino 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.30.100-gke.96
   

4. 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.
   Nota: El comando bmctl upgrade solo actualiza el valor anthosBareMetalVersion y las anotaciones de vista previa en el recurso personalizado del clúster. Si deseas modificar otros campos de la especificación del clúster, usa el comando bmctl update. Para obtener más información, consulta Actualiza clústeres.

   La operación de actualización del clúster ejecuta verificaciones previas para validar el estado del clúster y el estado de los nodos. La actualización del clúster no continúa si las verificaciones previas fallan. 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 hayan actualizado correctamente, la operación de actualización del clúster realizará verificaciones de estado del clúster. Este último paso verifica que el clúster esté en buenas condiciones de funcionamiento. Si el clúster no aprueba todas las verificaciones de estado, estas se seguirán ejecutando hasta que lo hagan. Cuando todas las verificaciones de estado se aprueben, la actualización finalizará correctamente.

   Para obtener más información sobre la secuencia de eventos de las actualizaciones de clústeres, consulta Ciclo de vida y etapas de las actualizaciones de clústeres.

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 de acceso del archivo de configuración del clúster editado.

   Al igual que con el proceso de actualización con bmctl, las verificaciones previas se ejecutan como parte de la actualización del clúster para validar el estado del clúster y el estado del nodo. 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 Cómo solucionar problemas de instalación o actualización de clústeres.

Aunque no necesitas la versión más reciente de bmctl para actualizar con kubectl, te recomendamos descargar 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 funcione correctamente.

Cómo pausar y reanudar actualizaciones

La función de pausa y reanudación de la actualización te permite pausar una actualización de clúster antes de que finalice. Cuando se pausa una actualización de clúster, no se activan actualizaciones de nodos trabajadores nuevos hasta que se reanuda la actualización.

Esta función está disponible en (versión preliminar) para clústeres con todos los nodos del plano de control en la versión menor 1.28 o una posterior. La función está disponible para todos los clústeres con todos los nodos del plano de control en la versión secundaria 1.29 o una posterior.

Es posible que quieras pausar una actualización por los siguientes motivos:

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

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

Mientras se pausa una actualización de clúster, se admiten las siguientes operaciones:

• Cómo agregar o quitar nodos
• Agrega o quita grupos de nodos
• Aumenta el rango de la red de servicios
• Cómo restablecer un clúster a partir de una copia de seguridad

Cuando se agrega un nodo nuevo mientras una actualización está en pausa, los trabajos de verificación de máquinas 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 de clúster:

• Rotación de autoridades certificadoras
• Cómo crear una copia de seguridad de un clúster

No puedes iniciar una nueva actualización de clúster mientras una actualización de clúster activa está detenida.

Cómo habilitar la pausa y la reanudación de la actualización

Google Distributed Cloud 1.30

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 una posterior.

Google Distributed Cloud 1.29

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 pausar y reanudar la actualización esté en versión preliminar, puedes habilitarla con una anotación en el recurso de clúster.

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

1. Agrega la secció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 el clúster:

   bmctl update CLUSTER_NAME
   

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

Cómo pausar una actualización

Para pausar una actualización de clúster, establece nodePoolUpgradeStrategy.pause en true en la especificación del clúster.

Para pausar una actualización de clúster activa, 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 ventana de terminal nueva para realizar el siguiente paso.

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

   bmctl update CLUSTER_NAME
   

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

3. Si usaste bmctl para iniciar la actualización y planeas 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 en el archivo de registro cluster-upgrade-TIMESTAMP en la carpeta del clúster de tu estación de trabajo de administrador y en Cloud Logging. Por lo tanto, para pausas breves, te recomendamos que mantengas bmctl en ejecución. Si dejas bmctl en ejecución durante un período prolongado mientras la actualización está pausada, se agota el tiempo de espera.

Cómo reanudar una actualización pausada

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

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

1. Configura nodePoolUpgradeStrategy.pause en el archivo de configuración del clúster y configúralo como 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 el clúster:

   bmctl update CLUSTER_NAME
   

   La operación de actualización se reanuda desde donde quedó.

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 de anthosBareMetalVersion.

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

   En el siguiente ejemplo, se muestra el formato de la respuesta para los recursos personalizados de 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 está en la versión 1.16.2 de Google Distributed Cloud.