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.

Zum Upgrade eines Clusters aktualisiert GKE die Version, mit der die Steuerungsebene und die Knoten ausgeführt werden. Cluster werden entweder auf eine neuere Nebenversion (z. B. 1.24 bis 1.25) oder eine neuere Patchversion (z. B. 1.24.2-gke.100 auf 1.24.5-gke.200) aktualisiert. Weitere Informationen finden Sie unter Versionsverwaltung und Support für GKE.

Wenn Sie einen Cluster in einer Release-Version registrieren, führen Knoten dieselbe Version von GKE wie der Cluster aus, mit Ausnahme einer kurzen Zeit (in der Regel einige Tage, je nach aktueller Version) zwischen dem Abschluss des Upgrade der Steuerungsebene des Clusters und dem Starten des Knotenpool-Upgrades oder wenn das Upgrade der Steuerungsebene manuell durchgeführt wurde. 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

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 innerhalb eines Knotenpools auch nacheinander in einer nicht definierten Reihenfolge aktualisiert. In einem Knotenpool, der über mehrere Zonen verteilt ist, finden Upgrades Zone für Zone statt. Innerhalb einer Zone werden die Knoten in einer nicht definierten Reihenfolge aktualisiert.

Bei GKE-Knotenpool-Upgrades können Sie zwischen konfigurierbaren, integrierten Upgradestrategien wählen, bei denen Sie den Upgradeprozess an die Anforderungen Ihrer Clusterumgebung anpassen können. Weitere Informationen zu Surge- und Blau/Grün-Upgradestrategien finden Sie unter Upgradestrategien.

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

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

Wie ein Knotenupgrade in einem Knotenpool durchgeführt wird, hängt Upgradestrategie des Knotenpools und von ihrer Konfiguration ab. Die grundlegenden Schritte bleiben jedoch konsistent. Zum Upgrade eines Knotens entfernt GKE Pods aus dem Knoten, damit ein Upgrade durchgeführt werden kann.

Folgendes passiert mit den Pods, wenn ein Knoten aktualisiert wird:

  1. Der Knoten wird gesperrt, sodass Kubernetes keine neuen Pods auf dem Knoten plant.
  2. Der Knoten wird dann geleert, d. h., die Pods werden entfernt. Bei Surge-Upgrades berücksichtigt GKE bis zu eine Stunde lang die Einstellungen PodDisruptionBudget und GracefulTerminationPeriod des Pods. Bei Blau/Grün-Upgrades kann dies verlängert werden, wenn Sie eine längere Vorlaufzeit konfigurieren.
  3. Die Steuerungsebene verschiebt Pods, die von Controllern verwaltet werden, auf andere Knoten. Pods, die nicht umgeplant werden können, bleiben in der Phase "Ausstehend", bis sie umgeplant werden können.

Der Upgradevorgang des Knotenpools kann je nach Upgradestrategie, Anzahl der Knoten und deren Arbeitslastkonfigurationen einige Stunden dauern.

Hinweise zur Dauer der Knotenaktualisierung

Zu den Konfigurationen, die dazu führen können, dass ein Knotenupgrade länger dauert, sind folgende:

Strategien für das Upgrade des Knotenpools

GKE bietet integrierte konfigurierbare Strategien, mit denen festgelegt wird, wie der Knotenpool aktualisiert wird.

Surge-Upgrades

Standardmäßig wird die Surge-Upgrade-Strategie für Knotenpool-Upgrades verwendet. Surge-Upgrades verwenden eine rollierende Methode zum Upgraden von Knoten. Diese Strategie eignet sich am besten für Anwendungen, die inkrementelle, unterbrechungsfreie Änderungen verarbeiten können. Bei dieser Strategie werden Knoten in einem rollierenden Zeitfenster aktualisiert. Mit den Einstellungen können Sie ändern, wie viele Knoten gleichzeitig aktualisiert werden können und wie umfangreich die Upgrades sein können. So finden Sie das optimale Verhältnis von Geschwindigkeit und möglicher Unterbrechung für die Anforderungen Ihrer Umgebung.

Blau/Grün-Upgrades

Der alternative Ansatz sind Blau/Grün-Upgrades, bei denen zwei Gruppen von Umgebungen (die ursprüngliche und die neue Umgebung) gleichzeitig bestehen, was das Rollback möglichst einfach macht. Blau/Grün ist ressourcenintensiver und besser für Anwendungen, die empfindlicher auf Änderungen reagieren. Bei dieser Strategie werden Arbeitslasten nach und nach von der ursprünglichen "blauen" Umgebung in die neue "grüne" Umgebung migriert und erhalten Vorlaufzeit, um sie mit der neuen Konfiguration zu validieren. Bei Bedarf können die Arbeitslasten schnell in die vorhandene "blaue" Umgebung zurückgesetzt werden.

Weitere Informationen zur Funktionsweise von Upgrade-Strategien für Knotenpools finden Sie unter Upgrade-Strategien für Knotenpools.

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.

Faktoren, die sich auf die Zeitplanung des Roll-outs einer Version auswirken

Zur Beibehaltung von Stabilität und Zuverlässigkeit von Clustern bei neuen Versionen folgt GKE bestimmten Verfahren während des Roll-outs.

Hier die wichtigsten Verfahren:

  • GKE führt Änderungen schrittweise in Google Cloud-Regionen und -Zonen ein.
  • GKE führt Patchversionen schrittweise in Release-Versionen ein. Ein Patch erhält Vorlaufzeit im Rapid Release Channel, dann im Regular Release Channel, bevor er zur stabilen Release-Version hochgestuft wird, nachdem er Nutzung angesammelt und Stabilität bewiesen hat. Wenn während der Vorlaufzeit in einer Release-Version ein Problem mit einer Patchversion auftritt, wird diese Version nicht zum nächsten Channel hochgestuft und das Problem wird bei einer neueren Patchversion behoben.
  • GKE führt schrittweise Nebenversionen ein. Dabei wird ein ähnlicher Vorlaufprozess wie bei Patchversionen angewendet. Nebenversionen haben längere Vorlaufzeiten, da die eingeführten Änderungen größer sind.
  • GKE kann automatische Upgrades verzögern, wenn sich eine neue Version auf eine Gruppe von Clustern auswirkt. Beispielsweise pausiert GKE automatische Upgrades für Cluster, die erkannt werden, auf eine verworfene API oder Funktion, die in der nächsten Nebenversion entfernt wird.
  • GKE kann die Einführung neuer Versionen zu Spitzenzeiten (z. B. an Feiertagen) verzögern, um für Geschäftskontinuität zu sorgen.

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.

Beziehung zum Kontingent

Surge-Upgrades und Blau/Grün-Upgrades erfordern möglicherweise zusätzliche Rechenressourcen. Surge-Upgrades erstellen zusätzliche VMs (wenn maxSurge auf einen Wert größer als 0 festgelegt ist) und Blau/Grün-Upgrades verdoppeln vorübergehend die Anzahl der Knoten in einem Knotenpool.

Wenn Sie die zusätzlichen Rechenressourcen minimieren möchten, die für Upgrades erforderlich sind, verwenden Sie Surge-Upgrades und setzen Sie maxSurge auf 0. Mit dieser Konfiguration können Sie vermeiden, dass GKE zusätzliche Knoten bei Änderungen der Knotenkonfiguration erstellt, bei denen die Knoten neu erstellt werden müssen. Weitere Informationen zu den Arten von Änderungen, die eine Strategie für Knotenpool-Upgrades verwenden, finden Sie unter Wenn GKE Surge-Upgrades verwendet und Wenn GKE Blau/Grün-Upgrades verwendet.

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.

Wie Sie prüfen, ob Ihr Projekt genügend Ressourcen für Surge-Upgrades hat, erfahren Sie unter Knotenupgrades und Kontingente prüfen. Bei Blau/Grün-Upgrades benötigt Ihr Projekt die doppelte Anzahl der Ressourcen, die vom Knotenpool verwendet werden.

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.

Upgrade-Logs prüfen

GKE-Logs für Steuerungsebenen und Knotenpool-Upgrades werden standardmäßig auf Cloud Logging protokolliert. Das Upgrade-Ereignislog bietet einen Einblick in den Upgrade-Prozess und enthält bei Bedarf wertvolle Informationen zur Fehlerbehebung.

Upgradelogs der Steuerungsebene

Clusterupgrade-Ereignisse können mit dem folgenden Filter abgefragt werden:

resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

Diese Logs werden als strukturierte Logging-Formate aufgezeichnet. In den folgenden Feldern finden Sie Details zu den Upgrade-Ereignissen:



Feld Beschreibung
protoPayload.metadata.operationType Es gibt zwei Arten von Cluster-Upgrade-Ereignissen: UPGRADE_MASTER und UPDATE_CLUSTER.
UPGRADE_MASTER ändert die Version der Kubernetes-Steuerungsebene.
UPDATE_CLUSTER bedeutet, dass ein Update die Version der Kubernetes-Steuerungsebene nicht ändert.
Beide Clusterupgrade-Typen können zum Verlust der Verfügbarkeit der Steuerungsebene für zonale Cluster führen. Weitere Informationen finden Sie unter Funktionsweise von Cluster- und Knotenpool-Upgrades.
protoPayload.methodName Dieses Feld zeigt, welche API das Cluster-Upgrade ausgelöst hat.
google.container.v1.ClusterManager.UpdateCluster: manuelles Upgrade der Steuerungsebene
google.container.internal.ClusterManagerInternal.UpdateClusterInternal: automatisches Upgrade der Steuerungsebene
google.container.v1.ClusterManager.PatchCluster: Änderung der Clusterkonfiguration
protoPayload.metadata.previousMasterVersion Dieses Feld wird nur für den Vorgangstyp MASTER_UPGRADE verwendet und enthält die Version der Steuerungsebene, die vor dem Upgrade verwendet wurde.
protoPayload.metadata.currentMasterVersion Dieses Feld wird nur für den Vorgangstyp MASTER_UPGRADE verwendet und enthält die neue Versionsnummer für die Steuerungsebene, die nach dem Upgrade verwendet wird.

Upgrade-Logs für Knotenpools

Verwenden Sie die folgende Abfrage, um Upgrade-Ereignisse von Knotenpools anzuzeigen: 

resource.type="gke_nodepool"
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"

Verwenden Sie das folgende Feld, um Details zum Upgrade-Ereignis zu erhalten:

protoPayload.methodName zeigt an, ob das Upgrade manuell oder automatisch ausgelöst wurde.

Nächste Schritte