Les clusters de Service TKG prennent en charge un modèle de mise à jour continue. 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, vous devez vous familiariser avec le processus de mise à jour continue.
Modèle de mise à jour continue pour les clusters TKGS après Service TKG 3.0
À partir de Service TKG 3.0, le contrôleur TKG est indépendant de vCenter Server et de Superviseur. Reportez-vous à la section Utilisation du Service TKG. La mise à niveau de ces composants n'entraînera pas une mise à jour continue des clusters TKGS.
La mise à niveau de la version Service TKG peut déclencher une mise à jour continue des clusters TKGS.
Modèle de mise à jour continue pour les clusters TKGS antérieurs à Service TKG 3.0
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 IaaS control plane 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
Mises à jour continues initiées par le système
- kubeadmcontrolplanetemplate/kubeadmcontrolplane
- kubeadmconfigtemplate/kubeadmconfig
- vpheremachinetemplate/vspheremachine (pour vSphere 8.x)
- wcpmachinetemplate/wcpmachine (pour vSphere 7.x)
Dans vSphere IaaS control plane, 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 vCenter Server 7.x vers n'importe quelle version de vCenter Server | Peut déclencher une mise à jour continue de tous les clusters Tanzu Kubernetes. Une mise à jour continue est déclenchée par la première mise à niveau de Superviseur suite à une mise à niveau de vCenter Server. Une mise à jour continue n'est généralement pas déclenchée par une mise à niveau de Superviseur sur le même vCenter Server. Reportez-vous aux notes de mise à jour pour plus de détails. |
| Mise à niveau de n'importe quelle version de vCenter Server vers n'importe quelle version de vCenter Server 8.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 vCenter Server 8.0 GA (8.0.0) vers les versions vCenter Server 8.0.0b ou 8.0.0c | Déclenche une mise à jour continue des clusters TKG spécifiés si l'un des cas suivants s'applique :
|
| Mise à niveau de la version vSphere 8.0.0b vers la version vSphere 8.0.0c | Aucun déploiement automatique des clusters de charge de travail |
| Mise à niveau de la version vSphere 8.0.0c vers vSphere version 8.0 Update 1 (8.0.1) | Aucun déploiement automatique des clusters de charge de travail |
| Mise à niveau de n'importe quelle version de vSphere 8.x vers la version 8.0 U2 (8.0.2) | Cela entraînera une mise à niveau propagée vers tous les TKC, car les modifications suivantes doivent se produire :
|
| Mise à niveau de n'importe quelle version de vSphere 8.x antérieure à la version 8.0 U2 (8.0.2) vers la version 8.0 U2c | Cela entraînera une mise à niveau propagée vers tous les TKC, car les modifications suivantes doivent se produire :
|
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.
Éléments à prendre en compte pour les mises à jour continues pour les clusters avec plusieurs pools de nœuds
- Pools de nœuds worker
-
Des pools de nœuds worker ont été introduits avec l'API TKGS v1alpha2 qui a été publiée avec vSphere 7 U3. L'API de cluster MachineDeployments est le Kubernetes primitif sous-jacent des pools de nœuds worker.
ClusterClass a été introduit avec la version vSphere 8 de TKGS. Les API v1alpha3 et v1beta1 sont basées sur ClusterClass. (v1alpha3 est une couche d'abstraction au-dessus de ClusterClass.)
- Mise à jour de plusieurs pools de nœuds lors de la mise à jour continue
-
Lorsque vous mettez à jour un cluster de charge de travail TKGS provisionné avec plusieurs pools de nœuds, le modèle de mise à jour continue diffère selon la version de vSphere utilisée.
vSphere API TKGS Comportement de la mise à niveau TKGS vSphere 7 API v1alpha2 Plusieurs pools de nœuds dans le même cluster sont mis à jour en même temps (simultanément) TKGS vSphere 8 API v1alpha3 et API v1beta1 Plusieurs pools de nœuds dans le même cluster sont mis à jour selon un ordre logique (séquentiellement)
- Éléments à prendre en compte concernant les meilleures pratiques
-
Le provisionnement d'un cluster TKGS vSphere 8 avec plusieurs pools de nœuds identiques ne sert à rien en termes de dimensionnement. Les pools de nœuds doivent être utilisés pour différentes tailles, classes de machine virtuelle, versions de TKr, etc. Évitez d'utiliser plusieurs pools de nœuds identiques pour jouer sur le système et mettre à niveau les clusters plus rapidement, car cela ne fonctionnera pas.
Les budgets d'interruption de l'espace constituent le bon moyen de s'assurer que les mises à niveau n'interfèrent pas avec les applications en cours d'exécution. La meilleure façon de gérer cela consiste à définir PodDisruptionBudgets sur les charges de travail (reportez-vous à la section https://kubernetes.io/docs/tasks/run-application/configure-pdb/). L'API de cluster les respecte et n'arrêtera pas une machine si les seuils sont dépassés.
- Détails de la mise à jour continue pour les clusters TKGS vSphere 8
-
Lors d'une mise à jour de la version du cluster TKGS vSphere 8 :
- Les nœuds du plan de contrôle sont mis à jour en premier, puis les nœuds worker sont déployés sur un nœud worker à la fois à partir du pool de nœuds de zone A. Si deux pools de nœuds sont utilisés, il n'y aura qu'un seul travailleur déployé à la fois.
