Surge-Updates

In diesem Dokument erhalten Sie einen kurzen Überblick über standardmäßige Rolling Updates. Außerdem werden Surge-Updates, eine spezielle Art von Rolling Updates, im Detail behandelt. Im Vergleich zu standardmäßigen Rolling Updates können Sie bei Surge-Updates die Geschwindigkeit des Updates konfigurieren. Mit Surge-Updates können Sie auch steuern, wie störende Updates für Ihre Arbeitslasten sind.

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

Funktionsweise von standardmäßigen Rolling Updates

Einige Aktualisierungen eines Knotenpools, z. B. wenn Sie die Annotationen eines Knotenpools ändern, erfordern keinen Neustart der Knoten und erfordern daher kein Rolling Update. Wenn GKE on AWS Änderungen auf einen Knotenpool anwenden kann, ohne Ressourcen neu starten oder neu erstellen zu müssen, werden so Unterbrechungen vermieden.

Zu den meisten Aktualisierungen eines Knotenpools in GKE on AWS müssen jedoch in der Regel vorhandene Knoten beendet und neue Knoten mit den aktualisierten Einstellungen gestartet werden. Das Beenden vorhandener Knoten kann Arbeitslasten stören.

Standardmäßig führt GKE on AWS Standard-Rolling Updates aus. Bei dieser Methode werden Knoten einzeln aktualisiert und mit der Methode "Beenden vor Erstellung" ersetzt: Zuerst wird ein Knoten beendet und dann ein neuer aktualisierter Knoten gestartet. Dies minimiert die Unterbrechungen, da immer nur ein Knoten beendet und ersetzt wird.

Hier sind die Schritte, die GKE on AWS während eines standardmäßigen Rolling Updates ausführt:

1. Wählt einen Knoten aus dem Knotenpool aus und markiert den Knoten als nicht verfügbar, damit keine neuen Pods darauf gestartet werden. Diese Aktion wird als Sperren bezeichnet.
2. Verschiebt die aktiven Pods vom gesperrten Knoten an andere verfügbare Knoten im Cluster. Wenn andere Knoten genügend Kapazität haben, können die entfernten Pods dort Platz finden. Andernfalls startet das Cluster-Autoscaling, das während eines standardmäßigen Rolling Updates aktiv bleibt, eine Hochskalierung und stellt zusätzliche Knoten bereit, damit genügend Kapazität zum Planen der entfernten Pods vorhanden ist. Informationen zu den Maßnahmen zum Schutz von Arbeitslasten während dieses Vorgangs finden Sie unter Arbeitslastschutz während der Größenanpassung.
3. Beendet den gesperrten Knoten.
4. Ersetzt den gesperrten Knoten durch einen neuen mit den aktualisierten Einstellungen.
5. Führt eine Systemdiagnose für den nun betriebsbereiten Knoten durch. Wenn der Knotenpool die Systemdiagnose nicht besteht, wird er mit dem Status DEGRADED gekennzeichnet. Dieser Status kann mit dem Befehl gcloud container aws node-pools describe aufgerufen werden. Wenn ein Knotenpool als DEGRADED markiert ist, werden möglicherweise keine neuen Pods auf den Knoten in diesem Pool geplant.
6. Führt die Aktualisierung Knoten für Knoten weiter, bis alle Knoten im Pool aktualisiert wurden.

So funktionieren Surge-Updates

In GKE on AWS werden mit der standardmäßigen rollierenden Methode Knoten nacheinander aktualisiert. Mit Surge-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 Arbeitslasten unterbrechen. Surge-Updates bieten Optionen, um das Ausmaß der Unterbrechung Ihrer Arbeitslasten zu regulieren.

Surge-Updates können sich außerdem von standardmäßigen Rolling Updates unterscheiden, indem Knoten ersetzt werden. Mit der Strategie „Vor dem Erstellen beenden“ werden Knoten mit Standard Rolling Updates ersetzt. Abhängig von den ausgewählten Einstellungen können Surge-Updates entweder die Strategie „Vor dem Beenden erstellen“, „Vor dem Erstellen beenden“ oder sogar eine Kombination aus beidem verwenden.

Cluster-Autoscaling spielt bei Surge-Updates eine wichtigere Rolle als bei standardmäßigen Rolling Updates. Daher ist es in der folgenden Liste der Aktionen, die GKE on AWS während eines Surge-Updates ausführt, an erster Stelle:

1. Erstellen einer neuen Autoscaling-Gruppe: GKE on AWS stellt neue Knoten mit den im Update-Befehl angegebenen Änderungen bereit und weist diese einer neuen AWS-Autoscaling-Gruppe (ASG) zu.
2. Verhalten von Cluster-Autoscaling: Zu Beginn der Surge-Aktualisierung wird Cluster-Autoscaling für die neue Autoscaling-Gruppe aktiviert. Das Cluster-Autoscaling für die ursprüngliche Autoscaling-Gruppe wird deaktiviert. Dadurch wird sichergestellt, dass alle Skalierungsvorgänge nur auf die neue Gruppe ausgerichtet sind.
3. Knotenaustausch: Abhängig von den Surge-Update-Parametern werden unterschiedliche Strategien für den Knotenaustausch verwendet:
   • „create before least“ (vor dem Beenden erstellen): Diese Strategie wird aktiviert, wenn der Parameter max-surge-update auf einen Wert größer als null gesetzt wird. Es erstellt neue Knoten in der neuen ASG, bevor die alten in der 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. Knoten aus der ursprünglichen ASG werden zuerst beendet, gefolgt von der Erstellung neuer Knoten in der neuen ASG.
4. Anpassungen der Knotenpoolgröße: Während der Aktualisierung kann die Knotenpoolgröße (d. h. die Summe der Knoten in der alten und der neuen ASG) über oder unter der ursprünglichen Anzahl von Knoten im Knotenpool vor Beginn der Aktualisierung schwanken. Insbesondere zielt GKE on AWS darauf ab, die Gesamtzahl der Knoten im Bereich von (original_count – max-unavailable-update) bis (original_count + max-surge-update) zu halten. Schließlich werden die Knoten in der alten ASG (original_count) durch aktualisierte Knoten in der neuen ASG ersetzt. Das Cluster-Autoscaling startet möglicherweise mehr Knoten in der neuen ASG, wenn es erkennt, dass Pods nicht geplant werden können, aber innerhalb der durch min-nodes und max-nodes definierten Limits bleibt.

Ein Beispiel zur Veranschaulichung des Prozesses

Betrachten Sie das folgende Beispiel, um die Funktionsweise von Surge-Updates besser zu verstehen. 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 gesetzt und Sie stellen eine neue Knotenpoolversion bereit (d. h., Sie ändern die GKE-Version, die auf den Knoten im Knotenpool ausgeführt wird).

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

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

Während dieser Aktualisierung enthält der Knotenpool 4 bis 7 operative Knoten.

Was du vor dem Ausführen von Surge-Updates beachten solltest

Beachten Sie Folgendes, bevor Sie ein Surge-Update ausführen:

• Zusätzliche Instanzen, die im Rahmen dieses Surge-Schritts erstellt werden, können möglicherweise Ihr Kontingentlimit für AWS-Instanzen überschreiten. Wenn Ihr Kontingent nicht ausreicht und diese zusätzlichen Instanzen nicht bereitgestellt werden können, schlägt die Aktualisierung möglicherweise fehl.
• Wenn max-unavailable-update auf 0 gesetzt ist, können Arbeitslasten trotzdem unterbrochen werden, da Pods entfernt und auf die 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 beschränkt.

Die passenden Surge-Einstellungen für deine Anforderungen auswählen

Während standardmäßige Rolling Updates häufig den Ansatz „Vor dem Erstellen beenden“ verwenden, bieten Surge-Updates mehr Flexibilität. Abhängig von der Konfiguration können Surge-Updates einer Strategie vom Typ „Erstellen vor dem Beenden“, der Strategie „Vor dem Erstellen beenden“ oder einer Kombination aus beidem folgen. In diesem Abschnitt werden verschiedene Konfigurationen beschrieben, damit Sie den besten Ansatz für Ihre Arbeitslasten auswählen können.

Die folgende Tabelle zeigt drei Beispieleinstellungen und hebt ihre Auswirkungen auf die Aktualisierungsgeschwindigkeit und die potenzielle Unterbrechung Ihrer Arbeitslasten hervor:

Name	Beschreibung	Configuration
Ausgeglichene Einstellung (Standardeinstellung)	Ausgewogen, langsamer, aber am wenigsten störend.	maxSurge=1, maxNicht verfügbar=0
Schnelle Updates ohne zusätzliche Ressourcen	Schnell, keine Surge-Ressourcen, äußerst störend.	maxSurge=0, maxNicht verfügbar=20
Schnelle, weniger störende Updates	Schnell, die meisten Surge-Ressourcen und weniger störend.	maxSurge=20, maxNicht verfügbar=0

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

Ausgeglichene Einstellung (Standardeinstellung)

Die einfachste Methode für die Verwendung von Surge-Updates 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. Nach dem Erstellen vor dem Beenden wird jeweils nur ein Knoten aktualisiert. Im Vergleich zum standardmäßigen Rolling 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.

Beachten Sie, dass die Übernahme der Einstellung „Ausgeglichen“ zusätzliche Kosten verursachen kann, da der temporäre Surge-Knoten während der Aktualisierung hinzugefügt wird. Für diesen zusätzlichen Knoten fallen Gebühren an, solange er aktiv ist, wodurch die Gesamtkosten im Vergleich zu Methoden ohne Surge-Knoten leicht steigen.

Schnelle Updates ohne zusätzliche Ressourcen

Bei Arbeitslasten, die Unterbrechungen tolerieren können, ist möglicherweise ein schnellerer Updateansatz geeignet. Dafür müssen Sie max-surge-update=0 und max-unavailable-update=20 konfigurieren. Mit dieser Konfiguration können 20 Knoten gleichzeitig aktualisiert werden, ohne dass Surge-Knoten hinzugefügt werden müssen. Diese Aktualisierungsmethode folgt dem Ansatz "Vor dem Erstellen beenden". Da während des Prozesses keine zusätzlichen Surge-Knoten hinzugefügt werden, ist diese Methode auch die kostengünstigste, sodass zusätzliche Kosten im Zusammenhang mit temporären Knoten vermieden werden.

Schnelle, weniger störende Updates

Wenn Ihre Arbeitslasten empfindlich auf Unterbrechungen reagieren, können Sie die Geschwindigkeit der Aktualisierung mit den folgenden Einstellungen erhöhen: max-surge-update=20 und max-unavailable-update=0. Durch diese Konfiguration werden 20 Knoten gleichzeitig mit der Erstellung vor dem Beenden aktualisiert.

Die Gesamtgeschwindigkeit der Aktualisierung kann jedoch eingeschränkt werden, wenn Sie PodDisruptionBudgets (PDB) für Ihre Arbeitslasten eingerichtet haben. Dies 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 nur ein Pod dieser Arbeitslasten gleichzeitig entfernt werden, wenn Sie für eine oder mehrere Arbeitslasten, die im Knotenpool ausgeführt werden, ein PDB mit maxUnavailable gleich 1 erstellen. Dadurch wird die Parallelität der gesamten Aktualisierung eingeschränkt.

Denken Sie daran, dass das Initiieren mehrerer Surge-Knoten zu Beginn des Aktualisierungsvorgangs zu einem vorübergehenden Kostenanstieg führen kann, insbesondere im Vergleich zu Konfigurationen, bei denen während eines Updates keine zusätzlichen Knoten 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.