Upgrade von Autopilot-Clustern

Auf dieser Seite wird erläutert, wie automatische Upgrades in Autopilot-Clustern in Google Kubernetes Engine (GKE) ausgeführt werden. Außerdem finden Sie Links zu weiteren Informationen über verwandte Aufgaben und Einstellungen. Mithilfe dieser Informationen können Sie Ihre Cluster bei minimalen Unterbrechungen auf dem aktuellen Stand halten, sodass Sie stabil und sicher laufen.

Automatische Steuerungsebenen- und Knotenupgrades

Automatische Upgrades sind für alle Autopilot-Cluster aktiviert. GKE initiiert automatische Upgrades, wenn GKE-Versionen für das automatische Upgrade ausgewählt werden. Es beobachtet automatische Upgrades in allen Clustern und greift bei Problemen wie fehlerhaften Knoten ein.

Zum Upgrade eines Clusters aktualisiert GKE die Version, mit der die Steuerungsebene und die Knoten ausgeführt werden. Cluster werden entweder auf eine neuere Nebenversion (z. B. 1.24 bis 1.25) oder eine neuere Patchversion (z. B. 1.24.2-gke.100 auf 1.24.5-gke.200) aktualisiert. Weitere Informationen finden Sie unter Versionsverwaltung und Support für GKE.

Alle Autopilot-Cluster sind in einer Release-Version registriert. Daher aktualisiert GKE automatisch die Steuerungsebene und die Knoten, um dieselbe GKE-Version auszuführen.

GKE aktualisiert die Steuerungsebene eines Clusters, bevor ein Upgrade von Knoten durchgeführt wird.

Automatische Upgrades der Steuerungsebene

Alle Autopilot-Cluster sind regionale Cluster. Regionale Cluster haben mehrere Replikate der Steuerungsebene. Die Replikate werden jeweils einzeln in einer nicht festgelegten Reihenfolge aktualisiert. Dadurch bleibt der Cluster während der automatischen Upgrades hochverfügbar. Jedes Replikat der Steuerungsebene ist nur während des Upgrades nicht verfügbar.

Wenn Sie ein Wartungsfenster oder einen Ausschluss konfigurieren, wird die Konfiguration nach Möglichkeit von GKE berücksichtigt.

GKE kann keine neuen Knoten erstellen, wenn sowohl für Autopilot als auch für Standard eine Aktualisierung der Steuerungsebene ausgeführt wird. Wenn Sie Autopilot-Pods bereitstellen, für die neue Knotentypen erforderlich sind, während ein Upgrade der Steuerungsebene ausgeführt wird, kann es zu Verzögerungen kommen, bis das Upgrade der Steuerungsebene abgeschlossen ist.

Automatische Knotenupgrades

Nachdem GKE die Steuerungsebene des Autopilot-Clusters aktualisiert hat, aktualisiert GKE die Knoten auf dieselbe GKE-Version.

Beim Autopilot werden von GKE Knoten gruppiert, die ähnliche Merkmale haben. GKE verwendet Surge-Upgrades für Autopilot-Knoten, wobei bis zu 20 Knoten in einer Gruppe gleichzeitig aktualisiert werden. Die genaue Anzahl von Knoten, die gleichzeitig aktualisiert werden, variiert, um eine weiterhin hohe Verfügbarkeit von Knoten und Arbeitslasten zu gewährleisten.

Knotenupgrades können mehrere Stunden dauern, je nach Anzahl der Knoten und Konfiguration der in den Knoten ausgeführten Arbeitslasten. Die folgenden Konfigurationen können beispielsweise zu längeren Upgrades führen:

Wenn Sie ein Wartungsfenster oder einen Ausschluss konfigurieren, wird die Konfiguration nach Möglichkeit von GKE berücksichtigt.

Wenn GKE einen Knoten aktualisiert, geschieht Folgendes:

  1. GKE erstellt einen neuen Surge-Knoten mit der neuen GKE-Version und wartet auf die Registrierung des Surge-Knotens bei der Steuerungsebene.
  2. GKE wählt einen vorhandenen Knoten (den Zielknoten) aus, der aktualisiert werden soll.
  3. GKE sperrt den Zielknoten, sodass keine neuen Pods auf dem Zielknoten platziert werden.
  4. GKE kennzeichnet den Zielknoten und entfernt vorhandene Pods aus dem Zielknoten.

  5. GKE verschiebt Pods, die von einem Arbeitslast-Controller verwaltet werden, auf andere verfügbare Knoten. Pods, die nicht umgeplant werden können, bleiben im Status PENDING, bis GKE sie neu planen kann.

  6. GKE löscht den Zielknoten.

Wenn eine beträchtliche Anzahl automatischer Upgrades auf eine bestimmte GKE-Version zu fehlerhaften Knoten im GKE-Bestand führt, beendet GKE Upgrades auf diese Version, während wir das Problem untersuchen.

Versionsauswahl für automatische Upgrades

GKE veröffentlicht regelmäßig neue Nebenversionen. Für automatische Upgrades wird jedoch nicht sofort eine Releaseversion ausgewählt. Damit die GKE-Version als Ziel für automatisches Upgrade geeignet ist, muss sie genügend Nutzung ansammeln, um die Stabilität im Laufe der Zeit nachzuweisen.

Google Cloud wählt diese Version dann als automatisches Ziel-Upgrade für Cluster aus, die eine bestimmte Teilmenge älterer GKE-Versionen ausführen. Kurz nachdem eine neue Nebenversion verfügbar wird, wird die älteste verfügbare Nebenversion normalerweise nicht mehr unterstützt. GKE aktualisiert Cluster, auf denen nicht unterstützte Nebenversionen ausgeführt werden, auf die Zielversion für automatische Upgrades.

GKE kündigt neue Zielversionen für automatische Upgrades in den Versionshinweisen an. Gelegentlich wird eine Version für automatische Upgrades der Steuerungsebene und automatische Knotenupgrades in verschiedenen Wochen ausgewählt. GKE aktualisiert automatisch auf neue Patchreleases innerhalb einer Nebenversion (z. B. Version 1.21.x).

Informationen zum Versionslebenszyklus und zum Versionsverwaltungsschema finden Sie unter GKE-Versionsverwaltung und -Support.

Faktoren, die sich auf die Zeitplanung des Roll-outs einer Version auswirken

Zur Beibehaltung von Stabilität und Zuverlässigkeit von Clustern bei neuen Versionen folgt GKE bestimmten Verfahren während des Roll-outs.

Hier die wichtigsten Verfahren:

  • GKE führt Änderungen schrittweise in Google Cloud-Regionen und -Zonen ein.
  • GKE führt Patchversionen schrittweise in Release-Versionen ein. Ein Patch erhält Vorlaufzeit im Rapid Release Channel, dann im Regular Release Channel, bevor er zur stabilen Release-Version hochgestuft wird, nachdem er Nutzung angesammelt und Stabilität bewiesen hat. Wenn während der Vorlaufzeit in einer Release-Version ein Problem mit einer Patchversion auftritt, wird diese Version nicht zum nächsten Channel hochgestuft und das Problem wird bei einer neueren Patchversion behoben.
  • GKE führt schrittweise Nebenversionen ein. Dabei wird ein ähnlicher Vorlaufprozess wie bei Patchversionen angewendet. Nebenversionen haben längere Vorlaufzeiten, da die eingeführten Änderungen größer sind.
  • GKE kann automatische Upgrades verzögern, wenn sich eine neue Version auf eine Gruppe von Clustern auswirkt. Beispielsweise pausiert GKE automatische Upgrades für Cluster, die erkannt werden, auf eine verworfene API oder Funktion, die in der nächsten Nebenversion entfernt wird.
  • GKE kann die Einführung neuer Versionen zu Spitzenzeiten (z. B. an Feiertagen) verzögern, um für Geschäftskontinuität zu sorgen.

Zeitpunkt für automatische Upgrades konfigurieren

Standardmäßig können automatische Upgrades jederzeit durchgeführt werden. Der Betrieb wird bei automatischen Upgrades nicht gestört, insbesondere nicht bei regionalen Clustern. Bei einigen Arbeitslasten ist möglicherweise jedoch eine feinere Steuerung erforderlich. Dafür können Sie Wartungsfenster und -ausschlüsse konfigurieren, denn so können Sie verwalten, wann automatische Upgrades stattfinden dürfen und wann nicht.

Bei der Konfiguration von Wartungsfenstern und -ausschlüssen erfolgt das Upgrade erst, wenn sich die aktuelle Zeit in einem Wartungsfenster befindet. Wenn ein Wartungsfenster vor dem Abschluss eines Upgrades abläuft, versucht GKE, das Upgrade zu pausieren. GKE setzt das Upgrade während des nächsten verfügbaren Wartungsfensters fort.

Autopilot-Cluster manuell aktualisieren

Sie können die GKE-Version Ihrer Steuerungsebene für Autopilot-Cluster manuell aktualisieren. GKE aktualisiert Ihre Knoten automatisch so, dass sie der Version der Steuerungsebene entsprechen, wenn die Wartungsverfügbarkeit gewährleistet ist. Eine Anleitung finden Sie unter Manuelles Upgrade der Steuerungsebene. Sie können die Knotenversion für Autopilot-Cluster nicht manuell verwalten.

Sie können ein Upgrade der Steuerungsebenenversion auf eine unterstützte Neben- oder Patchversion im selben Releasekanal oder auf eine Patchversion derselben Nebenversion wie Ihr Cluster in einer anderen Releaseversion durchführen.

Betrachten Sie beispielsweise einen Autopilot-Cluster, auf dem die GKE-Version 1.22.8-gke.202 im regulären Release-Kanal ausgeführt wird. Das folgende Verhalten gilt:

  • Sie können ein Upgrade auf eine beliebige Version in Regular ausführen.
  • Sie können ein Upgrade auf eine beliebige Patch-Version von 1.22 im Rapid Channel ausführen.

Weitere Informationen zum Upgrade außerhalb Ihres Kanals finden Sie unter Patchversionen aus einem neueren Kanal ausführen.

Surge-Upgrades

Autopilot-Cluster verwenden Surge-Upgrades, um mehrere Knoten gleichzeitig zu aktualisieren. Mit Surge-Upgrades kann GKE reduzieren, wie stark Betriebsversionen auf Ihre laufenden Arbeitslasten aufgeteilt werden. Dazu wird die Rechenkapazität für Ihre laufenden Arbeitslasten ausreichen. Autopilot verwaltet die Anzahl der Surge-Knoten, die dem Cluster während des Upgrades hinzugefügt werden. Diese Zahl variiert je nach der Gesamtgröße des Clusters. GKE verwaltet auch die Gesamtzahl der Zielknoten, die während des Upgrades gleichzeitig nicht verfügbar sind.

Die Anzahl neuer Surge-Knoten und nicht verfügbarer Zielknoten variiert, um sicherzustellen, dass Ihr Cluster immer genügend Rechenkapazität für alle laufenden Arbeitslasten hat. Möglicherweise treten geringfügige Unterbrechungen auf, wenn GKE Arbeitslasten während des Upgrades von Zielknoten zu Surge-Knoten migriert.

Eine Beschreibung des Surge-Upgrades finden Sie unter Automatische Knotenupgrades.

Kontingentanforderungen für Surge-Upgrades

Im Gegensatz zur Neuerstellung des Knotens benötigen Surge-Upgrades zusätzliche Compute Engine-Ressourcen. Die Ressourcenzuweisung hängt von Ihrem verfügbaren Compute Engine-Kontingent ab. Je nach Konfiguration kann dieses Kontingent die Anzahl der parallelen Upgrades begrenzen oder sogar dazu führen, dass das Upgrade fehlschlägt. Um Skalierungsprobleme zu vermeiden und besser vorhersehbare Upgrades auszuführen, sollten Sie darauf achten, dass Ihr Compute Engine-Instanzkontingent nicht mehr als 90 % beträgt.

Weitere Informationen zu Kontingenten finden Sie unter Ressourcen für Knotenupgrades bereitstellen.

Upgrade-Benachrichtigungen erhalten

GKE veröffentlicht Benachrichtigungen zu Upgrades in Pub/Sub. Damit haben Sie einen Kanal, über den Sie Informationen zu Ihren Clustern von GKE erhalten.

Weitere Informationen finden Sie unter Benachrichtigungen zu Clustern erhalten.

Komponentenupgrades

GKE führt Systemarbeitslasten auf Worker-Knoten aus, um bestimmte Funktionen für Cluster zu unterstützen. Die Systemarbeitslast gke-metadata-server unterstützt beispielsweise die Workload Identity-Föderation für GKE. GKE ist verantwortlich für die Integrität dieser Arbeitslasten. Weitere Informationen zu diesen Komponenten finden Sie in der Dokumentation zu den zugehörigen Funktionen.

Wenn neue Features oder Fehlerkorrekturen für eine Komponente verfügbar sind, gibt GKE die Patchversion an, in der sie enthalten sind. Die neueste Version einer Komponente finden Sie in der zugehörigen Dokumentation oder in den Versionshinweisen. Dort finden Sie Anleitungen zum Upgrade Ihrer Steuerungsebene oder Knoten auf die entsprechende Version.

Nächste Schritte