Best Practices für GKE on VMware-Clusterupgrades

In diesem Dokument werden Best Practices und Überlegungen für das Upgrade von GKE on VMware beschrieben. Sie lernen, wie Sie sich auf Clusterupgrades vorbereiten, und welche Best Practices Sie vor dem Upgrade beachten sollten. Diese Best Practices helfen, die mit Clusterupgrades verbundenen Risiken zu reduzieren.

Wenn Sie mehrere Umgebungen haben, z. B. Test, Entwicklung und Produktion, empfehlen wir, mit der am wenigsten kritischen Umgebung zu beginnen, z. B. Test, und prüfen die Upgradefunktionalität. Nachdem Sie geprü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 durchgeführt haben. Auf diese Weise können Sie von einem kritischen Punkt zum nächsten übergehen 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.

Den Zeitaufwand schätzen und ein Wartungsfenster planen

Standardmäßig werden alle Knotenpools parallel aktualisiert, aber in jedem Knotenpool werden die Knoten nacheinander aktualisiert. Die Gesamtzeit für ein Upgrade hängt also von der Anzahl der Knoten im größten Knotenpool ab. Eine grobe Schätzung für die Upgradezeit lässt sich mit 15 Minuten × der Anzahl der Knoten im größten Knotenpool berechnen. Wenn der größte Pool beispielsweise 10 Knoten enthält, beträgt die gesamte Upgradezeit etwa 150 Minuten.

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 finden Sie unter Administratorcluster mit gkectl sichern und wiederherstellen.

Verwendung von PodDisruptionBudgets prüfen

In Kubernetes kann 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. Dieses Verhalten ist hilfreich, um die Verfügbarkeit von Anwendungen zu prüfen.

  1. Verwenden Sie den Befehl kubectl get pdb, um zu prüfen, welche PDBs in Ihrem Cluster konfiguriert sind:

    kubectl get pdb -A --kubeconfig KUBECONFIG

    Ersetzen Sie KUBECONFIG durch den Namen der 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 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 ein Replikat enthält. In diesem Beispiel wird der Ausgleichsvorgang unterbrochen, da das PDB vom Ressourcencontroller nicht erfüllt werden kann.

Prüfen Sie alle PDBs in einem bestimmten Cluster, bevor Sie das Upgrade starten, damit die PDBs das Upgrade nicht beeinträchtigen. 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 wird 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 für die Anzahl der Knoten im Cluster steht.
  • Bei Verwendung statischer IP-Adressen müssen die erforderlichen IP-Adressen in den IP-Blockdateien aufgeführt sein.
  • Wenn Sie DHCP verwenden, sorgen Sie dafür, 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ü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 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 per Drain beendet wird, und dass genügend Ressourcen im zu aktualisierenden Cluster vorhanden sind, um das Upgrade zu verwalten. Die aktuelle Ressourcennutzung des Clusters können Sie mit benutzerdefinierten Dashboards in der Google Cloud-Beobachtbarkeit 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 Nutzung der Clusterressourcen. Dashboards können eine detailliertere Ansicht der im Laufe der Zeit verbrauchten Ressourcen bieten. Diese Daten zur Ressourcennutzung können Ihnen Aufschluss darüber geben, wann ein Upgrade die geringste Unterbrechung verursachen würde, z. B. an Wochenenden oder Abenden, 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 Ausfallzeiten der Anwendung führt. Sie sollten jedoch trotzdem in vSphere nach kostenlosen Ressourcen suchen, bevor Sie mit dem Upgrade des Administratorclusters beginnen. Außerdem kann ein Upgrade des Administratorclusters ein gewisses Risiko mit sich bringen. Daher wird es möglicherweise empfohlen, wenn der Verwaltungszugriff auf den Cluster weniger kritisch ist, wenn die Nutzung weniger aktiv 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 zum Prüfen dieser Ressourcennutzung einen Cluster in vCenter aus und prüfen Sie den Tab Zusammenfassung.

Der Tab „Zusammenfassung“ zeigt den Arbeitsspeicher-, CPU- und Speicherverbrauch des gesamten Clusters insgesamt. 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

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

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

Beim Upgradeprozess werden mithilfe des vSphere-Klonvorgangs VMs erstellt. Das Klonen mehrerer VMs aus einer Vorlage kann das zugrunde liegende Speichersystem in Form zunehmender 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 zu liefern.

vSphere ist auf die gleichzeitige Ressourcennutzung ausgelegt und verfügt über Mechanismen zur Bereitstellung von Ressourcen, selbst wenn ein Overcommit erfolgt. Wir empfehlen jedoch dringend, kein Overcommit des VM-Arbeitsspeichers zu verwenden. Eine Überbelegung des Arbeitsspeichers kann zu schwerwiegenden Leistungseinbußen führen, die sich auf den gesamten Cluster auswirken, da vSphere den „fehlenden RAM“ bereitstellt, damit Seiten in den Datenspeicher ausgelagert werden. Dieses Verhalten kann während eines Upgrades eines Clusters zu Problemen und Leistungseinbußen bei anderen ausgeführten 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 potenzielle Leistungseinbußen zu vermeiden.

Clusterzustand und -konfiguration prüfen

Führen Sie vor dem Upgrade die folgenden Tools für alle Cluster aus:

  • Der Befehl gkectl diagnose (gkectl diagnose) sorgt dafür, dass alle Cluster fehlerfrei sind. 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.

  • Das Tool vor dem Upgrade prüft nicht nur den Zustand und die Konfiguration des Clusters, sondern sucht auch nach potenziellen bekannten Problemen, die während eines Clusterupgrades auftreten können.

Obwohl mit dem Befehl gkectl upgrade Preflight-Prüfungen ausgeführt und der Upgradeprozess angehalten werden, wenn diese Prüfungen nicht erfolgreich sind, dienen die Preflight-Prüfungen dazu, Cluster vor möglichen Schäden zu schützen. Wir empfehlen Ihnen, die Tools zu verwenden, um Probleme vor dem Upgrade zu identifizieren und zu beheben, anstatt sich auf die Preflight-Prüfungen zu verlassen.

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 können Anwendungen Unterbrechungen verarbeiten. Die Auswirkungen auf Deployments mit mehreren Replikaten sollten minimal sein. Sie können den Cluster auch dann upgraden, wenn Anwendungen keine Deployments verwenden.

Es gibt auch Regeln für Bereitstellungen, 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 ihre Pods aus irgendeinem Grund neu geplant werden müssen, z. B. durch Upgrades oder Wartungen der Clusterknoten, und diese vor einem Upgrade unbedingt überprüft werden müssen.

Load-Balancer-Paar mit Hochverfügbarkeit verwenden

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

Zum Erhöhen der Dienstverfügbarkeit (d. h. für den Kubernetes API-Server) empfehlen wir, immer ein Hochverfügbarkeitspaar 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 hohe Verfügbarkeit, wenn auch der Nutzercluster selbst für Hochverfügbarkeit konfiguriert ist. In dieser Best-Practices-Serie wird davon ausgegangen, dass ein Hochverfügbarkeits-Nutzercluster ein Load-Balancer-Paar mit Hochverfügbarkeit 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.

Entscheiden Sie, wie die einzelnen Nutzercluster aktualisiert werden sollen

Ab Version 1.14 können Sie einen Nutzercluster als Ganzes upgraden (Sie können also die Steuerungsebene und alle Knotenpools im Cluster upgraden) oder die Steuerungsebene des Nutzerclusters aktualisieren und die Knotenpools in der aktuellen Version belassen. Informationen dazu, warum Sie die Steuerungsebene separat upgraden 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 aktualisieren, 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 in der GKE On-Prem API registriert sind, können Sie über die gcloud CLI die Versionen von Nutzerclustern, Knotenpools im Nutzercluster und Administratorclustern abrufen.

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

    gcloud components update

  2. Prüfen Sie die Versionen mit den folgenden Befehlen:

  • So prüfen Sie die Version von Nutzerclustern:

    gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-

    Ersetzen Sie PROJECT_ID durch die Projekt-ID Ihres Flotten-Hostprojekts.

    Wenn Sie --location=- festlegen, werden alle Cluster in allen Regionen aufgelistet. Wenn Sie die Liste eingrenzen 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 von Clusterknoten abzurufen, aber kubectl gibt die Kubernetes-Version zurück. Informationen zum Abrufen der entsprechenden GKE on VMware-Version für eine Kubernetes-Version finden Sie unter 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 alle fünf Jahre manuell rotieren. Weitere Informationen finden Sie unter Zertifizierungsstellen von Nutzerclustern rotieren und CA-Zertifikate von Administratorcluster rotieren.

Unterschiede zwischen Clustertypen

Es gibt zwei verschiedene Arten von Clustern:

  • Nutzercluster
  • Administratorcluster

Je nachdem, wie Sie einen Nutzercluster erstellen, enthält er möglicherweise sowohl Worker-Knoten als auch Knoten der Steuerungsebene (Controlplane V2) oder nur Worker-Knoten (kubeception). 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 ab Version 1.14 die Steuerungsebene eines Nutzerclusters getrennt von den Knotenpools aktualisieren, auf denen Ihre Arbeitslasten ausgeführt werden.

Unterschiedliche Auswirkungen von Nutzerclustern im Vergleich zu Administratorclusterupgrades

Das Upgradeverfahren für GKE on VMware umfasst einen Knotenausgleichsprozess, bei dem alle Pods aus einem Knoten entfernt werden. Im Prozess 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 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ähigkeit des Clusters nicht zu stark belastet wird, aktualisiert GKE on VMware jeweils einen Knoten.

Störung des Nutzerclusters

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

Funktion Administratorcluster Nutzercluster ohne Hochverfügbarkeit Hochverfügbarkeits-Nutzercluster
Zugriff auf die Kubernetes API 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 bis zum Abschluss des Upgrades bemerkbar.
  • Nicht betroffen: Eine Dienstunterbrechung kann innerhalb sehr kurzer Zeit auftreten, ist aber fast unbemerkt.

Die Knoten der Steuerungsebene des Nutzerclusters führen keine Nutzerarbeitslasten aus, egal ob sie auf dem Administratorcluster (kubeception) oder auf dem Nutzercluster selbst (Controlplane V2) ausgeführt werden. Während eines Upgrades werden diese Knoten der Steuerungsebene per Drain beendet und dann entsprechend aktualisiert.

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

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

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

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
Zugriff auf die Kubernetes API 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 bis zum Abschluss des Upgrades bemerkbar.
  • Nicht betroffen: Eine Dienstunterbrechung kann innerhalb sehr kurzer Zeit auftreten, ist aber fast unbemerkt.

Nächste Schritte