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. Im Laufe der Zeit aktualisiert GKE Cluster auf neuere Kubernetes-Versionen. Weitere Informationen zur Funktionsweise von Upgrades finden Sie unter Informationen zu GKE-Cluster-Clusterupgrades.

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.

Unterstützung von Nebenversionen

Die GKE-Unterstützung für Kubernetes-Nebenversionen basiert auf Kubernetes-Open-Source-Richtlinien. Um verfügbare Nebenversionen während ihres Lebenszyklus zu unterstützen, stellt GKE Patchversionen bereit und führt regelmäßig automatische Clusterupgrades durch, um diese neueren Patches anzuwenden. Informationen dazu, wie GKE Patchversionen unterstützt, finden Sie unter Unterstützung für Patchversionen.

Zusätzlich zur Unterstützung verfügbarer Nebenversionen bietet GKE auch Alpha-Patchversionen der nächsten Nebenversion im Kubernetes-Releasezyklus bis zu vier Monate vor der Verfügbarkeit dieser Nebenversion für alle Cluster im Rapid Channel. Diese Alphaversionen sind nur für GKE-Alphacluster im Rapid Channel verfügbar und richten sich an Erstanwender, die mit anstehenden Funktionen experimentieren möchten.

Wie Kubernetes eine Nebenversion unterstützt

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 findest du im Abschnitt Supportzeitraum.

Unterstützung von Nebenversionen durch GKE

Vor der Veröffentlichung einer stabilen neuen Nebenversion veröffentlicht das Kubernetes-Projekt experimentelle, instabile Patchversionen dieser Nebenversion. GKE führt Alpha-Patchversionen, die auf diesen experimentellen Versionen im Rapid-Channel basieren, nur für GKE-Alpha-Cluster ein. Ähnlich wie andere Patchversionen im Rapid Channel sind Alphaversionen von der GKE-SLA ausgenommen.

Nachdem Kubernetes die stabile neue Nebenversion veröffentlicht hat, entfernt GKE die Alphaversionen dieser Nebenversion und stellt Patchversionen für diese Nebenversion für alle Cluster im Rapid Channel zur Verfügung. Da der Rapid Channel die neuesten GKE-Patchversionen 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 Regular Channel übernommen. Die GKE bietet insgesamt bis zu 24 Monate Support für eine Nebenversion, nachdem die Version für die Erstellung neuer Cluster im Regular-Kanal verfügbar gemacht 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-Veröffentlichungszeitplan.

Lebenszyklus von GKE-Nebenversionen

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

1. Bis zu vier Monate vor dem Veröffentlichungsdatum einer Nebenversion stellt GKE Alpha-Patchversionen für diese Nebenversion im Rapid Channel nur für Alpha-Cluster zur Verfügung.
2. Kubernetes veröffentlicht die neue Nebenversion.
3. GKE stellt die neue Nebenversion im Rapid-Kanal zur Verfügung und entfernt alle vorhandenen Alpha-Patchversionen für diese Nebenversion.
4. GKE stellt die neue Nebenversion im regulären Kanal zur Verfügung (Beginn des Standard-Supportzeitraums).
5. Während des Standard-Supportzeitraums stellt GKE Patches für die Nebenversion bereit, die neue Funktionen, Sicherheits- und Fehlerkorrekturen enthalten.
6. Die Nebenversion erreicht das Ende des Standardsupports nach insgesamt etwa 14 Monaten und geht dann in den Zeitraum des erweiterten Supports über. Danach stellt GKE Sicherheitspatches für Cluster im Extended-Kanal bereit.
7. Die Nebenversion erreicht das Ende des erweiterten Supports. Das bedeutet, dass für die Nebenversion keine weiteren Sicherheitspatches mehr bereitgestellt werden.

Anpassungen der Versionsverfügbarkeit

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.

Die GKE bietet mindestens 14 Monate Standardsupport und bis zu 24 Monate Support mit erweitertem 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ügbarkeitszeiträume im Lebenszyklus der 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 Verfügbarkeitszeitraum
Verfügbarkeitszeitraum der Alphaversion	Monat -5 bis Monat -1	Die GKE führt neue Alpha-Patchversionen im Rapid Channel ein, bis der Zeitraum der ausschließlichen Verfügbarkeit der Rapid-Version beginnt. Die Alpha-Patchversionen sind nur für Alpha-Cluster verfügbar, haben keinen technischen Support oder SLA und enthalten mit hoher Wahrscheinlichkeit Probleme. Wenn die Nebenversion am Ende des Zeitraums, in dem nur Alpha-Versionen verfügbar sind, für alle Cluster im Rapid Channel verfügbar ist, entfernt GKE alle Alpha-Versionen aus dem Rapid Channel.	Nur Rapid Channel (erfordert Alpha-Cluster)
Verfügbarkeitszeitraum nur für die Rapid-Variante	Monat -1 bis Monat 0	Die GKE stellt die Nebenversion für alle Cluster im Rapid Channel zur Verfügung, indem sie Patchversionen mit neuen Funktionen, Sicherheitsverbesserungen und Fehlerkorrekturen bereitstellt. Diese Versionen sind jedoch von der GKE-SLA ausgenommen und können Probleme ohne bekannte Abhilfemaßnahmen enthalten. GKE entfernt auch alle verfügbaren Alphaversionen für diese Nebenversion aus dem Rapid-Kanal.	Nur Rapid-Kanal
Standard-Supportzeitraum	Monat 1 bis Monat 14	Die GKE stellt Patchversionen mit neuen Funktionen, Sicherheitsverbesserungen und Fehlerkorrekturen bereit.	Rapid, Regelmäßig, Stabil, Erweitert, Kein Kanal (eingestellt)
Verlängerter Supportzeitraum	Monat 15 bis Monat 24	Die GKE stellt Patchversionen mit Sicherheitsverbesserungen bereit.	Nur Extended Channel (erfordert zusätzliche Gebühr pro Cluster, siehe Langzeitsupport mit dem Extended Channel erhalten)

Zeitraum der Verfügbarkeit der Alphaversion

GKE veröffentlicht Alpha-Patchversionen einer anstehenden Nebenversion im Rapid Channel bis zu vier Monate vor der Veröffentlichung dieser Nebenversion. Die Alpha-Versionen sind nur für Alpha-Cluster verfügbar. GKE veröffentlicht in den folgenden Wochen zusätzliche Alpha-Patchversionen und verwaltet in der Regel zwischen einer und drei aktive Alpha-Versionen.

Dieser Zeitraum dauert, bis GKE die stabile Nebenversion im Rapid Channel veröffentlicht. Nach dem stabilen Release entfernt GKE alle Alpha-Patchversionen für diese Nebenversion aus dem Rapid Channel, da stabile Patchversionen zur Installation verfügbar sind.

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–2 Monate. Der genaue Zeitpunkt hängt jedoch von der jeweiligen Nebenversion ab. Weitere Informationen finden Sie unter Geschätzter Zeitplan für Release-Versionen.

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 aktualisiert die GKE Cluster regelmäßig automatisch auf neue Patchversionen, die neue Funktionen, Sicherheits- und Fehlerkorrekturen enthalten.

GKE aktualisiert Cluster automatisch so:

• Rapid, Regulär, Stabil, Kein Kanal (eingestellt): Automatische Upgrades auf andere unterstützte Nebenversionen oder Patchversionen derselben Nebenversion.
• Erweitert: GKE führt nur automatische Upgrades 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-Versionen. GKE aktualisiert Cluster in diesem Zeitraum jedoch nicht, 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: GKE hat zuvor den Begriff End of Life verwendet, um das Ende des Standardsupports zu bezeichnen. 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, die das Ende des Supportzeitraums erreicht hat, werden vor dem Ende des Supportzeitraums einer Version per E-Mail an den Projektkontakt benachrichtigt. Die GKE beginnt außerdem, Knoten, auf denen nicht unterstützte Versionen ausgeführt werden, schrittweise automatisch zu aktualisieren (unabhängig davon, ob automatische Upgrades aktiviert sind). Dies dient der Sicherheit und Kompatibilität, da für Versionen, die das Ende des Supports erreicht haben, 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. Die GKE aktualisiert automatisch alle Cluster, die nicht in der erweiterten Version registriert sind. Weitere Informationen finden Sie unter Automatische Upgrades am Ende des Supports.

Zeitraum des erweiterten Supports

Nach dem Ende des Standardsupports erreicht die Nebenversion den Zeitraum des erweiterten Supports (Monat 15 bis Monat 24). Während dieses Zeitraums stellt GKE Patches für Sicherheitskorrekturen bereit, darunter die folgenden Arten von Korrekturen:

• Sicherheitspatches mit mittlerem, hohem und kritischem Schweregrad für Kubernetes-Kernkomponenten, das Knotenbetriebssystem und von Google verwaltete Container, die in der GKE-Clusterversion enthalten 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. Es können auch inkompatible Änderungen eingeführt werden. Weitere Informationen dazu, wie die 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. Die GKE führt keine Upgrades von Clustern durch, die verworfene 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 erweiterten Supports

Nach Ablauf des erweiterten Supports stellt die GKE keine Patches für Sicherheitskorrekturen mehr bereit und die Nebenversion gilt als nicht unterstützt. Die GKE führt Upgrades von Clustern, auf denen noch die nicht unterstützte Nebenversion ausgeführt wird, auf die nächste Nebenversion durch, unabhängig davon, ob der Cluster verworfene Funktionen oder APIs verwendet.

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-Versionen. 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 Wartungsausschlüssen auf Clusterebene verhindern oder indem Sie festlegen, welche Arten von Upgrades GKE in einer Roll-out-Sequenz durchführt. Außerdem führt die GKE keine Upgrades von Clustern 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 der Cluster auf die nächste unterstützte Nebenversion durch, um dafür zu sorgen, dass der Cluster leistungsfähig, verfügbar und sicher bleibt.

Jede GKE-Nebenversion wird 14 Monate lang im Rahmen des Standardsupports und insgesamt 24 Monate lang unterstützt, einschließlich des erweiterten Supports. Sie können Ihren Cluster nicht unbegrenzt mit einer Nebenversion ausführen, da der Betrieb eines Clusters mit einer nicht unterstützten GKE-Nebenversion ein erhebliches Sicherheits-, Zuverlässigkeits- und Kompatibilitätsrisiko darstellt. GKE stellt keine Sicherheitspatches oder Fehlerkorrekturen für Nebenversionen bereit, für die der Support eingestellt wurde. Die GKE kann sich nicht verpflichten, Patches oder Updates für Nebenversionen am Ende des Supports bereitzustellen.

GKE aktualisiert den Cluster so:

• 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 Nebenversion ausgeführt wird, nachdem die Nebenversion das 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 Nebenversionen ausgeführt werden, wird innerhalb eines Monats nach dem Ende des Supports in der Regel ein automatisches Upgrade auf eine unterstützte Nebenversion geplant. Knoten, die nicht unterstützte Nebenversionen ausführen, werden möglicherweise nicht sofort nach dem Ende der Lebensdauer aktualisiert. Der tatsächliche Zeitpunkt kann nach Ermessen von Google variieren.

Ebenso aktualisiert die GKE die Cluster-Steuerungsebenen, die innerhalb von 90 Tagen nicht auf eine neue Version aktualisiert wurden. Weitere Informationen finden Sie unter 90-Tage-Patchrichtlinie für die Steuerungsebene.

Vorübergehende Notfallverhinderung automatischer Upgrades am Ende des Supports

Als vorübergehende Maßnahme, die nur in Notfällen verwendet werden sollte, wenn keine anderen Optionen verfügbar sind, können Sie die automatischen Upgrades am Ende des Supports um bis zu 90 Tage nach dem Ende des Supports verzögern. Dazu konfigurieren Sie einen Wartungsausschluss mit dem Standardbereich „Keine Upgrades“. Wir raten davon ab, da die Ausführung einer nicht unterstützten Version mit Risiken verbunden ist. Nach Ablauf des Wartungsausschlusses aktualisiert GKE den Cluster.

Cluster identifizieren, auf denen eine Nebenversion nach dem Ende des Standardsupports ausgeführt wird

Die GKE identifiziert Cluster, die beide der folgenden Bedingungen erfüllen:

• Auf der Steuerungsebene wird eine Nebenversion ausgeführt, die das Ende des Standardsupports erreicht hat.
• Der Cluster ist nicht für den erweiterten Release-Kanal registriert.

Die GKE empfiehlt, diese Cluster zu aktualisieren, da die Ausführung einer nicht unterstützten Nebenversion mit Risiken verbunden ist. Die GKE aktualisiert Cluster auf die nächste unterstützte Nebenversion, wenn die vorhandene Version in der Release-Version des Clusters nicht unterstützt wird.

GKE stellt diese Anleitung mit einer Statistik und Empfehlung über den Recommender-Dienst bereit. Diese Anleitung gilt nicht für Cluster, die für den Extended Channel registriert sind. Diese können bis zum Ende des erweiterten Supports weiterhin eine Nebenversion ausführen. Weitere Informationen zum Verwalten von Statistiken und Empfehlungen von Recommendern finden Sie unter Nutzung von GKE mit Statistiken und Empfehlungen optimieren.

So finden Sie Cluster, auf denen die Steuerungsebene eine Version nach dem Ende des Supports ausführt:

• Verwenden Sie die Google Cloud Console.
• Verwenden Sie die gcloud CLI oder die Recommender API und geben Sie den Recommender-Untertyp CLUSTER_VERSION_END_OF_LIFE an.

Eine Anleitung finden Sie unter Statistiken und Empfehlungen ansehen.

Wenn Sie diese Empfehlung umsetzen möchten, aktualisieren Sie die Steuerungsebene Ihres Clusters auf eine unterstützte Nebenversion. Informationen zu unterstützten Nebenversionen und zum Ende des Supports finden Sie im GKE-Releasezeitplan. Oder ändern Sie Ihren Cluster in den erweiterten Kanal, wenn Sie die vorhandene Nebenversion bis zum Ende des erweiterten Supports weiter verwenden möchten.

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. Diese Patch-Upgrades können Updates für das Container-Optimized OS für den vorhandenen Container-Optimized OS-Meilenstein enthalten, der von der GKE-Nebenversion verwendet wird. GKE-Nebenversionen verwenden in der Regel einen Meilenstein während des Standard-Supportzeitraums bis zum Beginn des erweiterten Supportzeitraums.

Der von der GKE-Nebenversion verwendete Container-Optimized OS-Meilenstein erreicht jedoch sein eigenes Supportende, in der Regel während des erweiterten Supportzeitraums für eine GKE-Nebenversion. In diesem Fall erstellt GKE alle nachfolgenden GKE-Patchversionen mit dem nächsten Container-Optimized OS-Meilenstein. Weitere Informationen zu Meilenstein-Lebenszyklen finden Sie im Versionsverwaltungsschema für Container-Optimized OS.

Sehen Sie sich das folgende Szenario an, um zu verstehen, wie automatische Upgrades ablaufen und welche Entscheidungen Clusteradministratoren treffen müssen, wenn GKE keine Container-Optimized OS-Updates mehr im selben Meilenstein für eine GKE-Nebenversion einführen kann.

Die Unterstützung für die Container-Optimized OS-Version endet vor dem Ende des erweiterten Supports für die Nebenversion

Der Container-Optimized OS-Meilenstein erreicht das Ende des Supports vor dem Ende des erweiterten Supports für die Nebenversion, die den Meilenstein verwendet. In diesem Fall verwendet GKE den nächsten verfügbaren Container-Optimized OS-Meilenstein für zukünftige Patch-Upgrades. Die GKE führt dieses Update durch, bevor der von der Nebenversion verwendete Container-Optimized OS-Meilenstein das Ende des Supports erreicht.

Clusteradministratoren müssen entscheiden, ob sie die Worker-Knoten des Clusters aktualisieren möchten, da GKE diese Knoten nicht automatisch auf die nächste Patchversion mit dem neuen Meilenstein aktualisiert. Sie können die Knoten manuell auf die nächste GKE-Patchversion aktualisieren, die einen neuen Meilenstein enthält. Sie können die Knoten auch auf derselben GKE-Patchversion belassen, um den neuen Meilenstein nicht zu verwenden. Die Knoten erhalten jedoch erst dann Sicherheitspatches, wenn sie auf den nächsten Patch oder die nächste Nebenversion aktualisiert werden.

Automatische Upgrades für den neuen Container-Optimized OS-Meilenstein

Die nächste Patch-Version für eine GKE-Nebenversion im erweiterten Supportzeitraum verwendet einen neueren Container-Optimized OS-Meilenstein als vorherige Patch-Versionen. Die GKE führt automatisch Upgrades für Cluster durch, wenn die neue Patchversion zum Ziel für automatische Upgrades wird:

• Upgrades der Steuerungsebene:
  • Die GKE aktualisiert die Steuerungsebene wie gewohnt auf die nächste Patchversion.
• Knotenupgrades:
  • GKE aktualisiert Knoten nicht auf die nächste Patchversion.
  • Die GKE aktualisiert die Knoten wie gewohnt gegen Ende des erweiterten Supports auf die nächste Nebenversion. Weitere Informationen finden Sie unter Automatische Upgrades nach Ablauf des Supports.

Da die neue Meilensteinversion möglicherweise Änderungen einführt, die mit Ihren Arbeitslasten nicht kompatibel sind, pausiert GKE automatische Knotenupgrades auf die nächste Patchversion. Sie können manuell auf die neue Patchversion upgraden, wenn Sie festgestellt haben, dass Ihre Arbeitslasten mit dem nächsten Container-Optimized OS-Meilenstein kompatibel sind. Wenn Sie Ihre Knoten manuell auf eine Patchversion aktualisieren, die den neuen Container-Optimized OS-Meilenstein verwendet, setzt GKE die automatischen Patchupgrades der Knoten fort, da auf den Knoten jetzt der neue Meilenstein ausgeführt wird.

Clusterbenachrichtigung, wenn neue Patchversionen den neuen Meilenstein verwenden

GKE sendet eine Clusterbenachrichtigung, wenn diese Situation eintritt. Diese Benachrichtigung wird gesendet, wenn die erste Patchversion, die den neuen Container-Optimized OS-Meilenstein verwendet, im erweiterten Kanal verfügbar ist.

Wenn Sie diese Benachrichtigung erhalten, sollten Sie prüfen, ob Sie die Knoten manuell auf die nächste Patch- oder Nebenversion aktualisieren möchten oder ob Sie während des erweiterten Supports keine späteren Patchversionen für diese Nebenversion erhalten möchten. Weitere Informationen finden Sie unter Neue Patchversionen wechseln während des erweiterten Supports zu einer neuen Container-Optimized OS-Meilensteinversion.

Versionsverwaltungsschema

Kubernetes-Releases verwenden den Standard für die semantische Versionsverwaltung für Versionsnummern (X.Y.Z). GKE hängt eine GKE-Patchversionsnummer an die Kubernetes-Version an (X.Y.Z-gke.N).

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-Patchversion (Z)

Kubernetes veröffentlicht Patchversionen während des 12-monatigen Zeitraums, der auf die Veröffentlichung einer Nebenversion folgt. Eine Patchversion erhöht die Kubernetes-Version von X.Y.Z auf X.Y.Z+1. Beispiel: 1.32.6 ist der Patch-Release, der auf 1.32.5 folgt.

GKE-Patchversion (-gke.N)

Die GKE veröffentlicht Patchversionen, die den Upstream-Kubernetes-Patchversionen entsprechen. Die GKE-Patchversionen können Sicherheitsupdates, Funktionsänderungen und Fehlerkorrekturen für GKE sowie die Open-Source-Kubernetes-Software enthalten. Diese Updates oder Fehlerkorrekturen sind für die Kompatibilität und Interoperabilität mit Google Clouderforderlich.

GKE veröffentlicht möglicherweise mehrere GKE-Patchversionen für jede Kubernetes-Patchversion. Die Kubernetes-Patchversion 1.35.6 hat beispielsweise GKE-Patchversionen wie 1.35.6-gke.1638000, 1.35.6-gke.1641000 und 1.35.6-gke.1250000.

GKE-Patchversionen werden in der Regel wöchentlich veröffentlicht. Der Roll-out der Patchreleases in jeder Zone erfolgt schrittweise.

GKE-Alpha-Patchversion (X.Y+1.Z-gke.N+preview) – nur Alpha-Cluster

GKE veröffentlicht Alpha-Patchversionen für eine anstehende Kubernetes-Nebenversion bis zu vier Monate vor dem Veröffentlichungsdatum dieser Nebenversion. Diese Vorabveröffentlichungen von Patchversionen sind für Experimente und Tests in GKE-Alpha-Clustern verfügbar, die in der Release-Version „Schnell“ registriert sind. Alpha-Patchversionen sind immer auf die nächste Nebenversion im Kubernetes-Releasezyklus vor der Veröffentlichung dieser Nebenversion ausgerichtet. Wenn beispielsweise die Nebenversion 1.36 die neueste stabile Version ist und Version 1.37 noch nicht veröffentlicht wurde, sind die Alpha-Patchversionen für Version 1.37.

Verfügbare und als Standard festgelegte Versionen auflisten

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

Wählen Sie eine der folgenden Optionen aus, um die Standard- und verfügbaren GKE-Versionen zu prüfen:

Console

1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster erstellen auf:

   Zur Seite „Kubernetes-Cluster erstellen“

2. Wählen Sie im Abschnitt Standorttyp einen Standorttyp und die Region oder Zone für die Steuerungsebene des Clusters aus.

3. Wählen Sie in der Liste Ziel-Release-Version eine Release-Version aus.

4. Öffnen Sie die Liste Zielversion. In dieser Liste werden alle verfügbaren GKE-Patchversionen für die Release-Version angezeigt. Die Standard-Patchversion für die Release-Version wird automatisch ausgewählt. Wenn Sie die Release-Version „Rapid“ auswählen, werden auch alle verfügbaren Alpha-Patchversionen für die nächste Nebenversion angezeigt.

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.

gcloud

Führen Sie einen der folgenden Befehle aus, um die verfügbaren und Standardversionen für eine bestimmte Release-Version zu prüfen:

• Prüfen Sie die verfügbaren Versionen:

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

  Ersetzen Sie Folgendes:

  • RELEASE_CHANNEL ist der Name der Release-Version. Geben Sie einen der folgenden Werte an:

    • RAPID
    • REGULAR
    • STABLE
    • EXTENDED

  • COMPUTE_LOCATION: der Compute Engine-Standort, den Sie prüfen möchten.

  Die Ausgabe sieht etwa so aus:

  channels:
    channel: RAPID
    validVersions:
    - 1.36.2-gke.2064000
    - 1.36.2-gke.1498000
    - 1.35.6-gke.1641000
    - 1.35.6-gke.1638000
    - 1.35.6-gke.1258000
    - 1.34.9-gke.1610000
    - 1.34.9-gke.1322000
    - 1.33.13-gke.1269000
    - 1.33.13-gke.1109000
  

  Im Rapid Channel gibt das Feld previewVersions die GKE-Alpha-Patchversionen für die anstehende Kubernetes-Nebenversion an. Diese Versionen sind nur für Alpha-Cluster verfügbar.

• Prüfen Sie die Standardversion:

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

  Die Ausgabe sieht etwa so aus:

  channels:
    channel: RAPID
    defaultVersion: 1.36.2-gke.1498000
  

• Prüfen Sie die verfügbaren Alpha-Patchversionen im Rapid-Kanal:

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

  Die Ausgabe sieht etwa so aus:

  channels:
    channel: RAPID
    previewVersions:
    - 1.37.0-gke.2064000+preview
  

Führen Sie einen der folgenden Befehle aus, um die verfügbaren und Standardversionen für Cluster zu prüfen, die keinen Kanal verwenden (eingestellt):

• Prüfen Sie die Standardversion:

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

  Ersetzen Sie COMPUTE_LOCATION durch den Compute Engine-Standort, den Sie prüfen möchten.

  Die Ausgabe sieht etwa so aus: 1.35.6-gke.1127000.

• Prüfen Sie die verfügbaren Versionen der Steuerungsebene:

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

  Die Ausgabe sieht etwa so aus:

  validMasterVersions:
  - 1.36.2-gke.2064000
  - 1.36.2-gke.1498000
  - 1.36.2-gke.1346000
  - 1.36.0-gke.4681000
  - 1.36.0-gke.4447000
  - 1.35.6-gke.1641000
  - 1.35.6-gke.1638000
  - 1.35.6-gke.1258000
  - 1.35.6-gke.1250000
  - 1.35.6-gke.1127000
  - 1.35.6-gke.1049000
  

• Prüfen Sie die verfügbaren Knotenversionen:

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

  Die Ausgabe sieht etwa so aus:

  validNodeVersions:
  - 1.36.2-gke.2064000
  - 1.36.2-gke.1498000
  - 1.36.2-gke.1346000
  - 1.36.0-gke.4681000
  - 1.36.0-gke.4447000
  - 1.35.6-gke.1641000
  - 1.35.6-gke.1638000
  - 1.35.6-gke.1258000
  - 1.35.6-gke.1250000
  - 1.35.6-gke.1127000
  - 1.35.6-gke.1049000
  # Multiple lines are omitted here
  

Hinweis: Informationen zur erweiterten Bearbeitung der get-server-config-Ausgabe finden Sie in der Dokumentation zur gcloud CLI unter Filtern und Formatieren.

Clusterversion angeben

Wenn Sie einen Cluster mit der gcloud CLI erstellen oder aktualisieren, können Sie mit dem Flag --cluster-version entweder eine Clusterversion oder einen Alias angeben.

Für Autopilot- und Standardcluster können Sie beim Erstellen eines Clusters den folgenden Alias verwenden:

• upgrade-target (Vorabversion): Für Cluster, die in einer Roll-out-Sequenz registriert sind, wird dieser Alias in die Zielversion der Phase eines Clusters aufgelöst. Andernfalls verwendet die GKE die Zielversion für automatische Upgrades der Release-Version. Sie können diesen Alias nur beim Erstellen des Clusters verwenden. Sie kann nicht während Clusterupgrades verwendet werden.

Nur für Standardcluster können Sie eine verfügbare Version (z. B. 1.30.2-gke.1500) angeben oder einen der folgenden Aliase verwenden:

• latest: Die höchste unterstützte Kubernetes-Version, die in der Zone oder Region des Clusters verfügbar ist. Wenn Sie latest angeben, werden keine automatischen Upgrades bereitgestellt. Aktivieren Sie automatische Knotenupgrades, damit die Knoten in Ihrem Cluster auf dem neuesten Stand der stabilen Version sind.
• 1.X: Der höchste gültige Patch-Release in der angegebenen Nebenversion.
• 1.X.Y: Der höchste gültige gke.N-Patch im angegebenen Patch-Release.

• -: Die Kubernetes-Standardversion für Steuerungsebenen. Bei Knotenupgrades wird die Version angegeben, die von der Cluster-Steuerungsebene ausgeführt wird.

  Sie können diese Aliasse sowohl für die Clustererstellung als auch für Clusterupgrades verwenden.

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.

Frühere Patchversionen bleiben für Knoten verfügbar, bis die Nebenversion das Ende des Supports erreicht, auch wenn diese Versionen für die Steuerungsebene nicht mehr verfügbar sind. In seltenen Fällen kann eine Knotenversion früher nicht mehr verfügbar sein.

90-tägige Patchrichtlinie für die Steuerungsebene

Damit ein GKE-Cluster wichtige Sicherheitspatches und andere Fehlerkorrekturen rechtzeitig erhält, muss die Steuerungsebene eines Clusters mindestens alle 90 Tage auf eine neue Patch- oder Nebenversion aktualisiert werden. Die GKE aktualisiert die Steuerungsebene von Clustern standardmäßig häufiger als alle 90 Tage. Sie können diese Upgrades der Steuerungsebene jedoch verzögern, indem Sie Wartungsausschlüsse konfigurieren oder auswählen, welche Arten von Upgrades GKE in einer Roll-out-Sequenz ausführt. Ähnlich wie bei automatischen Upgrades am Ende des Supports gilt jedoch: Wenn Sie einen GKE-Cluster haben, der nicht wie erforderlich aktualisiert wurde, aktualisiert GKE Ihren Cluster automatisch auf eine neuere Patchversion, unabhängig von den von Ihnen konfigurierten Richtlinien.

Richtlinie für GKE-Versionsabweichungen

Die GKE-Richtlinie für Versionsinkompatibilität sorgt dafür, dass ein GKE-Cluster die Kompatibilität zwischen der Steuerungsebene und den Knoten aufrechterhält. In einem GKE-Cluster können Knoten der Version der Steuerungsebene entsprechen oder bis zu zwei Nebenversionen älter als die Steuerungsebene sein.

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 die Knoten die folgenden Versionen ausführen: 1.31, 1.30 oder 1.29, aber nicht 1.28 oder früher. 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.

Cluster mit nicht unterstützter Versionsabweichung identifizieren

GKE identifiziert Cluster, in denen auf den Knoten eine Version ausgeführt wird, die aufgrund einer Versionsabweichung nicht mit der Steuerungsebene kompatibel ist. Die GKE empfiehlt, die Knoten, auf denen diese nicht unterstützte Version ausgeführt wird, zu aktualisieren. Diese Empfehlung wird mit einer Statistik und einer Empfehlung über den Recommender-Dienst bereitgestellt. Weitere Informationen zum Verwalten von Statistiken und Empfehlungen von Recommendern finden Sie unter Nutzung von GKE mit Statistiken und Empfehlungen optimieren.

So finden Sie Cluster mit einer nicht unterstützten Versionsabweichung:

• Verwenden Sie die Google Cloud Console.
• Verwenden Sie die gcloud CLI oder die Recommender API und geben Sie den Recommender-Untertyp CLUSTER_VERSION_SKEW_UNSUPPORTED an.

Eine Anleitung finden Sie unter Statistiken und Empfehlungen ansehen.

Wenn Sie diese Empfehlung umsetzen möchten, aktualisieren Sie alle Knoten, auf denen eine Nebenversion ausgeführt wird, die mehr als zwei Nebenversionen älter als die Version der Steuerungsebene ist.

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.

Unterstützung von Patchversionen

GKE führt eine Patchversion zuerst im Rapid Channel ein und stuft diese Patchversion dann schrittweise über andere Release-Versionen hoch. Wenn die GKE eine Patchversion in einer Release-Version verfügbar macht, können Sie Ihren Cluster auf diese Version erstellen, aktualisieren oder in bestimmten Fällen downgraden. Solange eine Nebenversion unterstützt wird, führt GKE weiterhin neue Patchversionen der Nebenversion in einer Release-Version ein.

Frühere Patchversionen bleiben in der Release-Version für Knoten verfügbar, bis die Nebenversion das Ende des Supports erreicht. Sie werden jedoch vor diesem Datum entfernt und sind dann nicht mehr für die Verwendung mit der Steuerungsebene verfügbar. Wenn GKE eine Patchversion für die Verwendung mit der Steuerungsebene entfernt, können Sie die Steuerungsebene Ihres Clusters nicht auf die entfernte Patchversion erstellen, aktualisieren oder downgraden. Wenn auf der Steuerungsebene Ihres Clusters eine entfernte Patchversion ausgeführt wird, empfehlen wir, die Steuerungsebene auf das neueste Ziel für automatische Upgrades zu aktualisieren.

Einstellung von Patchversionen für die Steuerungsebene

Die folgenden Informationen gelten für alle Patchversionen, bei denen die Nebenversion bereits im Regular Channel eingeführt wurde.

Bevor die GKE Patchversionen aus einer Release-Version zur Verwendung mit einer Cluster-Steuerungsebene entfernt, wird die Patchversion von der GKE verworfen. Verworfene Patchversionen werden zwar nicht mehr als verfügbar für die Steuerungsebene aufgeführt, Sie können sie aber weiterhin zum Erstellen, Upgraden oder Downgraden Ihrer Steuerungsebene verwenden.

Wir empfehlen, so schnell wie möglich ein Upgrade auf eine neuere Patchversion durchzuführen. Verwenden Sie verworfene Versionen nur, wenn der Roll-out-Prozess Ihrer Umgebung ein früheres Upgrade strikt verhindert. Die GKE stellt eine Patchversion für 90 Tage ein oder bis die Nebenversion das Ende des Standardsupports (Regular, Stable, No Channel) oder das Ende des erweiterten Supports (Extended Channel) erreicht.

Unterstützung von Alpha-Versionen

Achtung: Alpha-Versionen sind instabile Versionen von Kubernetes, die für experimentelle Zwecke gedacht sind. Für diese Versionen gelten dieselben Erwartungen an den technischen Support und die Stabilität wie für die Einführungsphase Vorschau.

Alpha-Versionen sind GKE-Patchversionen einer anstehenden Kubernetes-Nebenversion, die GKE bis zu vier Monate vor der Verfügbarkeit der Nebenversion für alle Cluster im Rapid Channel veröffentlicht. Diese Alphaversionen sind nur in GKE-Alphaclustern verfügbar und richten sich an erste Nutzer, die mit anstehenden Funktionen experimentieren möchten, ohne dass Stabilität oder Support erwartet werden.

Im Rapid Channel sind zwischen einer und drei Alpha-Patchversionen für die kommende Nebenversion verfügbar. In den Monaten, bevor GKE die Nebenversion für alle Cluster im Rapid Channel verfügbar macht, führt GKE neue Alpha-Patchversionen ein und entfernt vorhandene Versionen. Da Alpha-Patchversionen nur in Alpha-Clustern verfügbar sind, gilt Folgendes:

• Sie können die Alpha-Cluster nicht auf neue Versionen aktualisieren. Wenn Sie eine neue Alphaversion testen möchten, erstellen Sie einen Alphacluster, auf dem diese Version ausgeführt wird.
• Alpha-Cluster, auf denen eine entfernte Alpha-Version ausgeführt wird, bleiben bestehen, bis die Cluster 30 Tage nach der Erstellung ablaufen oder bis Sie die Cluster löschen.
• Korrekturen für CVEs und Fehler in bestimmten Systemkomponenten werden nicht rückwirkend auf vorhandene Alpha-Patchversionen angewendet. Um diese Fehlerkorrekturen zu erhalten, müssen Sie einen Alpha-Cluster erstellen, auf dem eine neuere Alpha-Patchversion ausgeführt wird.

Nachdem GKE eine stabile Nebenversion im Rapid Channel veröffentlicht hat, werden die Alpha-Patchversionen für diese Nebenversion entfernt. Alphaversionen der nächsten Nebenversion im Releasezyklus werden im Rapid Channel bis zu vier Monate vor dem Releasedatum dieser Nebenversion verfügbar.

Lebenszyklus der Alphaversion

Der Lebenszyklus der Alphaversion umfasst die folgenden Meilensteine:

1. Kubernetes veröffentlicht die erste Entwicklungsversion für die kommende Nebenversion (X.Y+1.0-alpha.0).
2. Bis zu vier Monate vor dem Veröffentlichungsdatum der nächsten Nebenversion führt GKE Alpha-Patchversionen für diese Nebenversion im Rapid Channel (X.Y+1.0-gke.N+preview) ein.
3. Kubernetes veröffentlicht die stabile Nebenversion (X.Y.0).
4. GKE stellt die stabile Nebenversion im Rapid Channel (X.Y.0-gke.N) zur Verfügung. GKE entfernt die Alphaversionen für diese Nebenversion aus dem Rapid Channel.

Der Lebenszyklus einer Alphaversion hat keine Auswirkungen auf den Lebenszyklus der GKE-Nebenversion.