Se usó la API de Cloud Translation para traducir esta página.

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 la actualización de clústeres de Anthos alojados 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:

Actualizaciones selectivas del grupo de nodo trabajador trabajadores: actualiza grupos de nodo trabajador específicos por separado del resto del clúster.
Actualizaciones paralelas: Configura el proceso de actualización para actualizar grupos de nodos o grupos de nodos de forma simultánea.

Estas opciones pueden reducir el riesgo de interrupciones en aplicaciones y servicios 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 o 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.

Si quieres conocer las reglas de control de versiones para actualizar grupos de nodo trabajador de forma selectiva, consulta Reglas de control de versiones de los grupos de nodos en Ciclo de vida y las 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:

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.
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:
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.15.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.16.8, pero deseas que wpool02 permanezca en la versión 1.15.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.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.8
  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.15.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:

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.
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.16.8, pero el grupo de nodos wpool02 aún está en la versión 1.15.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.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.8
  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:

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.

Nota: No puedes especificar una estrategia de actualización de nodos para el plano de control o los grupos de nodos del balanceador de cargas.
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.16.8
  ...
  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.
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.

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

Edita el archivo de configuración del clúster para establecer anthosBareMetalVersion en la versión de destino de la actualización.
Para iniciar la actualización, ejecuta el siguiente comando:
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
Reemplaza CLUSTER_CONFIG_PATH por la ruta de acceso al 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.