Cuando instalas una versión nueva de bmctl
, puedes actualizar los clústeres existentes que se crearon con una versión anterior. La actualización de un clúster a la versión más reciente de Google Distributed Cloud le proporciona funciones adicionales y correcciones al clúster. También garantiza que tu clúster permanezca compatible.
Puedes actualizar clústeres de administrador, híbridos, independientes 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 y las reglas de control de versiones, consulta Ciclo de vida y etapas de las actualizaciones del clúster.
Planifica la actualización
En esta sección, encontrarás información y vínculos a información que debes tener en cuenta antes de actualizar un clúster.
prácticas recomendadas
Si deseas obtener información que te ayude a prepararte para actualizar el clúster, consulta Prácticas recomendadas para las actualizaciones de clústeres de Google Distributed Cloud.
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 Información sobre las comprobaciones preliminares.
A fin de comprobar 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 para 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 equipos físicos y selecciona la categoría de problemas Actualizaciones y actualizaciones.
Configurar opciones de actualización
Antes de iniciar la actualización de un clúster, puedes configurar las siguientes opciones de actualización que controlan el funcionamiento del proceso de actualización:
Actualizaciones selectivas de grupos 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 esenciales, y reducir de forma 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. Para obtener más información sobre lo que hacen estas opciones y cómo usarlas, consulta las siguientes secciones.
Actualizaciones selectivas de grupos de 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 requerir mucho tiempo, ya que hace que cada nodo se desvíe y 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 que se actualice un clúster y, así, minimizar la interrupción de la carga de trabajo. Esta función se aplica solo a los clústeres independientes, híbridos y de usuario, 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:
Para recoger correcciones de seguridad sin interrumpir las cargas de trabajo: Puedes actualizar solo los nodos del plano de control (y los nodos del balanceador de cargas) para aplicar correcciones de vulnerabilidades de Kubernetes sin interrumpir los grupos de 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 forma selectiva para garantizar que las cargas de trabajo se ejecuten correctamente en un grupo de nodos actualizado antes de actualizar otro grupo de nodos.
Para reducir el período de mantenimiento: La actualización de un clúster grande puede llevar mucho tiempo y es difícil predecir con precisión cuándo se completará una actualización. La hora de actualización del clúster es proporcional a la cantidad de nodos que se actualizan. Reducir la cantidad de nodos que se actualizan mediante la exclusión de grupos de nodos reduce el tiempo de actualización. Actualizas varias veces, pero los períodos de mantenimiento más pequeños y predecibles pueden ayudar con la programación.
Sesgo de dos versiones secundarias del grupo de nodos de la versión
Para la versión 1.28 y los clústeres posteriores, una versión de grupo de nodo trabajador puede ser de hasta dos versiones secundarias detrás de la versión del clúster (plano de control). Gracias a la compatibilidad con el sesgo de versiones n-2, también puedes omitir una versión de actualización secundaria cuando actualizas un grupo de nodo trabajador de dos versiones secundarias detrás del clúster a la misma versión secundaria que el clúster.
Esta compatibilidad con el sesgo de versiones n-2 para los grupos de nodo trabajador te brinda más flexibilidad para planificar las actualizaciones de tu flota.
Por ejemplo, si tienes un clúster de la versión 1.28, puedes tener grupos de nodo trabajador en las versiones seleccionadas 1.28, 1.16 y 1.15. Para actualizar tu clúster a la versión 1.29, primero debes actualizar cualquier grupo de nodo trabajador 1.15 a una versión compatible para el clúster de versión 1.28 previo a la actualización. No es necesario que actualices los grupos de nodo trabajador de la versión 1.16 a la versión 1.28 para poder actualizar tu clúster a la versión 1.29. Una vez que el clúster se actualizó a la versión 1.29, cuando decides actualizar los grupos de nodo trabajador de la versión 1.16 a la versión 1.29, puedes realizar la actualización en un solo paso y omitir la versión 1.28.
Para obtener más información, incluidas las listas de las versiones de grupos de nodo trabajador compatibles con una versión de clúster determinada, consulta Reglas de control de versiones del grupo de nodos
1.29
En la versión 1.29, la compatibilidad con el sesgo de versiones n-2 para grupos de nodo trabajador tiene disponibilidad general para todos los tipos de clústeres. Esta función está habilitada de forma predeterminada para los clústeres en la versión 1.29.
A medida que realizamos la transición de esta función de la versión preliminar pública a la DG, los clústeres híbridos aún requieren la anotación de vista previa en la siguiente situación. Si tienes un clúster híbrido versión 1.28.x con un grupo de nodo trabajador versión 1.16.y, debes agregar la anotación preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
al clúster antes de actualizarlo a la versión 1.29.z:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: baremetal-demo
namespace: cluster-baremetal-demo
annotations:
preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
type: hybrid
profile: default
anthosBareMetalVersion: 1.28.400-gke.77
...
1.28
La compatibilidad con el sesgo de versiones n-2 para grupos de nodo trabajador está disponible para la versión preliminar en la versión 1.28. Para habilitar esta función de vista previa, agrega la anotación preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
al archivo de configuración del clúster:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: baremetal-demo
namespace: cluster-baremetal-demo
annotations:
preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
...
Si no habilitas esta función de versión preliminar, el sesgo máximo de versiones entre un grupo de nodo trabajador y el clúster es de una versión secundaria.
Si quieres obtener más información sobre las reglas del control de versiones para actualizar grupos de nodos trabajadores de forma selectiva, consulta Reglas de control de versiones del grupo 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, sigue estos pasos:
Para los grupos de nodo trabajador que quieres incluir en la actualización del clúster, realiza uno de los siguientes cambios en la especificación del grupo de nodos:
- Configura
anthosBareMetalVersion
en la especificación del grupo de nodos para la versión de actualización objetivo del clúster. - Omite el campo
anthosBareMetalVersion
de la especificación del grupo de nodos o configúralo en la string vacía. De forma predeterminada, los grupos de nodo trabajador se incluyen en las actualizaciones del clúster.
- Configura
Para los grupos de nodo trabajador que deseas excluir de la actualización, configura
anthosBareMetalVersion
en la versión actual (antes de 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 un grupo de nodos del balanceador de cargas de forma selectiva; 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 se encuentra en la versión 1.28.0 y tiene dos grupos de nodo trabajador: wpool01
y wpool02
. Además, supongamos que deseas actualizar el plano de control y wpool01
a 1.29.100-gke.251, pero deseas que wpool02
permanezca en la versión 1.28.0.
En el siguiente extracto del archivo de configuración del clúster, se muestra cómo puedes modificar la configuración del clúster para admitir esta actualización parcial:
...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user001
namespace: cluster-user001
spec:
type: user
profile: default
anthosBareMetalVersion: 1.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.29.100-gke.251
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.28.0
nodes:
- address: 10.200.1.1
- address: 10.200.1.2
- address: 10.200.1.3
...
- address: 10.200.1.12
Actualiza los grupos de nodos a la versión actual del clúster
Si excluiste grupos de nodos de una actualización 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 NodePool
establecido en la versión del clúster anterior (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 de
NodePool
en el archivo de configuración del clúster para los grupos de nodos trabajadores que deseas usar en la versión actual del clúster. EstableceanthosBareMetalVersion
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 corresponde. Si no quieres actualizar 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
en la versión actual del clúster actualizada.
Por ejemplo, supongamos que actualizaste tu clúster a la versión 1.29.100-gke.251, pero el grupo de nodos wpool02
aún se encuentra en la versión 1.28.0 anterior del clúster previo a la actualización. Las cargas de trabajo se ejecutan de forma correcta en el grupo de nodos actualizado, wpool01
, por lo que ahora también debes llevar wpool02
a la versión actual del clúster. Para actualizar wpool02
, puedes quitar el campo anthosBareMetalVersion
o establecer su valor como la cadena vacía.
En el siguiente extracto del archivo de configuración del clúster, se muestra cómo puedes modificar la configuración del clúster para admitir esta actualización parcial:
...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user001
namespace: cluster-user001
spec:
type: user
profile: default
anthosBareMetalVersion: 1.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.29.100-gke.251
nodes:
- address: 10.200.0.1
- address: 10.200.0.2
- address: 10.200.0.3
...
- address: 10.200.0.8
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool02
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: ""
nodes:
- address: 10.200.1.1
- address: 10.200.1.2
- address: 10.200.1.3
...
- address: 10.200.1.12
Revierte la actualización de un grupo de nodos
Hay muchas dependencias, como la compatibilidad con kubelet o complementos, que pueden afectar el rendimiento de tus cargas de trabajo. En caso de que encuentres un problema después de actualizar un grupo de nodo trabajador, puedes revertir el grupo de nodos a su versión anterior.
La capacidad de reversión de grupos de nodos está disponible en la Vista previa para los clústeres de la versión 1.29 (clústeres con nodos del plano de control en la versión 1.29). Mientras esta función se encuentra en versión preliminar, debes agregar la anotación preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable
al recurso Cluster
para habilitarla.
Para revertir una actualización de grupo de nodos, sigue estos pasos:
bmctl
Cuando usas bmctl
para revertir la actualización de un grupo de nodos, edita el archivo de configuración del clúster y aplica los cambios con el comando bmctl update
:
Edita las especificaciones de
NodePool
en el archivo de configuración del clúster para los grupos de nodo trabajador que deseas revertir a la versión anterior. ConfiguraanthosBareMetalVersion
en la versión del clúster anterior (antes de la actualización).... --- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: wpool01 namespace: cluster-user001 spec: clusterName: user001 anthosBareMetalVersion: 1.28.500-gke.120 nodes: - address: 10.200.0.1 - address: 10.200.0.2 - address: 10.200.0.3 ...
Si se seleccionan varios grupos de nodo 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 revertir grupos de nodo trabajador de forma simultánea, selecciona un grupo de nodos a la vez para la reversión o actualiza la configuración denodePoolUpgradeStrategy
. Del mismo modo, el valor despec.upgradeStrategy.parallelUpgrade.concurrentNodes
en la especificaciónNodePool
determina cuántos nodos se revierten en paralelo.Usa
bmctl update
para aplicar los cambios a las especificaciones deNodePool
:bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
Reemplaza lo siguiente:
CLUSTER_NAME
: Es el nombre del clúster que deseas actualizar.ADMIN_KUBECONFIG
: Es la ruta de acceso del archivo kubeconfig del clúster de administración (administrador, híbrido o independiente).
La reversión comienza automáticamente.
A medida que se ejecuta la reversión, Google Distributed Cloud realiza las siguientes actividades para cada nodo:
- Poner el nodo en modo de mantenimiento
- Ejecuta un trabajo de restablecimiento en el nodo para que quede en un estado limpio.
- Ejecuta verificaciones previas de la máquina en el nodo.
- Ejecuta un trabajo de machine-init en el nodo para reinstalarlo en la versión de reversión de destino (antes de la actualización).
- Quitar el nodo del modo de mantenimiento
Cuando finaliza una reversión exitosa, el valor de
nodePool.status.anthosBareMetalVersion
en el recursoNodePool
se establece en la versión objetivo de reversión.
kubectl
Puedes revertir una actualización del grupo de nodos con kubectl
para editar el recurso NodePool
directamente:
Si deseas revertir un grupo de nodo trabajador, abre el recurso
NodePool
para editarlo:kubectl edit nodepool NODE_POOL_NAME \ --namespace CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG
Reemplaza lo siguiente:
NODE_POOL_NAME
: Es el nombre del grupo de nodos que estás revirtiendo.CLUSTER_NAMESPACE
: Es el nombre del espacio de nombres en el que se implementa el grupo de nodos. Este es el espacio de nombres del clúster.ADMIN_KUBECONFIG
: Es la ruta de acceso del archivo kubeconfig del clúster de administración (administrador, híbrido o independiente).
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.28.500-gke.120 nodes: - address: 10.200.0.1 - address: 10.200.0.2 - address: 10.200.0.3 ...
Guarda y cierra el recurso
NodePool
en el editor.La reversión comienza automáticamente.
A medida que se ejecuta la reversión, Google Distributed Cloud realiza las siguientes actividades para cada nodo:
- Poner el nodo en modo de mantenimiento
- Ejecuta un trabajo de restablecimiento en el nodo para que quede en un estado limpio.
- Ejecuta verificaciones previas de la máquina en el nodo.
- Ejecuta un trabajo de machine-init en el nodo para reinstalarlo en la versión de reversión de destino (antes de la actualización).
- Quitar el nodo del modo de mantenimiento
Cuando finaliza una reversión exitosa, el valor de
nodePool.status.anthosBareMetalVersion
en el recursoNodePool
se establece en la versión objetivo de reversión.
Actualizaciones paralelas
En una actualización de clúster predeterminada típica, cada nodo del clúster se actualiza de forma secuencial, uno tras 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, los que tienen cientos de nodos.
Existen 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 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 los grupos de nodos del balanceador de cargas solo se pueden actualizar de a uno. Para obtener más información, consulta Estrategia de actualización de nodos.Actualización simultánea del grupo de nodos: puedes configurar tu clúster para que varios grupos de nodos se actualicen 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 a fin de 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 del grupo de nodos. Para obtener más información sobre estos campos, consulta la referencia del campo 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 el plano de control o los grupos de nodos 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 exceder el 50% de la cantidad de nodos en el grupo de nodos ni el número fijo 15, lo que sea menor. Por ejemplo, si tu grupo de nodos tiene 20 nodos, no puedes especificar un valor superior a 10. Si tu grupo de nodos tiene 100 nodos, 15 es el valor máximo que puedes especificar.Cuando usas
concurrentNodes
junto conminimumAvailableNodes
, 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 yminimumAvailableNodes
se estableció en 18,concurrentNodes
no puede ser mayor que 2. Del mismo modo, siconcurrentNodes
se establece en 10,minimumAvailableNodes
no puede superar este valor.
En el siguiente ejemplo, se muestra un grupo de nodo trabajador np1
con 10 nodos. En una actualización, los nodos se actualizan de 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 o no todos los grupos de nodo trabajador de un clúster de forma simultánea. De forma predeterminada (1
), los grupos de nodos se actualizan de forma secuencial, uno tras otro. Cuando configuras concurrentNodePools
como 0
, cada grupo de nodo trabajador del clúster se actualiza en paralelo.
El plano de control y los grupos de nodos del balanceo de cargas no se ven afectados por esta configuración.
Estos grupos de nodos siempre se actualizan de forma secuencial, uno a la vez. Los grupos de nodos del plano de control y los grupos de nodos del balanceador de cargas se especifican en la especificación del clúster (controlPlane.nodePoolSpec.nodes
y loadBalancer.nodePoolSpec.nodes
).
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: cluster1
namespace: cluster-cluster1
spec:
...
nodePoolUpgradeStrategy:
concurrentNodePools: 0
...
Cómo realizar una actualización paralela
En esta sección, se describe cómo configurar un clúster y un grupo de nodo trabajador para actualizaciones paralelas.
Para realizar una actualización paralela de nodos y grupos de nodos trabajadores en un grupo de nodo trabajador, haz lo siguiente:
Agrega una sección
upgradeStrategy
a la especificación del grupo de nodos.Puedes aplicar este manifiesto por separado o como parte del archivo de configuración del clúster cuando realizas 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
es5
, lo que significa que 5 nodos se actualizan en paralelo. El campominimumAvailableNodes
se establece en10
, lo que significa que, al menos, 10 nodos deben permanecer disponibles para las cargas de trabajo durante la actualización.Agrega una sección
nodePoolUpgradeStrategy
a la especificación del clúster en el archivo de configuración del clúster.--- apiVersion: v1 kind: Namespace metadata: name: cluster-user001 --- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: user001 namespace: cluster-user001 spec: type: user profile: default anthosBareMetalVersion: 1.29.100-gke.251 ... nodePoolUpgradeStrategy: concurrentNodePools: 0 ...
En este ejemplo, el campo
concurrentNodePools
se establece en0
, lo que significa que todos los grupos de nodo trabajador se actualizan al mismo tiempo durante la actualización del clúster. La estrategia de actualización para los nodos de los grupos de nodos se define en las especificaciones de NodePool.Actualiza el clúster como se describe en la sección anterior Actualiza clústeres de administrador, independientes, híbridos o de usuario.
Valores predeterminados de 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 paralela y sus valores predeterminados:
Campo | Valor predeterminado | Significado |
---|---|---|
nodePoolUpgradeStrategy.concurrentNodePools (especificación del clúster) |
1 |
Actualiza los grupos de nodo trabajador de forma secuencial, uno tras otro. |
upgradeStrategy.parallelUpgrade.concurrentNodes (especificación de NodePool) |
1 |
Actualiza los nodos de forma secuencial, uno tras otro. |
upgradeStrategy.parallelUpgrade.minimumAvailableNodes (especificación de NodePool) |
El valor predeterminado de minimumAvailableNodes depende del valor de concurrentNodes .
|
La actualización se detiene una vez que se alcanza minimumAvailableNodes y solo continúa cuando la cantidad de nodos disponibles es mayor que minimumAvailableNodes . |
Inicia la actualización del clúster
Esta sección contiene instrucciones para actualizar clústeres.
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 el
bmctl
más reciente como se describe en Descargas de Google Distributed Cloud.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 campoanthosBareMetalVersion
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.29.100-gke.251
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 preliminares para validar su estado y el 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 actualizan de forma correcta, la operación de actualización del clúster realiza verificaciones de estado. En este último paso, se verifica que el clúster esté en buenas condiciones de funcionamiento. Si el clúster no pasa todas las verificaciones de estado, estas 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 del clúster, consulta Ciclo de vida y etapas de las actualizaciones del clúster.
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 del archivo de configuración de 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 clústeres 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 el clúster se mantenga en buen estado.
Detén y reanuda las actualizaciones
La función de pausa y reanudación de la actualización te permite pausar la actualización de un clúster antes de que finalice. Cuando se pausa la actualización de un clúster, no se activan nuevas actualizaciones de nodo trabajador hasta que se reanuda.
Esta función está disponible en (vista previa) para los clústeres con todos los nodos del plano de control en la versión secundaria 1.28 o en versiones posteriores. La función tiene disponibilidad general para los clústeres con todos los nodos del plano de control en la versión secundaria 1.29 o posterior.
Es posible que desees detener una actualización por los siguientes motivos:
Detectaste un problema con las cargas de trabajo del clúster durante la actualización y deseas pausarla para revisar el problema.
Tienes períodos de mantenimiento breves, por lo que deseas pausar la actualización entre períodos
Mientras la actualización de un clúster está en pausa, se admiten las siguientes operaciones:
- Agrega o quita nodos
- Agrega o quita grupos de nodos
- Aumenta el rango de la red de servicio
- Restablece un clúster a partir de una copia de seguridad
Cuando se agrega un nodo nuevo mientras se pausa una actualización, los trabajos de verificación de la máquina no se ejecutan en él hasta que se reanuda y completa la actualización.
Mientras la actualización del clúster está en pausa, no se admiten las siguientes operaciones:
No puedes iniciar la actualización de un clúster nuevo mientras está pausada una actualización de clúster activo.
Habilitar la opción para pausar y reanudar la actualización
Google Distributed Cloud 1.29
La función de pausa y reanudación de la actualización está habilitada de forma predeterminada para los clústeres con todos los nodos del plano de control en la versión secundaria 1.29 o superior.
Google Distributed Cloud 1.28
Mientras la función de pausa y reanudación de la actualización se encuentra en versión preliminar, puedes habilitarla con una anotación en el recurso del clúster.
Para habilitar la pausa y la reanudación de la actualización, sigue estos pasos:
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: ...
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.
Detén 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:
Agrega
nodePoolUpgradeStrategy.pause
al archivo de configuración del clúster y configúralo comotrue
:apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: baremetal-demo namespace: cluster-baremetal-demo ... spec: ... nodePoolUpgradeStrategy: pause: true ...
Si usaste
bmctl
para iniciar la actualización, necesitas una nueva ventana de terminal para realizar el siguiente paso.Para aplicar el cambio, actualiza tu clúster:
bmctl update CLUSTER_NAME
La operación de actualización está detenida. No se activan nuevas actualizaciones de nodos.
Si usaste
bmctl
para iniciar la actualización y tienes previsto hacer una pausa prolongada, presiona Control + C para salir debmctl
; de lo contrario, manténbmctl
en ejecución.La CLI de
bmctl
no detecta cambios en el estado de pausa de la actualización, por lo que no se cierra automáticamente. Sin embargo, cuando sales debmctl
, se detiene el registro del progreso de la actualización al archivo de registrocluster-upgrade-TIMESTAMP
en la carpeta del clúster en la estación de trabajo de administrador y en Cloud Logging. Por lo tanto, te recomendamos que mantengasbmctl
en ejecución durante pausas cortas. Si dejasbmctl
en ejecución durante un período prolongado mientras la actualización está en pausa, finalmente se agota el tiempo de espera.
Reanuda una actualización en pausa
Para reanudar la actualización de un clúster pausado, configura nodePoolUpgradeStrategy.pause
como false
en la especificación del clúster o quita nodePoolUpgradeStrategy.pause
de la especificación.
Para reanudar la actualización de un clúster que se detuvo, sigue estos pasos:
Establece
nodePoolUpgradeStrategy.pause
en el archivo de configuración del clúster y establécelo enfalse
:apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: baremetal-demo namespace: cluster-baremetal-demo ... spec: ... nodePoolUpgradeStrategy: pause: false ...
Como alternativa, puedes quitar el campo
pause
, ya que su valor predeterminado esfalse
.Para aplicar el cambio, actualiza tu clúster:
bmctl update CLUSTER_NAME
La operación de actualización se reanudará desde donde se detuvo.
Para verificar el estado de la actualización, primero obtén una lista de los recursos que tienen
anthosBareMetalVersion
en sustatus
:kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces
Reemplaza lo siguiente:
RESOURCE
: Es el nombre del recurso que deseas obtener. Los recursosCluster
,NodePool
yBareMetalMachine
contienen información de estadoanthosBareMetalVersion
.ADMIN_KUBECONFIG
: la ruta del archivo kubeconfig del clúster de administrador
En el siguiente ejemplo, se muestra el formato de la respuesta a los recursos personalizados
BareMetalMachine
. CadaBareMetalMachine
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
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 IP192.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 la versión 1.16.2 de Google Distributed Cloud.