Ciclo de vida y etapas de las actualizaciones de clústeres

Cuando actualizas Google Distributed Cloud, el proceso de actualización implica varios pasos y componentes. Para supervisar el estado de la actualización o diagnosticar y solucionar problemas, es útil saber qué sucede cuando ejecutas el comando bmctl upgrade cluster. En este documento, se detallan los componentes y las etapas de la actualización de un clúster.

Descripción general

El proceso de actualización mueve tu clúster de Google Distributed Cloud de su versión actual a una superior.

Esta información de la versión se almacena en las siguientes ubicaciones como parte del recurso personalizado del clúster en el clúster de administrador:

  • status.anthosBareMetalVersion: Define la versión actual del clúster.

  • spec.anthosBareMetalVersion: Define la versión de destino y se establece cuando comienza a ejecutarse el proceso de actualización.

Una operación de actualización correcta concilia status.anthosBareMetalVersion con spec.anthosBareMetalVersion de modo que ambos muestren la versión de destino.

Sesgo de versiones del clúster

El sesgo de versiones del clúster es la diferencia de versiones entre un clúster de administración (híbrido o de administrador) y sus clústeres de usuario administrados. Cuando agregas o actualizas un clúster de usuario, se aplican las siguientes reglas de versión:

1.29

Las siguientes reglas se aplican a los clústeres de usuario administrados por un clúster de administrador o un clúster híbrido con la versión 1.29:

  • Las versiones del clúster de usuario no pueden ser posteriores a la versión del clúster de administración (de administrador o híbrida).

  • (1.29 Vista previa) Los clústeres de usuario pueden ser hasta dos versiones secundarias por debajo de la versión del clúster de administración. Por ejemplo, un clúster de administrador con la versión 1.29 puede administrar un clúster de usuario 1.16. Esta administración del sesgo de versiones n-2 está disponible como una función de Versión preliminar para administrar clústeres en la versión 1.29.

  • (1.29 Vista previa) Para un clúster de administración determinado, no es necesario que los clústeres de usuario tengan la misma versión secundaria que los demás. Por ejemplo, un clúster de administrador con la versión 1.29 puede administrar las versiones 1.29, 1.28 y 1.16 de los clústeres de usuario. Esta administración del sesgo de versiones mixtas está disponible como una función de Versión preliminar para administrar clústeres en la versión 1.29.

    La capacidad de administración de varios sesgos de la Vista previa te brinda más flexibilidad para planificar las actualizaciones de tu flota. Por ejemplo, no es necesario que actualices todos los clústeres de usuario de la versión 1.16 a la versión 1.28 para poder actualizar el clúster de administrador a la versión 1.29.

1.28 y anteriores

Las siguientes reglas se aplican a los clústeres de usuario administrados por una versión 1.28 o anterior de un clúster de administrador o híbrido:

  • Las versiones del clúster de usuario no pueden ser posteriores a la versión del clúster de administración (de administrador o híbrida).

  • Los clústeres de usuario pueden ser hasta una versión secundaria por debajo de la versión del clúster de administración. Por ejemplo, un clúster de administrador con la versión 1.28 no puede administrar un clúster de usuario en la versión 1.15.

  • Para un clúster de administración determinado, todos los clústeres de usuario administrados deben tener la misma versión secundaria.

Si quieres obtener información sobre las reglas del sesgo de versiones para los grupos de nodos, consulta Reglas de control de versiones de los grupos de nodos.

Reglas de la versión

Cuando descargas una versión nueva de bmctl y la instalas, puedes actualizar los clústeres de administrador, híbridos, independientes y de usuario creados o actualizados con una versión anterior de bmctl. Los clústeres no se pueden cambiar a una versión inferior.

Solo puedes actualizar un clúster a una versión que coincida con la versión de bmctl que usas. Es decir, si usas la versión 1.29.100-gke.251 de bmctl, solo puedes actualizar un clúster a la versión 1.29.100-gke.251.

Actualizaciones de versiones de parches

Para una versión secundaria determinada, puedes actualizar a cualquier versión de parche superior. Es decir, puedes actualizar un clúster de la versión 1.29.X a la versión 1.29.Y siempre que Y sea mayor que X. Por ejemplo, puedes actualizar de 1.28.0 a 1.28.100 y actualizar de 1.28.100 a 1.28.300. Te recomendamos actualizar a la versión de parche más reciente siempre que sea posible para garantizar que los clústeres tengan las correcciones de seguridad más recientes.

Actualizaciones de versiones secundarias

Puedes actualizar los clústeres de una versión secundaria a la siguiente, sin importar la versión del parche. Es decir, puedes actualizar de 1.N.X a 1.N+1.Y, donde 1.N.X es la versión de tu clúster y N+1 es la siguiente versión secundaria disponible. Las versiones del parche, X y Y, no afectan la lógica de actualización en este caso. Por ejemplo, puedes actualizar de 1.28.500-gke.120 a 1.29.100-gke.251.

No puedes omitir versiones secundarias cuando actualizas clústeres. Si intentas actualizar a una versión secundaria que es dos o más versiones secundarias posteriores a la versión del clúster, bmctl emite un error. Por ejemplo, no puedes actualizar un clúster de versión 1.16.0 a la versión 1.29.0.

Un clúster de administrador puede administrar clústeres de usuario que se encuentran en la misma versión secundaria o en una anterior. Los clústeres de usuario administrados no pueden tener una versión secundaria menor que el clúster de administrador, por lo que, antes de actualizar un clúster de administrador a una versión secundaria nueva, asegúrate de que todos los clústeres de usuario administrados usen la misma versión secundaria que el clúster de administrador.

Reglas de control de versiones de los grupos de nodos

Cuando actualizas grupos de nodos de forma selectiva, se aplican las siguientes reglas de versión:

1.29

  • La versión del clúster debe ser mayor o igual que la versión del grupo de nodo trabajador.

  • El sesgo máximo de versiones entre un grupo de nodo trabajador y el clúster (1.29 GA) es de dos versiones secundarias.

  • Los grupos de nodos trabajadores no pueden estar en una versión que se lanzó cronológicamente después que la versión del clúster. La versión anterior no tiene los detalles completos de la versión posterior, lo que es un requisito de compatibilidad.

    Por ejemplo, la versión 1.16.6 se lanzó después de la versión 1.28.100-gke.146, por lo que no puedes actualizar tu clúster de la versión 1.16.6 a la versión 1.28.100-gke.146 y dejar un grupo de nodo trabajador en la versión 1.16.6. Del mismo modo, si actualizas tu clúster a la versión 1.28.100-gke.146, pero optas por dejar un grupo de nodo trabajador en la versión 1.16.5, no puedes actualizar el grupo de nodo trabajador a la versión 1.16.6 mientras el clúster está en la versión 1.28.100-gke.146.

1.28

  • La versión del clúster debe ser mayor o igual que la versión del grupo de nodo trabajador.

  • (1.28 Vista previa) El sesgo máximo de versiones entre un grupo de nodo trabajador y el clúster es de dos versiones secundarias cuando se habilita la función Vista previa del sesgo de versiones n-2. Si no habilitas esta capacidad, el sesgo máximo de versiones entre un grupo de nodos trabajadores y el clúster es de una versión secundaria.

  • Los grupos de nodos trabajadores no pueden estar en una versión que se lanzó cronológicamente después que la versión del clúster. La versión anterior no tiene los detalles completos de la versión posterior, lo que es un requisito de compatibilidad.

    Por ejemplo, la versión 1.16.6 se lanzó después de la versión 1.28.100-gke.146, por lo que no puedes actualizar tu clúster de la versión 1.16.6 a la versión 1.28.100-gke.146 y dejar un grupo de nodo trabajador en la versión 1.16.6. Del mismo modo, si actualizas tu clúster a la versión 1.28.100-gke.146, pero optas por dejar un grupo de nodo trabajador en la versión 1.16.5, no puedes actualizar el grupo de nodo trabajador a la versión 1.16.6 mientras el clúster está en la versión 1.28.100-gke.146.

1.16

  • La versión del clúster debe ser mayor o igual que la versión del grupo de nodo trabajador.

  • El sesgo máximo de versiones entre un grupo de nodo trabajador y el clúster es de una versión secundaria.

  • Los grupos de nodos trabajadores no pueden estar en una versión que se lanzó cronológicamente después que la versión del clúster. La versión anterior no tiene los detalles completos de la versión posterior, lo que es un requisito de compatibilidad.

    Por ejemplo, la versión 1.16.6 se lanzó después de la versión 1.28.100-gke.146, por lo que no puedes actualizar tu clúster de la versión 1.16.6 a la versión 1.28.100-gke.146 y dejar un grupo de nodo trabajador en la versión 1.16.6. Del mismo modo, si actualizas tu clúster a la versión 1.28.100-gke.146, pero optas por dejar un grupo de nodo trabajador en la versión 1.16.5, no puedes actualizar el grupo de nodo trabajador a la versión 1.16.6 mientras el clúster está en la versión 1.28.100-gke.146.

En la siguiente tabla, se enumeran las versiones del grupo de nodos compatibles que se permiten para una versión específica del clúster:

1.29

Versión del clúster (plano de control) Versiones compatibles de grupos de nodo trabajador
1.29.100-gke.251
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.0-gke.1449
  • 1.29.0-gke.1449
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0

1.28

Versión del clúster (plano de control) Versiones compatibles de grupos de nodo trabajador
1.28.500-gke.120
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.400-gke.77
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.300-gke.131
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.200-gke.118
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.100-gke.146
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.0-gke.425
  • 1.28.0-gke.425
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

     

     

     

1.16

Versión del clúster (plano de control) Versiones compatibles de grupos de nodo trabajador
1.16.9
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.8
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.7
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.6
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.5
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.4
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.3
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.2
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.1
  • 1.16.1
  • 1.16.0
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.0
  • 1.16.0
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

Actualizar componentes

Los componentes se actualizan a nivel del nodo y del clúster. En el nivel del clúster, se actualizan los siguientes componentes:

  • Componentes de clústeres para las herramientas de redes, la observabilidad y el almacenamiento.
  • Para los clústeres independientes, híbridos y de administrador, los controladores del ciclo de vida.
  • El tipo gke-connect-agent.

Los nodos de un clúster se ejecutan como una de las siguientes funciones, con diferentes componentes actualizados según la función del nodo:

Función del nodo Función Componentes que se actualizarán
Trabajador Ejecuta cargas de trabajo de usuarios Kubelet, entorno de ejecución del contenedor (Docker o containerd)
Plano de control Ejecuta el plano de control de Kubernetes, los controladores del ciclo de vida del clúster y los complementos de la plataforma de la edición Google Kubernetes Engine (GKE) Enterprise Pods estáticos del plano de control de Kubernetes (kubeapi-server, kube-scheduler, kube-controller-manager, etcd)

Controladores de ciclo de vida como lifecycle-controllers-manager y anthos-cluster-operator

Complementos de la plataforma de la edición Google Kubernetes Engine (GKE) Enterprise, como stackdriver-log-aggregator y gke-connect-agent
Balanceador de cargas del plano de control Ejecuta Perfetto y Keepalived que entregan el tráfico a kube-apiserver y ejecuta los altavoces de MetalLB para reclamar direcciones IP virtuales. Pods estáticos del balanceador de cargas del plano de control (Perfetto, Keepalived)

Bocinas de MetalLB

Expectativa de tiempo de descanso

En la siguiente tabla, se detalla el tiempo de inactividad esperado y el impacto potencial cuando actualizas clústeres. En esta tabla, se supone que tienes varios nodos de clúster y un plano de control de HA. Si ejecutas un clúster independiente o no tienes un plano de control de alta disponibilidad, se prevé un tiempo de inactividad adicional. A menos que se indique, este tiempo de inactividad se aplica a las actualizaciones de clústeres de administrador y de usuario:

Componentes Expectativas de tiempo de inactividad Cuándo se produce el tiempo de descanso
Servidor de la API del plano de control de Kubernetes (kube-apiserver), etcd y programador No hay tiempo de inactividad N/A
Controladores de ciclo de vida y trabajo de ansible-runner (solo clúster de administrador) No hay tiempo de inactividad N/A
Plano de control de Kubernetes loadbalancer-haproxy y keepalived Tiempo de inactividad transitorio (menos de 1 a 2 minutos) cuando el balanceador de cargas redirecciona el tráfico. Inicio del proceso de actualización.
Observabilidad pipeline-stackdriver y metrics-server Se desvió y actualizó el operador. El tiempo de inactividad debe ser inferior a 5 minutos.

Los DaemonSets siguen funcionando sin tiempo de inactividad.		 Después de que los nodos del plano de control terminen de actualizarse.
Interfaz de red de contenedor (CNI) No hay tiempo de inactividad para las rutas de red existentes.

El DaemonSet se implementa de dos en dos sin tiempo de inactividad.

El operador se desvía y se actualiza. Tiempo de inactividad inferior a 5 minutos.		 Después de que los nodos del plano de control terminen de actualizarse.
MetalLB (solo para clústeres de usuario) Se desvió y actualizó el operador. El tiempo de inactividad es menor a 5 minutos.

Sin tiempo de inactividad para el servicio existente		 Después de que los nodos del plano de control terminen de actualizarse.
CoreDNS y escalador automático de DNS (solo clúster de usuario) CoreDNS tiene varias réplicas con escalador automático. Por lo general, no hay tiempo de inactividad. Después de que los nodos del plano de control terminen de actualizarse.
Aprovisionador de volumen local No hay tiempo de inactividad para los volúmenes persistentes (PV) aprovisionados existentes.

El operador puede tener un tiempo de inactividad de 5 minutos.		 Después de que los nodos del plano de control terminen de actualizarse.
Istio / entrada El operador de Istio se desvía y se actualiza. Alrededor de 5 minutos de tiempo de inactividad

La entrada configurada existente sigue funcionando.		 Después de que los nodos del plano de control terminen de actualizarse.
Otros operadores de sistemas 5 minutos de inactividad cuando se desvía y actualiza. Después de que los nodos del plano de control terminen de actualizarse.
Cargas de trabajo del usuario Depende de la configuración; por ejemplo, si cuenta con alta disponibilidad.

Revisa tus propias implementaciones de cargas de trabajo para comprender el impacto potencial.		 Cuando se actualizan los nodo trabajador.

Detalles de actualización del clúster de usuario

En esta sección, se detalla el orden de las actualizaciones de los componentes y la información de estado de una actualización del clúster de usuario. En la siguiente sección, se detallan las desviaciones de este flujo para las actualizaciones de clústeres independientes, híbridos o de administrador.

En el siguiente diagrama, se muestra el proceso de comprobación previa de una actualización de clúster de usuario:

La comprobación previa del clúster ejecuta verificaciones de estado adicionales antes de que comience el proceso de actualización.

En el diagrama anterior, se detallan los pasos que ocurren durante una actualización:

  • El comando bmctl upgrade cluster crea un recurso personalizado PreflightCheck.
  • Esta comprobación previa ejecuta verificaciones adicionales, como verificaciones de actualización del clúster, verificaciones de estado de la red y verificaciones de estado de nodos.
  • Los resultados de estas verificaciones adicionales se combinan para informar sobre la capacidad del clúster de actualizarse correctamente a la versión de destino.

Si las comprobaciones preliminares se ejecutan correctamente y no hay problemas de bloqueo, los componentes del clúster se actualizan en un orden específico, como se muestra en el siguiente diagrama:

Se actualizaron los balanceadores de cargas del plano de control y el grupo de nodos del plano de control. Luego, se actualizaron GKE Connect, los complementos del clúster y el grupo de nodos del balanceador de cargas y los grupos de nodo trabajador.

En el diagrama anterior, los componentes se actualizan en el siguiente orden:

  1. La actualización comienza con la actualización del campo spec.anthosBareMetalVersion.
  2. Se actualizarán los balanceadores de cargas del plano de control.
  3. Se actualizará el grupo de nodos del plano de control.
  4. Al mismo tiempo, se actualiza GKE Connect, se actualizan los complementos del clúster y el grupo de nodos del balanceador de cargas.
    1. Después de que el grupo de nodos del balanceador de cargas se actualiza de forma correcta, se actualizan los grupos de nodos trabajadores.

  5. Cuando se actualicen todos los componentes, se ejecutan las verificaciones de estado del clúster.

    Las verificaciones de estado continúan ejecutándose hasta que se aprueban todas.

  6. Cuando se aprueban todas las verificaciones de estado, la actualización finaliza.

Cada componente tiene su propio campo de estado dentro del recurso personalizado del clúster. Puedes verificar el estado en estos campos para comprender el progreso de la actualización:

Secuencia Nombre del campo Significado
1 status.controlPlaneNodepoolStatus El estado se copia del estado del grupo de nodos del plano de control. El campo incluye las versiones de los nodos de los grupos de nodos del plano de control
2 status.anthosBareMetalLifecycleControllersManifestsVersion Se aplicó la versión de lifecycles-controllers-manager al clúster. Este campo solo está disponible para clústeres de administrador, independientes o híbridos.
2 status.anthosBareMetalManifestsVersion Versión del clúster desde el último manifiesto aplicado.
2 status.controlPlaneLoadBalancerNodepoolStatus El estado se copia del estado del grupo de nodos del balanceador de cargas del plano de control. Este campo estará vacío si no se especifica un balanceador de cargas del plano de control independiente en Cluster.Spec.
3 status.anthosBareMetalVersions Un mapa de versiones agregado de la versión a los números de los nodos.
4 status.anthosBareMetalVersion Estado final de la versión actualizada.

Detalles de actualización de los clústeres independientes, híbridos y de administrador

A partir de la versión 1.15.0 de bmctl, el comportamiento de actualización predeterminado para los clústeres autoadministrados (de administrador, híbridos o independientes) es una actualización local. Es decir, cuando actualizas un clúster a la versión 1.15.0 o a una versión posterior, la actualización usa 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.

Aunque no se recomienda usar un clúster de arranque para la actualización, la opción aún está disponible. Para usar un clúster de arranque cuando actualizas, ejecuta el comando bmctl upgrade con la marca --use-bootstrap=true. Las etapas de la actualización son diferentes según el método que uses.

Actualizaciones in situ

El proceso de actualización in situ predeterminado para los clústeres autoadministrados es similar al proceso de actualización del clúster de usuario. Sin embargo, cuando usas el proceso de actualización in situ, se implementa una versión nueva de preflightcheck-operator antes de que se ejecuten la verificación previa del clúster y las verificaciones de estado:

Se implementa una versión nueva del operador de verificación previa antes de que la comprobación previa del clúster ejecute verificaciones de estado adicionales en el clúster.

Al igual que la actualización del clúster de usuario, el proceso de actualización comienza con la actualización del campo Cluster.spec.anthosBareMetalVersion a la versión de destino. Se ejecutan dos pasos adicionales antes de que se actualicen los componentes, como se muestra en el siguiente diagrama: lifecycle-controller-manager se actualiza a la versión de destino y, luego, implementa la versión objetivo de anthos-cluster-operator. Este anthos-cluster-operator realiza los pasos restantes del proceso de actualización:

Lifecycle-controller-manager y anthos-cluster-operator se implementan antes de que el resto del clúster se actualice en el mismo orden que los componentes del clúster de usuario.

Si se ejecuta de forma correcta, anthos-cluster-operator concilia la versión objetivo de spec.anthosBareMetalVersion a status.anthosBareMetalVersion.

Actualiza con un clúster de arranque

El proceso para actualizar un clúster de administrador, híbrido o independiente es similar al clúster de usuario que se analizó en la sección anterior.

La diferencia principal es que el comando bmctl upgrade cluster inicia un proceso para crear un clúster de arranque. Este clúster de arranque es un clúster temporal que administra el clúster híbrido, de administrador o independiente durante una actualización.

El proceso para transferir la propiedad de la administración del clúster al clúster de arranque se denomina pivot. El resto de la actualización sigue el mismo proceso que la actualización del clúster de usuario.

Durante el proceso de actualización, los recursos del clúster de destino permanecen inactivos. El progreso de la actualización solo se refleja en los recursos del clúster de arranque.

Si es necesario, puedes acceder al clúster de arranque para ayudar a supervisar y depurar el proceso de actualización. Se puede acceder al clúster de arranque a través de bmctl-workspace/.kindkubeconfig.

Para volver a transferir la propiedad de administración del clúster después de que se complete la actualización, el clúster dinamiza los recursos del clúster de arranque al clúster actualizado. No hay pasos manuales que realices para reorientar el clúster durante el proceso de actualización. El clúster de arranque se borra después de que la actualización del clúster se realiza de forma correcta.

Vaciado de nodos

Las actualizaciones de los clústeres de Google Distributed Cloud pueden provocar la interrupción de la aplicación a medida que se desvían los nodos. Este proceso de desvío hace que todos los Pods que se ejecutan en un nodo se cierren y reinicien en los nodos restantes del clúster.

Los objetos Deployment pueden utilizarse para tolerar estas interrupciones. Un Deployment puede especificar varias réplicas de la ejecución de una aplicación o servicio. Una aplicación con varias réplicas debería experimentar poca o ninguna interrupción durante las actualizaciones.

PodDisruptionBudgets (PDB)

Cuando actualizas un clúster, Google Distributed Cloud usa el flujo del modo de mantenimiento para vaciar los nodos.

A partir de la versión 1.29, los nodos se vacían con la API de Expulsación, que respeta PodDisruptionBudgets (PDB). Los PDB se pueden usar para garantizar que una cantidad definida de réplicas siempre se ejecute en el clúster en condiciones normales de ejecución. Los PDB te permiten limitar la interrupción de una carga de trabajo cuando sus Pods deben reprogramarse. El vaciado de nodos basado en expulsiones está disponible como DG en la versión 1.29.

En las versiones 1.28 y anteriores, Google Distributed Cloud no respeta los PDB cuando los nodos se agotan durante una actualización. Por el contrario, el proceso de vaciado de nodos es el mejor esfuerzo. Es posible que algunos Pods queden atascados en un estado Terminating y se nieguen a desocupar el nodo. La actualización continúa, incluso con Pods atascados, cuando el proceso de desvío en un nodo tarda más de 20 minutos.

Para obtener más información, consulta Coloca nodos en modo de mantenimiento.

¿Qué sigue?