Actualiza los clústeres

Version 1.15 

• Más reciente
• Versión 1.16
• Versiones anteriores (no admitidas)

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.

A partir de la versión 1.15.0 de GKE en Bare Metal, el comportamiento de actualización predeterminado para los clústeres autoadministrados (de administrador, híbrido o independiente) es una actualización in situ. Las actualizaciones locales usan controladores de ciclo de vida, en lugar de un clúster de arranque, para administrar todo el proceso de actualización. Este cambio simplifica el proceso y reduce los requisitos de recursos, lo que hace que las actualizaciones de los clústeres sean más confiables y escalables.

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

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

Consideraciones sobre 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.

Actualiza clústeres de administrador, independiente, híbrido o de usuario

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.15.11, asegúrate de que los clústeres de usuario asociados estén en la versión 1.14.0 o superior. bmctl emitirá un error si descubre que un clúster de usuario es inferior a 1.14.0.

bmctl

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

1. Descarga 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.15.11
   

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

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.

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

Nota: En las versiones de GKE en Bare Metal de 1.14.0 a 1.14.4, el campo de especificación de NodePool spec.upgradeStrategy.parallelUpgrade.concurrentNodes es inmutable. En estas versiones, solo puedes agregar este campo a un grupo de nodos nuevo. Una vez que se agrega este campo, no se puede actualizar ni quitar. Te recomendamos que actualices a una versión más reciente a la 1.14.4 antes de ejecutar actualizaciones paralelas.

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. La capacidad de actualizar varios grupos de nodos de forma simultánea está disponible en la versión preliminar pública. Para obtener más información, consulta Estrategia de actualización del grupo de nodos.

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.

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

La estrategia de actualización de nodos solo se aplica a los grupos de nodo trabajador. No puedes especificar una estrategia de actualización de nodos para 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 20% de la cantidad de nodos en el grupo de nodos ni 10, lo que sea menor. Por ejemplo, si tu grupo de nodos tiene 40 nodos, no puedes especificar un valor superior a 8. Si tu grupo de nodos tiene 100 nodos, 10 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 dos a la vez, y al menos 5 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: 2
      minimumAvailableNodes: 5 

Estrategia de actualización del grupo de nodos

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

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).

La capacidad de actualizar todos los grupos de nodo trabajador de forma simultánea solo está disponible para la Vista previa. No uses esta función en los clústeres de producción.

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

Precaución: Para las versiones de 1.14.0 a 1.14.4 de GKE en Bare Metal, el campo upgradeStrategy es inmutable. En estas versiones, solo puedes agregar este campo a un grupo de nodos nuevo. Una vez que se agrega este campo, no se puede actualizar ni quitar.

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.

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

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

   Precaución: La capacidad de actualizar todos los grupos de nodo trabajador de forma simultánea solo está disponible para la vista previa. No uses esta función en los clústeres de producción.

   ---
   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.15.0
     ...
     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.

Cómo inhabilitar las actualizaciones paralelas de los nodos

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)	0	No es necesario garantizar que los nodos estén disponibles durante una actualización.