Surge-Updates

In diesem Dokument erhalten Sie einen kurzen Überblick über standardmäßige schrittweise Updates und werden dann ausführlich über Notfallupdates informiert, eine spezielle Art von schrittweisem Update. Im Vergleich zu standardmäßigen Rolling Updates können Sie bei Surge-Updates die Geschwindigkeit der Aktualisierung konfigurieren. Mit Surge-Updates können Sie auch steuern, wie stark Upgrades 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 standardmäßige Rolling Updates

Bei einigen Aktualisierungen eines Knotenpools, z. B. wenn Sie die Anmerkungen eines Knotenpools ändern, müssen die Knoten nicht neu gestartet werden. Daher wird kein schrittweises Update ausgelöst. Wenn GKE on AWS Änderungen an einem Knotenpool anwenden kann, ohne Ressourcen neu starten oder neu erstellen zu müssen, geschieht dies, 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 bestehender Knoten kann Arbeitslasten beeinträchtigen.

Standardmäßig führt GKE on AWS standardmäßige Rolling Updates durch. Bei dieser Methode werden die Knoten nacheinander aktualisiert und durch den Ansatz „Beenden vor Erstellen“ ersetzt: Ein Knoten wird zuerst beendet und dann wird ein neuer aktualisierter Knoten gestartet. Dadurch werden Unterbrechungen minimiert, da immer nur ein Knoten beendet und ersetzt wird.

So läuft ein standardmäßiges Rolling-Update in GKE on AWS ab:

1. Wählt einen Knoten aus dem Knotenpool aus und kennzeichnet ihn als nicht verfügbar, damit keine neuen Pods darauf gestartet werden. Diese Aktion wird als Absperren bezeichnet.
2. Die aktiven Pods werden vom abgesperrten Knoten auf andere verfügbare Knoten im Cluster verschoben. Wenn andere Knoten ausreichend Kapazität haben, werden die entfernten Pods dort untergebracht. Andernfalls startet der Cluster-Autoscaler, der während eines standardmäßigen schrittweisen Updates aktiv bleibt, ein Hochskalieren und stellt zusätzliche Knoten bereit, damit genügend Kapazität vorhanden ist, um die entfernten Pods zu planen. Informationen zu den Maßnahmen zum Schutz von Arbeitslasten während dieses Vorgangs finden Sie unter Arbeitslastschutz beim Ändern der Größe.
3. Der abgesperrte Knoten wird beendet.
4. Ersetzt den abgesperrten Knoten durch einen neuen mit den aktualisierten Einstellungen.
5. Führt eine Systemdiagnose für den neu betriebsbereiten Knoten durch. Wenn der Knotenpool die Systemdiagnose nicht besteht, wird er mit dem Status DEGRADED gekennzeichnet. Sie können den Status mit dem Befehl gcloud container aws node-pools describe prüfen. Wenn ein Knotenpool als DEGRADED gekennzeichnet ist, werden neue Pods möglicherweise nicht auf den Knoten in diesem Pool geplant.
6. Die Aktualisierung wird Knoten für Knoten fortgesetzt, bis alle Knoten im Pool aktualisiert wurden.

So funktionieren Aktualisierungen bei Spitzennachfrage

In GKE on AWS werden mit der standardmäßigen Rolling-Methode Knoten nacheinander aktualisiert. Mit Surge-Upgrades, einer Form des Rolling Updates, können Sie mehrere Knoten gleichzeitig aktualisieren. Surge-Updates sind daher schneller als standardmäßige Rolling-Updates. Das gleichzeitige Aktualisieren mehrerer Knoten kann jedoch zu Unterbrechungen bei den Arbeitslasten führen. Um dies zu vermeiden, bieten Surge-Upgrades Optionen, mit denen Sie den Grad der Unterbrechung Ihrer Arbeitslasten steuern können.

Ein weiterer Unterschied zwischen Spitzenaktualisierungen und standardmäßigen schrittweisen Aktualisierungen besteht darin, wie Knoten ersetzt werden. Bei standardmäßigen schrittweisen Aktualisierungen werden Knoten mit der Strategie „Beenden vor Erstellen“ ersetzt. Je nach den ausgewählten Einstellungen kann für die Aktualisierung bei Spitzenlast entweder die Strategie „Erstellen vor Beenden“, die Strategie „Beenden vor Erstellen“ oder eine Kombination aus beiden verwendet werden.

Die Cluster Autoscaler spielt bei Notfall-Upgrades eine wichtigere Rolle als bei standardmäßigen Rolling Upgrades. Daher wird sie in der folgenden Liste der Aktionen, die GKE on AWS bei einem Notfall-Upgrade ausführt, besonders hervorgehoben:

1. Erstellen einer neuen Autoscaling-Gruppe: GKE on AWS stellt neue Knoten mit den vom Befehl „update“ angegebenen Änderungen bereit und weist diese neuen Knoten einer neuen AWS-Autoscaling-Gruppe (ASG) zu.
2. Verhalten der Cluster Autoscaler: Zu Beginn der Leistungssteigerung wird die 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.
3. Knotenersatz: Je nach den Parametern für die Surge-Aktualisierung werden unterschiedliche Strategien für den Knotenersatz verwendet:
   • „create before terminate“ (Erstellen vor Beenden): Diese Strategie wird aktiviert, wenn der Parameter max-surge-update auf einen Wert größer als null gesetzt ist. Es werden neue Knoten im neuen ASG erstellt, bevor die alten im ursprünglichen ASG beendet werden, um Dienstunterbrechungen zu minimieren.
   • „terminate before create“: Diese Methode wird ausgelöst, wenn der Parameter max-surge-update auf null gesetzt ist und der Parameter max-unavailable-update einen Wert größer als null hat. Die Knoten aus der ursprünglichen ASG werden zuerst beendet, gefolgt vom Erstellen neuer Knoten in der neuen ASG.
4. Anpassungen der Knotenpoolgröße: Während des Updates kann die Knotenpoolgröße (d. h. die Summe der Knoten in der alten und der neuen ASG) über oder unter der ursprünglichen Anzahl der Knoten im Knotenpool liegen, die vor Beginn des Updates vorhanden war. Bei GKE on AWS wird die Gesamtzahl der Knoten im Bereich (original_count – max-unavailable-update) bis (original_count + max-surge-update) gehalten. Die Knoten in der alten ASG (original_count) werden schließlich durch aktualisierte Knoten in der neuen ASG ersetzt. Der Cluster-Autoscaler kann weitere Knoten in der neuen ASG starten, wenn er erkennt, dass Pods nicht geplant werden können, aber die Limits von min-nodes und max-nodes eingehalten werden.

Beispiel zur Veranschaulichung des Prozesses

Das folgende Beispiel verdeutlicht die Funktionsweise von Aktualisierungen bei Spitzennachfrage. Angenommen, Sie haben einen Knotenpool mit 5 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.

Durch Ausführen dieses Befehls wird ein Notfallupdate ausgelöst und GKE on AWS führt die folgenden Aktionen aus:

1. Es werden zwei zusätzliche Knoten erstellt, da der Wert von max-surge-update 2 ist.
2. Diese beiden zusätzlichen Knoten werden einer neuen AWS-Autoscaling-Gruppe zugewiesen.
3. Knoten werden aus der ursprünglichen Autoscaling-Gruppe entfernt, sobald diese neuen Knoten einsatzbereit sind. GKE on AWS fährt bis zu drei Knoten herunter (die Summe von max-surge-update und max-unavailable-update), sorgt aber dafür, dass immer nur ein Knoten nicht verfügbar ist (aufgrund des Werts „1“ für max-unavailable-update).
4. 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 vier und sieben betriebsbereiten Knoten.

Was Sie vor dem Ausführen von Spitzenupdates beachten sollten

Beachten Sie Folgendes, bevor Sie ein Hochskalierungsupdate ausführen:

• Zusätzliche Instanzen, die im Rahmen dieses Schritts zur Leistungssteigerung erstellt werden, können Ihr AWS-Instanzkontingent überschreiten. Wenn Sie nicht genügend Kontingent haben und diese zusätzlichen Instanzen nicht bereitgestellt werden können, schlägt das Update möglicherweise fehl.
• Wenn max-unavailable-update auf 0 festgelegt ist, können Unterbrechungen bei Arbeitslasten dennoch auftreten, da Pods entfernt und auf die neueren Knoten verschoben 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 beschränkt.

Die richtigen Überspannungseinstellungen für Ihre Anforderungen auswählen

Bei standardmäßigen Rolling-Upgrades wird häufig der Ansatz „Beenden vor Erstellen“ verwendet. Bei Surge-Updates ist mehr Flexibilität möglich. Je nach Konfiguration können Aktualisierungen bei Spitzenlast nach der Strategie „Erstellen vor Beenden“, der Strategie „Beenden vor Erstellen“ oder einer Kombination aus beiden erfolgen. In diesem Abschnitt werden verschiedene Konfigurationen beschrieben, die Ihnen bei der Auswahl des besten Ansatzes für Ihre Arbeitslasten helfen.

In der folgenden Tabelle sind drei Beispieleinstellungen aufgeführt, die Auswirkungen auf die Geschwindigkeit des Updates und die potenziellen Unterbrechungen Ihrer Arbeitslasten haben:

Die einzelnen Einstellungen in der Tabelle werden in den folgenden Abschnitten beschrieben.

Ausgeglichene Einstellung (Standard)

Die einfachste Möglichkeit, Surge-Updates zu verwenden, ist die Standardkonfiguration von max-surge-update=1 und max-unavailable-update=0. Bei dieser Konfiguration wird dem Knotenpool während der Aktualisierung nur ein Surge-Knoten hinzugefügt und jeweils nur ein Knoten aktualisiert. Dabei wird der Ansatz „Erstellen vor Beenden“ verwendet. Im Vergleich zum standardmäßigen rollierenden Update ohne Spitzenlast, das (max-surge-update=0, max-unavailable-update=1) entspricht, ist diese Methode weniger störend, beschleunigt den Neustart von Pods während der Updates und ist bei der Durchführung konservativer.

Die Einstellung „Ausgewogen“ kann zu zusätzlichen Kosten führen, da während der Aktualisierung ein temporärer Surge-Knoten hinzugefügt wird. Für diesen zusätzlichen Knoten fallen Kosten an, während er aktiv ist. Die Gesamtkosten steigen dadurch im Vergleich zu Methoden ohne Spitzenlastknoten leicht.

Schnelle Updates ohne zusätzliche Ressourcen

Bei Arbeitslasten, die Unterbrechungen tolerieren können, ist möglicherweise ein schnellerer Aktualisierungsansatz geeignet. Dies lässt sich durch die Konfiguration von max-surge-update=0 und max-unavailable-update=20 erreichen. Mit dieser Konfiguration können 20 Knoten gleichzeitig aktualisiert werden, ohne dass zusätzliche Surge-Knoten hinzugefügt werden müssen. Bei dieser Aktualisierungsmethode wird der Ansatz „Beenden vor Erstellen“ verwendet. Da bei diesem Verfahren keine zusätzlichen Spitzenlastknoten eingeführt werden, ist es auch die kostengünstigste Methode. Zusätzliche Kosten für temporäre Knoten werden vermieden.

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 gleichzeitig im Modus „Erstellen vor Beenden“ aktualisiert.

Die Gesamtgeschwindigkeit des Updates kann jedoch eingeschränkt sein, wenn Sie für Ihre Arbeitslasten PodDisruptionBudgets (PDB) 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 = 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 Upgrades begrenzt wird.

Wie Sie wissen, kann das Initiieren mehrerer Spitzenknoten zu Beginn des Aktualisierungsprozesses zu einer vorübergehenden Erhöhung der Kosten führen, insbesondere im Vergleich zu Konfigurationen, bei denen bei Aktualisierungen keine oder weniger Knoten hinzugefügt werden.

Nächste Schritte

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