Upgrade von Standardclustern

Auf dieser Seite wird erläutert, wie automatische und manuelle Upgrades in Standardclustern 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 mit minimalen Unterbrechungen für Ihre Arbeitslasten auf dem aktuellen Stand halten, sodass Sie stabil und sicher ausgeführt werden.

Weitere Informationen zur Anwendung von Clusterupgrades für Autopilot finden Sie unter Upgrade von Autopilot-Clustern.

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.

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 (in der Regel ein paar Tage, abhängig vom aktuellen Release) zwischen dem Abschluss des Upgrade der Steuerungsebene des Clusters und dem Beginn des Upgrades eines bestimmten Knotenpools. Weitere Informationen finden Sie in den Versionshinweisen.

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. Standardmäßig werden Knoten nacheinander in einer nicht definierten Reihenfolge aktualisiert. Sie können die Anzahl der Knoten ändern, die zusammen mit Surge-Upgrades aktualisiert werden.

In einem Knotenpool, der über mehrere Zonen verteilt ist, werden Upgrades für jede Zone einzeln ausgeführt. Innerhalb einer Zone werden die Knoten in einer nicht definierten Reihenfolge aktualisiert.

Während des Upgrades eines Knotenpools können Sie keine Änderungen an der Clusterkonfiguration vornehmen, es sei denn, Sie brechen das Upgrade ab.

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:

GKE berücksichtigt Wartungsfenster oder Ausschlüsse, wenn möglich für automatische Upgrades. Manuelle Upgrades umgehen die konfigurierten Wartungsfenster und -ausschlüsse.

Wenn GKE einen Knoten aktualisiert, geschieht Folgendes:

  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 Zielknoten) aus, der aktualisiert werden soll. Es sperrt den Zielknoten und beginnt damit, ihn per Drain zu beenden. Zu diesem Zeitpunkt kann GKE keine neuen Pods auf dem Zielknoten planen.
    • PodDisruptionBudget wird bis zu einer Stunde lang beachtet. Wenn der Zielknoten nach einer Stunde nicht vollständig per Drain beendet wurde, löscht GKE die verbleibenden Pods und der Upgradeprozess wird fortgesetzt.
    • GracefulTerminationPeriod ist auf eine Stunde begrenzt.
  3. Die Steuerungsebene verschiebt Pods, die von Controllern verwaltet werden, auf andere Knoten. Pods, die nicht neu geplant werden können, verbleiben in der Phase Ausstehend bis sie geplant werden können.
  4. Wenn ein Surge-Knoten erstellt wurde, wird der Zielknoten gelöscht. Wenn kein Surge-Knoten erstellt wurde, aktualisiert GKE den Zielknoten, nachdem er entfernt wurde, und wartet auf die Registrierung des aktualisierten Knotens auf der Steuerungsebene.

Automatisches Upgrade

Wenn Sie einen Standardcluster erstellen, sind automatische Upgrades für den Cluster und dessen Knotenpools standardmäßig aktiviert.

Google ist für die Sicherung der Steuerungsebene Ihres Clusters verantwortlich und aktualisiert die Cluster, wenn eine neue GKE-Version für das automatische Upgrade ausgewählt wird. Die Infrastruktursicherheit hat für GKE höchste Priorität. Daher werden die Steuerungsebenen regelmäßig aktualisiert und können nicht deaktiviert werden. Sie können jedoch Wartungsfenster und -ausschlüsse anwenden, um Upgrades für Steuerungsebenen und Knoten vorübergehend zu blockieren.

Im Rahmen des Modells der geteilten Verantwortung sind Sie für die Sicherung der Knoten, Container und Pods verantwortlich. Das automatische Upgrade von Knoten ist standardmäßig aktiviert. Sie können das automatische Upgrade von Knoten deaktivieren. Dieser Vorgang wird jedoch nicht empfohlen. Durch das Deaktivieren von automatischen Knotenupgrades wird nicht das Upgrade der Steuerungsebene des Clusters blockiert. Wenn Sie automatische Knotenupgrades deaktivieren, müssen Sie dafür sorgen, dass auf den Knoten des Clusters eine Version ausgeführt wird, die mit der Version des Clusters kompatibel ist, und dass die Version der Supportrichtlinie für Kubernetes-Versionen und Versionsinkompatibilität entspricht.

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, wird auf Knoten immer dieselbe GKE-Version wie auf dem Cluster selbst ausgeführt, außer während einer kurzen Zeitperiode. Diese umfasst in der Regel nur wenige Tage, abhängig vom aktuellen Release, zwischen dem Abschluss des Upgrade der Steuerungsebene des Clusters und dem Beginn der Aktualisierung eines bestimmten Knotenpools. Weitere Informationen finden Sie in den Versionshinweisen.

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, um die Sicherheit der Infrastruktur zu wahren. 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.

Wie GKE auf Fehler bei automatischen Upgrades reagiert

Automatische Upgrades von Knotenpools können aufgrund von Problemen mit den zugrunde liegenden Compute Engine-Instanzen oder aufgrund von Problemen mit Kubernetes fehlschlagen. Automatische Upgrades schlagen beispielsweise in folgenden Situationen fehl:

  • Die von Ihnen konfigurierte Einstellung maxSurge überschreitet Ihr Compute Engine-Ressourcenkontingent.
  • Neue Surge-Knoten wurden nicht auf der Clustersteuerungsebene registriert.
  • Das Drain der Knoten dauerte zu lange oder das Löschen dauerte zu lange.

Wenn Probleme bei einzelnen Knotenupgrades auftreten, wiederholt GKE das Upgrade einige Male, mit einem zunehmenden Zeitabstand zwischen den Versuchen. Wenn für Knoten im Knotenpool kein Upgrade gelingt, führt GKE kein Rollback der aktualisierten Knoten durch. Stattdessen versucht GKE das automatische Upgrade des Knotenpools so lange, bis alle Knoten erfolgreich aktualisiert wurden.

Wenn Ihre Knotenupgrades fehlschlagen, weil Ihre Surge-Knotenanfragen Ihr Compute Engine-Kontingent überschreiten, reduziert GKE die Anzahl der gleichzeitigen Surge-Knoten, um zu versuchen, das Kontingent einzuhalten und das Upgrade fortzusetzen.

Benachrichtigungen zu Upgrades erhalten

GKE veröffentlicht Benachrichtigungen zu Ereignissen, die für Ihren Cluster relevant sind, z. B. Versionsupgrades und Sicherheitsbulletins, in Pub/Sub, damit Sie einen Kanal für den Empfang von GKE-Informationen zu Ihrem Cluster haben.

Weitere Informationen finden Sie unter Clusterbenachrichtigungen erhalten.

Nächste Schritte