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. Actualizar un clúster a la versión más reciente de GKE en Bare Metal proporciona características y correcciones adicionales al 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 puedes usar kubectl.

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

Planifica la actualización

Esta sección contiene información y vínculos a información que debes tener en cuenta antes de actualizar un clúster.

prácticas recomendadas

Si quieres obtener información que te ayude a prepararte para la actualización de un clúster, consulta Prácticas recomendadas para actualizar clústeres de GKE en Bare Metal.

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 Comprende las comprobaciones preliminares.

A fin de verificar 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 de actualizaciones.

Problemas conocidos

Para obtener información sobre posibles problemas relacionados con las actualizaciones de clústeres, consulta Problemas conocidos de clústeres de Anthos alojados en Bare Metal y selecciona la categoría de problema Actualizaciones y actualizaciones.

Configura las opciones de actualización

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

Estas opciones pueden reducir el riesgo de interrupciones en aplicaciones y servicios fundamentales y reducir de manera 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. Si deseas obtener más información sobre qué hacen estas opciones y cómo usarlas, consulta las siguientes secciones.

Actualizaciones selectivas del grupo 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 lenta, ya que provoca que cada nodo se desvíe y que 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 la actualización de un clúster a fin de minimizar la interrupción de la carga de trabajo. Esta función solo se aplica a los clústeres de usuario, híbridos y independientes, 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:

  • Implementa 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 tus 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 manera selectiva para garantizar que las cargas de trabajo se ejecuten de forma correcta 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 actualizan. Si reduces la cantidad de nodos que se actualizan mediante la exclusión de grupos de nodos, reduce el tiempo de actualización. Debes actualizar varias veces, pero los períodos de mantenimiento más pequeños y predecibles pueden ayudar con la programación.

Sesgo de versiones de grupos de nodos de dos versiones secundarias

Con la versión secundaria 1.28 de GKE en Bare Metal, una versión del grupo de nodo trabajador puede ser de hasta dos versiones secundarias detrás de la versión del clúster (plano de control). Este sesgo de versión n-2 está disponible como una función (Versión preliminar).

  • 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 una versión secundaria.

Si quieres obtener más información sobre las reglas de control de versiones para actualizar de forma selectiva grupos de nodos trabajadores, consulta Reglas de control de versiones de grupos 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, haz lo siguiente:

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

    • Establece anthosBareMetalVersion en la especificación de grupo de nodos como 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 string vacía. De forma predeterminada, los grupos de nodo trabajador se incluyen en las actualizaciones de los clústeres.

  2. En los grupos de nodo trabajador que deseas excluir de la actualización, configura anthosBareMetalVersion en la versión actual (previa 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 manera selectiva un grupo de nodos del balanceador de cargas, ya que 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 está en la versión 1.16.0 y tiene dos grupos de nodo trabajador: wpool01 y wpool02. Además, supongamos que deseas actualizar el plano de control y wpool01 a la versión 1.28.400-gke.77, pero deseas que wpool02 permanezca en la versión 1.16.0.

En el siguiente extracto del archivo de configuración del clúster, se muestra cómo 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.28.400-gke.77
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.400-gke.77
  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.16.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 la 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 de grupo de nodos establecido en la versión anterior del clúster (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 del grupo de nodos en el archivo de configuración del clúster para los grupos de nodos trabajadores que deseas mostrar 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 los hay. Si no quieres actualizar los 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 a la versión actual del clúster actualizada.

Por ejemplo, supongamos que actualizaste tu clúster a la versión 1.28.400-gke.77, pero el grupo de nodos wpool02 aún está en la versión 1.16.0 anterior del clúster previa a la actualización. Las cargas de trabajo se ejecutan de forma correcta en el grupo de nodos actualizado, wpool01, por lo que ahora deseas que wpool02 también esté en la versión actual del clúster. Para actualizar wpool02, puedes quitar el campo anthosBareMetalVersion o establecer su valor como una cadena vacía.

En el siguiente extracto del archivo de configuración del clúster, se muestra cómo 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.28.400-gke.77
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.400-gke.77
  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

Actualizaciones paralelas

En una actualización de clúster predeterminada típica, cada nodo del clúster se actualiza de forma secuencial, uno después del 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 para los clústeres que tienen cientos de nodos.

Hay 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 los 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 de los grupos de nodos 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 del grupo de nodos: Puedes configurar el clúster para que se actualicen varios grupos de nodos 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 de forma 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 del clúster.

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 los grupos de nodos del plano de control o 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 superar el 50% de la cantidad de nodos del grupo de nodos ni el número fijo 15, el 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 está configurado en 18, concurrentNodes no puede ser mayor que 2. Del mismo modo, si concurrentNodes se configura en 10, minimumAvailableNodes no puede superar 10.

En el siguiente ejemplo, se muestra un grupo de nodo trabajador np1 con 10 nodos. En una actualización, los nodos se actualizan de a 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 todos los grupos de nodo trabajador de un clúster de forma simultánea o no. De forma predeterminada (1), los grupos de nodos se actualizan de forma secuencial, uno después del otro. Cuando configuras concurrentNodePools como 0, cada grupo de nodo trabajador en el clúster se actualiza en paralelo.

Esta configuración no afecta a los grupos de nodos del plano de control y del balanceo de cargas. 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 las especificaciones 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 las actualizaciones paralelas.

Para realizar una actualización paralela de grupos de nodo trabajador y nodos en un grupo de nodo trabajador, sigue estos pasos:

  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.

    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 configura como 10, lo que significa que deben permanecer al menos 10 nodos disponibles para las cargas de trabajo durante la actualización.

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

    ---
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.28.400-gke.77
  ...
  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 de forma simultánea durante la actualización del clúster. La estrategia de actualización para los nodos en los grupos de nodos se define en las especificaciones de grupo de nodos.

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

Valores predeterminados de las 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 paralelas y sus valores predeterminados:

Campo Valor predeterminado Significado
nodePoolUpgradeStrategy.concurrentNodePools (especificaciones de clúster) 1 Actualiza los grupos de nodo trabajador de forma secuencial, uno tras otro.
upgradeStrategy.parallelUpgrade.concurrentNodes (especificación de grupo de nodos) 1 Actualiza los nodos de forma secuencial, uno tras otro.
upgradeStrategy.parallelUpgrade.minimumAvailableNodes (especificación de grupo de nodos) El valor predeterminado minimumAvailableNodes depende del valor de concurrentNodes.
  • Si no especificas concurrentNodes, minimumAvailableNodes de forma predeterminada es 2/3 el 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 el minimumAvailableNodes y solo continúa cuando la cantidad de nodos disponibles es mayor que minimumAvailableNodes.

Inicia la actualización del clúster

En esta sección, se incluyen instrucciones para actualizar clústeres.

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 la versión más reciente de bmctl como se describe en Descargas de GKE en Bare Metal.

  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.28.400-gke.77

  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 previas para validar el estado del clúster y 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 hayan actualizado de forma correcta, la operación de actualización del clúster realiza verificaciones de estado del clúster. Con este último paso, se verifica que el clúster se encuentre en buenas condiciones de funcionamiento. Si el clúster no pasa todas las verificaciones de estado, 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 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 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 grupos 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 tu clúster se mantenga en condiciones operativas.

Pausar y reanudar actualizaciones

Con la versión secundaria 1.28 de GKE en Bare Metal, puedes pausar y reanudar una actualización del clúster. Cuando se pausa la actualización de un clúster, no se activan actualizaciones de nodos nuevas hasta que se reanude. Esta función solo está disponible para clústeres con todos los nodos del plano de control en la versión secundaria 1.28 o superior.

Recomendamos detener una actualización por los siguientes motivos:

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

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

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

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

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

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

Habilitar la pausa y la reanudación de actualizaciones

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

Para habilitar la pausa y la reanudación de actualizaciones, 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.

Detener 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 establécelo en true:

    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:
  ...
  nodePoolUpgradeStrategy:
    pause: true
  ...

    Si usaste bmctl para iniciar la actualización, necesitas una ventana de terminal nueva a fin de 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 actualizaciones de nodos nuevos.

  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 sale 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 en la carpeta del clúster de la estación de trabajo de administrador y en Cloud Logging. Por lo tanto, para las pausas cortas, te recomendamos que sigas ejecutando bmctl. Si dejas que bmctl se ejecute durante un período prolongado mientras la actualización está pausada, finalmente se agotará el tiempo de espera.

Reanuda una actualización pausada

Para reanudar la actualización de un clúster en pausa, 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 pausó, 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
  annotations:
        preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: false
  ...

    También 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 la dejó.

  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 del 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 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 se encuentra en GKE en la versión 1.16.2 de Bare Metal.