In diesem Dokument werden Best Practices und Überlegungen für das Upgrade von Google Distributed Cloud beschrieben. Sie erfahren, wie Sie sich auf Cluster-Upgrades 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, ist vorab eine sorgfältige Planung erforderlich, 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 Upgrade-Zeit 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 Cluster-Upgrade starten, wird vor dem Upgrade des Clusters eine Sicherungsaufgabe ausgeführt.
Wenn Sie Probleme haben, einen Administratorcluster aus der Sicherung wiederherzustellen, finden Sie weitere Informationen unter 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 hilfreich, um die Anwendungsverfügbarkeit zu gewährleisten.
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 Ihrer 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 wird für jedes 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-Freigaben 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 updateaus. Weitere Informationen finden Sie unter IP-Adressen planen.
- Wenn Sie IP-Adressen hinzufügen möchten, 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 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 der jeweilige Vorgang 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, sodass nur eine VM gleichzeitig aktualisiert werden kann, auch wenn mehrere Knotenpools verwendet werden.
Clusterauslastung prüfen
Achten Sie darauf, dass Pods evakuiert werden können, wenn der Knoten per Drain beendet 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 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 Cluster-Upgrade 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 E/A-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-Befehlgkectl diagnosewird 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 feststecken. Wenn beim Befehlgkectl diagnoseeineCluster unhealthy-Warnung angezeigt wird, beheben Sie die Probleme, bevor Sie ein Upgrade durchführen. 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 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 Nutzercluster-Upgrades.
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
gkectl
So prüfen Sie die Version von Nutzerclustern:
gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Ersetzen Sie
ADMIN_CLUSTER_KUBECONFIGdurch den Pfad der kubeconfig-Datei für Ihren Administratorcluster.So prüfen Sie die Version von Administratorclustern:
gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG
gcloud-CLI
Bei Clustern, die in der GKE On-Prem API registriert sind, können Sie mit der gcloud CLI die Versionen von Nutzerclustern, Knotenpools im Nutzercluster und Administratorclustern abrufen.
Prüfen Sie, ob Sie die neueste Version der gcloud CLI haben. Aktualisieren Sie bei Bedarf die gcloud CLI-Komponenten:
gcloud components updateFühren Sie die folgenden Befehle aus, um die Versionen zu prüfen:
So prüfen Sie die Version von Nutzerclustern:
gcloud container vmware clusters list \ --project=PROJECT_ID \ --location=-Ersetzen Sie
PROJECT_ID: die Projekt-ID des Flottenhostprojekts.Wenn Sie
--location=-festlegen, bedeutet dies, dass alle Cluster in allen Regionen aufgelistet werden. Wenn Sie den Bereich in der Liste verkleinern möchten, legen Sie--locationauf die Region fest, die Sie bei der Clusterregistrierung angegeben haben.Die Ausgabe des Befehls enthält die Clusterversion.
So prüfen Sie die Version von Administratorclustern:
gcloud container vmware admin-clusters list \ --project=PROJECT_ID \ --location=-
Version der Clusterknoten prüfen:
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:
| Funktion | Administratorcluster | Nicht-HA-Nutzercluster | HA-Nutzercluster |
|---|---|---|---|
| Kubernetes API-Zugriff | Nicht betroffen | Nicht betroffen | Nicht betroffen |
| Nutzerarbeitslasten | Nicht betroffen | Nicht betroffen | Nicht betroffen |
| PodDisruptionBudgets* | Nicht betroffen | Nicht betroffen | Nicht betroffen |
| Knoten der Steuerungsebene | Nicht betroffen | Betroffen | Nicht betroffen |
| Pod-Autoscaler (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 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:
| Funktion | Administratorcluster | Nicht-HA-Nutzercluster | HA-Nutzercluster |
|---|---|---|---|
| Kubernetes API-Zugriff | Betroffen | Betroffen | Nicht betroffen |
| Nutzerarbeitslasten | Nicht betroffen | Nicht betroffen | Nicht betroffen |
| Knoten der Steuerungsebene | Betroffen | Betroffen | Nicht betroffen |
| Pod-Autoscaler | Betroffen | Betroffen | Nicht betroffen |
| Kfz-Reparatur | Betroffen | Betroffen | Nicht betroffen |
| Autoscaling für Knoten | Betroffen | Betroffen | Nicht betroffen |
| Horizontales Pod-Autoscaling | Betroffen | Betroffen | Nicht betroffen |
- 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.