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 Versionen von Kubernetes. Weitere Informationen zu Upgrades finden Sie unter GKE-GKE-ClusterClusterupgrades.

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 den Open-Source-Richtlinien von Kubernetes. Um die verfügbaren Nebenversionen während ihres Lebenszyklus zu unterstützen, stellt GKE Patchversionen bereit und führt regelmäßig automatische Cluster-Upgrades durch, um diese neueren Patches anzuwenden. Informationen dazu, wie GKE Patchversionen unterstützt, finden Sie unter Unterstützung für Patchversionen.

Neben der Unterstützung verfügbarer Nebenversionen bietet GKE auch Alpha-Patchversionen der nächsten Nebenversion im Kubernetes-Releasezyklus an. Diese sind bis zu vier Monate vor der Verfügbarkeit der Nebenversion für alle Cluster im Rapid Channel verfügbar. Diese Alphaversionen sind nur für GKE-Alphacluster im Rapid Channel verfügbar und für Early Adopters gedacht, die mit kommenden Funktionen experimentieren möchten.

Unterstützung einer Nebenversion durch 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

Vor der Veröffentlichung einer stabilen neuen Nebenversion veröffentlicht das Kubernetes-Projekt experimentelle, instabile Patchversionen dieser Nebenversion. GKE führt Alpha-Patchversionen ein, die auf diesen experimentellen Versionen im Rapid-Channel basieren und nur für GKE-Alphacluster verfügbar sind. Ähnlich wie bei anderen 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 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-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 nach insgesamt etwa 14 Monaten das Ende des Standardsupports und geht 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 die Nebenversion keine weiteren Sicherheitspatches mehr erhält.

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.

GKE bietet mindestens 14 Monate Standardsupport und mit erweitertem Support bis zu 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ü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 im Detail beschrieben werden:

Verfügbarkeitszeitraum	Ungefähre Zeitspanne nach der Verfügbarkeit im Regular Channel	Welchen Support bietet GKE?	Zugriff auf diesen Verfügbarkeitszeitraum
Verfügbarkeitszeitraum der Alphaversion	Monat –5 bis Monat –1	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 Alphacluster verfügbar, bieten keinen technischen Support oder SLA und enthalten mit hoher Wahrscheinlichkeit Probleme. Wenn die Nebenversion am Ende des Zeitraums, in dem sie nur als Alphaversion verfügbar ist, für alle Cluster im Rapid Channel verfügbar wird, entfernt GKE alle Alphaversionen aus dem Rapid Channel.	Nur Rapid Channel (erfordert Alphacluster)
Verfügbarkeitszeitraum nur für die Rapid-Variante	Monat –1 bis Monat 0	GKE stellt die Nebenversion für alle Cluster im Rapid Channel zur Verfügung, indem Patchversionen mit neuen Funktionen, Sicherheits- und Fehlerkorrekturen bereitgestellt werden. 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 Channel.	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)
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 bis zu vier Monate vor der Veröffentlichung einer neuen Nebenversion Alpha-Patchversionen dieser Nebenversion im Rapid Channel. Die Alpha-Versionen sind nur für Alphacluster verfügbar. In den folgenden Wochen veröffentlicht GKE zusätzliche Alpha-Patchversionen und unterhält in der Regel ein bis drei aktive Alphaversionen.

Dieser Zeitraum dauert an, bis GKE die stabile Nebenversion im Rapid Channel veröffentlicht. Nach der stabilen Version 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 ein bis zwei Monate. Der genaue Zeitpunkt hängt jedoch von der jeweiligen Nebenversion ab. Weitere Informationen finden Sie unter Geschätzter Zeitplan für Release-Channels.

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

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

• Schnell, Regulär, Stabil, Kein Kanal (eingestellt): Automatische Upgrades auf andere unterstützte Nebenversionen oder Patchversionen derselben Nebenversion.
• Erweitert: GKE führt automatische Upgrades nur 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-Channels. GKE führt in diesem Zeitraum jedoch keine Clusterupgrades durch, wenn in den Clustern eingestellte Funktionen 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 Standardsupports (früher End of Life)

Hinweis :In GKE wurde früher der Begriff End of Life für das Datum des Endes des Standardsupports verwendet. 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 mit End of Support ausführen, werden vor dem End of Support einer Version mit einer E-Mail an den Projektkontakt benachrichtigt. GKE beginnt aus Sicherheits- und Kompatibilitätsgründen auch mit dem schrittweisen automatischen Upgrade von Knoten (unabhängig von der Aktivierung von automatischen Upgrades), auf denen nicht unterstützte Versionen ausgeführt werden, 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. GKE führt für alle Cluster, die nicht im Extended Channel registriert sind, automatisch Upgrades durch. 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, einschließlich der folgenden Arten von Korrekturen:

• Sicherheitskorrekturen mit mittlerem, hohem und kritischem Schweregrad für Kubernetes-Kernkomponenten, das Betriebssystem des Knotens 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. 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 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. 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-Channels. 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 auswählen, welche Arten von Upgrades GKE in einer Roll-out-Sequenz durchführt. Außerdem führt 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 Extended Channel registriert sind, führt GKE jedoch automatisch ein Upgrade von Clustern auf die nächste unterstützte Nebenversion durch, um sicherzustellen, dass der Cluster leistungsfähig, verfügbar und sicher bleibt.

Jede GKE-Nebenversion wird 14 Monate lang mit Standardsupport und insgesamt 24 Monate lang unterstützt, einschließlich erweitertem Support. 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. GKE kann sich nicht verpflichten, Patches oder Updates für Nebenversionen nach Ablauf 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, auf denen nicht unterstützte Nebenversionen ausgeführt werden, werden möglicherweise nicht sofort nach dem Ende der Lebensdauer der Nebenversion aktualisiert. Der tatsächliche Zeitpunkt kann nach Ermessen von Google variieren.

Ebenso aktualisiert GKE die Clustersteuerungsebenen, die seit 90 Tagen nicht auf eine neue Version aktualisiert wurden. Weitere Informationen finden Sie unter 90-Tage-Patch-Richtlinie für die Steuerungsebene.

Vorübergehende Notfallmaßnahme zur Verhinderung 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 Enddatum des Supports verzögern, indem Sie einen Wartungsausschluss mit dem Standardbereich „Keine Upgrades“ konfigurieren. Wir raten davon ab, da die Verwendung einer nicht unterstützten Version mit Risiken verbunden ist. Nach Ablauf des Wartungsausschlusses aktualisiert GKE den Cluster.

Cluster mit einer Nebenversion identifizieren, die das Ende des Standardsupports überschritten hat

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 Extended Channel registriert.

GKE empfiehlt, diese Cluster zu aktualisieren, da die Ausführung einer nicht unterstützten Nebenversion mit Risiken verbunden ist. GKE führt ein Upgrade von Clustern auf die nächste unterstützte Nebenversion durch, wenn die vorhandene Version im Release-Kanal des Clusters nicht unterstützt wird.

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

Sie haben folgende Möglichkeiten, Cluster zu finden, in denen auf der Steuerungsebene eine Version ausgeführt wird, die nicht mehr unterstützt wird:

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

Eine Anleitung finden Sie unter Insights und Empfehlungen ansehen.

Um diese Empfehlung umzusetzen, aktualisieren Sie die Steuerungsebene Ihres Clusters auf eine unterstützte Nebenversion. Informationen zu unterstützten Nebenversionen und End-of-Support-Terminen finden Sie im GKE-Releasezeitplan. Oder stellen Sie Ihren Cluster auf den erweiterten Kanal um, 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 Container-Optimized OS-Updates für den vorhandenen Container-Optimized OS-Meilenstein umfassen, 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 Ende des Supports, 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 Versionsschema für Container-Optimized OS.

Im folgenden Szenario wird beschrieben, wie automatische Upgrades ablaufen und welche Entscheidungen Clusteradministratoren treffen müssen, wenn GKE keine Container-Optimized OS-Updates mehr im selben Milestone für eine GKE-Nebenversion einführen kann.

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

Das Container-Optimized OS -Milestone erreicht sein eigenes Ende des Supports vor dem Ende des erweiterten Supports für die Nebenversion, die den Milestone verwendet. In diesem Fall verwendet GKE den nächsten verfügbaren Container-Optimized OS-Meilenstein für zukünftige Patch-Upgrades. 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. Alternativ können Sie die Knoten mit derselben GKE-Patchversion ausführen, um den neuen Meilenstein nicht zu verwenden. Die Knoten erhalten jedoch erst dann Sicherheitspatches, wenn Sie ein Upgrade auf die nächste Patch- oder Nebenversion durchführen.

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

Für die nächste Patch-Version einer GKE-Nebenversion im Supportzeitraum des erweiterten Supports wird ein neuerer Container-Optimized OS-Meilenstein als bei früheren Patch-Versionen verwendet. GKE führt automatisch Upgrades für Cluster durch, wenn die neue Patchversion zum Ziel für automatische Upgrades wird:

• Aktualisierungen der Steuerungsebene:
  • GKE aktualisiert die Steuerungsebene wie gewohnt auf die nächste Patchversion.
• Knotenupgrades:
  • GKE aktualisiert Knoten nicht auf die nächste Patchversion.
  • GKE führt wie gewohnt ein Upgrade der Knoten auf die nächste Nebenversion durch, wenn das Ende des erweiterten Supports näher rückt. Weitere Informationen zu automatischen Upgrades am Ende des Supports

Da die neue Milestone-Version möglicherweise Änderungen enthält, die mit Ihren Arbeitslasten inkompatibel sind, pausiert GKE automatische Knoten-Upgrades auf die nächste Patchversion. Sie können manuell auf die neue Patch-Version aktualisieren, 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 automatische Patchupgrades der Knoten fort, da auf den Knoten jetzt der neue Meilenstein ausgeführt wird.

Clusterbenachrichtigung, wenn neue Patch-Versionen den neuen Meilenstein verwenden

GKE sendet eine Clusterbenachrichtigung, um Sie über diese Situation zu informieren. Diese Benachrichtigung wird gesendet, wenn die erste Patchversion, die den neuen Container-Optimized OS-Meilenstein verwendet, im Extended-Kanal verfügbar ist.

Wenn Sie diese Benachrichtigung erhalten, können Sie entscheiden, ob Sie die Knoten manuell auf die nächste Patch- oder Nebenversion aktualisieren möchten oder ob Sie während des Zeitraums des erweiterten Supports keine späteren Patchversionen für diese Nebenversion erhalten möchten. Weitere Informationen finden Sie unter Neue Patchversionen werden während des erweiterten Supports auf den neuen Container-Optimized OS-Meilenstein umgestellt.

Versionsverwaltungsschema

Für Kubernetes-Releases wird der Standard für die semantische Versionsverwaltung für Versionsnummern (X.Y.Z) verwendet. GKE hängt eine GKE-Patchversionsnummer an die Kubernetes-Version (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-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. 1.32.6 ist beispielsweise die Patch-Version, die auf 1.32.5 folgt.

GKE-Patchversion (-gke.N)

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.

Für jede Kubernetes-Patchversion werden möglicherweise mehrere GKE-Patchversionen veröffentlicht. 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 Rollout der Patchreleases in jeder Zone erfolgt schrittweise.

GKE-Alphapatchversion (X.Y+1.Z-gke.N+preview) – nur Alphacluster

GKE veröffentlicht Alpha-Patchversionen für eine bevorstehende Kubernetes-Nebenversion bis zu vier Monate vor dem Veröffentlichungsdatum dieser Nebenversion. Diese Vorab-Patchversionen sind für Experimente und Tests in GKE-Alphaclustern verfügbar, die im Rapid Release-Version registriert sind. Alpha-Patchversionen sind immer auf die nächste Nebenversion im Kubernetes-Releasezyklus ausgerichtet, bevor diese Nebenversion veröffentlicht wird. Wenn beispielsweise die Nebenversion 1.36 das aktuelle stabile Release ist und 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.

So prüfen Sie die Standard- und verfügbaren GKE-Versionen:

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 den Rapid Release Channel auswählen, sehen Sie auch alle verfügbaren Alpha-Patchversionen für die nächste Nebenversion.

Hinweis: Wenn Sie vor Abschluss eines Versionsrollouts in der Google Cloud Console einen Cluster erstellen, werden für Ihre Zone unter Umständen falsche verfügbare Versionen 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:

• Verfügbare Versionen prüfen:

  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: der Name des Release-Channels. 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-Alphapatchversionen für die bevorstehende Kubernetes-Nebenversion an. Diese Versionen sind nur für Alpha-Cluster verfügbar.

• Standardversion prüfen:

  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 Alphapatch-Versionen 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 standardmäßigen Versionen für Cluster ohne Channel (eingestellt) zu prüfen:

• Standardversion prüfen:

  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 ähnelt 1.35.6-gke.1127000.

• Verfügbare Versionen der Steuerungsebene prüfen:

  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
  

• Verfügbare Knotenversionen prüfen:

  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 gcloud CLI-Dokumentation zum Filtern und Formatieren.

Clusterversion angeben

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

Wenn Sie einen Cluster mit der gcloud 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 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.

90-Tage-Patchrichtlinie für die Steuerungsebene

Damit ein GKE-Cluster rechtzeitig kritische Sicherheitspatches und andere Korrekturen erhält, muss die Steuerungsebene eines Clusters mindestens alle 90 Tage auf eine neue Patch- oder Nebenversion aktualisiert werden. Standardmäßig aktualisiert GKE die Steuerungsebene von Clustern häufiger als alle 90 Tage. Sie können diese Upgrades der Steuerungsebene jedoch verzögern, indem Sie Ausschlusszeiträume für die Wartung konfigurieren oder auswählen, welche Arten von Upgrades GKE in einer Roll-out-Sequenz durchführt. Ähnlich wie bei automatischen Upgrades am Ende des Supports wird Ihr GKE-Cluster jedoch automatisch auf eine neuere Patchversion aktualisiert, wenn er nicht wie erforderlich aktualisiert wurde. Dies geschieht unabhängig von den von Ihnen konfigurierten Richtlinien.

GKE-Richtlinie für Versionsabweichungen

Die GKE-Richtlinie zur Versionsabweichung sorgt dafür, dass in einem GKE-Cluster die Kompatibilität zwischen der Steuerungsebene und den Knoten aufrechterhalten wird. In einem GKE-Cluster können Knoten der Version der Steuerungsebene entsprechen oder bis zu zwei Nebenversionen früher als die Steuerungsebene ausgeführt werden.

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 Versionen 1.31, 1.30 oder 1.29 ausgeführt werden, nicht aber 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 erkennt Cluster, in denen auf den Knoten eine Version ausgeführt wird, die aufgrund von Versionsabweichungen nicht mit der Steuerungsebene kompatibel ist. GKE empfiehlt, dass Sie die Knoten, auf denen diese nicht unterstützte Version ausgeführt wird, aktualisieren. Diese Empfehlung wird über den Recommender-Dienst als Statistik und Empfehlung 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 CLUSTER_VERSION_SKEW_UNSUPPORTED Recommender-Untertyp an.

Eine Anleitung finden Sie unter Insights und Empfehlungen ansehen.

Um diese Empfehlung umzusetzen, aktualisieren Sie alle Knoten, auf denen eine Nebenversion ausgeführt wird, die mehr als zwei Nebenversionen vor der Version der Steuerungsebene liegt.

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 sie dann schrittweise in anderen Release-Channels hoch. Wenn GKE eine Patch-Version in einem Releasekanal verfügbar macht, können Sie Ihren Cluster auf diese Version erstellen, aktualisieren oder – in bestimmten Fällen – ein Downgrade auf diese Version durchführen. Während eine Nebenversion unterstützt wird, führt GKE weiterhin neue Patchversionen der Nebenversion in einer Release-Version ein.

Frühere Patchversionen bleiben im Release-Channel für Knoten verfügbar, bis die Nebenversion das Ende des Supports erreicht. Sie werden jedoch vor diesem Datum entfernt und sind 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 Patch-Version 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, in denen die Nebenversion bereits im Regular Channel eingeführt wurde.

Bevor GKE Patchversionen aus einem Release-Kanal für die Verwendung mit einer Cluster-Steuerungsebene entfernt, wird die Patchversion eingestellt. Obwohl eingestellte Patchversionen nicht mehr als für die Steuerungsebene verfügbar aufgeführt werden, können Sie sie weiterhin verwenden, um Ihre Steuerungsebene zu erstellen, zu aktualisieren oder zu downgraden.

Wir empfehlen, so schnell wie möglich ein Upgrade auf eine neuere Patch-Version durchzuführen. Verwenden Sie eingestellte Versionen nur, wenn der Bereitstellungsprozess Ihrer Umgebung ein früheres Upgrade nicht zulässt. GKE stellt eine Patchversion für 90 Tage ein oder bis die Nebenversion das Ende des Standardsupports (Regular, Stable, kein Channel) oder das Ende des erweiterten Supports (Extended Channel) erreicht.

Unterstützung von Alphaversionen

Achtung :Alphacluster sind instabile Versionen von Kubernetes, die für Experimente vorgesehen sind. Für diese Versionen gelten dieselben Erwartungen an technischen Support und Stabilität wie für die Vorschau.

Alphabereiche sind GKE-Patchversionen einer bevorstehenden Kubernetes-Nebenversion, die bis zu vier Monate vor der Verfügbarkeit der Nebenversion für alle Cluster im Rapid Channel veröffentlicht werden. Diese Alphaversionen sind nur in GKE-Alphaclustern verfügbar und für Early Adopters gedacht, die mit kommenden 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 nächste Nebenversion verfügbar. In den Monaten, bevor GKE die Nebenversion für alle Cluster im Rapid Channel verfügbar macht, werden neue Alpha-Patchversionen eingeführt und vorhandene Versionen entfernt. Da Alphapatch-Versionen nur in Alphaclustern verfügbar sind, gelten die folgenden Überlegungen:

• Sie können die Alphacluster nicht auf neue Versionen aktualisieren. Wenn Sie eine neue Alphaversion testen möchten, erstellen Sie einen Alphacluster, in dem diese Version ausgeführt wird.
• Alphacluster, in denen eine entfernte Alphaversion 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 Korrekturen zu erhalten, müssen Sie einen Alphacluster erstellen, in dem eine neuere Alphapatch-Version 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 sind bis zu vier Monate vor dem Releasedatum dieser Nebenversion im Rapid Channel verfügbar.

Lebenszyklus der Alphaversion

Der Lebenszyklus der Alphaversion umfasst die folgenden Meilensteine:

1. Kubernetes veröffentlicht die erste Entwicklungsversion für die bevorstehende Nebenversion (X.Y+1.0-alpha.0).
2. Bis zu vier Monate vor dem Veröffentlichungsdatum der nächsten Nebenversion führt GKE Alphapatch-Versionen 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 keinen Einfluss auf den Lebenszyklus der GKE-Nebenversion.