TKG-Dienstcluster unterstützen ein Modell für parallele Updates. Sie können ein paralleles Update initiieren, indem Sie die Clusterspezifikation ändern. Einige Systemvorgänge können ein paralleles Update initialisiert haben. Bevor Sie die Umgebung aktualisieren, sollten Sie sich mit dem Vorgang des parallelen Updates vertraut machen.
Modell für parallele Updates für TKGS-Cluster nach TKG-Dienst 3.0
Ab TKG-Dienst 3.0 ist der TKG-Controller unabhängig von vCenter Server und vom Supervisor. Weitere Informationen hierzu finden Sie unter Verwenden der TKG-Dienst. Durch das Upgrade dieser Komponenten wird kein paralleles Update von TKGS-Clustern aktiviert.
Das Upgrade der TKG-Dienstversion kann ein paralleles Update von TKGS-Clustern auslösen.
Modell für parallele Updates für TKGS-Cluster vor TKG-Dienst 3.0
Der TKG-Controller wird auf Supervisor ausgeführt. Wenn Sie Supervisor aktualisieren, wird der TKG-Controller automatisch aktualisiert, wenn ein Update verfügbar ist. Jedes TKG-Controller-Update kann Aktualisierungen für unterstützende Dienste wie z. B. CNI, CSI, CPI sowie Konfigurationsaktualisierungen für Cluster enthalten. Zum Zweck der Kompatibilität führt das System Vorabprüfungen durch und erzwingt die Konformität.
vSphere IaaS control plane unterstützt ein Modell für parallele Updates für TKG-Cluster auf Supervisor. Das Modell für parallele Updates minimiert die Ausfallzeiten während der Aktualisierung. Parallele Updates umfassen Upgrades der Kubernetes-Versionen sowie der Infrastruktur und der Dienste, die die Cluster unterstützen, wie z. B. Konfigurationen und Ressourcen virtueller Maschinen, Dienste und Namespaces sowie benutzerdefinierte Ressourcen. Damit das Update erfolgreich verläuft, muss Ihre Konfiguration verschiedene Kompatibilitätsanforderungen erfüllen, sodass das System Bedingungen für die erneute Prüfung erzwingt, um sicherzustellen, dass die Cluster für das Updates bereit sind, und Rollback unterstützt, falls das Cluster-Upgrade nicht erfolgreich ist.
Sie können ein paralleles Update eines TKG-Clusters initiieren, indem Sie d en Wert des Parameters in der Clusterspezifikation ändern. Ein paralleles Cluster-Update kann auch vom System initiiert werden. Wird beispielsweise ein vSphere-Namespaces-Update durchgeführt, gibt das System die aktualisierten Konfigurationen sofort an alle Arbeitslastcluster weiter. Diese Aktualisierungen können ein paralleles Update von Clusterknoten auslösen. Zudem kann eine Änderung an einem der Konfigurationselemente auch zur Initiierung eines parallelen Updates führen. Wenn beispielsweise das einer Verteilungsversion entsprechende VirtualMachineImage umbenannt oder ersetzt wird, wird ein paralleles Update initiiert, da das System versucht, alle auf dem neuen Image ausgeführten Knoten abzurufen. Darüber hinaus löst das Aktualisieren eines Supervisors wahrscheinlich ein paralleles Update der dort bereitgestellten Arbeitslast-Cluster aus. Wenn beispielsweise der vmware-system-tkg-controller-manager aktualisiert wird, fügt das System neue Werte in den Manifestgenerator ein, und der Controller initiiert ein paralleles Update zur Bereitstellung dieser Werte.
Der Vorgang des parallelen Updates zum Ersetzen der Clusterknoten ähnelt dem parallelen Update von Pods in einer Kubernetes-Bereitstellung. Es gibt zwei verschiedene Controller, die für das Durchführen eines parallelen Updates von Arbeitslast-Clustern verantwortlich sind: den Add-On-Controller und den Cluster-Controller. Innerhalb dieser beiden Controller gibt es drei wichtige Phasen für ein paralleles Update: das Aktualisieren von Add-Ons, das Aktualisieren der Steuerungsebene und das Aktualisieren der Worker-Knoten. Diese Phasen erfolgen in der genannten Reihenfolge mit Vorabprüfungen, die verhindern, dass ein Schritt gestartet wird, bevor der vorherige Schritt ausreichend fortgeschritten ist. Diese Schritte werden möglicherweise übersprungen, wenn sie als unnötig eingestuft wurden. Ein Update kann beispielsweise nur Worker-Knoten betreffen und daher keine Add-On- oder Steuerungsebenen-Updates erfordern.
Während des Updatevorgangs fügt das System einen neuen Clusterknoten hinzu und wartet darauf, dass der Knoten mit der Kubernetes-Zielversion in den Onlinemodus wechselt. Das System markiert dann den alten Knoten zum Löschen, wechselt zum nächsten Knoten und wiederholt den Vorgang. Der alte Knoten wird erst gelöscht, wenn alle Pods entfernt wurden. Wenn ein Pod beispielsweise mit PodDisruptionBudgets definiert ist, die verhindern, dass ein Knoten vollständig entleert wird, wird der Knoten isoliert, aber erst gelöscht, wenn diese Pods entfernt werden können. Das System aktualisiert zuerst alle Knoten der Steuerungsebene und dann die Worker-Knoten. Während eines Updates ändert sich der Status des Clusters in „wird aktualisiert“. Nach Abschluss des parallelen Updates ändert sich der Status des Clusters in „wird ausgeführt“.
Auf einem Cluster ausgeführte Pods, die nicht von einem Replizierungs-Controller gesteuert werden, werden während des Upgrades einer Kubernetes-Version, das im Rahmen der Entleerung des Worker-Knotens beim Update des Clusters stattfindet, gelöscht. Dies ist der Fall, wenn das Cluster-Update manuell oder automatisch durch ein vSphere Namespaces- oder Supervisor-Update ausgelöst wird. Zu den nicht durch einen Replizierungs-Controller gesteuerten Pods zählen Pods, die nicht als Teil einer Bereitstellungs- oder ReplicaSet-Spezifikation erstellt werden. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Pod Lifecycle: Pod lifetime (Pod-Lebenszyklus: Pod-Lebensdauer).
Vom Benutzer initiierte parallele Updates
Vom System initiierte parallele Updates
- kubeadmcontrolplanetemplate/kubeadmcontrolplane
- kubeadmconfigtemplate/kubeadmconfig
- vpheremachinetemplate/vspheremachine (für vSphere 8.x)
- vcpmachinetemplate/wcpmachine (für vSphere 7.x)
In vSphere IaaS control plane erzeugt der in Supervisor ausgeführte TKG-Controller diese Objekte und synchronisiert sie fortlaufend mit dem Systemcode. Wenn die Controller folglich auf einen neueren Code aktualisiert werden, führen Änderungen an einem der oben genannten Objekte zu einem parallelen Update der vorhandenen TKG-Cluster. Änderungen am Systemcode, die sich auf Supervisor auswirken, führen folglich zu parallelen Updates von TKG-Clustern.
| Upgrade-Szenario | Beschreibung |
|---|---|
| Upgrade von einer beliebigen vCenter Server 7.x-Version auf eine beliebige vCenter Server-Version | Löst möglicherweise ein paralleles Update aller Tanzu Kubernetes-Cluster aus. Ein paralleles Update wird durch das erste Upgrade vom Supervisor nach einem Upgrade von vCenter Server ausgelöst. Ein paralleles Update wird in der Regel nicht durch ein Upgrade vom Supervisor auf demselben vCenter Server ausgelöst. Spezifische Details finden Sie in den Versionshinweisen. |
| Upgrade von einer beliebigen vCenter Server-Version auf eine beliebige vCenter Server 8.x-Version | Löst ein paralleles Update aller TKG-Cluster aus, da die folgenden Codeänderungen weitergegeben werden müssen:
|
| Upgrade von vCenter Server Version 8.0 GA (8.0.0) auf die Versionen vCenter Server 8.0.0b oder 8.0.0c | Löst ein paralleles Update der angegebenen TKG-Cluster aus, wenn einer der folgenden Fälle zutrifft:
|
| Upgrade von vSphere Version 8.0.0b auf vSphere Version 8.0.0c | Keine automatischen Rollouts von Arbeitslastclustern |
| Upgrade von vSphere Version 8.0.0c auf vSphere 8.0 Version Update 1 (8.0.1) | Keine automatischen Rollouts von Arbeitslastclustern |
| Upgrade von einer beliebigen vSphere 8.x-Version auf eine 8.0 U2-Version (8.0.2) | Dies führt zu einem parallelen Upgrade für alle TKCs, da die folgenden Änderungen vorgenommen werden müssen:
|
| Upgrade von einer beliebigen vSphere 8.x-Version vor 8.0 U2 (8.0.2) auf Version 8.0 U2c | Dies führt zu einem parallelen Upgrade für alle TKCs, da die folgenden Änderungen vorgenommen werden müssen:
|
Betrachten Sie beispielsweise ein Szenario, in dem Sie eine abonnierte Inhaltsbibliothek verwenden, die automatisch die systemdefinierten OVA-Namen verwendet. Wechseln Sie anschließend zu einer lokalen Inhaltsbibliothek und befüllen Sie sie mit denselben OVAs. Verwenden Sie jedoch andere Namen. Auf diese Weise wird ein paralleles Update aller TKG-Cluster ausgelöst, da die Ersatzinhaltsbibliothek dieselben OVAs, aber unterschiedliche benutzerdefinierte Namen aufweist.
Überlegungen zu parallelen Updates für Cluster mit mehreren Knotenpools
- Worker-Knotenpools
-
Worker-Knotenpools wurden mit der TKGS-v1alpha2-API eingeführt, die mit vSphere 7 U3 veröffentlicht wurde. Cluster API MachineDeployments ist das zugrunde liegende Kubernetes-Primitiv von Worker-Knotenpools.
ClusterClass wurde mit der vSphere 8-Version von TKGS eingeführt. Sowohl die v1alpha3- als auch die v1beta1-APIs basieren auf ClusterClass. (v1alpha3 ist eine Abstraktionsschicht auf ClusterClass.)
- Aktualisieren mehrerer Knotenpools während des parallelen Updates
-
Wenn Sie einen TKGS-Arbeitslastcluster aktualisieren, der mit mehreren Knotenpools bereitgestellt wird, unterscheidet sich das Modell für parallele Updates je nach verwendeter Version von vSphere.
vSphere TKGS-API Upgrade-Verhalten vSphere 7 TKGS v1alpha2-API Mehrere Knotenpools innerhalb desselben Clusters werden zur selben Zeit (gleichzeitig) aktualisiert vSphere 8 TKGS v1alpha3-API und v1beta1-API Mehrere Knotenpools innerhalb desselben Clusters werden nach einer logischen Reihenfolge (sequenziell) aktualisiert.
- Best Practice-Überlegungen
-
Die Bereitstellung eines vSphere 8-TKGS-Clusters mit mehreren identischen Knotenpools ist im Hinblick auf die Dimensionierung irrelevant. Knotenpools sollten für verschiedene Größen, VM-Klassen, TKr-Versionen usw. verwendet werden. Vermeiden Sie es, mehrere identische Knotenpools zu verwenden, um das System herauszufordern und Cluster schneller zu aktualisieren, da dies nicht funktioniert.
Mit Pod Disruption Budgets können Sie sicherstellen, dass Upgrades ausgeführte Anwendungen nicht beeinträchtigen. Dazu empfiehlt es sich, PodDisruptionBudgets für die Arbeitslasten festzulegen (siehe https://kubernetes.io/docs/tasks/run-application/configure-pdb/). Die Cluster-API berücksichtigt diese und beendet eine Maschine nicht, wenn die Schwellenwerte überschritten würden.
- Details zu parallelen Updates für vSphere 8 TKGS-Cluster
-
Während einer Aktualisierung der TKGS-Clusterversion auf vSphere 8:
- Die Knoten der Steuerungsebene werden zuerst aktualisiert. Anschließend werden Worker-Knoten beginnend mit dem Knotenpool „Zone-A“ nacheinander bereitgestellt. Wenn zwei Knotenpools verwendet werden, wird jeweils nur ein Worker bereitgestellt.
