Vous pouvez initier une mise à jour continue d'un cluster TKG 2 sur le Superviseur en mettant à jour la version de Version de Tanzu Kubernetes, la classe de machine virtuelle et la classe de stockage. Avant de procéder ainsi, vous devez vérifier la compatibilité du cluster et vous familiariser avec le processus de mise à jour continue.
Modèle de mise à jour continue pour les clusters TKG 2
Le contrôleur TKG s'exécute sur Superviseur. Lorsque vous mettez à jour 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é.
TKG utilise un modèle de mise à jour continue pour mettre à jour les clusters de charge de travail. 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.
- Mettre à jour un cluster TKG 2 en modifiant la version de TKR à l'aide de Kubectl
- Mettre à jour un cluster TKG 2 en modifiant la classe de stockage à l'aide de Kubectl
- Mettre à jour un cluster TKG 2 en modifiant la classe de machine virtuelle Kubectl
- Mettre à jour un cluster TKG 2 en modifiant la version de TKR à l'aide de l'interface de ligne de commande Tanzu
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.
Le système déclenche les mises à jour continues automatisées
- kubeadmcontrolplanetemplate/kubeadmcontrolplane
- kubeadmconfigtemplate/kubeadmconfig
- vpheremachinetemplate/vspheremachine (pour vSphere 8.x)
- wcpmachinetemplate/wcpmachine (pour vSphere 7.x)
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.
Scénario de mise à niveau | Description |
---|---|
Mise à niveau de n'importe quelle version de vSphere v7.x vers n'importe quelle version de vSphere v7.x | Déclenche une mise à jour continue de tous les clusters TKG . |
Mise à niveau de n'importe quelle version de vSphere v7.x vers n'importe quelle version de vSphere v8.x | Déclenche une mise à jour continue de tous les clusters TKG, car les modifications de code suivantes doivent être propagées :
|
Mise à niveau de la version vSphere v8.0 GA vers la version vSphere 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 :
|
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 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.
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>
.