Auf dieser Seite werden die Versionsverwaltung in Google Kubernetes Engine (GKE) und die Richtlinien für die Versionsunterstützung erläutert. Den aktuellen Release- und Unterstützungszeitplan finden Sie im GKE-Releasezeitplan.
Versionsunterstützung
Die Kubernetes-Open-Source-Community-Community (OSS) veröffentlicht derzeit dreimal pro Jahr eine Nebenversion mit neuen Funktionen und Verbesserungen. Jeder Releasezyklus ist etwa 15 Wochen lang.
Ab Kubernetes 1.19 unterstützt OSS jede Nebenversion 12 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 kann den Versionsunterstützungskalender von Zeit zu Zeit überarbeiten.
Google bietet insgesamt 14 Monate Unterstützung für jede GKE-Nebenversion, sobald die Version im regulären Kanal zur Verfügung gestellt wurde. Knoten- und Knotenpoolversionen können bis zu zwei Nebenversionen älter als die Steuerungsebene sein, können aber aufgrund der Kubernetes OSS-Versionskompatibilitätsrichtlinie nicht älter 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.
Nach zwölf Monaten wird für eine unterstützte Version ein zweimonatiger Wartungszeitraum gestartet, bevor das End of Life erreicht wird.
Lebenszyklus der GKE-Nebenversion
Die erste Phase des Lebenszyklus einer Nebenversion beginnt mit der Veröffentlichung einer unterstützten GKE-Version. Cluster, auf denen eine unterstützte Nebenversion ausgeführt wird, erhalten regelmäßig Patches, um Fehler und Sicherheitsprobleme zu beheben. Gemäß den aktuellen Unterstützungsrichtlinien für die Kubernetes OSS-Community-Version plant GKE, Nebenversionen 14 Monate lang zu unterstützen, einschließlich der 12 Monate nach der Veröffentlichung im Regular Channel, gefolgt von einem Wartungszeitraum von 2 Monaten. Während der zwei Monate des Wartungszeitraums können keine neuen Knotenpools für eine Wartungsversion mehr erstellt werden, bestehende Knotenpools mit einer Wartungsversion bleiben jedoch aktiv.
Am Ende des Wartungszeitraums erreicht eine Nebenversion das End of Life, wird offiziell nicht mehr unterstützt und ist nicht mehr verfügbar. GKE-Nebenversionen, die das End of Life erreicht haben, erhalten keine Sicherheitspatches oder Fehlerkorrekturen mehr. Patchversionen einer Nebenversion, die das End of Life erreicht hat, werden nicht unterstützt und sind nicht verfügbar.
Ab der GKE-Version 1.19 aktualisiert GKE Knoten, auf denen eine nicht unterstützte Version ausgeführt wird, nachdem die Version abgelaufen ist, um den Zustand des Clusters und die Ausrichtung an der Open-Source-Versionsinkompatibilitätsrichtlinie sicherzustellen. 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.
Google kann sich nicht verpflichten, Patches oder Updates für End-of-Life-Versionen bereitzustellen.
In seltenen Fällen kann es erforderlich sein, den Wartungszeitraum oder das End of Life von GKE-Versionen zu überarbeiten. Dies ist auf Richtlinienänderungen in der Kubernetes OSS-Community oder auf das Auffinden von Sicherheitslücken oder auf technische Probleme, die nicht angemessen behoben werden können, zurückzuführen. Die neuesten verfügbaren Versionen finden Sie in den GKE-Versionshinweisen.
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.19 ist z. B. die Nebenversion, die auf Kubernetes 1.18 folgt.
- Kubernetes Patchrelease (z)
- Neue Kubernetes-Patchreleases (z. B. 1.18.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" (wie 1.18.6-gke.N) enthält Sicherheitsupdates und/oder Fehlerkorrekturen für GKE sowie die Open-Source-Upstream-Kubernetes-Software. Diese Updates oder Fehlerkorrekturen sind für die Kompatibilität und Interoperabilität mit Google Cloud erforderlich.
Verfügbare und als Standard festgelegte Versionen auflisten
Informationen zu verfügbaren Versionen finden Sie in den GKE-Versionshinweisen.
Sie können in der Google Cloud Console oder mithilfe der Google Cloud CLI auch prüfen, welche Kubernetes-Versionen verfügbar und in einer bestimmten Zone als Standard festgelegt sind.
Versionen mit der gcloud-CLI prüfen
Führen Sie einen der folgenden gcloud-Befehle für Ihren Clustertyp aus, um zu sehen, welche Versionen verfügbar sind und welche standardmäßig verwendet werden. Jeder Tab enthält Befehle zum Prüfen der Versionen für einen bestimmten Release-Kanal oder für keinen Kanal (statisch).
Rapid
Führen Sie die folgenden Befehle aus, um die Standardversion und die verfügbaren Versionen im Releasekanal Rapid anzusehen:
Standardversion
gcloud container get-server-config --flatten="channels" --filter="channels.channel=RAPID" \
--format="yaml(channels.channel,channels.defaultVersion)"
Verfügbare Versionen
gcloud container get-server-config --flatten="channels" --filter="channels.channel=RAPID" \
--format="yaml(channels.channel,channels.validVersions)"
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)"
Verfügbare Versionen
gcloud container get-server-config --flatten="channels" --filter="channels.channel=REGULAR" \
--format="yaml(channels.channel,channels.validVersions)"
Stabile Version
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)"
Verfügbare Versionen
gcloud container get-server-config --flatten="channels" --filter="channels.channel=STABLE" \
--format="yaml(channels.channel,channels.validVersions)"
Kein Kanal
Führen Sie die folgenden Befehle aus, um die Standardversion und die verfügbaren Versionen für einen Channel (statisch) aufzurufen:
Standardversion
gcloud container get-server-config --format="yaml(defaultClusterVersion)"
Verfügbare Versionen der Steuerungsebene
gcloud container get-server-config --format="yaml(validMasterVersions)"
Verfügbare Knotenversionen
gcloud container get-server-config --format="yaml(validNodeVersions)"
Mit der Google Cloud Console Versionen prüfen
Ermitteln Sie mit den folgenden Schritten, welche Versionen verfügbar und als Standard festgelegt sind:
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie auf add_box Erstellen.
Wählen Sie den Clustermodus Standard aus und klicken Sie dann auf Konfigurieren.
Wählen Sie im Abschnitt Standorttyp einen Standorttyp und den gewünschten Standort für den Cluster aus.
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.
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 derzeit 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 aktualisiert.
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.
FAQ zur Versionsunterstützung
Wann beginnt das Unterstützungsfenster für jede Nebenversion?
Unterstützung für eine Nebenversion von Kubernetes beginnt, wenn sie erstmals für die Erstellung eines neuen Clusters in der regulären Releaseversion bereitgestellt wird.
Wie lange wird eine Kubernetes-Nebenversion von GKE unterstützt?
GKE bietet 14 Monate Unterstützung für jede bereitgestellte Kubernetes-Nebenversion. Versionen erhalten während des Unterstützungszeitraums kritische Patches für Fehler und Sicherheitsprobleme.
Worin unterscheiden sich die Wartungs- und End-of-Life-Zeiträume einer GKE-Nebenversion?
Der Wartungszeitraum bedeutet, dass eine Version voraussichtlich bald den End-of-Life-Zeitraum erreicht. Während des End-of-Life-Zeitraums erhält die GKE-Nebenversion keine Sicherheitspatches, Fehlerkorrekturen oder neuen Features.
Wann wird eine Kubernetes-Version in GKE nicht mehr unterstützt?
Eine Nebenversion von Kubernetes wird in GKE nicht mehr unterstützt, wenn das End of Life erreicht wird (nach 14 Monaten Unterstützung).
Was passiert am Startdatum der Wartung?
Kunden werden von GKE ggf. mithilfe bestehender Touchpoints wie Versionshinweisen, E-Mails an Projektkontakte und GKE-Benachrichtigungen über anstehende Wartungs- und End-of-Life-Versionen informiert. Vorhandene Knotenpools, die eine Wartungsversion ausführen, funktionieren weiterhin und das Erstellen neuer Knotenpools für die Wartungsversion wird deaktiviert.
Was passiert am End-of-Life-Datum?
Kunden, die eine End-of-Life-Version ausführen, werden vor dem End of Life einer Version mit einer E-Mail an den Projektkontakt benachrichtigt. GKE wird aus Sicherheits- und Kompatibilitätsgründen nach und nach auch automatische Upgrades von Knoten (unabhängig von der Aktivierung von automatischen Upgrades) ausführen, die eine End-of-Life-Version ausführen, da keine neuen Sicherheitspatches oder Fehlerkorrekturen für End-of-Life-Versionen durchgeführt werden. Bevor Sie sich an Cloud Customer Care bei Problemen mit einem Cluster oder Knoten mit einer End-of-Life-Version wenden, müssen Sie zuerst Ihren Cluster und Ihre Knoten auf eine unterstützte Version aktualisieren.
Wann wird mein Cluster automatisch aktualisiert?
Clustersteuerungsebenen werden automatisch auf unterstützte Versionen aktualisiert, wenn die Version der Steuerungsebene nicht mehr für die Erstellung neuer Cluster verfügbar ist.
Für Knoten, auf denen nicht unterstützte Versionen ausgeführt werden, wird innerhalb eines Monats nach dem Ende ihrer Lebensdauer ein automatisches Upgrade auf eine unterstützte Version geplant.
Kann ich während eines Clusterupgrades GKE-Versionen überspringen?
GKE erlaubt kein Überspringen von Nebenversionen für die Cluster-Steuerungsebene. Sie können jedoch Patchversionen überspringen. Worker-Knoten können Nebenversionen überspringen. Ein Knotenpool kann beispielsweise von Version 1.23 auf 1.25 aktualisiert werden, sodass Version 1.24 ü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.23 auf 125 aktualisieren möchten, führen Sie zuerst ein Upgrade von Version 1.23 auf 1.24 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.24 auf 1.25.
Durch ein Upgrade der Worker-Knoten auf die entsprechenden Versionen können Sie 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.
Kann ich meinen Cluster unbegrenzt mit einer bestimmten Kubernetes-Version verwenden?
Nein, jede GKE-Version wird 14 Monate lang unterstützt. Wenn Sie einen Cluster mit einer End-of-Life-GKE-Version ausführen, erhöht sich das erhebliche Sicherheits-, Zuverlässigkeits- und Kompatibilitätsrisiko erheblich, da keine Sicherheitspatches oder Fehlerkorrekturen für End-of-Life-Versionen bereitgestellt werden.
Wie oft sollte ich eine Kubernetes-Version aktualisieren, um weiterhin Unterstützung zu erhalten?
Es wird empfohlen, eine Release-Version zu wählen und automatische Knotenupgrades zu aktivieren, um den operativen Aufwand für ein Upgrade von GKE-Versionen zu reduzieren. Wenn Sie das Upgrade manuell durchführen, sollten Sie jedoch spätestens alle sechs Monate ein Upgrade durchführen, um neue Funktionen nutzen zu können und in einer unterstützten Version zu bleiben.
Welche Rollout-Richtlinie gilt für GKE-Steuerungsebenen?
Cluster-Steuerungsebenen werden regelmäßig aktualisiert, unabhängig davon, ob Ihr Cluster in einer Release-Version registriert ist oder ob automatische Knoten-Upgrades deaktiviert sind. Weitere Informationen zu automatischen Upgrades