vSphere with Tanzu prend en charge un modèle de mise à jour continue pour les clusters TKG sur le Superviseur. Vous pouvez initier une mise à jour continue en modifiant la spécification du cluster. Certaines opérations système peuvent initier une mise à jour continue. Avant de mettre à jour l'environnement vSphere with Tanzu, vous devez vous familiariser avec le processus de mise à jour continue.

Modèle de mise à jour continue pour les clusters TKG sur le Superviseur

Le contrôleur TKG s'exécute sur le Superviseur. Lorsque vous mettez à jour le Superviseur, le contrôleur TKG est automatiquement mis à jour si une mise à jour est disponible. Chaque mise à jour du contrôleur TKG peut inclure des mises à jour pour les services de prise en charge, tels que CNI, CSI, CPI, ainsi que des mises à jour de configuration pour les clusters. Pour prendre en charge la compatibilité, le système effectue des vérifications préalables et applique la conformité.

vSphere with Tanzu utilise un modèle de mise à jour continue pour mettre à jour les clusters TKG sur le Superviseur. Le modèle de mise à jour continue garantit une interruption de service minimale lors du processus de mise à jour du cluster. Les mises à jour continues incluent la mise à niveau des versions du logiciel Kubernetes, ainsi que de l'infrastructure et des services prenant en charge les clusters, comme les configurations et les ressources de machine virtuelle, les services et les espaces de noms, ainsi que les ressources personnalisées. Pour que la mise à jour réussisse, votre configuration doit répondre à plusieurs exigences de compatibilité. Par conséquent, le système impose des conditions de revérification pour s'assurer que les clusters sont prêts pour les mises à jour et il prend en charge la restauration si la mise à niveau du cluster échoue.

Vous pouvez initier une mise à jour continue d'un cluster TKG en modifiant certains aspects dans le manifeste du cluster. Le système peut également initier une mise à jour continue du cluster. Par exemple, lorsqu'une mise à jour des Espaces de noms vSphere est effectuée, le système propage immédiatement les configurations mises à jour vers tous les clusters de charge de travail. Ces mises à jour peuvent déclencher une mise à jour continue des nœuds de cluster. En outre, une modification apportée à l'un des éléments de configuration peut également initier une mise à jour continue. Par exemple, le changement de nom ou le remplacement de l'VirtualMachineImage qui correspond à une version de distribution initie une mise à jour continue lorsque le système tente d'obtenir tous les nœuds en cours d'exécution sur la nouvelle image. En outre, la mise à jour d'un Superviseur déclenchera probablement une mise à jour continue des clusters de charge de travail y étant déployés. Par exemple, lorsque vmware-system-tkg-controller-manager est mis à jour, le système introduit de nouvelles valeurs dans le générateur de manifeste et le contrôleur initie une mise à jour continue pour déployer ces valeurs.

Le processus de mise à jour continue pour le remplacement des nœuds de cluster est semblable à la mise à jour continue des espaces dans un déploiement Kubernetes. Deux contrôleurs distincts sont responsables de l'exécution d'une mise à jour continue des clusters de charge de travail : le contrôleur Modules complémentaires et le contrôleur Cluster. Au sein de ces deux contrôleurs, il existe trois étapes clés pour une mise à jour continue : la mise à jour des modules complémentaires, la mise à jour du plan de contrôle et la mise à jour des nœuds worker. Ces étapes sont effectuées dans l'ordre, avec des vérifications préalables qui empêchent le début d'une étape tant que l'étape précédente n'a pas suffisamment progressé. Ces étapes peuvent être ignorées si elles sont jugées inutiles. Par exemple, une mise à jour peut affecter uniquement les nœuds worker et n'exige donc pas de mise à jour du module complémentaire ou du plan de contrôle.

Pendant le processus de mise à jour, le système ajoute un nouveau nœud de cluster et attend que le nœud soit mis en ligne avec la version cible de Kubernetes. Le système marque ensuite l'ancien nœud pour être supprimé, passe au nœud suivant et répète le processus. L'ancien nœud n'est pas supprimé tant que tous les espaces ne sont pas supprimés. Par exemple, si un espace est défini avec des PodDisruptionBudgets qui empêchent l'épuisement complet d'un nœud, le nœud est détaché mais n'est pas supprimé tant que ces espaces ne peuvent pas être supprimés. Le système met d'abord à niveau tous les nœuds de plan de contrôle, puis les nœuds worker. Lors d'une mise à jour, l'état du cluster passe à « Mise à jour ». Une fois le processus de mise à jour continue terminé, l'état du cluster passe à « En cours d'exécution ».

Les espaces s'exécutant sur un cluster qui ne sont pas régis par un contrôleur de réplication seront supprimés pendant la mise à niveau de la version de Kubernetes dans le cadre du drainage du nœud worker lors de la mise à jour du cluster . Cela est vrai si la mise à jour du cluster est déclenchée manuellement ou automatiquement par une mise à jour des espaces de noms vSphere ou du Superviseur. Les espaces non régis par un contrôleur de réplication comprennent les espaces qui ne sont pas créés dans le cadre d'une spécification de déploiement ou de ReplicaSet. Pour plus d'informations, reportez-vous à la rubrique Cycle de vie de l'espace : durée de vie de l'espace dans la documentation de Kubernetes.

Mises à jour continues initiées par l'utilisateur

Vous pouvez initier une mise à jour continue d'un cluster TKG sur le Superviseur en mettant à jour la version de Version de Tanzu Kubernetes, la classe de machine virtuelle et la classe de stockage. Reportez-vous à l'une des rubriques suivantes pour plus d'informations.

Mises à jour continues initiées par le système

Pour chaque version du Superviseur, des modifications peuvent être apportées à un ou plusieurs des objets suivants :
  • kubeadmcontrolplanetemplate/kubeadmcontrolplane
  • kubeadmconfigtemplate/kubeadmconfig
  • vpheremachinetemplate/vspheremachine (pour vSphere 8.x)
  • wcpmachinetemplate/wcpmachine (pour vSphere 7.x)
Lorsque le Superviseur est mis à niveau, les contrôleurs CAPI (API du cluster) principaux déclenchent une mise à jour continue sur les clusters de charge de travail TKG pour correspondre à l'état souhaité des objets ci-dessus dans les clusters de charge de travail en cours d'exécution.

Dans vSphere with Tanzu, le contrôleur TKG qui s'exécute dans le Superviseur génère et maintient ces objets synchronisés avec le code système. Cela signifie que lorsque les contrôleurs sont mis à jour vers un code plus récent, les modifications apportées à l'un des objets ci-dessus entraînent une mise à jour continue des clusters TKG existants. En somme, les modifications du code système affectant le Superviseur entraînent des mises à jour continues des clusters TKG.

Le tableau décrit les conditions dans lesquelles vous pouvez vous attendre à une mise à jour continue automatisée des clusters de charge de travail chaque fois que le Superviseur est mis à niveau.
Scénario de mise à niveau Description
Mise à niveau de n'importe quelle version de vSphere with Tanzu 7.x vers n'importe quelle version de vSphere with Tanzu 7.x

Peut déclencher une mise à jour continue de tous les clusters Tanzu Kubernetes. Consultez les notes de mise à jour.

Mise à niveau de n'importe quelle version de vSphere with Tanzu 7.x vers n'importe quelle version de vSphere with Tanzu 8.x Déclenche une mise à jour continue de tous les clusters TKG, car les modifications de code suivantes doivent être propagées :
  • Les fournisseurs CAPI sous-jacents doivent être déplacés depuis CAPW vers CAPV
  • Migrer les clusters depuis des clusters CAPI sans classe vers un cluster CAPI avec classe
Mise à niveau de la version vSphere with Tanzu 8.0 GA vers la version vSphere with Tanzu 8.0 MP1 ou ultérieure Déclenche une mise à jour continue des clusters TKG spécifiés si l'un des cas suivants s'applique :
  • Cluster TKG qui utilisait des paramètres de proxy avec une liste noProxy non vide.
  • Tous les clusters TKG si le service de registre Habor intégré a été activé sur le Superviseur.
Mise à niveau de la version vSphere with Tanzu 8.0 MP1 vers la version vSphere with Tanzu 8.0 P01 Aucun déploiement automatique des clusters de charge de travail
Mise à niveau de la version vSphere with Tanzu 8.0 P01 vers la version vSphere with Tanzu 8.0 U1 Aucun déploiement automatique des clusters de charge de travail
Mise à niveau de n'importe quelle version vSphere 8.x vers la version 8.0 U2 Cela entraînera une mise à niveau propagée vers tous les TKC, car les modifications suivantes doivent se produire :
  • vSphere 8.0 U2 contient des modifications STIG de niveau Kubernetes pour les TKR TKG 1.0 et TKG 2.0 dans GCM, dans le cadre de la ClusterClass.
  • Étant donné que les TKC de la version 1.23 et des versions ultérieures sont compatibles avec la version 8.0 U2, tous les clusters font l'objet d'une mise à niveau continue.
En outre, la modification de la bibliothèque de contenu hébergeant les images TKR peut déclencher des mises à jour continues des clusters TKG. L'ajout de nouvelles images, via un abonnement ou manuellement, ne déclenche pas de mise à jour continue des clusters TKG. Toutefois, la modification de la bibliothèque de contenu et l'ajout d'images avec des noms différents déclenchent une mise à jour continue de tous les clusters TKG.

Par exemple, considérons un scénario dans lequel vous utilisez une bibliothèque de contenu abonnée qui utilise automatiquement les noms OVA définis par le système. Ensuite, vous basculez vers une bibliothèque de contenu locale et vous la remplissez avec les mêmes fichiers OVA, mais en leur donnant des noms différents. Cela déclenchera une mise à jour continue de tous les clusters TKG, car la bibliothèque de contenu de remplacement a les mêmes fichiers OVA, mais avec des noms différents définis par l'utilisateur.

Vérification de la compatibilité du cluster TKG 2.0 pour la mise à jour

Avant de mettre à niveau un cluster de charge de travail, vous devez vérifier sa compatibilité pour la mise à niveau. Si un cluster est incompatible avec l'infrastructure cible, mettez-le à niveau avant de procéder à la mise à niveau du système.

Vous pouvez répertorier les Versions de Tanzu Kubernetes et afficher la compatibilité et la capacité de mise à jour de chaque version à l'aide de la commande suivante.
kubectl get tanzukubernetesreleases

La colonne COMPATIBLE indique si cette Version de Tanzu Kubernetes est compatible avec le Superviseur actuel. La colonne UPDATES AVAILABLE indique si une mise à niveau Kubernetes est disponible et les Versions de Tanzu Kubernetes suivantes recommandées à utiliser.

Les mêmes informations sont également disponibles en utilisant kubectl get tkc <tkgs-cluster-name> et kubectl get cluster <tkgs-cluster-name>.