Cluster-Upgrades

Auf dieser Seite wird erläutert, wie automatische und manuelle Upgrades in GKE-Clustern (Google Kubernetes Engine) funktionieren. Außerdem enthält die Seite Links zu weiteren Informationen über ähnliche 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.

Funktionsweise von Upgrades für Cluster und Knotenpools

In diesem Abschnitt wird erläutert, was bei automatischen oder manuellen Upgrades in Clustern geschieht. Bei automatischen Upgrades initiiert Google das automatische Upgrade. Google beobachtet automatische und manuelle Upgrades in allen GKE-Clustern und greift bei Problemen ein.

Ein Cluster wird vor seinen Knoten aktualisiert.

Clusterupgrades

In diesem Abschnitt wird erläutert, was zu erwarten ist, wenn Google Ihre Cluster automatisch aktualisiert oder Sie ein manuelles Upgrade durchführen.

  • Zonale Cluster haben nur eine einzige Steuerungsebene. Während des Upgrades werden Arbeitslasten weiter ausgeführt. Sie können jedoch erst neue Arbeitslasten bereitstellen, vorhandene Arbeitslasten ändern oder andere Änderungen an der Clusterkonfiguration vornehmen, wenn das Upgrade abgeschlossen ist.

  • Regionale Cluster haben mehrere Replikate der Steuerungsebene. Die Replikate werden jeweils einzeln in einer nicht festgelegten Reihenfolge aktualisiert. Während des Upgrades bleibt der Cluster hochverfügbar und jedes Replikat der Steuerungsebene ist nur während der Aktualisierung nicht verfügbar.

Wenn Sie ein Wartungsfenster oder einen Wartungsausschluss konfigurieren, werden diese nach Möglichkeit berücksichtigt.

Knotenpool-Upgrades

Ein Cluster und die zugehörigen Knotenpools haben nicht unbedingt dieselbe Version von GKE. In diesem Abschnitt wird erläutert, was zu erwarten ist, wenn Google Knotenpools automatisch aktualisiert oder Sie bei Knotenpools ein manuelles Upgrade durchführen.

Knotenpools werden nacheinander aktualisiert. Innerhalb eines Knotenpools werden Knoten nacheinander in einer nicht definierten Reihenfolge aktualisiert. Sie können die Anzahl der Knoten ändern, die gleichzeitig aktualisiert werden.

Dieser Vorgang kann je nach Anzahl der Knoten und deren Arbeitslastkonfigurationen mehrere Stunden dauern. Zu den Konfigurationen, die die Rate der Knotenupgrades verlangsamen können, gehören:

Wenn Sie ein Wartungsfenster oder einen Wartungsausschluss konfigurieren, werden diese nach Möglichkeit berücksichtigt.

Das passiert, wenn ein Knoten aktualisiert wird:

  1. Wenn Surge-Upgrades aktiviert sind, erstellt GKE einen neuen Surge-Knoten mit der aktualisierten Version und wartet auf die Registrierung bei der Steuerungsebene.
  2. GKE wählt einen vorhandenen Knoten (den wir Zielknoten nennen) für das Upgrade aus. Es sperrt den Zielknoten und beginnt damit, ihn per Drain zu beenden. Zu diesem Zeitpunkt kann GKE keine neuen Pods auf dem Zielknoten planen.
  3. Pods auf dem Zielknoten werden auf andere Knoten umgeplant. Wenn ein Pod nicht umgeplant werden kann, verbleibt dieser Pod im Status PENDING, bis er umgeplant werden kann.
  4. Wenn in Schritt 1 ein Surge-Knoten erstellt wurde, wird der Zielknoten gelöscht. Wenn kein Surge-Knoten erstellt wurde, aktualisiert GKE den Zielknoten und wartet anschließend auf die Registrierung des Knotens.
  5. Wenn eine beträchtliche Anzahl von automatischen Knotenupgrades für eine bestimmte Version zu fehlerhaften Knoten im GKE-Bestand führt, werden Upgrades auf diese Version angehalten, während das Problem untersucht wird.

Automatisches Upgrade

Wenn Sie einen Cluster mit der Google Cloud Console erstellen, ist das automatische Upgrade für den Cluster und dessen Knotenpools standardmäßig aktiviert. Google aktualisiert die Cluster, wenn eine neue GKE-Version für das automatische Upgrade ausgewählt ist.

Wenn Sie einen Cluster mit dem Befehl gcloud oder der GKE API erstellen, ist das automatische Upgrade für Knoten derzeit standardmäßig aktiviert. Informationen zur manuellen Deaktivierung finden Sie unter Knoten automatisch upgraden.

Wenn Sie besser steuern möchten, wann automatische Upgrades erfolgen können bzw. nicht erfolgen dürfen, können Sie Wartungsfenster und -ausschlüsse konfigurieren.

Die Knotenpools eines Clusters dürfen nicht mehr als zwei Nebenversionen hinter der Version der Steuerungsebene sein. Nur so bleiben sie mit der Cluster-API kompatibel. Die Knotenpoolversion bestimmt auch die Versionen der Softwarepakete, die auf jedem Knoten installiert sind. Deshalb sollten Knotenpools immer auf die Clusterversion aktualisiert sein.

Wenn Sie einen Cluster in einer Release-Version registrieren, führen Knoten immer dieselbe Version von GKE wie der Cluster selbst aus. Das gilt nicht für einen kurzen Zeitraum zwischen dem Abschluss des Upgrade der Steuerungsebene des Clusters und dem Beginn des Upgrades eines bestimmten Knotenpools.

Versionsauswahl für automatische Upgrades

Neue GKE-Versionen werden zwar regelmäßig veröffentlicht. Es wird jedoch nicht sofort eine Version für automatische Upgrades ausgewählt. Wenn eine GKE-Version genügend Cluster-Nutzung angesammelt hat und damit nachweislich stabil ist, wählt Google sie als automatisches Ziel-Upgrade für Cluster aus, die eine Teilmenge älterer Versionen ausführen.

Neue Versionen für automatische Upgrades werden in den Versionshinweisen angekündigt. Solange keine verfügbare Version für ein automatisches Upgrade ausgewählt ist, können Sie ein manuelles Upgrade durchführen. Gelegentlich wird eine Version für automatische Cluster-Upgrades und automatische Knoten-Upgrades in unterschiedlichen Wochen ausgewählt.

Kurz nachdem eine neue Nebenversion allgemein verfügbar wird, wird die älteste verfügbare Nebenversion in der Regel nicht mehr unterstützt. Cluster, die nicht mehr unterstützte Nebenversionen ausführen, werden automatisch auf die nächste Nebenversion aktualisiert.

In einer Nebenversion (z. B. Version 1.14.x) können Cluster automatisch auf ein neues Patch-Release aktualisiert werden.

Mit Release-Versionen können Sie die Version von Clustern und Knotenpools anhand der Stabilität einer Version steuern, anstatt die Version direkt zu verwalten.

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.

Manuelle Upgrades

Sie können jederzeit ein manuelles Upgrade eines Clusters oder seiner Knotenpools auf eine verfügbare und kompatible Version vornehmen. Manuelle Upgrades umgehen alle konfigurierten Wartungsfenster und -ausschlüsse.

Wenn Sie einen Cluster manuell aktualisieren, hängt seine Verfügbarkeit davon ab, ob der Cluster regional ist oder nicht:

  • Bei zonalen Clustern ist die Steuerungsebene während des Upgrades nicht verfügbar. Arbeitslasten werden in der Regel normal ausgeführt, können aber während des Upgrades nicht geändert werden.

  • Bei regionalen Clustern ist während des Upgrades jeweils nur ein Replikat der Steuerungsebene nicht verfügbar. Der Cluster bleibt jedoch während des Upgrades hochverfügbar.

Sie können Knoten-Upgrades manuell auf eine Version initiieren, die mit der Steuerungsebene kompatibel ist.

Surge-Upgrades

Mit Surge-Upgrades können Sie steuern, wie viele Knoten GKE gleichzeitig aktualisieren kann, und steuern, wie stark Upgrades Ihre Arbeitslasten stören dürfen.

Upgrade-Einstellungen ändern, um Geschwindigkeit und Unterbrechung auszugleichen

Sie können die Anzahl der Knoten ändern, die GKE gleichzeitig aktualisiert. Ändern Sie dazu die Parameter für Surge-Upgrades in einem Knotenpool. Surge-Upgrades sorgen bei Arbeitslasten für weniger Unterbrechungen während der Clusterwartung. Außerdem ermöglichen sie Ihnen, die Anzahl von parallel aktualisierten Knoten zu steuern. Surge-Upgrades arbeiten auch mit dem Cluster Autoscaler zusammen, um Änderungen an Knoten zu verhindern, die aktualisiert werden.

Das Verhalten von Surge-Upgrades bestimmt sich durch zwei Einstellungen:

max-surge-upgrade

Die Anzahl zusätzlicher Knoten, die während eines Upgrades dem Knotenpool hinzugefügt werden können. Durch Erhöhen von max-surge-upgrade wird die Anzahl der Knoten erhöht, die gleichzeitig aktualisiert werden können. Der Standardwert ist 1. Er kann auf 0 oder höher eingestellt werden.

max-unavailable-upgrade

Die Anzahl der Knoten, die während eines Upgrades gleichzeitig nicht verfügbar sind. Der Standardwert ist 0. Durch Erhöhen von max-unavailable-upgrade wird die Anzahl von Knoten erhöht, die parallel aktualisiert werden können.

Die Anzahl der gleichzeitig aktualisierten Knoten ist die Summe von max-surge-upgrade und max-unavailable-upgrade. Dabei ist die maximale Anzahl gleichzeitig aktualisierter Knoten auf 20 beschränkt.

Beispiel: Ein Pool mit fünf Knoten wird erstellt, wobei max-surge-upgrade auf 2 gesetzt und max-unavailable-upgrade auf 1 gesetzt wird. Während eines Upgrade des Knotenpools erstellt GKE zwei aktualisierte Knoten. GKE beendet nach der Bereitstellung der aktualisierten Knoten höchstens drei Knoten, d. h. die Summe von max-surge-upgrade und max-unavailable-upgrade. Zugleich gilt, dass GKE maximal jeweils einen Knoten nicht verfügbar macht (max-unavailable-upgrade). Während des Upgrades enthält der Knotenpool zwischen vier und sieben Knoten.

Sie können Parameter für Surge-Upgrades für Knotenpools konfigurieren, die automatische Upgrades und manuelle Upgrades verwenden. In dieser Anleitung finden Sie weitere Informationen und können Surge-Upgrades testen: "Surge-Upgrades verwenden, um Störungen durch GKE-Knoten-Upgrades zu reduzieren".

Optimale Surge-Konfiguration ermitteln

Die folgende Tabelle stellt drei verschiedene Upgrade-Einstellungen als Demonstration dar, damit Sie die verschiedenen Konfigurationen besser verstehen können:

Beschreibung Konfiguration
Ausgeglichen (Standardeinstellung), langsamer, aber am wenigsten störend maxSurge=1 maxUnavailable=0
Schnell, keine Surge-Ressourcen, am störendsten maxSurge=0 maxUnavailable=20
Schnell, die meisten Surge-Ressourcen und weniger störend maxSurge=20 maxUnavailable=0

Ausgeglichen (Standardeinstellung)

Die einfachste Möglichkeit, die Vorteile von Surge-Upgrades zu nutzen, ist die Konfiguration von maxSurge=1 maxUnavailable=0.. Dies bedeutet, dass während eines Upgrades nur ein Surge-Knoten zum Knotenpool hinzugefügt werden kann, sodass jeweils nur ein Knoten aktualisiert wird. Diese Einstellung ist der vorhandenen Upgradekonfiguration (maxSurge=0 maxUnavailable=1) überlegen, da sie Pod-Neustarts während Upgrades beschleunigt und dabei konservativ voranschreitet.

Schnell und keine Surge-Ressourcen

Wenn Ihre Arbeitslast nicht störungsanfällig ist, wie bei den meisten Batchjobs, können Sie mithilfe von maxSurge=0 maxUnavailable=20 den Fokus auf Geschwindigkeit legen. Bei dieser Konfiguration werden keine zusätzlichen Surge-Knoten erstellt und es können 20 Knoten gleichzeitig aktualisiert werden.

Schnell und weniger störend

Wenn Ihre Arbeitslast störungsanfällig ist und Sie bereits PodDisruptionBudgets (PDB) eingerichtet haben und nicht externalTrafficPolicy: Local verwenden (da es nicht zusammen mit parallelen Knotendrains funktioniert), können Sie die Geschwindigkeit des Upgrades mithilfe von maxSurge=20 maxUnavailable=0 erhöhen. Bei dieser Konfiguration werden 20 Knoten gleichzeitig aktualisiert, während das PDB die Anzahl der Pods begrenzt, die zu einer bestimmten Zeit 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.

Beziehung zum Kontingent

Für die Neuerstellung von Knoten sind keine zusätzlichen Compute Engine-Ressourcen erforderlich. Für Surge-Upgrades hingegen benötigen Sie zusätzliche Ressourcen. Die Ressourcenzuweisung unterliegt einem Compute Engine-Kontingent. Je nach Konfiguration kann dieses Kontingent die Anzahl der parallelen Upgrades begrenzen oder sogar dazu führen, dass das Upgrade fehlschlägt.

Weitere Informationen zu Kontingenten finden Sie unter Knotenupgrades und -kontingente.

Benachrichtigungen zu Upgrades 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 Cluster-Upgrades erhalten.

Nächste Schritte