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:
- Ein hoher Wert von terminationGracePeriodSeconds in der Konfiguration eines Pods.
- Ein konservatives Budget zur Pod-Unterbrechung.
- Interaktionen mit Knotenaffinität.
- Angehängte PersistentVolumes.
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:
- Wenn Surge-Upgrades aktiviert sind, erstellt GKE einen neuen Surge-Knoten mit der aktualisierten Version und wartet auf die Registrierung bei der Steuerungsebene.
- 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.
- 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.
- 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 ist1
. Er kann auf0
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 vonmax-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
- Weitere Informationen zu den Cluster-Typen
- Upgrade an Clustern oder zugehörigen Knoten ausführen
- Wartungsfenster und -Wartungsausschlüsse konfigurieren
- Best Practices für das Upgrade von Clustern