Cuando actualizas GKE en Bare Metal, el proceso de actualización implica varios pasos y componentes. Para ayudar a supervisar el estado de 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 GKE en Bare Metal 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 exitosa concilia status.anthosBareMetalVersion
con spec.anthosBareMetalVersion para que ambas muestren la versión de destino.
Sesgo de versión
El sesgo de versiones es la diferencia de versiones entre un clúster de administrador y sus clústeres de usuario administrados. Los clústeres de GKE en Bare Metal siguen el mismo estilo que Kubernetes: el clúster de administrador puede ser, como máximo, una versión secundaria por delante de los clústeres administrados.
Reglas de versión para actualizaciones
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.28.400-gke.77 de bmctl, solo puedes actualizar un clúster a la versión 1.28.400-gke.77.
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.28.X a la versión 1.28.Y siempre que Y sea mayor que X. Por ejemplo, puedes actualizar de 1.16.0 a 1.16.1 y actualizar de 1.16.1 a 1.16.3. 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.16.3 a 1.28.400-gke.77.
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.15.0 a la versión 1.28.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:
La versión del clúster debe ser mayor o igual que la versión del grupo de nodo trabajador.
Con la versión secundaria 1.28 de GKE en Bare Metal, una versión del grupo de nodo trabajador puede ser de hasta dos versiones secundarias detrás de la versión del clúster (plano de control). Este sesgo de versión n-2 está disponible como una función (Versión preliminar). Esta función de vista previa está habilitada con una anotación en el archivo de configuración del clúster. Si no habilitas esta función de vista previa, el sesgo máximo de versiones entre un grupo de nodo trabajador y el clúster es una versión secundaria.
Los grupos de nodos trabajadores no pueden estar en una versión que se lanzó cronológicamente más tarde a la versión del clúster.
Por ejemplo, si la versión 1.16.4 se lanza en una fecha posterior a la versión 1.28.0-gke.425, no podrás actualizar tu clúster a la versión 1.28.0-gke.425 y dejar un grupo de nodo trabajador en la versión 1.16.4. Del mismo modo, si actualizas el clúster a la versión 1.28.0-gke.425, pero elegiste dejar un grupo de nodo trabajador en la versión 1.16.3, no podrás actualizarlo más adelante a la versión 1.16.4.
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:
| Versión del clúster (plano de control) | Versiones compatibles del grupo de nodo trabajador | |||
|---|---|---|---|---|
| 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 |
|
|
|
|
Actualiza los 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úster para herramientas de redes, observabilidad y almacenamiento.
- En el caso de los clústeres de administrador, independientes y híbridos, 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 del usuario | Kubelet, entorno de ejecución de contenedores (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-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 WorkManager y Keepalived que entregan el tráfico a kube-apiserver y ejecutan bocinas MetalLB para reclamar direcciones IP virtuales. |
Pods estáticos del balanceador de cargas del plano de control (WorkManager, Keepalived)
Bocinas MetalLB |
Expectativa de tiempo de descanso
En la siguiente tabla, se detallan el tiempo de inactividad esperado y el impacto potencial de la actualización de clústeres. En esta tabla, se supone que tienes varios nodos del 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, se espera un tiempo de inactividad adicional. A menos que se indique lo contrario, este tiempo de inactividad se aplica a las actualizaciones de los clústeres de administrador y de usuario:
| Componentes | Expectativas de tiempo de descanso | Cuándo ocurre el tiempo de inactividad |
|---|---|---|
El servidor de la API del plano de control de Kubernetes (kube-apiserver), etcd y el programador |
No hay tiempo de inactividad | N/A |
Controladores de ciclo de vida y trabajo ansible-runner (solo 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. | Inicio del proceso de actualización. |
Observabilidad pipeline-stackdriver y
metrics-server |
Se vació y se actualizó el operador. El tiempo de descanso debe ser inferior a 5 minutos.
Los DaemonSets continúan 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 herramientas de redes existentes. El DaemonSet se implementó dos por dos sin tiempo de inactividad. El operador se vacía y se actualiza. Tiempo de descanso de menos de 5 minutos. |
Después de que los nodos del plano de control terminen de actualizarse. |
| MetalLB (solo clúster de usuario) | Se vació y se actualizó el operador. El tiempo de descanso es inferior 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.
Es posible que el operador tenga 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 vacía y se actualiza. Aproximadamente 5 minutos de tiempo de inactividad. El Ingress configurado existente sigue funcionando. |
Después de que los nodos del plano de control terminen de actualizarse. |
| Otros operadores del sistema | Tiempo de inactividad de 5 minutos cuando se vacía y se 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 tiene alta disponibilidad. Revisa tus propias implementaciones de cargas de trabajo para comprender el impacto potencial. |
Cuando se actualizan 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 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 de administrador, híbridos o independientes.
En el siguiente diagrama, se muestra el proceso de comprobación previa para la actualización de un clúster de usuario:
En el diagrama anterior, se detallan los pasos que ocurren 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 de nodos.
- Los resultados de estas verificaciones adicionales se combinan para informar sobre la capacidad del clúster de actualizarse de forma correcta a la versión de destino.
Si las comprobaciones preliminares se realizan de forma correcta 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 orden de la siguiente manera:
- La actualización comienza con la actualización del campo
spec.anthosBareMetalVersion. - Se actualizan los balanceadores de cargas del plano de control.
- Se actualizará el grupo de nodos del plano de control.
- Al mismo tiempo, GKE Connect se actualiza, se actualizan los complementos del clúster y se actualiza el grupo de nodos del balanceador de cargas.
- Una vez que el grupo de nodos del balanceador de cargas se actualice de forma correcta, se actualizarán los grupos de nodos trabajadores.
Cuando se actualizan 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.
La actualización finaliza cuando se aprueban todas las verificaciones de estado.
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 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 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 las versiones a los números de nodos. |
| 4 | status.anthosBareMetalVersion |
Estado final de la versión actualizada. |
Detalles de 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 (de administrador, híbridos o independientes) es una actualización in situ.
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 los 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 realizas una 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 clústeres autoadministrados es similar al proceso de actualización del clúster de usuario. Sin embargo, cuando usas el proceso de actualización local, se implementa una versión nueva de preflightcheck-operator antes de que se ejecuten la verificación previa y las verificaciones de estado del 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 de destino de anthos-cluster-operator. Este
anthos-cluster-operator realiza los pasos restantes del proceso de actualización:
Cuando se ejecuta de forma correcta, anthos-cluster-operator concilia la versión de destino 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 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 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 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 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 gira los recursos del clúster de arranque al clúster actualizado. No debes realizar pasos manuales para dinamizar 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 del clúster de GKE en Bare Metal pueden provocar la interrupción de la aplicación mientras se desvían los nodos. Este proceso de vaciado hace que todos los Pods que se ejecutan en un nodo se cierren y se reinicien en los nodos restantes del clúster.
Los objetos Deployment pueden usarse para tolerar esta interrupción. Un Deployment puede especificar varias réplicas de una aplicación o un servicio que se deben ejecutar. Una aplicación con varias réplicas debería experimentar una interrupción mínima o nula durante las actualizaciones.
Presupuestos de interrupción de Pods (PDB)
Los presupuestos de interrupción de Pods (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 a una carga de trabajo cuando sus Pods deben reprogramarse.
Sin embargo, GKE en Bare Metal no respeta los PDB cuando se agotan los nodos durante una actualización.
En cambio, 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 de un nodo tarda más de 20 minutos.
¿Qué sigue?
- Revisa las prácticas recomendadas para las actualizaciones de GKE en Bare Metal.
- Actualiza GKE en Bare Metal
- Soluciona problemas de actualización del clúster