Best Practices für Cluster-Upgrades in der Google Distributed Cloud

In diesem Dokument werden Best Practices und Überlegungen für das Upgrade von Google Distributed Cloud beschrieben. Sie erfahren, wie Sie sich auf Clusterupgrades vorbereiten und welche Best Practices Sie vor dem Upgrade beachten sollten. Mit diesen Best Practices lassen sich die mit Cluster-Upgrades verbundenen Risiken reduzieren.

Wenn Sie mehrere Umgebungen wie Test, Entwicklung und Produktion haben, empfehlen wir Ihnen, mit der am wenigsten kritischen Umgebung zu beginnen, z. B. Test, und die Funktion des Upgrades zu prüfen. Nachdem Sie bestätigt haben, dass das Upgrade erfolgreich war, fahren Sie mit der nächsten Umgebung fort. Wiederholen Sie diesen Vorgang, bis Sie Ihre Produktionsumgebungen aktualisiert haben. So können Sie von einem kritischen Punkt zum nächsten übergehen und prüfen, ob das Upgrade und Ihre Arbeitslasten ordnungsgemäß ausgeführt werden.

Checkliste für Upgrades

Damit der Upgradevorgang möglichst reibungslos abläuft, sollten Sie die folgenden Prüfungen durchführen, bevor Sie mit dem Upgrade Ihrer Cluster beginnen:

Upgrade planen

Updates können zu Unterbrechungen führen. Bevor Sie mit dem Upgrade beginnen, sollten Sie sorgfältig planen, damit Ihre Umgebung und Anwendungen bereit sind.

Zeitaufwand schätzen und Wartungsfenster planen

Standardmäßig werden alle Knotenpools parallel aktualisiert, innerhalb der einzelnen Knotenpools jedoch nacheinander. Die Gesamtzeit für ein Upgrade hängt also von der Anzahl der Knoten im größten Knotenpool ab. Um eine grobe Schätzung für die Upgradezeit zu berechnen, multiplizieren Sie 15 Minuten mit der Anzahl der Knoten im größten Knotenpool. Wenn Sie beispielsweise 10 Knoten im größten Pool haben, beträgt die Gesamtzeit für das Upgrade etwa 150 Minuten.

Ab Version 1.28 können Sie ein Upgrade beschleunigen, indem Sie den Wert von maxSurge für einzelne Knotenpools festlegen.

Nutzer- und Administratorcluster sichern

Sichern Sie Ihre Nutzer- und Administratorcluster, bevor Sie mit dem Upgrade beginnen.

Eine Nutzercluster-Sicherung ist ein Snapshot des etcd-Speichers des Nutzerclusters. Der etcd-Speicher enthält alle zum Verwalten des Clusterstatus erforderlichen Kubernetes-Objekte und benutzerdefinierten Objekte. Der Snapshot enthält die Daten, die zum Neuerstellen der Komponenten und Arbeitslasten des Clusters erforderlich sind. Weitere Informationen finden Sie unter Nutzercluster sichern.

Ab Google Distributed Cloud-Version 1.8 können Sie automatische Sicherungen mit clusterBackup.datastore in der Konfigurationsdatei des Administratorclusters einrichten. Wenn Sie diese Funktion in einem vorhandenen Cluster aktivieren möchten, bearbeiten Sie die Konfigurationsdatei des Administratorclusters, fügen Sie das Feld clusterBackup.datastore hinzu und 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 Sicherungsvorgang wird jedes Mal wiederholt, wenn sich der Administratorcluster ändert. Wenn Sie ein Clusterupgrade starten, wird vor dem Upgrade des Clusters eine Sicherungsaufgabe ausgeführt.

Wenn Sie Probleme haben, einen Administratorcluster aus der Sicherung wiederherzustellen, lesen Sie den Hilfeartikel Administratorcluster mit gkectl sichern und wiederherstellen.

Nutzung von PodDisruptionBudgets prüfen

In Kubernetes können PodDisruptionBudgets (PDBs) dazu beitragen, unerwünschte Anwendungsausfälle zu vermeiden. Mit PDBs wird der Scheduler angewiesen, immer eine bestimmte Anzahl von Pods auszuführen, während andere Pods möglicherweise ausfallen. Dieses Verhalten ist eine nützliche Möglichkeit, die Anwendungsverfügbarkeit zu gewährleisten.

1. Mit dem Befehl kubectl get pdb können Sie prüfen, welche PDBs in Ihrem Cluster konfiguriert sind:

   kubectl get pdb -A --kubeconfig KUBECONFIG
   

   Ersetzen Sie KUBECONFIG durch den Namen Ihrer kubeconfig-Datei.

   Die folgende Beispielausgabe zeigt PDBs mit den Namen istio-ingress, istiod und kube-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 wird für jeden PDB angegeben, dass immer mindestens ein Pod verfügbar sein muss. Diese Verfügbarkeit wird während Upgrades kritisch, wenn Knoten per Drain beendet werden.

Prüfen Sie, ob es PDBs gibt, die nicht erfüllt werden können. Sie können beispielsweise eine Mindestverfügbarkeit von 1 festlegen, wenn das Deployment nur ein Replikat enthält. In diesem Beispiel wird der Vorgang zum Beenden per Drain unterbrochen, weil der Ressourcencontroller das PDB nicht erfüllen kann.

Prüfen Sie vor dem Upgrade alle PDBs in einem bestimmten Cluster, damit sie das Upgrade nicht beeinträchtigen. Möglicherweise müssen Sie sich mit den Entwicklungsteams und den Anwendungseigentümern abstimmen, um PDBs während eines Cluster-Upgrades vorübergehend zu ändern oder zu deaktivieren.

Google Distributed Cloud führt während des Upgrades eine Preflight-Prüfung durch, um Sie in Bezug auf PDBs zu warnen. Sie sollten die PDBs jedoch auch manuell prüfen, um ein reibungsloses Upgrade zu ermöglichen. Weitere Informationen zu PDBs finden Sie unter Unterbrechungsbudget für Ihre Anwendung festlegen.

Verfügbare IP-Adressen prüfen

Bei Cluster-Upgrades sind die folgenden Aspekte in Bezug auf IP-Adressen zu beachten:

• Beim Cluster-Upgrade wird ein neuer Knoten erstellt und die Ressourcen werden per Drain beendet, bevor der alte Knoten gelöscht wird. Wir empfehlen, für den Administrator- oder Nutzercluster immer N + 1 IP-Adressen zu verwenden, wobei N die Anzahl der Knoten im Cluster ist.
• Bei Verwendung statischer IP-Adressen müssen die erforderlichen IP-Adressen in den IP-Blockdateien aufgeführt sein.
• Wenn Sie DHCP verwenden, achten Sie darauf, dass neue VMs während eines Upgrades zusätzliche IP-Leases im gewünschten Subnetz erhalten können.
  • Wenn Sie IP-Adressen hinzufügen möchten, aktualisieren Sie die IP-Blockdatei und führen Sie dann den Befehl gkectl update aus. Weitere Informationen finden Sie unter IP-Adressen planen.
• Wenn Sie statische IP-Adressen verwenden und das Upgrade des Nutzerclusters beschleunigen möchten, listen Sie in Ihrer IP-Blockdatei genügend IP-Adressen auf, damit für jeden Knotenpool eine zusätzliche IP-Adresse verfügbar ist. Mit diesem Ansatz lässt sich das Hinzufügen und Entfernen von VMs beschleunigen, da es pro Knotenpool ausgeführt wird.
  • Dieser Ansatz ist zwar eine gute Möglichkeit, Nutzercluster-Upgrades zu beschleunigen, aber Sie sollten die Ressourcen- und Leistungsverfügbarkeit Ihrer vSphere-Umgebung berücksichtigen, bevor Sie fortfahren.
• Wenn es nur eine Ersatz-IP für den gesamten Nutzercluster gibt, verlangsamt diese Einschränkung das Upgrade auf nur eine VM gleichzeitig, auch wenn mehrere Knotenpools verwendet werden.

Clusterauslastung prüfen

Achten Sie darauf, dass Pods evakuiert werden können, wenn der Knoten überlastet ist, und dass im Cluster, der aktualisiert wird, genügend Ressourcen vorhanden sind, um das Upgrade zu verwalten. Sie können die aktuelle Ressourcennutzung des Clusters mithilfe benutzerdefinierter Dashboards in Google Cloud Observability oder direkt im Cluster mit Befehlen wie kubectl top nodes prüfen.

Befehle, die Sie für den Cluster ausführen, zeigen einen Snapshot der aktuellen Clusterressourcennutzung an. Dashboards können eine detailliertere Übersicht über die im Laufe der Zeit verbrauchten Ressourcen bieten. Anhand dieser Daten zur Ressourcennutzung lässt sich ermitteln, wann ein Upgrade die geringsten Unterbrechungen verursacht, z. B. an Wochenenden oder abends, je nach laufender Arbeitslast und 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 in der Regel keine Anwendungsausfallzeiten verursacht. Es ist jedoch wichtig, in vSphere nach freien Ressourcen zu suchen, bevor Sie mit dem Upgrade eines Administratorclusters beginnen. Außerdem kann das Upgrade des Administratorclusters ein gewisses Risiko bergen. Daher wird es empfohlen, es in Zeiten mit geringerer Nutzung durchzuführen, wenn der Verwaltungszugriff auf den Cluster weniger kritisch ist.

Weitere Informationen finden Sie unter Welche Dienste sind von einem Clusterupgrade betroffen?

vSphere-Nutzung prüfen

Prüfen Sie, ob in der zugrunde liegenden vSphere-Infrastruktur genügend Ressourcen vorhanden sind. Um diese Ressourcennutzung zu prüfen, wählen Sie in vCenter einen Cluster aus und sehen Sie sich den Tab Zusammenfassung an.

Auf dem Tab „Zusammenfassung“ sehen Sie den Arbeitsspeicher-, CPU- und Speicherverbrauch des gesamten Clusters. Da Google Distributed Cloud-Upgrades zusätzliche Ressourcen erfordern, sollten Sie auch prüfen, ob der Cluster diese zusätzlichen Ressourcenanfragen bewältigen kann.

Im Allgemeinen muss Ihr vSphere-Cluster die folgenden zusätzlichen Ressourcen unterstützen:

• + 1 VM pro Administratorcluster-Upgrade
• + 1 VM pro Knotenpool pro Nutzercluster-Upgrade

Angenommen, ein Nutzercluster hat drei Knotenpools, wobei jeder Knotenpool Knoten mit 8 vCPUs und mindestens 32 GB RAM hat. Da das Upgrade standardmäßig parallel für die drei Knotenpools durchgeführt wird, werden für die drei zusätzlichen Surge-Knoten die folgenden zusätzlichen Ressourcen verbraucht:

• 24 vCPUs
• 256 GB RAM
• Laufwerksspeicher der VM + 256 GB vSwap

Beim Upgrade werden VMs mithilfe des vSphere-Klonvorgangs erstellt. Wenn Sie mehrere VMs aus einer Vorlage klonen, kann das zugrunde liegende Speichersystem durch steigende I/O-Vorgänge belastet werden. Das Upgrade kann sich erheblich verlangsamen, wenn das zugrunde liegende Speichersubsystem während eines Upgrades nicht genügend Leistung bietet.

vSphere ist zwar für die gleichzeitige Ressourcennutzung konzipiert und verfügt über Mechanismen zur Bereitstellung von Ressourcen, auch wenn ein Overcommit vorliegt. Wir empfehlen jedoch dringend, Overcommits im VM-Speicher zu vermeiden. Ein Overcommit des Arbeitsspeichers kann zu erheblichen Leistungseinbußen führen, die sich auf den gesamten Cluster auswirken, da vSphere den „fehlenden RAM“ durch Auslagern von Seiten in den Datenspeicher bereitstellt. Dieses Verhalten kann zu Problemen beim Upgrade eines Clusters und zu Leistungseinbußen bei anderen laufenden VMs im vSphere-Cluster führen.

Wenn die verfügbaren Ressourcen bereits knapp sind, fahren Sie nicht benötigte VMs herunter, um diese zusätzlichen Anforderungen zu erfüllen und einen potenziellen Leistungseinbruch zu verhindern.

Clusterstatus und ‑konfiguration prüfen

Führen Sie vor dem Upgrade die folgenden Tools auf allen Clustern aus:

• Mit dem gkectl diagnose-Befehl gkectl diagnose wird sichergestellt, dass alle Cluster fehlerfrei arbeiten. Der Befehl führt erweiterte Prüfungen durch, z. B. um Knoten zu identifizieren, die nicht richtig konfiguriert sind, oder Pods, die sich in einem angehaltenen Zustand befinden. Wenn beim Befehl gkectl diagnose eine Cluster unhealthy-Warnung angezeigt wird, beheben Sie die Probleme, bevor Sie ein Upgrade versuchen. Weitere Informationen finden Sie unter Clusterprobleme diagnostizieren.

• Pre-Upgrade-Tool: Neben der Prüfung des Clusterstatus und der Clusterkonfiguration prüft das Pre-Upgrade-Tool auch mögliche bekannte Probleme, die während eines Cluster-Upgrades auftreten können.

Wenn Sie Nutzercluster auf Version 1.29 oder höher aktualisieren, empfehlen wir außerdem, den Befehl gkectl upgrade cluster mit dem Flag --dry-run auszuführen. Mit dem Flag --dry-run werden Preflight-Prüfungen ausgeführt, aber der Upgrade-Vorgang wird nicht gestartet. In früheren Versionen von Google Distributed Cloud werden zwar Preflight-Prüfungen ausgeführt, diese können jedoch nicht unabhängig vom Upgrade ausgeführt werden. Wenn Sie das Flag --dry-run hinzufügen, können Sie alle Probleme ermitteln und beheben, die bei den Preflight-Prüfungen mit Ihrem Nutzercluster vor dem Upgrade festgestellt werden.

Deployments verwenden, um Anwendungsunterbrechungen zu minimieren

Da Knoten während der Updates per Drain beendet werden müssen, können Cluster-Upgrades zu Anwendungsunterbrechungen führen. Wenn Sie die Knoten per Drain beenden, müssen alle laufenden Pods auf den verbleibenden Knoten im Cluster heruntergefahren und neu gestartet werden.

Verwenden Sie nach Möglichkeit Deployments für Ihre Anwendungen. Bei diesem Ansatz sind Anwendungen so konzipiert, dass sie Unterbrechungen verarbeiten können. Bei Deployments mit mehreren Replikaten sollten die Auswirkungen minimal sein. Sie können Ihren Cluster auch aktualisieren, wenn Anwendungen keine Deployments verwenden.

Es gibt auch Regeln für Deployments, mit denen dafür gesorgt wird, dass immer eine festgelegte Anzahl von Replikaten ausgeführt wird. Diese Regeln werden als PodDisruptionBudgets (PDBs) bezeichnet. Mit PDBs können Sie Unterbrechungen für eine Arbeitslast begrenzen, wenn ihre Pods aus irgendeinem Grund neu geplant werden müssen, z. B. aufgrund von Upgrades oder Wartungsarbeiten an den Clusterknoten. Sie sollten vor einem Upgrade geprüft werden.

Load Balancer-Paar mit Hochverfügbarkeit verwenden

Wenn Sie Seesaw als Load Balancer in einem Cluster verwenden, werden die Load Balancer automatisch aktualisiert, wenn Sie den Cluster aktualisieren. Dieses Upgrade kann zu einer Dienstunterbrechung führen. Um die Auswirkungen eines Upgrades und eines möglichen Load Balancer-Ausfalls zu verringern, können Sie ein Hochverfügbarkeitspaar (HA-Paar) verwenden. Bei dieser Konfiguration erstellt und konfiguriert das System zwei Load Balancer-VMs, damit ein Failover zum anderen Peer erfolgen kann.

Um die Dienstverfügbarkeit (d. h. für den Kubernetes API-Server) zu erhöhen, empfehlen wir, immer ein HA-Paar vor dem Administratorcluster zu verwenden. Weitere Informationen zu Seesaw und seiner HA-Konfiguration finden Sie unter Gebündeltes Load Balancing mit Seesaw.

Um eine Dienstunterbrechung während eines Upgrades mit einem HA-Paar zu vermeiden, initiiert der Cluster ein Failover, bevor die neue Load Balancer-VM erstellt wird. Wenn in einem Nutzercluster nur eine Load Balancer-Instanz verwendet wird, kommt es zu einer Dienstunterbrechung, bis das Upgrade für den Load Balancer abgeschlossen ist.

Wir empfehlen ein HA-Load Balancer-Paar, wenn der Nutzercluster selbst auch für Hochverfügbarkeit konfiguriert ist. In dieser Reihe von Best Practices wird davon ausgegangen, dass ein HA-Nutzercluster ein HA-Load Balancer-Paar verwendet.

Wenn Sie MetalLB als gebündelten Load Balancer verwenden, ist keine Einrichtung vor dem Upgrade erforderlich. Der Load Balancer wird während des Cluster-Upgrades aktualisiert.

Festlegen, wie die einzelnen Nutzercluster aktualisiert werden

In Version 1.14 und höher können Sie einen Nutzercluster als Ganzes aktualisieren, d. h. die Steuerungsebene und alle Knotenpools im Cluster. Sie können auch nur die Steuerungsebene des Nutzerclusters aktualisieren und die Knotenpools bei der aktuellen Version belassen. Informationen dazu, warum Sie die Steuerungsebene separat aktualisieren sollten, finden Sie unter Upgrades für Nutzercluster.

In einer Multi-Cluster-Umgebung sollten Sie im Blick behalten, welche Nutzercluster aktualisiert wurden, und deren Versionsnummer notieren. Wenn Sie die Steuerungsebene und die Knotenpools separat aktualisieren möchten, notieren Sie sich die Version der Steuerungsebene und jedes Knotenpools in jedem Cluster.

Versionen von Nutzer- und Administratorclustern prüfen

Prüfen Sie die Version der Clusterknoten:

Mit kubectl können Sie die Version der Clusterknoten abrufen, mit kubectl wird jedoch die Kubernetes-Version zurückgegeben. Informationen zur entsprechenden Google Distributed Cloud-Version für eine Kubernetes-Version finden Sie unter Versionsverwaltung.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei für Ihren Nutzercluster.

Prüfen, ob CA-Zertifikate rotiert werden müssen

Während eines Upgrades werden untergeordnete Zertifikate rotiert, aber keine CA-Zertifikate. Sie müssen Ihre CA-Zertifikate mindestens alle fünf Jahre manuell rotieren. Weitere Informationen finden Sie unter Zertifizierungsstellen für Nutzercluster rotieren und CA-Zertifikate von Administratorclustern rotieren.

Unterschiede zwischen Clustertypen

Es gibt zwei unterschiedliche Typen von Clustern:

• Nutzercluster
• Administratorcluster

Je nachdem, wie Sie einen Nutzercluster erstellen, kann er sowohl Worker-Knoten als auch Knoten der Steuerungsebene (Controlplane V2) oder nur Worker-Knoten (kubeception) enthalten. Bei kubeception wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten in einem Administratorcluster ausgeführt. In beiden Fällen können Sie in Version 1.14 und höher die Steuerungsebene eines Nutzerclusters separat von den Knotenpools aktualisieren, in denen Ihre Arbeitslasten ausgeführt werden.

Unterschiedliche Auswirkungen von Nutzercluster- und Administratorcluster-Upgrades

Das Upgrade von Google Distributed Cloud umfasst einen Knoten-Beendigungsprozess, bei dem alle Pods von einem Knoten entfernt werden. Dabei wird für jeden per Drain beendeten Worker-Knoten eine neue VM erstellt und dem Cluster hinzugefügt. Die per Drain beendeten Worker-Knoten werden dann aus dem VMware-Inventar entfernt. Während dieses Vorgangs werden alle Arbeitslasten, die auf diesen Knoten ausgeführt werden, beendet und auf anderen verfügbaren Knoten im Cluster neu gestartet.

Je nach gewählter Architektur der Arbeitslast kann sich dieser Vorgang auf die Verfügbarkeit einer Anwendung auswirken. Um eine zu starke Belastung der Ressourcen des Clusters zu vermeiden, führt Google Distributed Cloud die Upgrades jeweils nur an einem Knoten durch.

Störung im Nutzercluster

In der folgenden Tabelle werden die Auswirkungen eines direkten Upgrades eines Nutzerclusters beschrieben:

• * : PDBs können dazu führen, dass das Upgrade fehlschlägt oder angehalten wird.
• Betroffen: Während des Upgrades kommt es zu einer Dienstunterbrechung, die bis zum Abschluss des Upgrades wahrnehmbar ist.
• Nicht betroffen: Es kann zu einer kurzen Dienstunterbrechung kommen, die aber fast nicht wahrnehmbar ist.

Auf den Knoten der Nutzercluster-Steuerungsebene werden keine Nutzerarbeitslasten ausgeführt, unabhängig davon, ob sie im Administratorcluster (kubeception) oder im Nutzercluster selbst (Controlplane V2) ausgeführt werden. Während eines Upgrades werden diese Steuerungsebenenknoten per Drain beendet und dann entsprechend aktualisiert.

In Umgebungen mit Steuerungsebenen mit Hochverfügbarkeit (HA) kommt es durch das Upgrade der Steuerungsebene eines Nutzerclusters nicht zu Unterbrechungen der Nutzerarbeitslasten. In einer Hochverfügbarkeitsumgebung wirkt sich ein Upgrade eines Administratorclusters nicht auf Nutzerarbeitslasten aus. Bei Nutzerclustern mit Controlplane V2 kommt es nicht zu Unterbrechungen bei den Nutzerarbeitslasten, wenn nur die Steuerungsebene aktualisiert wird.

Während eines Upgrades in einer Umgebung ohne HA-Steuerungsebene kann die Steuerungsebene die Pod-Skalierung, Wiederherstellung oder Deployment-Aktionen nicht steuern. Während der kurzen Unterbrechung der Steuerungsebene im Laufe des Upgrades können Nutzerarbeitslasten betroffen sein, wenn sie sich in einem Skalierungs-, Deployment- oder Wiederherstellungsstatus befinden. Das bedeutet, dass Roll-outs während eines Upgrades in einer Umgebung ohne Hochverfügbarkeit fehlschlagen.

Um die Verfügbarkeit zu verbessern und Unterbrechungen von Produktionsnutzerclustern während Upgrades zu reduzieren, empfehlen wir die Verwendung von drei Knoten der Steuerungsebene (Hochverfügbarkeitsmodus).

Störung im Administratorcluster

In der folgenden Tabelle werden die Auswirkungen eines direkten Upgrades eines Administratorclusters beschrieben:

• Betroffen: Während des Upgrades kommt es zu einer Dienstunterbrechung, die bis zum Abschluss des Upgrades wahrnehmbar ist.
• Nicht betroffen: Es kann zu einer kurzen Dienstunterbrechung kommen, die aber fast nicht wahrnehmbar ist.

Nächste Schritte

• Anthos-Cluster auf VMware aktualisieren