Versionsverwaltung und Unterstützung für GKE

---

Auf dieser Seite werden die Versionsverwaltung in Google Kubernetes Engine (GKE) und die Richtlinien für die Versionsunterstützung erläutert. Den aktuellen Release- und Unterstützungszeitplan finden Sie im GKE-Releasezeitplan.

Hinweis: Die Versionsverwaltung der Kubernetes API erfolgt getrennt von Kubernetes. Informationen zur Versionsverwaltung der Kubernetes API finden Sie in der Dokumentation zur Kubernetes API.

Versionsunterstützung

Der GKE-Support für Kubernetes-Nebenversionen basiert auf den Open-Source-Richtlinien von Kubernetes. GKE unterstützt eine Nebenversion, indem es Patchversionen derselben Nebenversion bereitstellt und Cluster regelmäßig automatisch auf diese neueren Patches aktualisiert.

Unterstützung von Nebenversionen in Kubernetes

Die Kubernetes Open-Source Software-Community (OSS) veröffentlicht dreimal pro Jahr eine Nebenversion mit neuen Funktionen und Verbesserungen. Jeder Releasezyklus ist etwa 15 Wochen lang.

Kubernetes unterstützt jede Nebenversion 14 Monate lang. Wichtige Fehler und Sicherheitslücken, die in einer unterstützten Nebenversion gefunden werden, werden mit dem Release einer Ad-hoc-Patchversion behoben. Die Kubernetes-Community ändert den Kalender derVersionsunterstützung bei Bedarf. Weitere Informationen finden Sie unter Supportzeitraum.

Unterstützung von Nebenversionen in GKE

Nachdem Kubernetes eine neue Nebenversion veröffentlicht hat, wird sie zuerst im Rapid-Kanal eingeführt. Während dieser Zeit stellt GKE Patchversionen bereit. Da der Rapid Channel die neuesten GKE-Versionen bereitstellt, sind diese Versionen von der GKE-SLA ausgenommen und können Probleme ohne bekannte Abhilfemaßnahmen enthalten.

Nach der Erstveröffentlichung im Rapid Channel wird die neue Nebenversion von GKE in den regulären Kanal übernommen. GKE bietet insgesamt bis zu 24 Monate Unterstützung für eine Nebenversion, nachdem die Version für die Erstellung neuer Cluster im regulären Kanal zur Verfügung gestellt wurde. Dieser Support umfasst etwa 14 Monate Standardsupport und ungefähr 10 weitere Monate erweiterten Support, der mit dem Extended-Kanal verfügbar ist. Informationen zur Verfügbarkeit bestimmter Nebenversionen finden Sie im GKE-Releasezeitplan.

Lebenszyklus von GKE-Nebenversionen

Der Lebenszyklus einer GKE-Nebenversion umfasst die folgenden wichtigen Schritte:

1. Kubernetes veröffentlicht eine neue Nebenversion.
2. GKE stellt die neue Nebenversion im Rapid-Kanal zur Verfügung.
3. GKE stellt die neue Nebenversion im regulären Kanal zur Verfügung (Beginn des Standard-Supportzeitraums).
4. Während des Standard-Supportzeitraums stellt GKE Patches für die Nebenversion bereit, die neue Funktionen, Sicherheits- und Fehlerkorrekturen enthalten.
5. Nach insgesamt etwa 14 Monaten endet der Standardsupport für die Nebenversion und der erweiterte Support beginnt. Danach stellt GKE Sicherheitspatches für Cluster im Extended-Kanal bereit.
6. Die Nebenversion erreicht das Ende des erweiterten Supports. Das bedeutet, dass sie keine weiteren Sicherheitspatches mehr erhält.

Anpassungen der Verfügbarkeit von Versionen

GKE kann das Ende der Supportzeit für GKE-Versionen aufgrund von Richtlinienänderungen in der Kubernetes-OSS-Community, dem Auffinden von Sicherheitslücken oder anderen technischen Problemen, die nicht angemessen behoben werden können, anpassen. Bei GKE kann es auch vorkommen, dass die Supportzeiträume um wichtige Geschäftszeiten wie Black Friday und Cyber Monday herum verlängert werden.

GKE bietet mindestens 14 Monate Standardsupport und mit erweitertem Support bis zu insgesamt 24 Monate Support.

Die neuesten verfügbaren Versionen finden Sie in den GKE-Versionshinweisen. GKE aktualisiert den Releasezeitplan regelmäßig, um die Auführungszeit der automatischen Upgrades widerzuspiegeln.

Verfügbarkeitszeiten im Lebenszyklus einer Nebenversion

GKE bietet die folgenden Verfügbarkeitszeiten für Kubernetes-Nebenversionen:

In der folgenden Tabelle sind die Verfügbarkeitszeiträume zusammengefasst, die in den nächsten Abschnitten ausführlich beschrieben werden:

Verfügbarkeitszeitraum	Ungefähre Zeitspanne nach der Verfügbarkeit im Regular Channel	Welche Unterstützung bietet GKE?	Zugriff auf diesen Zeitraum
Verfügbarkeitszeitraum nur für die Rapid-Variante	Monat −1 bis Monat 0	GKE stellt Patchversionen mit neuen Funktionen, Sicherheits- und Fehlerkorrekturen bereit. Diese Versionen sind jedoch von der GKE-SLA ausgenommen und können Probleme ohne bekannte Abhilfemaßnahmen enthalten.	Nur Rapid-Kanal
Standard-Supportzeitraum	Monat 1 bis Monat 14	GKE stellt Patchversionen mit neuen Funktionen, Sicherheits- und Fehlerkorrekturen bereit.	Rapid, Regelmäßig, Stabil, Erweitert, Kein Kanal
Verlängerte Supportdauer	15. bis 24. Monat	GKE bietet Patchversionen mit Sicherheitskorrekturen.	Nur im erweiterten Kanal (erfordert GKE Enterprise oder eine zusätzliche Gebühr pro Cluster, siehe Langzeitsupport mit dem erweiterten Kanal erhalten)

Zeitraum der ausschließlichen Verfügbarkeit der Rapid-Version

Neue Nebenversionen von GKE werden zuerst im Rapid Channel veröffentlicht. Die Version wird zuerst in diesem Kanal clusterübergreifend genutzt und muss sich als stabil erweisen, bevor sie zum Regular Channel hochgestuft wird. Nur Cluster, die für den Rapid Channel registriert sind, können während dieses Zeitraums eine neue Nebenversion ausführen.

Dieser Zeitraum dauert in der Regel etwa 1 bis 2 Monate. Die genaue Dauer hängt jedoch von der jeweiligen Nebenversion ab. Weitere Informationen finden Sie unter Geschätzter Zeitplan für Release-Kanäle.

Standard-Supportzeitraum

Der Standard-Supportzeitraum für eine GKE-Nebenversion beginnt, wenn die Version im Regular Channel veröffentlicht wird. Alle GKE-Cluster können unabhängig von der Registrierung für eine Release-Version eine Nebenversion im Rahmen des Standardsupports ausführen. Während dieses Zeitraums werden Cluster von GKE regelmäßig automatisch auf neue Patchversionen aktualisiert, die neue Funktionen, Sicherheits- und Fehlerkorrekturen enthalten.

GKE führt automatische Upgrades von Clustern auf folgende Weise durch:

• Rapid, Regulär, Stabil, Kein Kanal: Automatische Upgrades auf andere unterstützte Nebenversionen oder Patchversionen derselben Nebenversion.
• Erweitert: GKE führt nur automatisch ein Upgrade auf neuere Patchversionen derselben Nebenversion durch.

Bei Clustern, die nicht für den erweiterten Release-Kanal registriert sind, führt GKE vor Ablauf des Standardsupports automatisch ein Upgrade auf die nächste unterstützte Nebenversion durch. Dabei wird der Zeitplan für die Release-Version des Clusters berücksichtigt. Weitere Informationen finden Sie unter Geschätzter Zeitplan für Release-Kanäle. In dieser Zeit werden Cluster von GKE jedoch nicht aktualisiert, wenn sie eingestellte Funktionen oder APIs verwenden. Mit einem Wartungsausschluss können Sie vorübergehend verhindern, dass GKE Ihren Cluster auf die nächste Nebenversion aktualisiert.

Ende des Standardsupports (früher End of Life)

Hinweis: In GKE wurde der Begriff End of Life bisher für das Datum verwendet, an dem der Standardsupport endet. Mit der Einführung des erweiterten Supports haben wir diesen Begriff aktualisiert, um die verschiedenen Supportzeiträume für eine GKE-Nebenversion widerzuspiegeln.

Nach dem Standard-Supportzeitraum erreicht die Nebenversion das Ende des Standardsupports (früher End of Life) und wird für alle Cluster, die nicht im erweiterten Kanal registriert sind, nicht mehr unterstützt und ist auch nicht mehr verfügbar.

Kunden, die eine Version verwenden, für die der Support bald endet, werden vor dem Ende des Supports einer Version mit einer E-Mail an den Projektkontakt benachrichtigt. GKE führt aus Sicherheits- und Kompatibilitätsgründen nach und nach auch automatische Upgrades von Knoten (unabhängig von der Aktivierung von automatischen Upgrades) aus, die nicht unterstützte Versionen ausführen, da für End-of-Support-Versionen keine neuen Sicherheitspatches oder Fehlerkorrekturen bereitgestellt werden. Bevor Sie sich an Cloud Customer Care bei Problemen mit einem Cluster oder Knoten mit einer nicht unterstützten Version wenden, müssen Sie zuerst Ihren Cluster und Ihre Knoten auf eine unterstützte Version aktualisieren.

GKE-Nebenversionen, die das Ende des Supports erreicht haben, erhalten keine Sicherheitspatches oder Fehlerkorrekturen mehr. Patchversionen einer Nebenversion, deren Supportzeitraum abgelaufen ist, werden nicht weiter unterstützt und sind auch nicht mehr verfügbar. GKE führt automatisch Upgrades für alle Cluster durch, die nicht im erweiterten Kanal registriert sind. Weitere Informationen finden Sie unter Automatische Upgrades am Ende des Supports.

Zeitraum des erweiterten Supports

Nach dem Ende des Standardsupports beginnt der erweiterte Supportzeitraum (15. bis 24. Monat). In diesem Zeitraum stellt GKE Patches für Sicherheitskorrekturen bereit, darunter die folgenden Arten von Korrekturen:

• Sicherheits-Patches mit mittlerem, hohem und kritischem Schweregrad für die wichtigsten Kubernetes-Komponenten, das Knotenbetriebssystem und von Google verwaltete Container, die mit der GKE-Clusterversion gebündelt sind.
• Bei Container-Optimized OS kann das Ende des Supports für das Knotenbetriebssystem vor dem Ende des erweiterten Supports für die GKE-Nebenversion eintreten. Ss können auch inkompatible Änderungen eingeführt werden. Weitere Informationen dazu, wie GKE weiterhin Support bietet, finden Sie unter Updates für Container-Optimized OS während des erweiterten Supportzeitraums.

Gegen Ende des erweiterten Supports beginnt GKE mit dem Upgrade von Clustern auf die nächste Nebenversion. GKE führt keine Clusterupgrades durch, wenn verworfene Features oder APIs verwendet werden. Mit einem Wartungsausschluss können Sie vorübergehend verhindern, dass GKE Ihren Cluster auf die nächste Nebenversion aktualisiert.

Ende des erweiterten Supports

Nach Ablauf des erweiterten Supports stellt GKE keine Sicherheitspatches mehr bereit und die Nebenversion wird als nicht unterstützt eingestuft. GKE aktualisiert Cluster, auf denen noch die nicht unterstützte Nebenversion ausgeführt wird, auf die nächste Nebenversion, unabhängig davon, ob im Cluster verworfene Funktionen oder APIs verwendet werden.

Automatische Upgrades am Ende des Supports

GKE plant für Cluster automatische Upgrades von einer Nebenversion auf die nächste unterstützte Nebenversion, bevor die Nebenversion das Ende des Supports erreicht. Die Ausführungszeit dieses Upgrades hängt vom Zeitplan der Release-Version des Clusters ab. Weitere Informationen finden Sie unter Geschätzter Zeitplan für Release-Kanäle. Cluster, die im Stable Channel registriert sind, werden beispielsweise näher am Ende des Standardsupports auf die nächste Nebenversion aktualisiert als Cluster, die im Regular Channel registriert sind.

Während des Standard-Supportzeitraums und des erweiterten Supportzeitraums für Cluster, die für den erweiterten Release-Kanal registriert sind, können Sie Upgrades auf eine Nebenversion mit einem Wartungsausschluss verhindern. GKE führt dann keine Upgrades für Cluster durch, die verworfene Funktionen oder APIs verwenden.

Am Ende des Standardsupports oder am Ende des erweiterten Supports für Cluster, die für den erweiterten Kanal registriert sind, führt GKE jedoch automatisch ein Upgrade auf die nächste unterstützte Nebenversion durch, damit der Cluster leistungsfähig, verfügbar und sicher bleibt.

Jede GKE-Version wird 14 Monate lang mit Standardsupport und insgesamt 24 Monate lang mit erweitertem Support unterstützt. Sie können Ihren Cluster nicht unbegrenzt mit einer Version ausführen, da der Betrieb eines Clusters mit einer nicht unterstützten GKE-Version ein erhebliches Sicherheits-, Zuverlässigkeits- und Kompatibilitätsrisiko darstellt. GKE stellt keine Sicherheitspatches oder Fehlerkorrekturen für Versionen bereit, für die der Support eingestellt wurde. GKE kann sich nicht verpflichten, Patches oder Updates für Versionen bereitzustellen, deren Support eingestellt wurde.

GKE führt das Upgrade des Clusters so durch:

• Steuerungsebene: GKE aktualisiert Clustersteuerungsebenen automatisch auf unterstützte Versionen, wenn die Version der Steuerungsebene nicht mehr für die Erstellung neuer Cluster verfügbar ist.
• Knoten: GKE aktualisiert automatisch Knoten, auf denen eine nicht unterstützte Version ausgeführt wird, nachdem die Version den Ende des Supports erreicht hat, um den Zustand des Clusters und die Ausrichtung an der Richtlinie zur GKE-Versionsinkompatibilität sicherzustellen. Für Knoten, auf denen nicht unterstützte Versionen ausgeführt werden, wird innerhalb eines Monats nach dem Ende des Supports in der Regel ein automatisches Upgrade auf eine unterstützte Version geplant. Knoten, die nicht unterstützte Versionen ausführen, werden möglicherweise nicht sofort nach dem Ende der Lebensdauer aktualisiert. Der tatsächliche Zeitpunkt kann nach Ermessen von Google variieren.

Updates für Container-Optimized OS während des erweiterten Supports

Während des erweiterten Supports für eine GKE-Nebenversion bietet GKE Patch-Upgrades für den Cluster an, die auch Updates für das Container-Optimized OS umfassen können.

Die Unterstützung für die LTS-Version von Container-Optimized OS endet vor der Unterstützung der Nebenversion

Der LTS-Release von Container-Optimized OS wird möglicherweise vor dem Ende des erweiterten Supports für die Nebenversion eingestellt, die das Release verwendet. In diesem Fall verwendet GKE nach Möglichkeit das nächsten verfügbaren LTS-Release von Container-Optimized OS für zukünftige Patch-Upgrades. GKE führt dieses Update durch, bevor die LTS-Version von Container-Optimized OS, die von der Nebenversion der Knoten verwendet wird, das Ende des Supports erreicht. Clusteradministratoren müssen entscheiden, ob sie ein Upgrade auf die nächste GKE-Patchversion durchführen möchten, die eine neue LTS-Version von Container-Optimized OS enthält, oder bei der vorhandenen GKE-Patchversion bleiben, um keine Updates für das Knoten-Betriebssystem und auch keine Sicherheits-Patches für die wichtigsten Kubernetes-Komponenten zu erhalten, die mit der GKE-Clusterversion gebündelt sind.

Die nächste LTS-Version von Container-Optimized OS enthält Änderungen, die nicht mit der vorhandenen Nebenversion kompatibel sind

Die nächste LTS-Version von Container-Optimized OS kann Inkompatibilitäten mit den GKE-Systemkomponenten verursachen. GKE kann dann keine Patchversion mit Updates für das Knotenbetriebssystem bereitstellen. Clusteradministratoren müssen entscheiden, ob sie ein Upgrade auf die nächste GKE-Nebenversion ausführen möchten, oder die im vorherigen Abschnitt beschriebenen Vor- und Nachteile berücksichtigen.

Versionsverwaltungsschema

GKE hängt eine GKE-Patchversion an den semantisch versionierten Kubernetes-Branchenstandard (x.y.z-gke.N) an:

Kubernetes-Hauptversion (x)

Hauptversionen werden in der Regel erhöht, wenn nicht abwärtskompatible Änderungen an der öffentlichen API vorgenommen werden. Eine Hauptversion erhöht die Kubernetes-Version von x.y auf x+1.y.

Kubernetes-Nebenversion (y)

Kubernetes veröffentlicht dreimal pro Jahr eine neue Nebenversion. Jeder Releasezyklus ist etwa 15 Wochen lang. Verworfene APIs können mit einer neuen Nebenversion entfernt werden, z. B. mit 1.22. Eine Nebenversion erhöht die Kubernetes-Version von 1.y auf 1.y+1. Kubernetes 1.32 ist z. B. die Nebenversion, die auf Kubernetes 1.31 folgt.

Kubernetes Patchrelease (z)

Neue Kubernetes-Patchreleases (z. B. 1.32.6) für GKE werden in der Regel wöchentlich veröffentlicht. Der Rollout der Patchreleases in jeder Zone erfolgt schrittweise.

GKE-Patchrelease (-gke.N)

Ein Patchrelease mit dem Suffix -gke.N (z. B. 1.32.6-gke.N) kann Sicherheitsupdates und Fehlerkorrekturen für GKE sowie die Open-Source-Upstream-Kubernetes-Software enthalten. Diese Updates oder Fehlerkorrekturen sind für die Kompatibilität und Interoperabilität mit Google Cloud erforderlich.

Verfügbare und als Standard festgelegte Versionen auflisten

Informationen zu verfügbaren Versionen finden Sie in den GKE-Versionshinweisen.

Sie können in der Google Cloud Console oder mithilfe der Google Cloud CLI auch prüfen, welche Kubernetes-Versionen verfügbar und in einer bestimmten Zone als Standard festgelegt sind.

Mit der Google Cloud Console Versionen prüfen

Hinweis: Versionen, die älter als die Standardversion für einen Kanal sind, sind nur über die gcloud CLI und die Kubernetes Engine API sichtbar.

So rufen Sie die Standard- und andere verfügbare Versionen auf:

1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

   Zur Seite „Google Kubernetes Engine“

2. Klicken Sie auf Erstellen.

3. Wählen Sie den Clustermodus Standard aus und klicken Sie dann auf Konfigurieren.

4. Wählen Sie im Abschnitt Standorttyp einen Standorttyp und den gewünschten Standort für den Cluster aus.

5. Wählen Sie im Abschnitt Version der Steuerungsebene eine Release-Version aus. Alle derzeit verfügbaren Versionen werden für diesen Kanal aufgelistet. Die Standardversion ist automatisch ausgewählt.

Hinweis: Wenn Sie vor Abschluss eines Versionsrollouts in der Google Cloud Console einen Cluster erstellen, werden die verfügbaren Versionen für Ihre Zone möglicherweise nicht korrekt angezeigt.

Versionen mit der gcloud-CLI prüfen

Führen Sie einen der folgenden gcloud-Befehle für Ihren Clustertyp aus, um zu sehen, welche Versionen verfügbar sind und welche standardmäßig verwendet werden. Jeder Tab enthält Befehle zum Prüfen der Versionen für einen bestimmten Release-Kanal oder für keinen Kanal (statisch).

Rapid

Führen Sie die folgenden Befehle aus, um die Standardversion und die verfügbaren Versionen im Releasekanal Rapid anzusehen:

Standardversion

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=RAPID" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Verfügbare Versionen

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=RAPID" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Ersetzen Sie dabei Folgendes:

• COMPUTE_LOCATION: einen Compute Engine-Standort.

Regulär

Führen Sie die folgenden Befehle aus, um die Standardversion und die verfügbaren Versionen im Releasekanal Regular anzusehen:

Standardversion

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=REGULAR" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Verfügbare Versionen

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=REGULAR" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Ersetzen Sie dabei Folgendes:

• COMPUTE_LOCATION: einen Compute Engine-Standort.

Stabil

Führen Sie die folgenden Befehle aus, um die Standardversion und die verfügbaren Versionen im Releasekanal Stable anzusehen:

Standardversion

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=STABLE" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Verfügbare Versionen

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=STABLE" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Ersetzen Sie dabei Folgendes:

• COMPUTE_LOCATION: einen Compute Engine-Standort.

Erweitert

Führen Sie die folgenden Befehle aus, um die Standardversion und die verfügbaren Versionen im Releasekanal Extended anzusehen:

Standardversion

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=EXTENDED" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Verfügbare Versionen

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=EXTENDED" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Ersetzen Sie dabei Folgendes:

• COMPUTE_LOCATION: einen Compute Engine-Standort.

Kein Kanal

Führen Sie die folgenden Befehle aus, um die Standardversion und die verfügbaren Versionen für einen Channel (statisch) aufzurufen:

Standardversion

gcloud container get-server-config \
   --format="yaml(defaultClusterVersion)" \
   --location=COMPUTE_LOCATION

Verfügbare Versionen der Steuerungsebene

gcloud container get-server-config \
   --format="yaml(validMasterVersions)" \
   --location=COMPUTE_LOCATION

Verfügbare Knotenversionen

gcloud container get-server-config \
   --format="yaml(validNodeVersions)" \
   --location=COMPUTE_LOCATION

Ersetzen Sie dabei Folgendes:

• COMPUTE_LOCATION: einen Compute Engine-Standort.

Hinweis: Für eine fortgeschrittene get-server-config-Ausgabebearbeitung, siehe die gcloud-Dokumentation unter Filtern und Formatieren.

Clusterversion angeben

Dieser Abschnitt gilt nur für Cluster, die im Standardmodus erstellt werden.

Wenn Sie einen Cluster mit der CLI erstellen oder aktualisieren, können Sie mit dem Flag --cluster-version eine Clusterversion angeben. Sie können wahlweise eine bestimmte Version wie 1.9.7-gke.N oder einen Versionsalias verwenden:

• latest: Gibt die höchste unterstützte Kubernetes-Version an, die derzeit in GKE in der Zone oder Region des Clusters verfügbar ist.
• 1.X: Gibt den höchsten gültigen Patchrelease Patch+gke.N in der Nebenversion 1.x an.
• 1.X.Y: Gibt den höchsten gültigen Patch gke.N im Patchrelease 1.xY an.
• -: Gibt für Cluster-Steuerungsebenen die Kubernetes-Standardversion für Steuerungsebenen an. Bei Knotenupgrades wird die Version angegeben, die von der Cluster-Steuerungsebene ausgeführt wird.

Wenn Sie bei der Erstellung oder Aktualisierung eines Clusters für die Version latest angeben, werden keine automatischen Upgrades bereitgestellt. Aktivieren Sie automatische Knotenupgrades, wenn Sie gewährleisten möchten, dass auf den Knoten in Ihrem Cluster immer die neueste stabile Version ausgeführt wird.

Knotenversion angeben

Dieser Abschnitt gilt nur für Cluster, die im Standardmodus erstellt werden. In Autopilot-Clustern werden Knoten automatisch auf die Version der Steuerungsebene aktualisiert. Sie können keine Version angeben.

Wenn Sie einen Knotenpool erstellen oder upgraden, können Sie dessen Version angeben. Standardmäßig führen Knoten dieselbe Version von GKE wie die Steuerungsebene aus. Knoten können maximal zwei Nebenversionen älter als Steuerungsebenen sein.

Mit wenigen Ausnahmen bleiben Knotenversionen auch dann verfügbar, wenn die Clusterversion nicht mehr verfügbar ist.

Richtlinie zu Abweichungen bei GKE-Versionen

Die GKE-Richtlinie zur Versionsinkompatibilität sorgt dafür, dass in einem GKE-Cluster die Kompatibilität zwischen der Steuerungsebene und den Knoten erhalten bleibt. In einem GKE-Cluster können Knoten mit der Version der Steuerungsebene übereinstimmen oder bis zu zwei Nebenversionen älter sein als die Steuerungsebene.

Die Knoten dürfen keine Versionen ausführen, die neuer als die Version der Steuerungsebene sind. Wenn auf der Steuerungsebene des Clusters beispielsweise Version 1.31 ausgeführt wird, können auf den Knoten die folgenden Versionen ausgeführt werden: 1.31, 1.30 oder 1.29, aber nicht 1.28 oder niedriger. Die Version der Knoten darf aufgrund der Richtlinie zur Kubernetes OSS-Versionskompatibilität nicht neuer als die Version der Steuerungsebene sein.

Um die Unterstützbarkeit und Zuverlässigkeit sicherzustellen, sollten die Knoten eine unterstützte Version verwenden, unabhängig von einer gültigen Versionsabweichung.

Unterstützung für das Überspringen von Nebenversionen

GKE erlaubt das Überspringen von Nebenversionen für die Cluster-Steuerungsebene nicht. Sie können jedoch Patchversionen überspringen. Worker-Knoten können Nebenversionen überspringen. Ein Knotenpool kann beispielsweise von Version 1.32 auf 1.34 aktualisiert werden, sodass Version 1.33 übersprungen wird.

Wenn Sie einen Cluster über mehreren Nebenversionen hinweg aktualisieren möchten, führen Sie für die Steuerungsebene jeweils ein Upgrade um eine Nebenversion durch und upgraden Sie Ihre Worker-Knoten jedes Mal auf dieselbe Version. Wenn Sie beispielsweise die Steuerungsebene von Version 1.32 auf 1.34 aktualisieren möchten, führen Sie zuerst ein Upgrade von Version 1.32 auf 1.33 und dann ein Upgrade Ihrer Worker-Knoten entsprechend der Version der Steuerungsebene durch. Wiederholen Sie dann den Vorgang für das Upgrade von Version 1.33 auf 1.34.

Durch ein Upgrade der Worker-Knoten auf die entsprechenden Versionen können Sie nicht unterstützte Versionsinkompatibilitäten vermeiden. Sie sollten das Überspringen von Versionen nach Möglichkeit vermeiden. Das Überspringen von Worker-Knoten-Versionen impliziert im Allgemeinen einen größeren Testbereich, der zwar machbar ist, aber weitere Überlegungen erfordert.

Alternativ können Sie einen neuen Cluster mit der gewünschten Version erstellen und Ihre Arbeitslasten noch einmal bereitstellen.