Best Practices für Google Distributed Cloud-Clusterupgrades

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 befolgen sollten. Diese Best Practices helfen, die mit Clusterupgrades verbundenen Risiken zu reduzieren.

Wenn Sie mehrere Umgebungen wie test, development und production haben, empfehlen wir, mit der am wenigsten kritischen Umgebung, z. B. test, zu beginnen 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 durchführen. Mit diesem Ansatz 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

Damit der Upgradeprozess so reibungslos wie möglich verläuft, sollten Sie die folgenden Prüfungen prüfen und ausführen, 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.

Den Zeitaufwand schätzen und ein Wartungsfenster planen

Standardmäßig werden Upgrades für alle Knotenpools parallel durchgeführt, aber in jedem Knotenpool werden die Knoten sequenziell aktualisiert. 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, verwenden Sie 15 Minuten * die Anzahl der Knoten im größten Knotenpool. Wenn Sie beispielsweise 10 Knoten im größten Pool haben, beträgt die gesamte Upgradezeit 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 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 Google Distributed Cloud Version 1.8 und höher können Sie die automatische Sicherung mit clusterBackup.datastore in der Konfigurationsdatei des Administratorclusters einrichten. Zum Aktivieren dieses Features in einem vorhandenen Cluster bearbeiten Sie die Konfigurationsdatei des Administratorclusters, fügen das Feld clusterBackup.datastore hinzu und führen dann gkectl update admin aus.

Nachdem clusterBackup.datastore aktiviert wurde, wird Ihr Administratorcluster automatisch in etcd im konfigurierten vSphere-Datenspeicher gesichert. Dieser Sicherungsprozess wiederholt sich jedes Mal, wenn eine Änderung am Administratorcluster 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 kann PodDisruptionBudgets (PDBs) dazu beitragen, unerwünschte Anwendungsausfälle oder -ausfälle zu vermeiden. PDBs weisen den Planer an, immer eine Reihe von Pods auszuführen, während andere Pods ausfallen können. Dieses Verhalten ist eine nützliche Möglichkeit, für eine Anwendungsverfügbarkeit zu sorgen.

  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 vorherigen Tabelle gibt jedes PDB an, dass immer mindestens ein Pod verfügbar sein muss. Diese Verfügbarkeit wird bei Upgrades entscheidend, 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 ein Replikat enthält. In diesem Beispiel wird der Ausgleichsvorgang unterbrochen, da das PDB vom Ressourcencontroller nicht erfüllt werden kann.

Damit die PDBs den Upgradevorgang nicht beeinträchtigen, prüfen Sie vor dem Start des Upgrades alle PDBs in einem bestimmten Cluster. 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.

Google Distributed Cloud führt während des Upgrades eine Preflight-Prüfung durch, 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 überprüfen

Die folgenden Überlegungen zu IP-Adressen gelten bei Clusterupgrades:

  • Beim Clusterupgrade wird ein neuer Knoten erstellt und die Ressourcen werden entleert, bevor der alte Knoten gelöscht wird. Es empfiehlt sich, 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 sein.
  • Wenn Sie DHCP verwenden, müssen Sie dafür sorgen, 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üssen, 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 den Upgradeprozess des Nutzerclusters beschleunigen möchten, listen Sie genügend IP-Adressen in der IP-Blockdatei auf, damit jedem Knotenpool eine zusätzliche IP-Adresse zur Verfügung steht. Mit diesem Ansatz kann der Prozess das Hinzufügen und Entfernen von VMs beschleunigen, wenn es pro Knotenpool ausgeführt wird.
    • Obwohl sich dieser Ansatz gut eignet, um Nutzerclusterupgrades 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 im Cluster, der aktualisiert wird, genügend Ressourcen vorhanden sind, um das Upgrade zu verwalten. Um die aktuelle Ressourcennutzung des Clusters zu prüfen, können Sie benutzerdefinierte Dashboards in Google Cloud Observability verwenden oder mit Befehlen wie kubectl top nodes direkt auf dem Cluster ausführen.

Befehle, die Sie für den Cluster ausführen, zeigen einen Snapshot der aktuellen Nutzung der Clusterressourcen. Dashboards bieten eine detailliertere Ansicht der Ressourcen, die im Laufe der Zeit verbraucht werden. Anhand dieser Ressourcennutzungsdaten können Sie erkennen, wann ein Upgrade je nach ausgeführter Arbeitslast und Anwendungsfällen die geringste Störung verursachen würde, z. B. an Wochenenden oder Abenden.

Der Zeitpunkt für das Upgrade des Administratorclusters ist möglicherweise weniger wichtig als für die Nutzercluster, da ein Administratorclusterupgrade in der Regel keine Anwendungsausfallzeit zur Folge hat. Es ist jedoch weiterhin wichtig, in vSphere nach kostenlosen Ressourcen zu suchen, bevor Sie mit dem Upgrade eines Administratorclusters beginnen. Außerdem kann ein Upgrade des Administratorclusters ein gewisses Risiko mit sich bringen. Daher wird es möglicherweise zu Zeiten mit geringerer Aktivität empfohlen, in denen 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 in vCenter einen Cluster aus und prüfen Sie den Tab Summary (Zusammenfassung), um diese Ressourcennutzung zu prüfen.

Auf dem Tab „Summary“ (Zusammenfassung) wird der Gesamtspeicher-, CPU- und Speicherverbrauch des gesamten Clusters angezeigt. Da Google Distributed Cloud-Upgrades zusätzliche Ressourcen benötigen, 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

Angenommen, ein Nutzercluster hat 3 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 erfolgt, verbraucht das Upgrade-Verfahren die folgenden zusätzlichen Ressourcen für die drei zusätzlichen Surge-Knoten:

  • 24 vCPUs
  • 256 GB RAM
  • VM-Speicherplatz + 256 GB vSwap

Beim Upgradevorgang werden VMs mithilfe des vSphere-Klonvorgangs erstellt. Das Klonen mehrerer VMs aus einer Vorlage kann das zugrunde liegende Speichersystem in Form von zunehmenden E/A-Vorgängen belasten. Das Upgrade kann stark verlangsamt werden, wenn das zugrunde liegende Speichersubsystem während eines Upgrades keine ausreichende Leistung bereitstellen kann.

vSphere ist zwar für die gleichzeitige Ressourcennutzung ausgelegt und bietet Mechanismen zur Bereitstellung von Ressourcen, auch wenn ein Overcommit ausgeführt wird. Wir empfehlen jedoch dringend, kein Overcommit des VM-Arbeitsspeichers durchzuführen. Eine Überbelegung des Arbeitsspeichers kann zu schwerwiegenden Leistungseinbußen führen, die sich auf den gesamten Cluster auswirken, da vSphere den „fehlenden RAM“ für den Austausch von Seiten an den Datenspeicher bereitstellt. Dieses Verhalten kann beim Upgrade eines Clusters zu Problemen und Leistungseinbußen bei anderen VMs führen, die im vSphere-Cluster ausgeführt werden.

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.

Clusterzustand und -konfiguration prüfen

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

  • Mit dem Befehl gkectl diagnose (gkectl diagnose) wird sichergestellt, dass alle Cluster fehlerfrei sind. Der Befehl führt erweiterte Prüfungen aus, z. B. um Knoten zu identifizieren, die nicht richtig konfiguriert sind oder Pods enthalten, die sich nicht im Status befinden. 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.

  • Das Tool vor dem Upgrade: Zusätzlich zur Überprüfung des Clusterzustands und der Konfiguration prüft das Tool vor dem Upgrade auf potenzielle bekannte Probleme, die während eines Clusterupgrades auftreten können.

Wenn Sie Nutzercluster auf 1.29 und höher aktualisieren, empfehlen wir außerdem, den Befehl gkectl upgrade cluster mit dem Flag --dry-run auszuführen. Das Flag --dry-run führt Preflight-Prüfungen aus, startet aber nicht den Upgradeprozess. Obwohl frühere Versionen von Google Distributed Cloud Preflight-Prüfungen ausführen, können sie nicht separat vom Upgrade ausgeführt werden. Durch Hinzufügen des Flags --dry-run können Sie alle Probleme finden und beheben, die die Preflight-Prüfungen vor dem Upgrade in Ihrem Nutzercluster feststellen.

Mit Deployments Anwendungsunterbrechungen minimieren

Da Knoten während Updates per Drain beendet werden müssen, können Clusterupgrades zu Anwendungsunterbrechungen führen. Das Draining 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. Die Auswirkungen auf Bereitstellungen mit mehreren Replikaten sollten minimal sein. Sie können Ihren Cluster trotzdem aktualisieren, wenn Anwendungen Deployments nicht verwenden.

Es gibt auch 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 deren Pods aus irgendeinem Grund neu geplant werden müssen, z. B. für Upgrades oder Wartungen auf den Clusterknoten. Sie sollten diese vor einem Upgrade unbedingt prüfen.

Load-Balancer-Paar für Hochverfügbarkeit verwenden

Wenn Sie Seesaw als Load-Balancer in einem Cluster verwenden, wird beim Upgrade des Clusters automatisch ein Upgrade der Load-Balancer durchgeführt. Dieses Upgrade kann zu einer Dienstunterbrechung führen. Sie können ein Hochverfügbarkeitspaar (Hochverfügbarkeitspaar) verwenden, um die Auswirkungen eines Upgrades und eines möglichen Ausfalls des Load-Balancers zu reduzieren. In dieser Konfiguration erstellt und konfiguriert das System zwei Load-Balancer-VMs, sodass ein Failover auf den anderen Peer erfolgen kann.

Wir empfehlen, immer ein HA-Paar vor dem Administratorcluster zu verwenden, um die Dienstverfügbarkeit zu erhöhen (d. h. auf dem Kubernetes API-Server). 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 die neue Load-Balancer-VM erstellt wird. 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.

Wenn auch der Nutzercluster selbst für Hochverfügbarkeit konfiguriert ist, sollten Sie ein HA-Load-Balancer-Paar verwenden. In dieser Best-Practices-Serie 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 Clusterupgrades aktualisiert.

Entscheiden Sie, wie die einzelnen Nutzercluster aktualisiert werden sollen

In Version 1.14 und höher können Sie einen Nutzercluster insgesamt upgraden (d. h. Sie können die Steuerungsebene und alle Knotenpools im Cluster aktualisieren) oder die Steuerungsebene des Nutzerclusters aktualisieren und die Knotenpools in der aktuellen Version belassen. Informationen dazu, warum Sie die Steuerungsebene separat aktualisieren sollten, finden Sie unter Upgrades von Nutzerclustern.

Verfolgen Sie in einer Multi-Cluster-Umgebung, welche Nutzercluster aktualisiert wurden, und notieren Sie ihre Versionsnummer. Wenn Sie die Steuerungsebene und die Knotenpools separat upgraden möchten, notieren Sie 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_KUBECONFIG durch 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

Für Cluster, die bei der GKE On-Prem API registriert sind, können Sie über die gcloud CLI die Versionen von Nutzerclustern, Knotenpools auf dem Nutzercluster und Administratorcluster abrufen.

  1. Prüfen Sie, ob Sie die neueste Version der gcloud CLI haben. Aktualisieren Sie bei Bedarf die Komponenten der gcloud CLI:

    gcloud components update

  2. Führen Sie die folgenden Befehle aus, um 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 Ihres Flotten-Hostprojekts.

    Wenn Sie --location=- festlegen, werden alle Cluster in allen Regionen aufgelistet. Wenn Sie einen Bereich in der Liste nach unten verschieben müssen, legen Sie für --location die Region fest, die Sie bei der Registrierung des Clusters 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=-

Prüfen Sie die Version der Clusterknoten:

Sie können kubectl verwenden, um die Version der Clusterknoten abzurufen, aber kubectl gibt die Kubernetes-Version zurück. Die entsprechende Version von Google Distributed Cloud für eine Kubernetes-Version finden Sie im Versionsverlauf.

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, CA-Zertifikate jedoch nicht. Sie müssen Ihre CA-Zertifikate mindestens einmal alle fünf Jahre manuell rotieren. Weitere Informationen finden Sie unter Nutzercluster-Zertifizierungsstellen rotieren und CA-Zertifikate von Administratorclustern rotieren.

Unterschiede zwischen Clustertypen

Es gibt zwei verschiedene Clustertypen:

  • Nutzercluster
  • Administratorcluster

Je nachdem, wie Sie einen Nutzercluster erstellen, kann er sowohl Worker-Knoten als auch Knoten der Steuerungsebene (Steuerungsebene V2) oder nur Worker-Knoten (kubeception) enthalten. Mit 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 getrennt von den Knotenpools aktualisieren, auf denen Ihre Arbeitslasten ausgeführt werden.

Unterschiedliche Auswirkungen von Upgrades von Nutzerclustern im Vergleich zu Administratorclustern

Das Google Distributed Cloud-Upgradeverfahren umfasst einen Knotenausgleichsprozess, 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 wird jede auf diesen Knoten ausgeführte Arbeitslast beendet und auf anderen verfügbaren Knoten im Cluster neu gestartet.

Je nach ausgewählter Architektur der Arbeitslast kann sich dieser Vorgang auf die Verfügbarkeit einer Anwendung auswirken. Damit die Ressourcenfähigkeiten des Clusters nicht zu stark beansprucht werden, führt Google Distributed Cloud ein Upgrade nach dem anderen Knoten aus.

Störung des Nutzerclusters

In der folgenden Tabelle werden die Auswirkungen eines direkten Nutzerclusterupgrades beschrieben:

Funktion Administratorcluster Nutzercluster ohne Hochverfügbarkeit Hochverfügbarkeits-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-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: Eine Dienstunterbrechung während des Upgrades ist spürbar, bis das Upgrade abgeschlossen ist.
  • Nicht betroffen: Eine Dienstunterbrechung kann innerhalb kurzer Zeit auftreten, ist aber nahezu unbemerkt zu sehen.

Die Knoten der Steuerungsebene des Nutzerclusters führen keine Nutzerarbeitslasten aus, unabhängig davon, ob sie im Administratorcluster (kubeception) oder im Nutzercluster selbst (Steuerungsebene V2) ausgeführt werden. Bei einem Upgrade werden diese Knoten der Steuerungsebene per Drain beendet und dann entsprechend aktualisiert.

In Umgebungen mit Steuerungsebenen für Hochverfügbarkeit werden Nutzerarbeitslasten durch ein Upgrade der Steuerungsebene eines Nutzerclusters nicht unterbrochen. In einer Hochverfügbarkeitsumgebung werden Nutzerarbeitslasten durch ein Upgrade eines Administratorclusters nicht unterbrochen. Bei Nutzerclustern, die Steuerungsebene V2 verwenden, werden Nutzerarbeitslasten durch ein Upgrade nur der Steuerungsebene nicht unterbrochen.

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

Zur Verbesserung der Verfügbarkeit und Reduzierung von Störungen der Nutzercluster in der Produktionsumgebung während Upgrades empfehlen wir die Verwendung von drei Knoten der Steuerungsebene (Hochverfügbarkeitsmodus).

Störung des Administratorclusters

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

Funktion Administratorcluster Nutzercluster ohne Hochverfügbarkeit Hochverfügbarkeits-Nutzercluster
Kubernetes API-Zugriff Betroffen Betroffen Nicht betroffen
Nutzerarbeitslasten Nicht betroffen Nicht 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: Eine Dienstunterbrechung während des Upgrades ist spürbar, bis das Upgrade abgeschlossen ist.
  • Nicht betroffen: Eine Dienstunterbrechung kann innerhalb kurzer Zeit auftreten, ist aber nahezu unbemerkt zu sehen.

Nächste Schritte