Actualizar clústeres

Cuando instales una nueva versión de bmctl, podrás actualizar los clústeres que hayas creado con una versión anterior. Al actualizar un clúster a la versión más reciente de Google Distributed Cloud, se añaden funciones y correcciones al clúster. También asegura que tu clúster siga siendo compatible. Puedes actualizar clústeres de administrador, híbridos, independientes o de usuario con el comando bmctl upgrade cluster o con 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 fases de las actualizaciones de clústeres.

Esta página está dirigida a administradores, arquitectos y operadores que gestionan el ciclo de vida de la infraestructura tecnológica subyacente. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud

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 de parche más reciente disponible para asegurarte de que tienes los parches de seguridad más recientes. Consulta siempre las notas de la versión antes de actualizar para saber qué ha cambiado, incluidas las correcciones de seguridad y los problemas conocidos. No se puede cambiar a una versión anterior del clúster.

Planificar la actualización

Esta sección contiene información y enlaces a información que debe 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 de los clústeres y los grupos de nodos, consulta Ciclo de vida y fases de las actualizaciones de clústeres.

Prácticas recomendadas

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

Comprobaciones preparatorias de la actualización

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

Para comprobar si los clústeres están listos para una actualización, ejecuta la comprobación previa antes de ejecutar la actualización. Para obtener más información, consulta Comprobaciones de solicitudes preparatorias para las 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 bare metal y selecciona la categoría de problemas Actualizaciones.

Configurar las opciones de actualización

Antes de iniciar una actualización de clúster, puedes configurar las siguientes opciones de actualización que controlan cómo funciona el proceso de actualización:

• Actualizaciones selectivas de grupos de nodos de trabajador: actualiza grupos de nodos de 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 simultáneamente.

Estas opciones pueden reducir el riesgo de interrupciones en las aplicaciones y los servicios críticos, así como reducir significativamente el tiempo total de actualización. Estas opciones son especialmente útiles para clústeres grandes con muchos 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 secciones siguientes.

Actualizaciones selectivas de grupos de nodos de trabajador

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 un proceso largo y que cause interrupciones, ya que se vacía cada nodo y se reinician y reprograman todos los pods asociados. En esta sección se describe cómo puedes incluir o excluir grupos de nodos de trabajador concretos para actualizar un clúster y 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 los grupos de nodos de trabajo.

Puedes usar las actualizaciones selectivas de grupos de nodos 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 carga) para aplicar las correcciones de vulnerabilidades de Kubernetes sin interrumpir los grupos de nodos de trabajo.

• Para confirmar que un subconjunto actualizado de nodos de trabajo funciona correctamente antes de actualizar todos los nodos de trabajo: puedes actualizar los grupos de nodos de trabajo de forma selectiva para asegurarte de que las cargas de trabajo se ejecutan correctamente en un grupo de nodos actualizado antes de actualizar otro grupo de nodos.

• Para reducir la ventana de mantenimiento: actualizar un clúster grande puede llevar mucho tiempo y es difícil predecir con precisión cuándo se completará la actualización. El tiempo de actualización del clúster es proporcional al número de nodos que se van a actualizar. Si excluye grupos de nodos, se reduce el número de nodos que se actualizan y, por lo tanto, el tiempo de actualización. Puedes hacer varias actualizaciones, pero las ventanas de mantenimiento más pequeñas y predecibles pueden ayudarte a programarlas.

Diferencia de dos versiones secundarias en la versión del grupo de nodos

En los clústeres de la versión 1.28 y posteriores, la versión de un grupo de nodos de trabajador puede ser hasta dos versiones secundarias anterior a la versión del clúster (plano de control). Con la compatibilidad con la diferencia de versiones n-2, también puedes saltarte una versión secundaria cuando actualices un grupo de nodos de trabajo que tenga dos versiones secundarias anteriores a la del clúster a la misma versión secundaria que el clúster.

Esta compatibilidad con la diferencia de versiones n-2 para grupos de nodos de trabajador te ofrece más flexibilidad para planificar las actualizaciones de tu flota.

Por ejemplo, si tienes un clúster de la versión 1.33, puedes tener grupos de nodos de trabajador en las versiones 1.33, 1.32 y 1.31.

Antes de actualizar un clúster, todos los grupos de nodos de trabajo deben tener una versión compatible tanto con la versión actual del clúster como con la versión de destino.

Por ejemplo, si tienes un clúster con la versión 1.29 y grupos de nodos de trabajo con las versiones 1.29, 1.28 y 1.16, debes actualizar los grupos de nodos de la versión 1.16 a la 1.28 o a la 1.29 para 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 de trabajo admitidas por una versión de clúster determinada (aplicable a la versión 1.29 y anteriores), consulta Reglas de versiones de grupos de nodos.

1.30

En la versión 1.30, la compatibilidad con la diferencia de versiones n-2 para los grupos de nodos de trabajador está disponible de forma general para todos los tipos de clústeres. Esta función está habilitada de forma predeterminada en 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 la versión 1.30, siempre que la versión del grupo de nodos sea igual o inferior a la versión del clúster.

1,29

En la versión 1.29, la compatibilidad con la diferencia de versiones n-2 para grupos de nodos de trabajador está disponible para todos los tipos de clústeres. Esta función está habilitada de forma predeterminada en los clústeres de la versión 1.29.

Mientras pasamos esta función de Vista Previa Pública a Disponibilidad General, los clústeres híbridos seguirán necesitando 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 de trabajador de la versión 1.16.y, debes añadir 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 los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Los productos y las funciones previos a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases de lanzamiento.

La compatibilidad con la diferencia de versiones n-2 para los grupos de nodos de trabajador está disponible en vista previa en la versión 1.28. Para habilitar esta función de vista previa, añade 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 vista previa, la diferencia máxima entre la versión de un grupo de nodos de trabajo y la del clúster será de una versión secundaria.

Para obtener más información sobre las reglas de control de versiones para actualizar selectivamente los grupos de nodos de trabajador, consulta las reglas de control de versiones de grupos de nodos en Ciclo de vida y fases de las actualizaciones de clústeres.

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

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

1. En los grupos de nodos de trabajador que quieras incluir en la actualización del clúster, haz uno de los siguientes cambios en la especificación NodePool:

   • Define anthosBareMetalVersion en la especificación NodePool como la versión de actualización de destino del clúster.
   • Omita el campo anthosBareMetalVersion de la especificación NodePool o asígnele la cadena vacía. De forma predeterminada, los grupos de nodos de trabajador se incluyen en las actualizaciones de clústeres.

2. En los grupos de nodos de trabajo que quieras excluir de la actualización, asigna a anthosBareMetalVersion la versión actual (anterior a la actualización) del clúster:

3. Continúa con la actualización tal como se describe en Iniciar 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 carga, si tu clúster usa uno (spec.loadBalancer.nodePoolSpec). De forma predeterminada, los nodos del balanceador de carga pueden ejecutar cargas de trabajo normales. No puedes actualizar de forma selectiva un grupo de nodos de balanceador de carga, ya que siempre se incluye en la actualización inicial del clúster.
   • Grupos de nodos de trabajo que no hayas excluido de la actualización.

Por ejemplo, supongamos que tu clúster tiene la versión 1.32.0 y dos grupos de nodos de trabajador: wpool01 y wpool02. Supongamos que quieres actualizar el plano de control y wpool01 a la versión 1.33.0-gke.799, pero quieres que wpool02 siga en la versión 1.32.0.

El siguiente fragmento del archivo de configuración del clúster 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.33.0-gke.799
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.33.0-gke.799
  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.32.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

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

Si has excluido 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 del clúster de destino. Los grupos de nodos de trabajador que se han excluido de una actualización de clúster tienen el campo anthosBareMetalVersion en su especificación NodePool definido en la versión anterior del clúster (antes de la actualización).

Para actualizar los grupos de nodos de trabajador a la versión actual del clúster:

1. Edita las especificaciones de NodePool en el archivo de configuración del clúster de los grupos de nodos de trabajador que quieras actualizar a la versión actual del clúster. Define anthosBareMetalVersion en la versión actual del clúster (posterior a la actualización).

   Si se seleccionan varios grupos de nodos de 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 procede. Si no quieres actualizar los grupos de nodos de trabajador simultáneamente, selecciona un grupo de nodos cada vez para actualizarlo.

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

   La operación de actualización del clúster solo actualiza los grupos de nodos de trabajador excluidos anteriormente para los que hayas definido anthosBareMetalVersion a la versión actual del clúster actualizado.

Por ejemplo, supongamos que has actualizado tu clúster a la versión 1.33.0-gke.799, pero el grupo de nodos wpool02 sigue en la versión anterior a la actualización, la 1.32.0. Las cargas de trabajo se ejecutan correctamente en el grupo de nodos actualizado, wpool01, por lo que ahora quieres actualizar wpool02 a la versión actual del clúster. Para actualizar wpool02, puede quitar el campo anthosBareMetalVersion o asignarle el valor de cadena vacía.

El siguiente fragmento del archivo de configuración del clúster 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.33.0-gke.799
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.33.0-gke.799
  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

Revertir la actualización de un grupo de nodos

Hay muchas dependencias, como la compatibilidad con kubelet o los complementos, que pueden afectar al rendimiento de tus cargas de trabajo. Si tienes algún problema después de actualizar un grupo de nodos de trabajo, puedes restaurar la versión anterior del grupo de nodos.

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

1.30

En los clústeres de la versión 1.30 (clústeres con nodos del plano de control de la versión 1.30), la función de restauración de grupos de nodos está disponible de forma general y habilitada de forma predeterminada.

1,29

Vista previa

Este producto o función está sujeto a los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Los productos y las funciones previos a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases de lanzamiento.

La función de reversión de grupos de nodos está disponible en vista previa para los clústeres de la versión 1.29 (clústeres con nodos del plano de control de la versión 1.29). Mientras esta función esté en versión preliminar, debe añadir 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 restauración de grupos de nodos no está disponible en clústeres con la versión secundaria 1.28 o anterior.

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

bmctl

Cuando usas bmctl para revertir la 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 de los grupos de nodos de trabajador a los que quieras restaurar la versión anterior. Asigna a anthosBareMetalVersion 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.32.400-gke.68
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
   

   Si se seleccionan varios grupos de nodos de 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 restaurar los grupos de nodos de trabajo simultáneamente, selecciona un grupo de nodos a la vez para restaurarlo o actualiza los ajustes 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
   

   Haz los cambios siguientes:

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

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

   La reversión se inicia automáticamente. El comando bmctl update cluster se cierra inmediatamente, pero la reversión sigue su curso. No realices ninguna otra operación en el clúster mientras se esté llevando a cabo la reversión.

3. Mientras se ejecuta la reversión, Google Distributed Cloud realiza las siguientes actividades en cada nodo:

   • Pon el nodo en modo de mantenimiento.
   • Ejecuta un trabajo de restablecimiento en el nodo para que vuelva a un estado limpio.
   • Ejecuta comprobaciones preparatorias de la máquina en el nodo.
   • Ejecuta un trabajo de inicialización de la máquina en el nodo para reinstalarlo en la versión de restauración (anterior a la actualización) de destino.
   • 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 de destino.

No uses bmctl update y kubectl apply -f de forma indistinta al editar el archivo de configuración del clúster. Si estos comandos se usan indistintamente, es posible que se elimine contenido de forma involuntaria. Por ejemplo, puedes usar bmctl update para actualizar el archivo de configuración del clúster y configurar un mirror de registro. El clúster tendrá spec.nodeConfig.registryMirrors elementos después de la conciliación.

Si intentas hacer cambios en el clúster mediante la configuración del clúster con el comando kubectl apply -f, se eliminará el spec.nodeConfig.registryMirrors rellenado por el reconciliador en el clúster. Esto ocurre 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 un grupo de nodos mediante kubectl para editar el recurso NodePool directamente:

1. Para revertir un grupo de nodos de trabajador, abre el recurso NodePool para editarlo:

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

   Haz los cambios siguientes:

   • NODE_POOL_NAME: el nombre del grupo de nodos al que quieres volver.

   • CLUSTER_NAMESPACE: 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: la ruta del archivo kubeconfig del clúster de gestió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.32.400-gke.68
     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 se inicia automáticamente. No realices ninguna otra operación en el clúster mientras se esté llevando a cabo la reversión.

4. Mientras se ejecuta la reversión, Google Distributed Cloud realiza las siguientes actividades en cada nodo:

   • Pon el nodo en modo de mantenimiento.
   • Ejecuta un trabajo de restablecimiento en el nodo para que vuelva a un estado limpio.
   • Ejecuta comprobaciones preparatorias de la máquina en el nodo.
   • Ejecuta un trabajo de inicialización de la máquina en el nodo para reinstalarlo en la versión de restauración (anterior a la actualización) de destino.
   • 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 de destino.

Actualizaciones paralelas

En una actualización de clúster predeterminada, cada nodo del clúster se actualiza de forma secuencial, uno después del otro. En esta sección se explica cómo configurar los grupos de nodos de trabajador y de clúster para que varios nodos se actualicen en paralelo al actualizar el clúster. Actualizar nodos en paralelo acelera significativamente las actualizaciones de clústeres, sobre todo en el caso de los clústeres que tienen cientos de nodos.

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

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

• Actualización simultánea de nodos: puedes configurar tus grupos de nodos de trabajador para que varios nodos se actualicen en paralelo. Las actualizaciones paralelas de nodos se configuran en la especificación NodePool (spec.upgradeStrategy.parallelUpgrade) y solo se pueden actualizar en paralelo los nodos de un grupo de nodos de trabajador. Los nodos de los grupos de nodos del plano de control o del balanceador de carga solo se pueden actualizar de uno en uno. 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 se actualicen varios grupos de nodos en paralelo. Solo se pueden actualizar en paralelo los grupos de nodos de trabajo. Los grupos de nodos del plano de control y del balanceador de carga solo se pueden actualizar de uno en uno.

Estrategia de actualización de nodos

Puedes configurar los grupos de nodos de trabajo para que varios nodos se actualicen simultáneamente (concurrentNodes). También puedes definir un umbral mínimo para el número de nodos que pueden ejecutar cargas de trabajo durante el proceso de actualización (minimumAvailableNodes). Esta configuración se realiza en la especificación NodePool. Para obtener más información sobre estos campos, consulta la referencia de campos de configuración de clústeres.

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 estar disponibles para ejecutar cargas de trabajo durante todo el proceso de actualización.

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

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

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

• Si usas concurrentNodes junto con minimumAvailableNodes, los valores combinados no pueden superar el número total de nodos del grupo de nodos. Por ejemplo, si tu pool de nodos tiene 20 nodos y minimumAvailableNodes está configurado en 18, concurrentNodes no puede superar el valor 2. Del mismo modo, si concurrentNodes se define como 10, minimumAvailableNodes no puede superar el valor 10.

En el siguiente ejemplo se muestra un pool de nodos de trabajador np1 con 10 nodos. En una actualización, los nodos se actualizan de 5 en 5 y deben quedar disponibles al menos 4 nodos 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 de grupos de nodos

Puedes configurar un clúster para que varios grupos de nodos de trabajador se actualicen en paralelo. El campo booleano nodePoolUpgradeStrategy.concurrentNodePools de la especificación del clúster indica si se deben actualizar todos los grupos de nodos de trabajo de un clúster simultáneamente. De forma predeterminada (1), los grupos de nodos se actualizan secuencialmente, uno después del otro. Si asignas el valor concurrentNodePools a 0, todos los grupos de nodos de trabajo del clúster se actualizarán en paralelo.

Este ajuste no afecta a los grupos de nodos del plano de control ni del balanceo de carga. 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 carga 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 nodos de trabajador para realizar actualizaciones paralelas.

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

1. Añada una sección upgradeStrategy a la especificación NodePool.

   Puede aplicar este manifiesto por separado o como parte del archivo de configuración del clúster al actualizarlo.

   Veamos 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 se actualizan 5 nodos en paralelo. El campo minimumAvailableNodes se ha definido como 10, lo que significa que deben quedar disponibles al menos 10 nodos 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 o del balanceador de carga.

2. Añade 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.33.0-gke.799
     ...
     nodePoolUpgradeStrategy:
       concurrentNodePools: 0
     ...
   

   En este ejemplo, el campo concurrentNodePools se define como 0, lo que significa que todos los grupos de nodos de trabajo se actualizan simultáneamente durante la actualización del clúster. La estrategia de actualización de 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 Actualizar clústeres de administrador, independientes, híbridos o de usuario.

Valores predeterminados de la actualización paralela

Las actualizaciones paralelas están inhabilitadas de forma predeterminada y los campos relacionados con ellas se pueden modificar. En cualquier momento, puede quitar los campos o asignarles sus valores predeterminados para inhabilitar la función antes de una actualización posterior.

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

Campo	Valor predeterminado	Significado
nodePoolUpgradeStrategy.concurrentNodePools (especificación de clúster)	1	Actualiza los grupos de nodos de trabajador de forma secuencial, uno después del 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 minimumAvailableNodes depende del valor de concurrentNodes. Si no especificas concurrentNodes, el valor predeterminado de minimumAvailableNodes es 2/3 del tamaño del grupo de nodos. Si especifica concurrentNodes, el valor predeterminado de minimumAvailableNodes será el tamaño del grupo de nodos menos concurrentNodes.	La actualización se detiene cuando se alcanza el valor de minimumAvailableNodes y solo continúa cuando el número de nodos disponibles es superior a minimumAvailableNodes.

Iniciar la actualización del clúster

En esta sección se incluyen 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.33.0-gke.799, asegúrate de que sus clústeres de usuario asociados tengan la versión 1.32.0 o una superior. bmctl emite un error si detecta que algún clúster de usuarios tiene una versión inferior a 1.32.0.

bmctl

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

1. Define 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 Configurar credenciales predeterminadas de la aplicación.

2. Descarga la versión más reciente de bmctl, tal como se describe en la página de 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.33.0-gke.799
   

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

   bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Haz los cambios siguientes:

   • CLUSTER_NAME: el nombre del clúster que se va a actualizar.
   • ADMIN_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador.
   Nota: El comando bmctl upgrade solo actualiza el valor de anthosBareMetalVersion y las anotaciones de vista previa en el recurso personalizado de clúster. Si quieres modificar otros campos de la especificación del clúster, usa el comando bmctl update. Para obtener más información, consulta Actualizar clústeres.

   La operación de actualización del clúster ejecuta comprobaciones de solicitudes preparatorias para validar el estado del clúster y el estado de los nodos. La actualización del clúster no continúa si fallan las comprobaciones previas. Para obtener información sobre cómo solucionar problemas, consulta Solucionar 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á comprobaciones del estado del clúster. Este último paso verifica que el clúster esté en buen estado. Si el clúster no supera todas las comprobaciones de estado, estas se seguirán ejecutando hasta que lo haga. Cuando todas las comprobaciones de estado se superen, la actualización se completará correctamente.

   Para obtener más información sobre la secuencia de eventos de las actualizaciones de clústeres, consulta Ciclo de vida y fases 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 definir 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
   

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

   Al igual que en el proceso de actualización con bmctl, las comprobaciones preparatorias se ejecutan como parte de la actualización del clúster para validar el estado del clúster y el estado de los nodos. Si las comprobaciones previas fallan, la actualización del clúster se detiene. Para solucionar los fallos, 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 Solucionar problemas de instalación o actualización de clústeres.

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

Pausar y reanudar las actualizaciones

La función de pausar y reanudar la actualización te permite pausar la actualización de un clúster antes de que finalice. Cuando se pausa una actualización de un clúster, no se activan nuevas actualizaciones de nodos de trabajo 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 secundaria 1.28 o posterior. La función está disponible con carácter general para los clústeres con todos los nodos del plano de control en la versión secundaria 1.29 o posterior.

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

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

• Tienes ventanas de mantenimiento cortas, por lo que quieres pausar la actualización entre ventanas.

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

• Añadir o quitar nodos
• Añadir o quitar grupos de nodos
• Aumentar la cobertura de la red de servicio
• Restaurar un clúster a partir de una copia de seguridad

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

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

• Rotar autoridades de certificación
• Crear una copia de seguridad de un clúster

No puedes iniciar una nueva actualización de clúster mientras haya una actualización de clúster activa en pausa.

Habilitar la pausa y la reanudación de las actualizaciones

Google Distributed Cloud 1.33

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

Google Distributed Cloud 1.32

Vista previa

Este producto o función está sujeto a los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Los productos y las funciones previos a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases 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, siga estos pasos:

1. Añade 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: enable
   spec:
   ...
   

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

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   Haz los cambios siguientes:

   • CLUSTER_NAME: el nombre del clúster que quieras actualizar.
   • ADMIN_KUBECONFIG: en el caso de los clústeres de administrador, híbridos o independientes, introduce la ruta al archivo kubeconfig del clúster. En el caso de un clúster de usuario, introduce la ruta al archivo kubeconfig del clúster admin.

   El campo nodePoolUpgradeStrategy.pause es mutable. Puedes añadirla y actualizarla en cualquier momento.

Pausar una actualización

Para pausar una actualización de un clúster, asigna el valor true a nodePoolUpgradeStrategy.pause en la especificación del clúster.

Para pausar una actualización de clúster activa, siga estos pasos:

1. Añade nodePoolUpgradeStrategy.pause al archivo de configuración del clúster y asígnale el valor true:

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

   Si has usado bmctl para iniciar la actualización, necesitas una nueva ventana de terminal 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á en pausa. No se activan nuevas actualizaciones de nodos.

3. Si has usado bmctl para iniciar la actualización y tienes previsto pausarla durante mucho tiempo, pulsa Control+C para salir de bmctl. De lo contrario, deja que bmctl siga ejecutándose.

   La CLI bmctl no detecta los 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 deja de registrar el progreso de la actualización en el archivo de registro cluster-upgrade-TIMESTAMP de la carpeta del clúster en tu estación de trabajo de administrador y en Cloud Logging. Por lo tanto, en el caso de las pausas breves, te recomendamos que mantengas la bmctl ejecución. Si dejas bmctl en funcionamiento durante un periodo prolongado mientras la actualización está en pausa, al final se agota el tiempo de espera.

Reanudar una actualización pausada

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

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

1. Asigna el valor nodePoolUpgradeStrategy.pause al archivo de configuración del clúster y asigna el valor false:

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

   También puedes quitar el campo pause, ya que tiene el valor predeterminado false.

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

   bmctl update CLUSTER_NAME
   

   La operación de actualización se reanudará desde el punto en que se detuvo.

3. Para comprobar 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
   

   Haz los cambios siguientes:

   • RESOURCE: el nombre del recurso que quieres obtener. Todos 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 de 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 consultar la status.anthosBareMetalVersion (versión actual del recurso), obtén los detalles de los recursos concretos:

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

   En el siguiente ejemplo se muestran los detalles de BareMetalMachine del 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 tiene la versión 1.16.2 de Google Distributed Cloud.