Das in dieser Dokumentation beschriebene Produkt GKE on AWS befindet sich jetzt im Wartungsmodus und wird am 17. März 2027 eingestellt.

Diese Seite wurde von der Cloud Translation API übersetzt.

Surge-Updates

Dieses Dokument bietet einen kurzen Überblick über standardmäßige Rolling Updates und geht dann auf Surge Updates ein, die eine spezielle Art von Rolling Updates sind. Im Vergleich zu Standard-Rolling Updates können Sie bei Surge-Updates die Geschwindigkeit des Updates konfigurieren. Mit Surge-Updates können Sie auch steuern, wie stark Updates Ihre Arbeitslasten stören dürfen.

Informationen zum Aktivieren und Konfigurieren von Surge-Updates für GKE on AWS finden Sie unter Surge-Updates von Knotenpools konfigurieren.

So funktionieren Standard-Rolling Updates

Für einige Aktualisierungen eines Knotenpools, z. B. wenn Sie die Anmerkungen eines Knotenpools ändern, ist kein Neustart der Knoten erforderlich. Daher wird auch kein Rolling Update ausgelöst. Wenn GKE on AWS Änderungen an einem Knotenpool anwenden kann, ohne Ressourcen neu starten oder neu erstellen zu müssen, wird dies getan, um Unterbrechungen zu vermeiden.

Bei den meisten Aktualisierungen eines Knotenpools in GKE on AWS werden jedoch in der Regel vorhandene Knoten beendet und neue Knoten mit den aktualisierten Einstellungen gestartet. Das Beenden vorhandener Knoten kann zu Unterbrechungen von Arbeitslasten führen.

Standardmäßig führt GKE on AWS Standard-Rolling Updates durch. Bei dieser Methode werden Knoten einzeln aktualisiert und durch einen „Terminate before create“-Ansatz ersetzt: Ein Knoten wird zuerst beendet und dann ein neuer, aktualisierter Knoten gestartet. Dadurch werden Unterbrechungen minimiert, da jeweils nur ein Knoten beendet und ersetzt wird.

So geht GKE on AWS bei einem standardmäßigen Rolling Update vor:

Wählt einen Knoten aus dem Knotenpool aus und markiert ihn als nicht verfügbar, damit keine neuen Pods darauf gestartet werden. Diese Aktion wird als Absperren bezeichnet.
Die aktiven Pods werden vom abgesperrten Knoten auf andere verfügbare Knoten im Cluster verschoben. Wenn andere Knoten über ausreichend Kapazität verfügen, können sie die entfernten Pods aufnehmen. Andernfalls startet das Cluster-Autoscaling, das während eines standardmäßigen Rolling Updates aktiv bleibt, eine Aufskalierung und stellt zusätzliche Knoten bereit, um sicherzustellen, dass genügend Kapazität zum Planen der entfernten Pods vorhanden ist. Informationen zu den Maßnahmen, die zum Schutz von Arbeitslasten während dieses Vorgangs ergriffen werden, finden Sie unter Arbeitslastschutz während der Größenänderung.
Beendet den gesperrten Knoten.
Ersetzt den abgesperrten Knoten durch einen neuen mit den aktualisierten Einstellungen.
Führt eine Systemdiagnose für den neu betriebsbereiten Knoten durch. Wenn der Knotenpool die Systemdiagnose nicht besteht, wird er mit dem Status DEGRADED markiert. Dieser Status kann mit dem Befehl gcloud container aws node-pools describe angezeigt werden. Wenn ein Knotenpool als DEGRADED markiert ist, werden möglicherweise keine neuen Pods auf den Knoten in diesem Pool geplant.
Die Aktualisierung wird Knoten für Knoten fortgesetzt, bis alle Knoten im Pool aktualisiert wurden.

So funktionieren Surge-Updates

In GKE on AWS werden Knoten mit der Standardmethode für Rolling Updates einzeln aktualisiert. Mit Surge-Updates, einer Form von Rolling Updates, können Sie mehrere Knoten gleichzeitig aktualisieren. Surge-Updates sind daher schneller als standardmäßige Rolling Updates. Wenn Sie jedoch mehrere Knoten gleichzeitig aktualisieren, kann dies zu Störungen bei Arbeitslasten führen. Um dies zu minimieren, bieten Surge-Updates Optionen, um das Ausmaß der Störungen Ihrer Arbeitslasten zu modulieren.

Eine weitere Möglichkeit, wie sich Surge-Updates von Standard-Rolling-Updates unterscheiden, ist die Art und Weise, wie Knoten ersetzt werden. Bei Standard-Rolling Updates werden Knoten durch die Strategie „terminate before create“ (beenden vor dem Erstellen) ersetzt. Je nach den von Ihnen gewählten Einstellungen können für Surge-Updates entweder die Strategie „Erstellen vor Beenden“, die Strategie „Beenden vor Erstellen“ oder eine Kombination aus beiden verwendet werden.

Der Cluster Autoscaler spielt bei Surge-Updates eine wichtigere Rolle als bei standardmäßigen Rolling Updates. Daher ist er in der folgenden Liste der Aktionen, die GKE on AWS während eines Surge-Updates ausführt, besonders wichtig:

Erstellung einer neuen Autoscaling-Gruppe: GKE on AWS stellt neue Knoten mit den durch den Aktualisierungsbefehl angegebenen Änderungen bereit und weist diese neuen Knoten einer neuen AWS-Autoscaling-Gruppe (ASG) zu.
Verhalten von Cluster Autoscaler: Wenn das Surge-Update beginnt, wird Cluster Autoscaler für die neue Autoscaling-Gruppe aktiviert. Der Cluster Autoscaler für die ursprüngliche Autoscaling-Gruppe ist deaktiviert. So wird sichergestellt, dass alle Skalierungsvorgänge nur auf die neue Gruppe ausgerichtet sind.
Knotenersetzung: Je nach den Surge-Update-Parametern werden verschiedene Strategien für die Knotenersetzung verwendet:
- „create before terminate“: Diese Strategie wird aktiviert, wenn der Parameter max-surge-update auf einen Wert größer als null gesetzt ist. Es werden neue Knoten in der neuen ASG erstellt, bevor die alten Knoten in der ursprünglichen ASG beendet werden. So sollen Dienstunterbrechungen minimiert werden.
- „terminate before create“: Diese Methode wird ausgelöst, wenn der Parameter max-surge-update auf null und der Parameter max-unavailable-update auf einen Wert größer als null gesetzt ist. Zuerst werden Knoten aus der ursprünglichen ASG beendet, dann werden neue Knoten in der neuen ASG erstellt.
Anpassungen der Knotenpoolgröße: Während des Updates kann die Größe des Knotenpools (d. h. die Summe der Knoten in der alten und der neuen ASG) über oder unter die ursprüngliche Anzahl der Knoten im Knotenpool schwanken, die vor dem Start des Updates vorhanden waren. Bei GKE on AWS wird die Gesamtzahl der Knoten im Bereich von (original_count – max-unavailable-update) bis (original_count + max-surge-update) gehalten. Schließlich werden die Knoten in der alten ASG (original_count) durch aktualisierte Knoten in der neuen ASG ersetzt. Der Cluster Autoscaler startet möglicherweise weitere Knoten in der neuen ASG, wenn er erkennt, dass Pods nicht geplant werden können. Dabei werden jedoch die durch min-nodes und max-nodes definierten Grenzwerte eingehalten.

Beispiel zur Veranschaulichung des Vorgangs

Das folgende Beispiel veranschaulicht die Funktionsweise von Aktualisierungen bei plötzlichen Anstiegen. Angenommen, Sie haben einen Knotenpool mit fünf Knoten und führen den folgenden Befehl aus:

  gcloud container aws node-pools update production-node-pool
      --cluster my-cluster \
      --location us-west1 \
      --max-surge-update 2 \
      --max-unavailable-update 1 \
      --node-version 1.27.6-gke.700

In diesem Beispiel ist max-surge-update auf 2 und max-unavailable-update auf 1 festgelegt. Sie geben eine neue Knotenpoolversion an (d. h., Sie ändern die GKE-Version, die auf den Knoten im Knotenpool ausgeführt wird).

Wenn Sie diesen Befehl ausführen, wird ein Surge-Update ausgelöst und GKE on AWS führt die folgenden Aktionen aus:

Es werden zwei zusätzliche Knoten erstellt, da der Wert von max-surge-update gleich 2 ist.
Weist diese beiden zusätzlichen Knoten einer neuen AWS-Autoscaling-Gruppe zu.
Entfernt Knoten aus der ursprünglichen Autoscaling-Gruppe, sobald diese neuen Knoten betriebsbereit sind. GKE on AWS fährt bis zu drei Knoten herunter (der kombinierte Wert von max-surge-update und max-unavailable-update), sorgt aber dafür, dass jeweils nur ein Knoten nicht verfügbar ist (aufgrund des max-unavailable-update-Werts von 1).
Wiederholen Sie diese Schritte, bis alle Knoten im Knotenpool auf die neue GKE-Version aktualisiert wurden.

Während dieses Updates enthält der Knotenpool zwischen 4 und 7 Betriebsknoten.

Wichtige Hinweise vor der Durchführung von Surge-Updates

Beachten Sie vor dem Ausführen eines Surge-Updates Folgendes:

Zusätzliche Instanzen, die im Rahmen dieses Schritts erstellt werden, können Ihr AWS-Instanzkontingent überschreiten. Wenn Sie nicht genügend Kontingente haben und diese zusätzlichen Instanzen nicht bereitgestellt werden können, schlägt das Update möglicherweise fehl.
Wenn max-unavailable-update auf 0 gesetzt ist, können weiterhin Störungen bei Arbeitslasten auftreten, da Pods entfernt und auf den neueren Knoten neu geplant werden.
Die maximale Anzahl von Knoten, die gleichzeitig aktualisiert werden können, entspricht der Summe von max-surge-update und max-unavailable-update und ist auf 20 begrenzt.

Die richtigen Surge-Einstellungen für Ihre Anforderungen auswählen

Bei Standard-Rolling-Updates wird häufig der Ansatz „Beenden vor Erstellen“ verwendet. Surge-Updates bieten dagegen mehr Flexibilität. Je nach Konfiguration können Surge-Updates einer „Create before terminate“-Strategie, einer „Terminate before create“-Strategie oder einer Kombination aus beiden folgen. In diesem Abschnitt werden verschiedene Konfigurationen beschrieben, die Ihnen bei der Auswahl des besten Ansatzes für Ihre Arbeitslasten helfen.

Die folgende Tabelle enthält drei Beispielkonfigurationen und zeigt, wie sie sich auf die Geschwindigkeit des Updates und die potenzielle Unterbrechung Ihrer Arbeitslasten auswirken:

Name	Beschreibung	Configuration
Ausgewogene Einstellung (Standardeinstellung)	Ausgeglichen, langsamer, aber am wenigsten störend.	maxSurge=1, maxUnavailable=0
Schnelle Updates ohne zusätzliche Ressourcen	Schnell, keine Surge-Ressourcen, am störendsten.	maxSurge=0, maxUnavailable=20
Schnelle Updates, die weniger störend sind	Schnell, die meisten Surge-Ressourcen und weniger störend.	maxSurge=20, maxUnavailable=0

Jede der Einstellungen in der Tabelle wird in den folgenden Abschnitten beschrieben.

Ausgewogene Einstellung (Standardeinstellung)

Am einfachsten lassen sich Surge-Updates mit der Standardkonfiguration von max-surge-update=1 und max-unavailable-update=0 verwenden. Bei dieser Konfiguration wird dem Knotenpool während des Updates nur ein Surge-Knoten hinzugefügt und jeweils nur ein Knoten aktualisiert. Dabei wird das Verfahren „create before terminate“ (erstellen vor dem Beenden) angewendet. Im Vergleich zum standardmäßigen rollierenden Update ohne Surge, das (max-surge-update=0, max-unavailable-update=1) entspricht, ist diese Methode weniger störend, beschleunigt Pod-Neustarts während Updates und ist konservativer in ihrem Fortschritt.

Die Verwendung der ausgeglichenen Einstellung kann zu zusätzlichen Kosten führen, da während des Updates ein temporärer Surge-Knoten hinzugefügt wird. Für diesen zusätzlichen Knoten fallen Gebühren an, solange er aktiv ist. Dadurch steigen die Gesamtkosten im Vergleich zu Methoden ohne Surge-Knoten leicht an.

Schnelle Updates ohne zusätzliche Ressourcen

Für Arbeitslasten, die Unterbrechungen tolerieren können, ist möglicherweise ein schnellerer Aktualisierungsansatz geeignet. Dies wird durch die Konfiguration von max-surge-update=0 und max-unavailable-update=20 erreicht. Mit dieser Konfiguration können 20 Knoten gleichzeitig aktualisiert werden, ohne dass Surge-Knoten hinzugefügt werden. Diese Aktualisierungsmethode folgt dem Ansatz „terminate before create“ (vor dem Erstellen beenden). Da während des Prozesses keine zusätzlichen Surge-Knoten eingeführt werden, ist diese Methode auch die kostengünstigste, da zusätzliche Kosten für temporäre Knoten vermieden werden.

Schnelle Updates, die weniger störend sind

Wenn Ihre Arbeitslasten störungsanfällig sind, können Sie die Geschwindigkeit des Updates mit den folgenden Einstellungen erhöhen: max-surge-update=20 und max-unavailable-update=0. Bei dieser Konfiguration werden 20 Knoten parallel nach dem Prinzip „create before terminate“ (erstellen vor dem Beenden) aktualisiert.

Die Gesamtgeschwindigkeit des Updates kann jedoch eingeschränkt sein, wenn Sie PodDisruptionBudgets (PDB) für Ihre Arbeitslasten eingerichtet haben. Das liegt daran, dass das PDB die Anzahl der Pods begrenzt, die zu einem bestimmten Zeitpunkt per Drain beendet werden können. Obwohl die Konfigurationen von PDBs variieren können, kann beim Erstellen eines PDB mit maxUnavailable gleich 1 für eine oder mehrere im Knotenpool ausgeführte Arbeitslasten jeweils nur ein Pod dieser Arbeitslasten entfernt werden, wodurch die Parallelität des gesamten Updates begrenzt wird.

Wenn Sie zu Beginn des Updatevorgangs mehrere Surge-Knoten initiieren, kann dies zu einem vorübergehenden Anstieg der Kosten führen, insbesondere im Vergleich zu Konfigurationen, bei denen während der Updates keine oder weniger zusätzliche Knoten hinzugefügt werden.

Nächste Schritte