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 una actualización del 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 versión 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 reconcilia status.anthosBareMetalVersion con spec.anthosBareMetalVersion para que ambos muestren la versión de destino.
Sesgo de la versión del clúster
La diferencia de versión del clúster es la diferencia entre las versiones de 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.30 y versiones posteriores
Las siguientes reglas se aplican a los clústeres de usuario administrados por un clúster de administrador o híbrido de la versión 1.30 o posterior:
Las versiones de los clústeres de usuario no pueden ser superiores a la versión del clúster de administración (administrador o híbrido).
Los clústeres de usuario pueden tener hasta dos versiones secundarias anteriores a la versión del clúster de administración. Por ejemplo, un clúster de administrador de la versión 1.30 puede administrar un clúster de usuario de la versión 1.28. Esta capacidad de administración de la versión n-2 es de disponibilidad general para administrar clústeres en la versión 1.30.
En el caso de un clúster de administración determinado en la versión 1.30 o posterior, los clústeres de usuario no necesitan tener la misma versión secundaria entre sí. Por ejemplo, un clúster de administrador de la versión 1.30 puede administrar clústeres de usuario de las versiones 1.30, 1.29 y 1.28.
La capacidad de administración de múltiples sesgos 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.28 a la versión 1.29 antes de poder actualizar tu clúster de administrador a la versión 1.30.
1.29
Las siguientes reglas se aplican a los clústeres de usuario administrados por un clúster de administrador o híbrido de la versión 1.29:
Las versiones de los clústeres de usuario no pueden ser superiores a la versión del clúster de administración (administrador o híbrido).
(1.29 Vista previa) Los clústeres de usuario pueden tener hasta dos versiones secundarias anteriores a la versión del clúster de administración. Por ejemplo, un clúster de administrador de la versión 1.29 puede administrar un clúster de usuario de la versión 1.16. Esta administración de la diferencia de versión n-2 está disponible como una función de versión preliminar para administrar clústeres en la versión 1.29.
(1.29 versión preliminar) En el caso de un clúster de administración determinado, los clústeres de usuario no necesitan tener la misma versión secundaria entre sí. Por ejemplo, un clúster de administrador de la versión 1.29 puede administrar clústeres de usuario de las versiones 1.29, 1.28 y 1.16. Esta administración de la diferencia de versión mixta 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 múltiples sesgos de la versión preliminar 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 antes de poder actualizar tu clúster de administrador a la versión 1.29.
1.28 y anteriores
Se aplican las siguientes reglas a los clústeres de usuario administrados por un clúster de administrador o híbrido de la versión 1.28 o anterior:
Las versiones de los clústeres de usuario no pueden ser superiores a la versión del clúster de administración (administrador o híbrido).
Los clústeres de usuario pueden tener hasta una versión secundaria anterior a la versión del clúster de administración. Por ejemplo, un clúster de administrador de la versión 1.28 no puede administrar un clúster de usuario en la versión 1.15.
En el caso de un clúster de administración determinado, todos los clústeres de usuario administrados deben tener la misma versión secundaria.
Para obtener información sobre las reglas de sesgo de versiones para grupos de nodos, consulta Reglas de control de versiones de grupos de nodos.
Reglas de 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.32.100-gke.106 de bmctl, solo puedes actualizar un clúster a la versión 1.32.100-gke.106.
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.32.X a la versión 1.32.Y siempre que Y sea mayor que X. Por ejemplo, puedes actualizar de 1.31.0 a 1.31.100 y actualizar de 1.31.100 a 1.31.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.31.600-gke.85 a 1.32.100-gke.106.
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 actual, bmctl emite un error. Por ejemplo, no puedes actualizar un clúster de la versión 1.30.0 a la versión 1.32.0 en un solo paso.
Como se describió anteriormente, un clúster de administrador puede administrar clústeres de usuario que se encuentran en la misma versión o en una anterior. La diferencia de versiones entre los clústeres de usuario y su clúster de administración (a veces denominada sesgo de versión) varía según la versión del clúster. Antes de actualizar un clúster de administración a una versión secundaria nueva, asegúrate de que las versiones de los clústeres de usuario administrados sigan cumpliendo con las reglas de retraso de versiones de clústeres para la versión de actualización de destino.
Reglas de versiones de grupos de nodos
Cuando actualizas grupos de nodos de forma selectiva, se aplican las siguientes reglas de versión:
1.30 y versiones posteriores
La versión del clúster debe ser mayor o igual que la versión del grupo de nodo trabajador.
El sesgo de versiones máximo entre un grupo de nodo trabajador y el clúster es de dos versiones secundarias.
Los grupos de nodos trabajadores pueden tener cualquier versión de parche de una versión secundaria compatible.
1.29
La versión del clúster debe ser mayor o igual que la versión del grupo de nodo trabajador.
(1.29 GA) El sesgo de versión máximo entre un grupo de nodo trabajador y el clúster es de dos versiones secundarias.
Los grupos de nodos trabajadores no pueden tener una versión que se haya lanzado cronológicamente después de la versión del clúster. La versión anterior no tiene los detalles integrales de la versión posterior, lo que es un requisito para la 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 optaste 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 versión preliminar) El sesgo de versiones máximo entre un grupo de nodo trabajador y el clúster es de dos versiones secundarias cuando se habilita la función de versión preliminar de sesgo de versiones n-2. Si no habilitas esta capacidad, el sesgo de versiones máximo entre un grupo de nodos trabajador y el clúster es de una versión menor.
Los grupos de nodos trabajadores no pueden tener una versión que se haya lanzado cronológicamente después de la versión del clúster. La versión anterior no tiene los detalles integrales de la versión posterior, lo que es un requisito para la 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 optaste 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 de versión máximo entre un grupo de nodo trabajador y el clúster es de una versión secundaria.
Los grupos de nodos trabajadores no pueden tener una versión que se haya lanzado cronológicamente después de la versión del clúster. La versión anterior no tiene los detalles integrales de la versión posterior, lo que es un requisito para la 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 optaste 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 de grupos de nodos compatibles que se permiten para una versión de clúster específica:
1.30 y versiones posteriores
En el caso de las versiones de clúster 1.30 y posteriores, las versiones de los grupos de nodos pueden ser hasta dos versiones secundarias anteriores. Todas las versiones de parche del grupo de nodos dentro de las versiones secundarias compatibles son compatibles.
1.29
| Versión del clúster (plano de control) | Versiones compatibles de grupos de nodo trabajador (las versiones agregadas se muestran en negrita) | |||
|---|---|---|---|---|
| 1.29.1200-gke.98 |
|
|
|
|
| 1.29.1100-gke.84 |
|
|
|
|
| 1.29.1000-gke.93 |
|
|
|
|
| 1.29.900-gke.180 |
|
|
|
|
| 1.29.800-gke.111 |
|
|
|
|
| 1.29.700-gke.113 |
|
|
|
|
| 1.29.600-gke.105 |
|
|
|
|
| 1.29.500-gke.162 |
|
|
|
|
| 1.29.400-gke.86 |
|
|
|
|
| 1.29.300-gke.185 |
|
|
|
|
| 1.29.200-gke.243 |
|
|
|
|
| 1.29.100-gke.251 |
|
|
|
|
| 1.29.0-gke.1449 |
|
|
|
|
1.28
| Versión del clúster (plano de control) | Versiones compatibles de grupos de nodo trabajador (las versiones agregadas se muestran en negrita) | |||
|---|---|---|---|---|
| 1.28.1400-gke.79 |
|
|
|
|
| 1.28.1300-gke.59 |
|
|
|
|
| 1.28.1200-gke.83 |
|
|
|
|
| 1.28.1100-gke.94 |
|
|
|
|
| 1.28.1000-gke.60 |
|
|
|
|
| 1.28.900-gke.112 |
|
|
|
|
| 1.28.800-gke.111 |
|
|
|
|
| 1.28.700-gke.150 |
|
|
|
|
| 1.28.600-gke.163 |
|
|
|
|
| 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
| Versión del clúster (plano de control) | Versiones compatibles de grupos de nodo trabajador (las versiones agregadas se muestran en negrita) | |||
|---|---|---|---|---|
| 1.16.12 |
|
|
|
|
| 1.16.11 |
|
|
|
|
| 1.16.10 |
|
|
|
|
| 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 |
|
|
||
Actualiza componentes
Los componentes se actualizan a nivel del nodo y del clúster. A nivel del clúster, se actualizan los siguientes componentes:
- Componentes del clúster para redes, observabilidad y almacenamiento.
- Para los clústeres independientes, híbridos y de administrador, los controladores de ciclo de vida.
- El tipo
gke-connect-agent.
Los nodos de un clúster se ejecutan con uno de los siguientes roles, y los diferentes componentes se actualizan según el rol del nodo:
| Rol del nodo | Función | Componentes que se actualizarán |
|---|---|---|
| Trabajador | Ejecuta cargas de trabajo del usuario | 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 Enterprise de Google Kubernetes Engine (GKE). | 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-operatorComplementos 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 HAProxy y Keepalived que envían tráfico a kube-apiserver y ejecutan dispositivos de MetalLB para reclamar direcciones IP virtuales. |
Pods estáticos del balanceador de cargas del plano de control (HAProxy, Keepalived)
Altavoces de MetalLB |
Expectativa de tiempo de inactividad
En la siguiente tabla, se detallan 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 alta disponibilidad. Si ejecutas un clúster independiente o no tienes un plano de control con HA, espera un tiempo de inactividad adicional. A menos que se indique lo contrario, 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 para el 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. | Es el inicio del proceso de actualización. |
Observabilidad pipeline-stackdriver y
metrics-server |
Se actualizó y se vació el operador. El tiempo de inactividad debe ser inferior a 5 minutos.
Los DaemonSets siguen funcionando sin tiempo de inactividad. |
Después de que finalicen las actualizaciones de los nodos del plano de control |
| Interfaz de red de contenedor (CNI) | No hay tiempo de inactividad para las rutas de redes existentes. DaemonSet implementado de a dos sin tiempo de inactividad. Se vació y actualizó el operador. El tiempo de inactividad es inferior a 5 minutos. |
Después de que finalicen las actualizaciones de los nodos del plano de control |
| MetalLB (solo para clústeres de usuario) | Se actualizó y se vació el operador. El tiempo de inactividad es inferior a 5 minutos.
No hay tiempo de inactividad para el servicio existente |
Después de que finalicen las actualizaciones de los nodos del plano de control |
| CoreDNS y escalador automático de DNS (solo para clústeres de usuario) | CoreDNS tiene varias réplicas con ajuste de escala automático. Por lo general, no hay tiempo de inactividad. | Después de que finalicen las actualizaciones de los nodos del plano de control |
| Aprovisionador local de volumen | No hay tiempo de inactividad para los volúmenes persistentes (PV) aprovisionados existentes.
Es posible que el operador tenga 5 minutos de inactividad. |
Después de que finalicen las actualizaciones de los nodos del plano de control |
| Istio / Ingress | Se vacía y actualiza el operador de Istio. Aproximadamente 5 minutos de inactividad. El tráfico de entrada configurado existente sigue funcionando. |
Después de que finalicen las actualizaciones de los nodos del plano de control |
| Otros operadores del sistema | 5 minutos de inactividad cuando se agota y se actualiza. | Después de que finalicen las actualizaciones de los nodos del plano de control |
| Cargas de trabajo de usuarios | Depende de la configuración, por ejemplo, si tiene alta disponibilidad. Revisa tus propias implementaciones de cargas de trabajo para comprender el impacto potencial. |
Es la fecha y hora en que se actualizaron los nodo trabajador. |
Detalles de la actualización del clúster de usuario
En esta sección, se detalla el orden de las actualizaciones de componentes y la información de estado para la actualización de un clúster de usuario. En la siguiente sección, se detallan las desviaciones de este flujo para las actualizaciones de clústeres de administrador, híbridos o independientes.
En el siguiente diagrama, se muestra el proceso de verificación previa para la actualización de un clúster de usuario:
En el diagrama anterior, se detallan los pasos que se realizan durante una actualización:
- El comando
bmctl upgrade clustercrea un recurso personalizadoPreflightCheck. - Esta verificación previa ejecuta verificaciones adicionales, como verificaciones de actualización del clúster, verificaciones de estado de la red y verificaciones de estado del nodo.
- 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 verificaciones previas se realizan 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:
En el diagrama anterior, los componentes se actualizan en el siguiente orden:
- La actualización comienza con la actualización del campo
spec.anthosBareMetalVersion. - Se actualizan los balanceadores de cargas del plano de control.
- Se actualizó el grupo de nodos del plano de control.
- En paralelo, se actualiza GKE Connect, se actualizan los complementos del clúster y se actualiza el grupo de nodos del balanceador de cargas.
- Después de que se actualiza correctamente el grupo de nodos del balanceador de cargas, se actualizan los grupos de nodos de trabajadores.
Cuando todos los componentes se hayan actualizado, se ejecutarán las verificaciones de estado del clúster.
Las verificaciones de estado continúan ejecutándose hasta que se aprueben todas.
Cuando todas las verificaciones de estado se aprueben, la actualización finalizará.
Cada componente tiene su propio campo de estado dentro del recurso personalizado Cluster. 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
|
Es la versión de lifecycles-controllers-manager aplicada al clúster. Este campo solo está disponible para clústeres de administrador, independientes o híbridos. |
| 2 | status.anthosBareMetalManifestsVersion |
Es la versión del clúster del ú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 está vacío si no se especifica un balanceador de cargas del plano de control independiente en Cluster.Spec. |
| 3 | status.anthosBareMetalVersions |
Es un mapa de versiones agregado de la versión a los números de nodo. |
| 4 | status.anthosBareMetalVersion |
Es el estado final de la versión actualizada. |
Detalles de la actualización de 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 (independientes, híbridos o de administrador) es una actualización local.
Es decir, cuando actualizas un clúster a la versión 1.15.0 o una 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 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 sigue disponible. Para usar un clúster de arranque cuando realices la actualización, 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 local predeterminado para los clústeres autoadministrados es similar al proceso de actualización de los clústeres 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 las verificaciones previas y de estado del clúster:
Al igual que con 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. Antes de que se actualicen los componentes, se ejecutan dos pasos adicionales, como se muestra en el siguiente diagrama: lifecycle-controller-manager se actualiza a la versión de destino y, luego, implementa la versión de destino de anthos-cluster-operator. Este anthos-cluster-operator realiza los pasos restantes del proceso de actualización:
Si la operación se realiza correctamente, anthos-cluster-operator reconcilia 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 de un clúster de usuario que se describió 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 administración del clúster al clúster de arranque se denomina pivote. 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 obsoletos. 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 supervisar y depurar el proceso de actualización. Se puede acceder al clúster de arranque a través de bmctl-workspace/.kindkubeconfig.
Para transferir la propiedad de administración del clúster después de que se complete la actualización, el clúster pivota los recursos del clúster de arranque al clúster actualizado. No hay pasos manuales que debas realizar para cambiar 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 correctamente.
Desviación del nodo
Las actualizaciones de los clústeres de Google Distributed Cloud pueden provocar interrupciones de las aplicaciones, ya que se vacían los nodos. Este proceso de vaciado hace que todos los Pods que se ejecutan en un nodo se apaguen y se reinicien en los nodos restantes del clúster.
Las implementaciones se pueden usar para tolerar este tipo de interrupciones. Un Deployment puede especificar que se deben ejecutar varias réplicas de una aplicación o un servicio. Una aplicación con varias réplicas debería experimentar pocas interrupciones o ninguna durante las actualizaciones.
PodDisruptionBudgets (PDB)
Cuando actualizas un clúster, Google Distributed Cloud usa el flujo del modo de mantenimiento para agotar los nodos.
A partir de la versión 1.29, los nodos se agotan con la API de Eviction, que respeta los PodDisruptionBudgets (PDB). Los PDB se pueden usar para garantizar que una cantidad definida de réplicas siempre se ejecuten 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 la expulsión está disponible como versión GA para la versión 1.29.
En las versiones 1.28 y anteriores, Google Distributed Cloud no respeta los PDB cuando los nodos se vacían durante una actualización. En cambio, el proceso de vaciado de nodos es el mejor esfuerzo. Es posible que algunos Pods se detengan en un estado Terminating y se nieguen a abandonar el nodo. La actualización continúa, incluso con Pods atascados, cuando el proceso de vaciado en un nodo tarda más de 20 minutos.
Para obtener más información, consulta Coloca los nodos en modo de mantenimiento.
¿Qué sigue?
- Revisa las prácticas recomendadas para las actualizaciones de Google Distributed Cloud
- Actualiza Google Distributed Cloud
- Soluciona problemas de actualización de clústeres