Los clústeres de Servicio TKG admiten un modelo de actualización gradual. Para iniciar una actualización gradual, puede cambiar la especificación del clúster. Algunas operaciones del sistema pueden iniciar una actualización gradual. Antes de actualizar el entorno, debe familiarizarse con el proceso de actualización gradual.
Modelo de actualización gradual para clústeres TKGS después de Servicio TKG 3.0
A partir de Servicio TKG 3.0, la controladora TKG es independiente de vCenter Server y Supervisor. Consulte Usar Servicio TKG. La actualización de estos componentes no iniciará una actualización gradual de los clústeres de TKGS.
La actualización de la versión de Servicio TKG podría activar una actualización gradual de los clústeres de TKGS.
Modelo de actualización gradual para clústeres de TKGS anteriores a Servicio TKG 3.0
La controladora TKG se ejecuta en el Supervisor. Cuando se actualiza el Supervisor, la controladora TKG se actualiza automáticamente si hay alguna actualización disponible. Cada actualización de la controladora TKG puede incluir actualizaciones para servicios de respaldo, como CNI, CSI y CPI, así como actualizaciones de configuración para los clústeres. Para admitir la compatibilidad, el sistema realiza comprobaciones previas y aplica la conformidad.
vSphere IaaS control plane utiliza un modelo de actualización gradual para los clústeres de TKG en el Supervisor. El modelo de actualización gradual garantiza un tiempo de inactividad mínimo durante el proceso de actualización. Las actualizaciones graduales incluyen la actualización de las versiones de software de Kubernetes, así como de la infraestructura y los servicios que respaldan los clústeres, como los recursos y las configuraciones de máquinas virtuales, los servicios y los espacios de nombres, y los recursos personalizados. Para que la actualización se realice correctamente, la configuración debe cumplir con varios requisitos de compatibilidad, de modo que el sistema aplique condiciones de reverificación a fin de garantizar que los clústeres estén listos para las actualizaciones y que dicho sistema sea compatible con la reversión si el clúster no se actualiza correctamente.
Para iniciar una actualización gradual de un clúster de TKG, cambie ciertos aspectos del manifiesto del clúster. El sistema también puede iniciar una actualización gradual del clúster. Por ejemplo, cuando se realiza una actualización de espacios de nombres de vSphere, el sistema propaga de inmediato las configuraciones actualizadas a todos los clústeres de carga de trabajo. Estas actualizaciones pueden activar una actualización gradual de los nodos del clúster. Un cambio en cualquiera de los elementos de configuración también puede iniciar una actualización gradual. Por ejemplo, si se cambia el nombre o se reemplaza el objeto VirtualMachineImage que corresponde a una versión de distribución, se inicia una actualización gradual, ya que el sistema intenta obtener todos los nodos que se ejecutan en la nueva imagen. Además, la actualización de Supervisor podrá activar una actualización gradual de los clústeres de carga de trabajo implementados allí. Por ejemplo, si se actualiza vmware-system-tkg-controller-manager, el sistema introduce nuevos valores en el generador de manifiestos, y la controladora inicia una actualización gradual para implementar esos valores.
El proceso de actualización gradual para reemplazar los nodos del clúster es similar a la actualización gradual de pods de una implementación de Kubernetes. Existen dos controladoras distintas que se encargan de realizar una actualización gradual de los clústeres de carga de trabajo: la controladora de complementos y la controladora de clúster. Dentro de esas dos controladoras hay tres etapas clave de una actualización gradual: la actualización de los complementos, la actualización del plano de control y la actualización de los nodos de trabajo. Estas etapas se producen en orden, con comprobaciones previas que impiden que un paso comience hasta que el paso anterior haya avanzado lo suficiente. Es posible que estos pasos se omitan si se determina que son innecesarios. Por ejemplo, una actualización podría solo afectar a los nodos de trabajo y, por tanto, no necesitaría actualizaciones de los planos de control ni de los complementos.
Durante el proceso de actualización, el sistema agrega un nuevo nodo de clúster y espera a que el nodo se conecte con la versión de Kubernetes de destino. A continuación, el sistema marca el nodo antiguo para su eliminación, pasa al siguiente nodo y repite el proceso. El nodo antiguo no se eliminará hasta que se eliminen todos los pods. Por ejemplo, si un pod se define con PodDisruptionBudgets que impide que un nodo se vacíe completamente, el nodo se acordona, pero no se elimina hasta que dichos pods se puedan expulsar. El sistema actualiza primero todos los nodos del plano de control y, a continuación, los nodos de trabajo. Durante una actualización, el estado del clúster cambia a "Actualizando". Una vez finalizado el proceso de actualización gradual, el estado del clúster cambia a "En ejecución".
Los pods en ejecución en un clúster no regulados por una controladora de replicación se eliminarán durante una actualización de la versión de Kubernetes como parte de la purga de nodos de trabajo que se realiza al actualizar el clúster. Esto sucede si una actualización de espacios de nombres de vSphere o de Supervisor activa la actualización del clúster de forma manual o automática. Los pods que no están regidos por una controladora de replicación incluyen aquellos pods que no se crean como parte de una especificación de ReplicaSet o de implementación. Para obtener más información, consulte Ciclo de vida del pod: duración del pod en la documentación de Kubernetes.
Actualizaciones graduales iniciadas por el usuario
Actualizaciones graduales iniciadas por el sistema
- kubeadmcontrolplanetemplate/kubeadmcontrolplane
- kubeadmconfigtemplate/kubeadmconfig
- vspheremachinetemplate/vspheremachine (para vSphere 8.x)
- wcpmachinetemplate/wcpmachine (por vSphere 7.x)
En vSphere IaaS control plane, la controladora de TKG que se ejecuta en el Supervisor genera y mantiene estos objetos sincronizados con el código del sistema. Esto significa que, cuando las controladoras se actualizan al código más reciente, los cambios que se producen en alguno de los objetos anteriores provocan una actualización gradual de los clústeres de TKG existentes. En resumen, los cambios en el código del sistema que afectan al Supervisor provocan actualizaciones graduales de los clústeres de TKG.
| Escenario de actualización | Descripción |
|---|---|
| Actualizar desde cualquier versión de vCenter Server 7.x a cualquier versión de vCenter Server | Puede activar una actualización gradual de todos los clústeres de Tanzu Kubernetes. La primera actualización de Supervisor después de una actualización de vCenter Server activa una actualización gradual. Por lo general, no se activa una actualización gradual al actualizar Supervisor en el mismo vCenter Server. Compruebe las notas de la versión para obtener más información. |
| Actualizar desde cualquier versión de vCenter Server a cualquier versión de vCenter Server 8.x | Activará una actualización gradual de todos los clústeres de TKG porque se deben propagar los siguientes cambios de código:
|
| Actualizar de la versión vCenter Server 8.0 GA (8.0.0) a las versiones vCenter Server 8.0.0b u 8.0.0c | Activará una actualización gradual de los clústeres de TKG especificados si se aplica alguno de los siguientes casos:
|
| Actualización de la versión vSphere 8.0.0b a la versión vSphere 8.0.0c | No hay implementaciones automáticas de clústeres de carga de trabajo |
| Actualización de la versión vSphere 8.0.0c a la versión vSphere 8.0 Update 1 (8.0.1) | No hay implementaciones automáticas de clústeres de carga de trabajo |
| Actualizar desde cualquier versión de vSphere 8.x a la versión 8.0 U2 (8.0.2) | Esto provocará una actualización gradual en todos los TKC, ya que deben producirse los siguientes cambios:
|
| Actualización de cualquier versión de vSphere 8.x anterior a la 8.0 U2 (8.0.2) a la versión 8.0 U2c | Esto provocará una actualización gradual en todos los TKC, ya que deben producirse los siguientes cambios:
|
Por ejemplo, imagine un escenario en el que se utiliza una biblioteca de contenido suscrita que utiliza automáticamente los nombres de OVA definidos por el sistema. A continuación, se pasa a una biblioteca de contenido local y se rellena con los mismos archivos OVA, pero dándoles otros nombres. Esto activará una actualización gradual de todos los clústeres de TKG, ya que la biblioteca de contenido de reemplazo tiene los mismos archivos OVA, pero con otros nombres definidos por el usuario.
Consideraciones sobre la actualización gradual para clústeres con varios grupos de nodos
- Grupos de nodos de trabajo
-
Los grupos de nodos de trabajo se introdujeron con la API v1alpha2 de TKGS que se publicó con vSphere 7 U3. MachineDeployments de la API de clúster es el primitivo subyacente de Kubernetes de los grupos de nodos de trabajo.
ClusterClass se introdujo con la versión vSphere 8 de TKGS. Tanto la API v1alpha3 como v1beta1 se basan en ClusterClass. (v1alpha3 es una capa de abstracción encima de ClusterClass).
- Cómo se actualizan varios grupos de nodos durante una actualización gradual
-
Cuando se actualiza un clúster de carga de trabajo de TKGS aprovisionado con varios grupos de nodos, el modelo de actualización gradual varía según la versión de vSphere que se utilice.
vSphere API de TKGS Comportamiento de actualización TKGS de vSphere 7 API v1alpha2 Se actualizan varios grupos de nodos dentro del mismo clúster al mismo tiempo (simultáneamente) TKGS de vSphere 8 API v1alpha3 y API v1beta1 Varios grupos de nodos dentro del mismo clúster se actualizan siguiendo un orden lógico (secuencialmente)
- Consideraciones sobre prácticas recomendadas
-
Aprovisionar un clúster de TKGS de vSphere 8 con varios grupos de nodos idénticos no tiene ningún propósito en términos de dimensionamiento. Los grupos de nodos deben utilizarse para diferentes tamaños, clases de máquinas virtuales, versiones de TKr, etc. Evite utilizar varios grupos de nodos idénticos para burlar al sistema y actualizar los clústeres más rápido, ya que no funcionará.
Los Pod Disruption Budget son la forma adecuada de garantizar que las actualizaciones no interfieran con las aplicaciones en ejecución. La mejor forma de gestionar esto es establecer PodDisruptionBudgets en las cargas de trabajo (consulte https://kubernetes.io/docs/tasks/run-application/configure-pdb/). La API del clúster los respeta y no finalizará la máquina correspondiente si se superan los umbrales.
- Detalles de actualización gradual para clústeres TKGS de vSphere 8
-
Durante una actualización de la versión de un clúster TKGS de vSphere 8:
- Los nodos del plano de control se actualizan primero y, a continuación, los nodos de trabajo se consolidan en un nodo de trabajo a la vez empezando por el grupo de nodos de la zona A. Si se utilizan dos grupos de nodos, solo habrá 1 trabajo implementado a la vez.
