Cuando actualizas Google Distributed Cloud, el proceso de actualización consta de varios pasos y componentes. Para monitorizar el estado de la actualización o diagnosticar y solucionar problemas, es útil saber qué ocurre cuando ejecutas el comando bmctl upgrade
cluster. En este documento se detallan los componentes y las fases de una actualización de clúster.
Información general
El proceso de actualización cambia la versión de tu clúster de Google Distributed Cloud a una versión superior.
Esta información de la versión se almacena en las siguientes ubicaciones como parte del recurso personalizado de 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 configura cuando se inicia el proceso de actualización.
Si la operación de actualización se realiza correctamente, se reconcilia
status.anthosBareMetalVersion con
spec.anthosBareMetalVersion para que ambos muestren
la versión de destino.
Diferencia entre versiones de clústeres
La diferencia de versiones del clúster es la diferencia entre las versiones de un clúster de gestión (híbrido o de administrador) y sus clústeres de usuario gestionados. Cuando añades o actualizas un clúster de usuarios, se aplican las siguientes reglas de versiones:
1.30 y versiones posteriores
Se aplican las siguientes reglas a los clústeres de usuario gestionados por un clúster de administrador o un clúster híbrido con la versión 1.30 o posterior:
Las versiones de los clústeres de usuarios no pueden ser superiores a la versión del clúster de gestión (administrador o híbrido).
Los clústeres de usuarios pueden tener hasta dos versiones secundarias menos que la versión del clúster de gestión. Por ejemplo, un clúster de administradores con la versión 1.30 puede gestionar un clúster de usuarios con la versión 1.28. Esta función de gestión de la diferencia de versiones n-2 está disponible de forma general para gestionar clústeres con la versión 1.30.
En un clúster de gestión determinado con la versión 1.30 o posterior, los clústeres de usuarios no tienen que tener la misma versión secundaria. Por ejemplo, un clúster de administradores de la versión 1.30 puede gestionar clústeres de usuarios de las versiones 1.30, 1.29 y 1.28.
La función de gestión de múltiples SKUs te ofrece más flexibilidad para planificar las actualizaciones de tu flota. Por ejemplo, no es necesario que actualices todos los clústeres de usuarios de la versión 1.28 a la 1.29 para poder actualizar el clúster de administradores a la versión 1.30.
1,29
Se aplican las siguientes reglas a los clústeres de usuario gestionados por un clúster de administrador o un clúster híbrido de la versión 1.29:
Las versiones de los clústeres de usuarios no pueden ser superiores a la versión del clúster de gestión (administrador o híbrido).
(1.29 Vista previa) Los clústeres de usuarios pueden tener hasta dos versiones secundarias anteriores a la versión del clúster de gestión. Por ejemplo, un clúster de administradores de la versión 1.29 puede gestionar un clúster de usuarios de la versión 1.16. Esta gestión de la diferencia de versiones n-2 está disponible como función de vista previa para gestionar clústeres con la versión 1.29.
(1.29 Vista previa) En un clúster de gestión determinado, los clústeres de usuarios no tienen por qué tener la misma versión secundaria. Por ejemplo, un clúster de administrador de la versión 1.29 puede gestionar clústeres de usuario de las versiones 1.29, 1.28 y 1.16. Esta gestión de la diferencia de versiones mixtas está disponible como función de vista previa para gestionar clústeres en la versión 1.29.
La función de gestión de múltiples versiones de Vista previa te ofrece más flexibilidad para planificar las actualizaciones de tu flota. Por ejemplo, no es necesario que actualices todos los clústeres de usuarios de la versión 1.16 a la 1.28 para poder actualizar tu clúster de administradores a la versión 1.29.
1.28 y versiones anteriores
Se aplican las siguientes reglas a los clústeres de usuario gestionados por un clúster de administrador o un clúster híbrido de la versión 1.28 o anterior:
Las versiones de los clústeres de usuarios no pueden ser superiores a la versión del clúster de gestión (administrador o híbrido).
Los clústeres de usuarios pueden tener una versión secundaria inferior a la versión del clúster de gestión. Por ejemplo, un clúster de administradores con la versión 1.28 no puede gestionar un clúster de usuarios con la versión 1.15.
En un clúster de gestión determinado, todos los clústeres de usuarios gestionados deben tener la misma versión secundaria.
Para obtener información sobre las reglas de diferencia de versiones de los grupos de nodos, consulta Reglas de versiones de grupos de nodos.
Reglas de versiones
Cuando descargues e instales una nueva versión de bmctl, podrás actualizar los clústeres de administrador, híbridos, independientes y de usuario que hayas creado o actualizado con una versión anterior de bmctl. Los clústeres no se pueden cambiar a una versión anterior.
Solo puedes actualizar un clúster a una versión que coincida con la versión de bmctl que estés usando. Es decir, si usas la versión 1.33.0-gke.799 de bmctl, solo puedes actualizar un clúster a la versión 1.33.0-gke.799.
Actualizaciones de versiones de parches
En 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.33.X a la versión 1.33.Y siempre que Y sea mayor que X. Por ejemplo, puedes cambiar de 1.32.0 a 1.32.100 y de 1.32.100 a 1.32.300. Te recomendamos que actualices a la versión más reciente del parche siempre que sea posible para asegurarte de que tus clústeres tienen las correcciones de seguridad más recientes.
Actualizaciones de versiones secundarias
Puedes actualizar los clústeres de una versión secundaria a la siguiente, independientemente de la versión de 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 menor disponible. Las versiones de parche X y Y no afectan a la lógica de actualización en este caso. Por ejemplo, puedes cambiar de 1.32.400-gke.68 a 1.33.0-gke.799.
No puedes saltarte versiones secundarias al actualizar clústeres. Si intentas actualizar a una versión secundaria que sea dos o más versiones secundarias superior a la versión actual del clúster, bmctl emitirá un error. Por ejemplo, no puedes actualizar un clúster de la versión 1.31.0 a la versión 1.33.0 en un solo paso.
Como se ha descrito anteriormente, un clúster de administrador puede gestionar clústeres de usuarios que tengan la misma versión o una versión anterior. La diferencia de versiones entre los clústeres de usuarios y su clúster de gestión (a veces denominada "desfase de versiones") varía en función de la versión del clúster. Antes de actualizar un clúster de gestión a una nueva versión secundaria, asegúrate de que las versiones de los clústeres de usuarios gestionados sigan cumpliendo las reglas de diferencia de versiones de clústeres de la versión de actualización de destino.
Reglas de control 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 igual o posterior a la versión del grupo de nodos de trabajo.
La diferencia máxima entre la versión de un grupo de nodos de trabajo y la del clúster es de dos versiones secundarias.
Los grupos de nodos de trabajo pueden tener cualquier versión de parche de una versión secundaria compatible.
1,29
La versión del clúster debe ser igual o posterior a la versión del grupo de nodos de trabajo.
(1.29 GA) La diferencia máxima entre la versión de un grupo de nodos de trabajo y la del clúster es de dos versiones secundarias.
Los grupos de nodos de trabajador 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 completos 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 1.28.100-gke.146 y dejar un grupo de nodos de trabajo 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 decides dejar un grupo de nodos de trabajo en la versión 1.16.5, no podrás actualizar el grupo de nodos de trabajo 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 igual o posterior a la versión del grupo de nodos de trabajo.
(1.28 Vista previa) La diferencia máxima entre la versión de un grupo de nodos de trabajo y la del clúster es de dos versiones secundarias cuando la función de n-2 Vista previa está habilitada. Si no habilitas esta función, la diferencia máxima entre la versión de un grupo de nodos de trabajo y la del clúster será de una versión secundaria.
Los grupos de nodos de trabajador 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 completos 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 1.28.100-gke.146 y dejar un grupo de nodos de trabajo 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 decides dejar un grupo de nodos de trabajo en la versión 1.16.5, no podrás actualizar el grupo de nodos de trabajo 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 igual o posterior a la versión del grupo de nodos de trabajo.
La diferencia máxima entre la versión de un grupo de nodos de trabajo y la del clúster es de una versión secundaria.
Los grupos de nodos de trabajador 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 completos 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 1.28.100-gke.146 y dejar un grupo de nodos de trabajo 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 decides dejar un grupo de nodos de trabajo en la versión 1.16.5, no podrás actualizar el grupo de nodos de trabajo 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 indican las versiones de grupos de nodos admitidas que se permiten para una versión de clúster específica:
1.30 y versiones posteriores
En 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 de los grupos de nodos de las versiones secundarias compatibles son compatibles.
1,29
| Versión del clúster (plano de control) | Versiones de grupos de nodos de trabajo admitidas (las versiones añadidas 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 de grupos de nodos de trabajo admitidas (las versiones añadidas 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 de grupos de nodos de trabajo admitidas (las versiones añadidas 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 |
|
|
||
Actualizar componentes
Los componentes se actualizan tanto a nivel de nodo como de clúster. A nivel de clúster, se actualizan los siguientes componentes:
- Componentes de clúster para redes, observabilidad y almacenamiento.
- En el caso de los clústeres de administrador, híbridos y autónomos, los controladores del ciclo de vida.
- El
gke-connect-agent.
Los nodos de un clúster se ejecutan con uno de los siguientes roles, y los componentes se actualizan en función del rol del nodo:
| Rol del nodo | Función | Componentes que se van a actualizar |
|---|---|---|
| Trabajador | Ejecuta cargas de trabajo de usuarios | Kubelet, tiempo 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 Google Cloud complementos de la plataforma | 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 Google Cloud , como stackdriver-log-aggregator y
gke-connect-agent |
| Balanceador de carga del plano de control | Ejecuta HAProxy y Keepalived, que sirven tráfico a
kube-apiserver, y ejecuta altavoces de MetalLB para reclamar direcciones IP virtuales |
Pods estáticos del balanceador de carga del plano de control (HAProxy, Keepalived)
Speakers de MetalLB |
Tiempo de inactividad previsto
En la siguiente tabla se detalla el tiempo de inactividad previsto y el posible impacto al actualizar clústeres. En esta tabla se presupone 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 de alta disponibilidad, es posible que haya más tiempo de inactividad. A menos que se indique lo contrario, este tiempo de inactividad se aplica a las actualizaciones de clústeres de administradores y de usuarios:
| Componentes | Expectativas sobre el tiempo de inactividad | Cuándo se produce el tiempo de inactividad |
|---|---|---|
Servidor de la API del plano de control de Kubernetes (kube-apiserver),
etcd y programador |
Sin periodos inactivos | N/A |
Controladores de ciclo de vida y ansible-runner (solo en clústeres de administrador) |
Sin periodos inactivos | N/A |
Plano de control de Kubernetes loadbalancer-haproxy y
keepalived |
Tiempo de inactividad transitorio (de 1 a 2 minutos) cuando el balanceador de carga redirige el tráfico. | Inicio del proceso de actualización. |
Observabilidad pipeline-stackdriver y
metrics-server |
El operador se ha agotado y se ha actualizado. El tiempo de inactividad debe ser inferior a 5 minutos.
Los DaemonSets seguirán funcionando sin tiempo de inactividad. |
Después de que los nodos del plano de control terminen de actualizarse. |
| Interfaz de red de contenedores (CNI) | No hay tiempo de inactividad para las rutas de redes actuales. DaemonSet desplegado de dos en dos sin tiempo de inactividad. El operador se ha vaciado y actualizado. El tiempo de inactividad es inferior a 5 minutos. |
Después de que los nodos del plano de control terminen de actualizarse. |
| MetalLB (solo para clústeres de usuarios) | El operador se ha agotado y se ha actualizado. El tiempo de inactividad es inferior a 5 minutos.
El servicio actual experimenta un tiempo de inactividad transitorio (menos de 1 minuto) cuando el balanceador de carga redirige el tráfico. |
Después de que los nodos del plano de control terminen de actualizarse. |
| CoreDNS y el escalador automático de DNS (solo en clústeres de usuarios) | CoreDNS tiene varias réplicas con autoescalador. Normalmente, no hay tiempo de inactividad. | Después de que los nodos del plano de control terminen de actualizarse. |
| Proveedor de volúmenes locales | No hay tiempo de inactividad para los volúmenes persistentes aprovisionados.
El operador puede tener 5 minutos de inactividad. |
Después de que los nodos del plano de control terminen de actualizarse. |
| Istio/Ingress | El operador de Istio se ha purgado y actualizado. Unos 5 minutos de
tiempo de inactividad. Los recursos de entrada configurados seguirán funcionando. |
Después de que los nodos del plano de control terminen de actualizarse. |
| Otros operadores del sistema | 5 minutos de inactividad cuando se agota y se actualiza. | Después de que los nodos del plano de control terminen de actualizarse. |
| Cargas de trabajo de los usuarios | Depende de la configuración, por ejemplo, si es de alta disponibilidad. Revisa tus propias implementaciones de cargas de trabajo para conocer el posible impacto. |
Cuando se actualizan los nodos de trabajo. |
Detalles de la actualización de clústeres de usuarios
En esta sección se detalla el orden de las actualizaciones de los componentes y la información de estado de una actualización de un clúster de usuarios. 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 comprobación previa para actualizar un clúster de usuarios:
En el diagrama anterior se detallan los pasos que se siguen durante una actualización:
- El comando
bmctl upgrade clustercrea un recurso personalizadoPreflightCheck. - Esta comprobación previa ejecuta comprobaciones adicionales, como comprobaciones de actualización del clúster, comprobaciones del estado de la red y comprobaciones del estado de los nodos.
- Los resultados de estas comprobaciones adicionales se combinan para informar sobre la capacidad del clúster de actualizarse correctamente a la versión de destino.
Si las comprobaciones previas se realizan correctamente y no hay problemas que impidan la actualización, los componentes del clúster se actualizarán en un orden específico, tal 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 carga del plano de control.
- Se actualiza el grupo de nodos del plano de control.
- Paralelamente, se actualiza GKE Connect, se actualizan los complementos del clúster y se actualiza el grupo de nodos del balanceador de carga.
- Una vez que se haya actualizado correctamente el grupo de nodos del balanceador de carga, se actualizarán los grupos de nodos de trabajo.
Cuando se hayan actualizado todos los componentes, se ejecutarán las comprobaciones del estado del clúster.
Las comprobaciones de estado se siguen ejecutando hasta que se superan todas.
Cuando se superen todas las comprobaciones de estado, la actualización habrá finalizado.
Cada componente tiene su propio campo de estado dentro del recurso personalizado Cluster. Puedes consultar el estado en estos campos para saber cómo va 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
|
Versión de lifecycles-controllers-manager aplicada al clúster. Este campo solo está disponible para clústeres independientes, híbridos o de administrador. |
| 2 | status.anthosBareMetalManifestsVersion |
Versión del clúster del último manifiesto aplicado. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
El estado se copia del grupo de nodos del balanceador de carga del plano de control.
status. Este campo está vacío si no se especifica ningún balanceador de carga 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 nodo. |
| 4 | status.anthosBareMetalVersion |
Estado final de la versión actualizada. |
Detalles de la actualización de clústeres de administrador, híbridos y independientes
A partir de la versión 1.15.0 de bmctl, el comportamiento de actualización predeterminado de los clústeres autogestionados (administrador, híbrido o independiente) es una actualización in situ.
Es decir, cuando actualizas un clúster a la versión 1.15.0 o a una posterior, la actualización usa controladores de ciclo de vida en lugar de un clúster de arranque para gestionar 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 fiables y escalables.
Aunque no se recomienda usar un clúster de arranque para actualizar, la opción sigue estando disponible. Para usar un clúster de arranque al actualizar, ejecuta el comando bmctl upgrade con la marca --use-bootstrap=true.
Las fases de la actualización son diferentes en función del método que utilices.
Actualizaciones in situ
El proceso de actualización in situ predeterminado para los clústeres autogestionados es similar al proceso de actualización de clústeres de usuario. Sin embargo, cuando usas el proceso de actualización in situ, se implementa una nueva versión de preflightcheck-operator antes de que se ejecuten la comprobación preliminar del clúster y las comprobaciones de estado:
Al igual que en la actualización del clúster de usuarios, el proceso de actualización comienza actualizando el campo Cluster.spec.anthosBareMetalVersion a la versión de destino. Antes de actualizar los componentes, se realizan dos pasos adicionales, tal como se muestra en el siguiente diagrama: lifecycle-controller-manager se actualiza a la versión de destino y, a continuación, implementa la versión de destino de anthos-cluster-operator. Este
anthos-cluster-operator realiza los pasos restantes del proceso de actualización:
Si se completa correctamente, anthos-cluster-operator reconcilia la versión de destino de spec.anthosBareMetalVersion a status.anthosBareMetalVersion.
Actualizar 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 explica en la sección anterior.
La principal diferencia 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 gestiona el clúster híbrido, de administrador o independiente durante una actualización.
El proceso para transferir la propiedad de gestión del clúster al clúster de arranque se denomina pivote. El resto del proceso de actualización es el mismo que el de la actualización de clústeres de usuarios.
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 monitorizar 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 gestión del clúster una vez completada la actualización, el clúster transfiere los recursos del clúster de arranque al clúster actualizado. No tienes que hacer nada manualmente para cambiar el clúster durante el proceso de actualización. El clúster de arranque se elimina cuando la actualización del clúster se completa correctamente.
Purga de nodos
Las actualizaciones de clústeres de Google Distributed Cloud pueden provocar interrupciones en las aplicaciones, ya que los nodos se vacían. Este proceso de drenaje provoca que todos los pods que se ejecutan en un nodo se cierren y se reinicien en los nodos restantes del clúster.
Los despliegues se pueden usar para tolerar estas interrupciones. Una implementación puede especificar que se deben ejecutar varias réplicas de una aplicación o un servicio. Una aplicación con varias réplicas no debería sufrir interrupciones durante las actualizaciones.
PodDisruptionBudgets (PDBs)
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 Eviction, que respeta los PodDisruptionBudgets (PDBs). Los PDBs se pueden usar para asegurarse de que siempre se ejecute un número definido de réplicas en el clúster en condiciones de funcionamiento normales.
Los PDBs te permiten limitar las interrupciones de una carga de trabajo cuando sus pods deben reprogramarse. El drenaje de nodos basado en desalojos 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 PDBs cuando los nodos se vacían durante una actualización. En su lugar, el proceso de drenaje de nodos se realiza en la medida de lo posible. Es posible que algunos pods se queden atascados en el estado Terminating y no abandonen el nodo. La actualización continúa, incluso con los pods bloqueados, cuando el proceso de drenaje de un nodo tarda más de 20 minutos.
Para obtener más información, consulta el artículo sobre cómo poner los nodos en modo de mantenimiento.
Siguientes pasos
- Consulta las prácticas recomendadas para las actualizaciones de Google Distributed Cloud.
- Actualizar Google Distributed Cloud
- Solucionar problemas de actualización de clústeres