Es posible iniciar una actualización gradual de un clúster de TKG 2 en Supervisor. Para ello, se debe actualizar la versión de versión de Tanzu Kubernetes, actualizar la clase de máquina virtual y actualizar la clase de almacenamiento. Antes de hacer eso, debe comprobar la compatibilidad del clúster y familiarizarse con el proceso de actualización gradual.

Modelo de actualización gradual para clústeres de TKG 2

La controladora TKG se ejecuta en Supervisor. Cuando se actualiza Supervisor, la controladora TKG se actualiza automáticamente si existe una 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.

TKG utiliza un modelo de actualización gradual para actualizar los clústeres de carga de trabajo. 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.

Puede iniciar una actualización gradual de un clúster de TKG 2 mediante uno de los siguientes métodos:

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.

Activadores del sistema para actualizaciones graduales automatizadas

En cada versión del Supervisor, se pueden realizar cambios en uno o varios de los siguientes objetos:
  • kubeadmcontrolplanetemplate/kubeadmcontrolplane
  • kubeadmconfigtemplate/kubeadmconfig
  • vspheremachinetemplate/vspheremachine (para vSphere 8.x)
  • wcpmachinetemplate/wcpmachine (por vSphere 7.x)
Cuando se actualiza el Supervisor, los controladores principales de la API del clúster (CAPI) activan una actualización gradual en los clústeres de carga de trabajo de TKG para que coincidan con el estado deseado de los objetos anteriores en los clústeres de carga de trabajo en ejecución.

En vSphere with Tanzu, 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.

En la tabla se describen las condiciones en las que puede esperar una actualización gradual automatizada de los clústeres de carga de trabajo cada vez que el Supervisor se actualice.
Escenario de actualización Descripción
Actualización de cualquier versión de vSphere v7.x a cualquier versión de vSphere v7.x

Activará una actualización gradual de todos los clústeres de TKG .
Actualización de cualquier versión de vSphere v7.x a cualquier versión de vSphere v8.x Activará una actualización gradual de todos los clústeres de TKG porque se deben propagar los siguientes cambios de código:
  • Los proveedores de CAPI subyacentes deben moverse de CAPW a CAPV
  • Migrar los clústeres desde clústeres de CAPI sin clase a un clúster de CAPI con clase
Actualización de la versión de vSphere 8.0 GA a la versión de vSphere 8.0 MP1 o posterior Activará una actualización gradual de los clústeres de TKG especificados si se aplica alguno de los siguientes casos:
  • Cualquier clúster de TKG que utilizaba la configuración de proxy con una lista de noProxy que no está vacía.
  • Todos los clústeres de TKG si el servicio de registro de Habor integrado se habilitó en Supervisor.
Además, al cambiar la biblioteca de contenido que aloja las imágenes de TKR se pueden activar actualizaciones graduales de los clústeres de TKG. Al añadir nuevas imágenes, ya sea a través de una suscripción o de forma manual, no se activa una actualización gradual de los clústeres de TKG. Sin embargo, si se cambia la biblioteca de contenido y se agregan imágenes con otros nombres, se activará una actualización gradual de todos los clústeres de TKG.

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.

Comprobar la compatibilidad del clúster de TKG 2 para actualización

Antes de actualizar un clúster de carga de trabajo, debe comprobar su compatibilidad para la actualización. Si un clúster no es compatible con la infraestructura de destino, actualice el clúster antes de continuar con la actualización del sistema.

Puede enumerar las versiones de Tanzu Kubernetes y ver la compatibilidad y la capacidad de actualización de cada versión con el siguiente comando. 
kubectl get tanzukubernetesreleases

La columna COMPATIBLE indica si esa versión de Tanzu Kubernetes es compatible con el Supervisor actual. La columna UPDATES AVAILABLE indica si hay una actualización de Kubernetes disponible y la siguiente versiones de Tanzu Kubernetes recomendada que se utilizará.

Esta misma información también está disponible usando kubectl get tkc <tkgs-cluster-name> y kubectl get cluster <tkgs-cluster-name>.