In diesem Dokument werden Best Practices und Überlegungen für das Upgrade von GKE on VMware beschrieben. Sie erfahren, wie Sie sich auf Clusterupgrades vorbereiten, und welche Best Practices Sie vor dem Upgrade beachten sollten. Diese Best Practices helfen, die mit Clusterupgrades einhergehenden Risiken zu reduzieren.
Wenn Sie mehrere Umgebungen haben, z. B. test, development und production, empfehlen wir, mit der am wenigsten kritischen Umgebung zu beginnen, z. B. test, und die Upgradefunktionalität zu prüfen. Nachdem Sie überprüft haben, ob das Upgrade erfolgreich war, fahren Sie mit der nächsten Umgebung fort. Wiederholen Sie diesen Vorgang, bis Sie ein Upgrade Ihrer Produktionsumgebungen ausführen. Auf diese Weise können Sie von einem kritischen Punkt zum nächsten wechseln und prüfen, ob das Upgrade und Ihre Arbeitslasten korrekt ausgeführt werden.
Checkliste für die Umstellung
Um den Upgradeprozess so reibungslos wie möglich zu gestalten, prüfen und führen Sie die folgenden Prüfungen durch, bevor Sie mit dem Upgrade Ihrer Cluster beginnen:
Upgrade planen
Updates können störend sein. Bevor Sie mit dem Upgrade beginnen, sollten Sie sorgfältig planen, ob Ihre Umgebung und Anwendungen bereit und vorbereitet sind.
Nutzer- und Administratorcluster sichern
Sichern Sie vor dem Upgrade Ihre Nutzer- und Administratorcluster.
Eine Nutzercluster-Sicherung ist ein Snapshot des etcd-Speichers des Nutzerclusters. Der etcd-Speicher enthält alle Kubernetes-Objekte und benutzerdefinierten Objekte, die zum Verwalten des Clusterstatus erforderlich sind. Der Snapshot enthält die Daten, die zum Neuerstellen der Komponenten und Arbeitslasten des Clusters erforderlich sind. Weitere Informationen finden Sie unter Nutzercluster sichern.
Mit GKE on VMware Version 1.8 und höher können Sie eine automatische Sicherung mit clusterBackup.datastore in der Konfigurationsdatei des Administratorclusters einrichten. Wenn Sie dieses Feature in einem vorhandenen Cluster aktivieren möchten, bearbeiten Sie die Konfigurationsdatei des Administratorclusters und fügen Sie das Feld clusterBackup.datastore hinzu. Führen Sie dann gkectl update admin aus.
Nachdem clusterBackup.datastore aktiviert wurde, wird Ihr Administratorcluster automatisch in etcd im konfigurierten vSphere-Datenspeicher gesichert. Dieser Sicherungsprozess wird jedes Mal wiederholt, wenn am Administratorcluster eine Änderung vorgenommen wird. Wenn Sie ein Clusterupgrade starten, wird vor dem Upgrade des Clusters eine Sicherungsaufgabe ausgeführt.
Informationen zum Wiederherstellen eines Administratorclusters aus seiner Sicherung bei Problemen finden Sie unter Administratorcluster mit gkectl sichern und wiederherstellen .
Nutzung von PodDisruptionBudgets prüfen
In Kubernetes können PodDisruptionBudgets (PDBs) dazu beitragen, unerwünschte Ausfallzeiten oder Ausfälle von Anwendungen zu verhindern. PDBs weisen den Planer an, immer eine Reihe von Pods auszuführen, während andere Pods ausfallen könnten. Dieses Verhalten ist nützlich, um die Verfügbarkeit der Anwendung sicherzustellen.
Mit dem Befehl
kubectl get pdbkönnen Sie prüfen, welche PDBs in Ihrem Cluster konfiguriert sind:kubectl get pdb -A --kubeconfig KUBECONFIGErsetzen Sie
KUBECONFIGdurch den Namen der kubeconfig-Datei.Die folgende Beispielausgabe zeigt PDBs mit den Namen
istio-ingress,istiodundkube-dns:NAMESPACE NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE gke-system istio-ingress 1 N/A 1 16d gke-system istiod 1 N/A 1 16d kube-system kube-dns 1 N/A 1 16d
In der obigen Tabelle gibt jedes PDB an, dass mindestens ein Pod immer verfügbar sein muss. Diese Verfügbarkeit wird bei Upgrades kritisch, wenn Knoten entleert werden.
Suchen Sie nach PDBs, die nicht erfüllt werden können. Sie können beispielsweise eine Mindestverfügbarkeit von 1 festlegen, wenn das Deployment nur 1 Replikat enthält. In diesem Beispiel wird der Draining-Vorgang unterbrochen, da das PDB vom Ressourcencontroller nicht erfüllt werden kann.
Damit die PDBs das Upgrade nicht beeinträchtigen, prüfen Sie alle PDBs in einem bestimmten Cluster, bevor Sie das Upgrade starten. Möglicherweise müssen Sie sich mit den Entwicklungsteams und Anwendungsinhabern abstimmen, um PDBs während eines Clusterupgrades vorübergehend zu ändern oder zu deaktivieren.
GKE on VMware führt während des Upgrades eine Preflight-Prüfung aus, um vor PDBs zu warnen. Sie sollten die PDBs jedoch auch manuell prüfen, um ein reibungsloses Upgrade zu gewährleisten. Weitere Informationen zu PDBs finden Sie unter Unterbrechungsbudget für Ihre Anwendung festlegen.
Verfügbare IP-Adressen prüfen
Die folgenden Überlegungen zu IP-Adressen gelten bei Clusterupgrades:
- Beim Clusterupgrade werden ein neuer Knoten erstellt und die Ressourcen entleert, bevor der alte Knoten gelöscht wird. Wir empfehlen, immer N+1-IP-Adressen für den Administrator- oder Nutzercluster zu haben, wobei N die Anzahl der Knoten im Cluster ist.
- Wenn Sie statische IP-Adressen verwenden, müssen die erforderlichen IP-Adressen in den IP-Blockdateien aufgeführt werden.
- Wenn Sie DHCP verwenden, müssen neue VMs während eines Upgrades zusätzliche IP-Freigaben im gewünschten Subnetz erhalten.
- Wenn Sie IP-Adressen hinzufügen müssen, aktualisieren Sie die IP-Blockdatei und führen Sie dann den Befehl
gkectl updateaus. Weitere Informationen finden Sie unter IP-Adressen planen.
- Wenn Sie IP-Adressen hinzufügen müssen, aktualisieren Sie die IP-Blockdatei und führen Sie dann den Befehl
- Wenn Sie statische IP-Adressen verwenden und das Upgrade des Nutzerclusters beschleunigen möchten, listen Sie genügend IP-Adressen in Ihrer IP-Blockdatei auf, damit für jeden Knotenpool eine zusätzliche IP-Adresse verfügbar ist. Mit diesem Ansatz kann der Prozess das Hinzufügen und Entfernen von VMs beschleunigen, da er pro Knotenpool ausgeführt wird.
- Obwohl dieser Ansatz eine gute Option ist, um Upgrades von Nutzerclustern zu beschleunigen, sollten Sie die Ressourcen- und Leistungsverfügbarkeit Ihrer vSphere-Umgebung berücksichtigen, bevor Sie fortfahren.
- Wenn nur eine freie IP-Adresse für den gesamten Nutzercluster vorhanden ist, verlangsamt diese Einschränkung den Upgradeprozess auf jeweils nur eine VM, selbst wenn mehrere Knotenpools verwendet werden.
Clusterauslastung prüfen
Achten Sie darauf, dass Pods evakuiert werden können, wenn der Knoten entleert wird, und dass in dem Cluster, der aktualisiert wird, genügend Ressourcen für das Upgrade vorhanden sind. Zur Prüfung der aktuellen Ressourcennutzung des Clusters können Sie benutzerdefinierte Dashboards in der Cloud Operations Suite oder direkt im Cluster mit Befehlen wie kubectl top nodes verwenden.
Befehle, die Sie für den Cluster ausführen, zeigen einen Snapshot der aktuellen Nutzung der Clusterressourcen. Dashboards bieten eine detailliertere Ansicht der im Laufe der Zeit verbrauchten Ressourcen. Diese Ressourcennutzungsdaten können Ihnen Aufschluss darüber geben, wann ein Upgrade die geringste Unterbrechung verursachen würde, z. B. an Wochenenden oder Abenden. Das ist abhängig von der ausgeführten Arbeitslast und den Anwendungsfällen.
Der Zeitpunkt für das Upgrade des Administratorclusters ist möglicherweise weniger kritisch als für die Nutzercluster, da ein Upgrade des Administratorclusters normalerweise nicht zu einer Anwendungsausfallzeit führt. Sie müssen jedoch trotzdem prüfen, ob freie Ressourcen in vSphere vorhanden sind, bevor Sie mit einem Upgrade des Administratorclusters beginnen. Außerdem kann ein Upgrade des Administratorclusters mit einem gewissen Risiko verbunden sein. Daher kann es empfohlen werden, in Zeiträumen mit weniger aktiver Nutzung zu arbeiten, wenn der Verwaltungszugriff auf den Cluster weniger kritisch ist.
Weitere Informationen finden Sie unter Welche Dienste sind von einem Clusterupgrade betroffen?.
vSphere-Auslastung prüfen
Prüfen Sie, ob in der zugrunde liegenden vSphere-Infrastruktur genügend Ressourcen vorhanden sind. Wählen Sie einen Cluster in vCenter aus und prüfen Sie den Tab Summary (Zusammenfassung), um diese Ressourcennutzung zu prüfen.
Auf dem Tab „Zusammenfassung“ werden der Arbeitsspeicher, die CPU und die Speichernutzung des gesamten Clusters insgesamt angezeigt. Da Upgrades für GKE on VMware zusätzliche Ressourcen erfordern, sollten Sie auch prüfen, ob der Cluster diese zusätzlichen Ressourcenanfragen verarbeiten kann.
Im Allgemeinen muss Ihr vSphere-Cluster die folgenden zusätzlichen Ressourcen unterstützen können:
- +1 VM pro Administratorclusterupgrade
- +1 VM pro Knotenpool und Nutzerclusterupgrade
Wenn Sie beispielsweise einen Nutzercluster mit 3 Knoten aktualisieren, bei denen jeder Knoten 8 vCPUs und mindestens 32 GB RAM hat, verbraucht das Upgradeverfahren die folgenden zusätzlichen Ressourcen:
- 24 vCPUs
- 256 GB RAM
- VM-Speicherplatz + 256 GB vSwap
Beim Upgradeprozess werden VMs mithilfe des vSphere-Klonvorgangs erstellt. Das Klonen mehrerer VMs aus einer Vorlage kann das zugrunde liegende Speichersystem in Form ansteigender E/A-Vorgänge belasten. Das Upgrade kann stark verlangsamt werden, wenn das zugrunde liegende Speichersubsystem während eines Upgrades nicht in der Lage ist, ausreichend Leistung bereitzustellen.
vSphere ist zwar auf die gleichzeitige Ressourcennutzung ausgelegt und verfügt über Mechanismen zur Bereitstellung von Ressourcen, selbst bei einem Overcommit wird dringend empfohlen, ein Overcommit des VM-Arbeitsspeichers nicht zu überschreiten. Ein Overcommit des Arbeitsspeichers kann zu schwerwiegenden Leistungseinbußen führen, die sich auf den gesamten Cluster auswirken, da vSphere den „fehlenden RAM“ bereitstellt, damit Seiten an den Datenspeicher ausgelagert werden. Dieses Verhalten kann während eines Upgrades eines Clusters zu Problemen führen und die Leistung anderer laufender VMs im vSphere-Cluster beeinträchtigen.
Wenn die verfügbaren Ressourcen bereits knapp sind, fahren Sie nicht benötigte VMs herunter, um diese zusätzlichen Anforderungen zu erfüllen und potenzielle Leistungseinbußen zu vermeiden.
Clusterprobleme diagnostizieren
Führen Sie gkectl diagnose im Cluster aus, um den Status eines Clusters vor einem Upgrade zu prüfen. Mit dem Befehl werden erweiterte Prüfungen ausgeführt, z. B. um Knoten zu identifizieren, die nicht ordnungsgemäß konfiguriert sind oder bei denen Pods hängen geblieben sind.
Mit dem Befehl gkectl upgrade werden Preflight-Prüfungen ausgeführt und der Upgradeprozess beendet, wenn diese Prüfungen nicht erfolgreich sind. Es empfiehlt sich, diese Probleme proaktiv zu identifizieren und zu beheben, anstatt sich auf die Preflight-Prüfungen zu verlassen, die Cluster vor möglichen Schäden schützen. Da der Befehl gkectl diagnose mehr Prüfungen ausführt als die regulären Preflight-Prüfungen, sollten Sie diesen Befehl vor einem Upgrade manuell ausführen.
Wenn der Befehl gkectl diagnose eine Cluster unhealthy-Warnung anzeigt, beheben Sie die Probleme, bevor Sie ein Upgrade ausführen.
Weitere Informationen finden Sie unter Clusterprobleme diagnostizieren.
Minimieren von Anwendungsunterbrechungen mit Bereitstellungen
Da Knoten während Updates per Drain beendet werden müssen, können Clusterupgrades zu Anwendungsunterbrechungen führen. Das Leeren der Knoten bedeutet, dass alle ausgeführten Pods auf den verbleibenden Knoten im Cluster heruntergefahren und neu gestartet werden müssen.
Ihre Anwendungen sollten nach Möglichkeit Deployments verwenden. Bei diesem Ansatz sind Anwendungen auf Unterbrechungen ausgelegt. Auswirkungen auf Deployments mit mehreren Replikaten sollten minimal sein. Sie können den Cluster auch aktualisieren, wenn Anwendungen keine Deployments verwenden.
Außerdem gibt es Regeln für Deployments, die dafür sorgen, dass immer eine bestimmte Anzahl von Replikaten ausgeführt wird. Diese Regeln werden als PodDisruptionBudgets (PDBs) bezeichnet. Mit PDBs können Sie die Unterbrechung einer Arbeitslast begrenzen, wenn die zugehörigen Pods aus irgendeinem Grund neu geplant werden müssen, z. B. durch Upgrades oder Wartungen der Clusterknoten. Diese sollten vor einem Upgrade unbedingt geprüft werden.
Load-Balancer-Paar mit Hochverfügbarkeit verwenden
Wenn Sie Seesaw als Load-Balancer für einen Cluster verwenden, werden die Load-Balancer beim Upgrade des Clusters automatisch aktualisiert. Dieses Upgrade kann zu einer Dienstunterbrechung führen. Um die Auswirkungen eines Upgrades und eines letztendlichen Load-Balancer-Ausfalls zu reduzieren, können Sie ein Hochverfügbarkeitspaar (HA-Paar) verwenden. In dieser Konfiguration erstellt und konfiguriert das System zwei Load-Balancer-VMs, sodass ein Failover zum anderen Peer möglich ist.
Zum Erhöhen der Dienstverfügbarkeit (d. h. für den Kubernetes API-Server) empfehlen wir, immer ein HA-Paar vor dem Administratorcluster zu verwenden. Weitere Informationen zu Seesaw und seiner Hochverfügbarkeitskonfiguration finden Sie unter Gebündeltes Load-Balancing mit Seesaw.
Um eine Dienstunterbrechung während eines Upgrades mit einem Hochverfügbarkeitspaar zu vermeiden, initiiert der Cluster ein Failover, bevor er die neue Load-Balancer-VM erstellt. Wenn ein Nutzercluster nur eine einzige Load-Balancer-Instanz verwendet, kommt es zu einer Dienstunterbrechung, bis das Upgrade für den Load-Balancer abgeschlossen ist.
Wir empfehlen ein Paar eines Load-Balancers für Hochverfügbarkeit, wenn auch der Nutzercluster selbst für Hochverfügbarkeit konfiguriert ist. In dieser Best-Practices-Reihe wird davon ausgegangen, dass ein HA-Nutzercluster ein HA-Load-Balancer-Paar verwendet.
Wenn GKE on VMware Version 1.11 oder 1.12 MetalLB als gebündelten Load-Balancer verwendet, ist keine Einrichtung vor dem Upgrade erforderlich. Der Load-Balancer wird während des Clusterupgrades aktualisiert.
Upgradesequenz
Bei direkten Upgrades seit Version 1.7 muss immer eine bestimmte Upgradereihenfolge eingehalten werden:
- Führen Sie ein Upgrade der Administratorworkstation durch.
Führen Sie ein Upgrade der Nutzercluster nacheinander durch.
Wenn Sie nicht alle Nutzercluster upgraden möchten, können Sie den Administratorcluster nicht upgraden. Wenn Sie alle Nutzercluster upgraden, können Sie den Administratorcluster upgraden.
Führen Sie im letzten und optionalen Schritt ein Upgrade des Administratorclusters durch.
Unterschiede zwischen Clustertypen
Es gibt zwei verschiedene Clustertypen:
- Nutzercluster
- Administratorcluster
Wenn ein Nutzercluster erstellt wird, enthält er nur Worker-Knoten und keine Knoten der Steuerungsebene. Knoten der Steuerungsebene werden im Administratorcluster für alle angehängten Nutzercluster hinzugefügt oder erstellt. Mit diesem Ansatz können Upgrades von GKE on VMware unterschiedlich und flexibler verarbeitet werden, da Nutzerarbeitslasten und Knoten der Steuerungsebene getrennt sind.
Unterschiedliche Auswirkungen von Nutzercluster- und Administratorclusterupgrades
Das Upgradeverfahren für GKE on VMware umfasst einen Knotenausgleich, bei dem alle Pods aus einem Knoten entfernt werden. Bei diesem Vorgang wird für jeden per Drain beendeten Worker eine neue VM erstellt und dem Cluster hinzugefügt. Die per Drain beendeten Worker werden dann aus dem VMware-Inventar entfernt. Während dieses Vorgangs wird jede Arbeitslast, die auf diesen Knoten ausgeführt wird, beendet und auf anderen verfügbaren Knoten im Cluster neu gestartet.
Abhängig von der gewählten Architektur der Arbeitslast kann sich dieses Verfahren auf die Verfügbarkeit einer Anwendung auswirken. Damit die Ressourcenfähigkeiten des Clusters nicht zu stark belastet werden, führt GKE on VMware ein Upgrade für jeden Knoten einzeln durch.
Störung des Nutzerclusters
In der folgenden Tabelle werden die Auswirkungen eines Upgrades eines direkten Nutzerclusters beschrieben:
| Funktion | Administratorcluster | Nutzercluster ohne Hochverfügbarkeit | Hochverfügbarkeits-Nutzercluster |
|---|---|---|---|
| Kubernetes API-Zugriff | Nicht betroffen | Nicht betroffen | Nicht betroffen |
| Nutzerarbeitslasten | – | Betroffen | Betroffen |
| PodDisruptionBudgets* | Nicht betroffen | Nicht betroffen | Nicht betroffen |
| Knoten der Steuerungsebene | Nicht betroffen | Betroffen | Nicht betroffen |
| Pod-Autoscaling (VMware) | Nicht betroffen | Nicht betroffen | Nicht betroffen |
| Automatische Reparatur | Nicht betroffen | Nicht betroffen | Nicht betroffen |
| Knoten-Autoscaling (VMware) | Nicht betroffen | Nicht betroffen | Nicht betroffen |
| Horizontales Pod-Autoscaling | Betroffen | Betroffen | Nicht betroffen |
- * : PDBs können dazu führen, dass das Upgrade fehlschlägt oder beendet wird.
- Betroffen: Während des Upgrades tritt eine Dienstunterbrechung auf, bis das Upgrade abgeschlossen ist.
- Nicht betroffen: Eine Dienstunterbrechung kann innerhalb sehr kurzer Zeit auftreten, ist aber nahezu unbemerkt.
Durch ein Upgrade des Administratorclusters werden die Arbeitslasten des Nutzerclusters nicht unterbrochen. Der Administratorcluster enthält nur Knoten der Nutzersteuerungsebene, auf denen keine Nutzerarbeitslasten ausgeführt werden. Während des Upgrades werden diese Knoten der Steuerungsebene per Drain beendet und dann entsprechend aktualisiert.
Um die Verfügbarkeit zu verbessern und Unterbrechungen von Nutzerclustern in der Produktionsumgebung während Upgrades zu reduzieren, empfehlen wir die Verwendung von drei Knoten der Steuerungsebene (Hochverfügbarkeitsmodus).
Unterbrechung des Administratorclusters
In der folgenden Tabelle werden die Auswirkungen eines Upgrades eines direkten Administratorclusters beschrieben:
| Funktion | Administratorcluster | Nutzercluster ohne Hochverfügbarkeit | Hochverfügbarkeits-Nutzercluster |
|---|---|---|---|
| Kubernetes API-Zugriff | Betroffen | Betroffen | Nicht betroffen |
| Nutzerarbeitslasten | – | Nicht betroffen | Nicht betroffen |
| PodDisruptionBudgets | Betroffen | Betroffen | Nicht betroffen |
| Knoten der Steuerungsebene | Betroffen | Betroffen | Nicht betroffen |
| Pod-Autoscaling | Betroffen | Betroffen | Nicht betroffen |
| Automatische Reparatur | Betroffen | Betroffen | Nicht betroffen |
| Knoten-Autoscaling | Betroffen | Betroffen | Nicht betroffen |
| Horizontales Pod-Autoscaling | Betroffen | Betroffen | Nicht betroffen |
- Betroffen: Während des Upgrades tritt eine Dienstunterbrechung auf, bis das Upgrade abgeschlossen ist.
- Nicht betroffen: Eine Dienstunterbrechung kann innerhalb sehr kurzer Zeit auftreten, ist aber nahezu unbemerkt.