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.

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 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 einer Nebenversion durch 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 im regulären-Kanal für die Erstellung neuer Cluster 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. 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.
  6. 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:

Supportzeiträume. GKE unterstützt eine Nebenversion insgesamt 24 Monate lang.

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 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
Zeitraum des erweiterten Supports 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 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 führt GKE regelmäßig automatische Upgrades von Clustern auf neue Patchversionen durch, 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 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-Channels. GKE führt jedoch in diesem Zeitraum 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)

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 Supports.

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, wenn diese 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 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 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-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 Supportende erreicht ist.

GKE aktualisiert den Cluster auf folgende Weise:

  • 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.

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

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

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 Extended Channel 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 das End-of-Support-Datum überschritten hat:

  • 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

Der Container-Optimized OS-Meilenstein erreicht sein eigenes 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. 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 weiter 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 Zeitraum 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:

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 Patchversion 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, müssen 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

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 Clouderforderlich.

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 -Konsole oder mithilfe der Google Cloud CLI auch prüfen, welche Kubernetes-Versionen verfügbar und in einer bestimmten Zone als Standard festgelegt sind.

Versionen mit der Google Cloud Console prüfen

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

  1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

    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.

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 (früher 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:

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:

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:

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:

Keine Release-Version

Führen Sie die folgenden Befehle aus, um die Standardversion und die verfügbaren Versionen für keinen Channel (früher 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:

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.

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 mit der Version der Steuerungsebene übereinstimmen 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 folgenden Versionen ausgeführt werden: 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 erkennt Cluster, in denen auf den Knoten eine Version ausgeführt wird, die aufgrund von Versionsabweichungen nicht mit der Steuerungsebene kompatibel ist. GKE empfiehlt, die Knoten, auf denen diese nicht unterstützte Version ausgeführt wird, zu aktualisieren. Diese Empfehlung wird über eine Statistik und eine 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 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.