Release-Versionen

Release-Versionen für Google Kubernetes Engine (GKE) verwenden, um Versionen für Ihre Cluster mit dem gewünschten Ausgleich zwischen Verfügbarkeit und Stabilität der Features auszuwählen.

GKE aktualisiert automatisch alle Cluster im Laufe der Zeit, einschließlich derjenigen, die nicht in einer Release-Version registriert sind. So werden Sicherheitsupdates, Fehlerkorrekturen für neue Funktionen und die Ausführung einer unterstützten Kubernetes-Version bereitgestellt. Sie können den Zeitpunkt der Upgrades mit Wartungsfenstern und -ausschlüssen steuern.

Es wird empfohlen, Ihren Cluster in einer Release-Version zu registrieren. Auf diese Weise erhalten Sie die größte Kontrolle über den Bereich von Wartungsausschlüssen und können bestimmte Arten von Upgrades verhindern, statt alle Upgrades – und Sequenzierung der Einführung von Cluster-Upgrades. Autopilot-Cluster können nur in einer Release-Version registriert werden.

Wenn Sie Ihren Standardcluster nicht für eine Release-Version registrieren, werden die Steuerungsebenen aller Cluster weiterhin automatisch aktualisiert. Wenn eine Version das Ende des Supports erreicht, werden die Steuerungsebenen und Knoten des Clusters unabhängig von der Release-Version-Registrierung automatisch aktualisiert. Weitere Informationen finden Sie im Vergleich zwischen Clustern, die für eine Release-Version registriert sind und solchen, die es nicht sind.

Welche Kanäle sind verfügbar?

In der folgenden Tabelle werden die Attribute der verfügbaren Release-Versionen erläutert. Diese bieten einen Kompromiss zwischen der Verfügbarkeit von Funktionen und der Stabilität. Alle Kanäle bieten unterstützte Versionen von GKE und werden als allgemein verfügbar (General Availability, GA) betrachtet. Einzelne Features sind wie angegeben jedoch nicht immer allgemein verfügbar. Die Kubernetes-Releases in diesen Kanälen sind offizielle Kubernetes-Releases und enthalten wie angegeben sowohl allgemein verfügbare als auch Kubernetes APIs in der Betaversion.

Kanal Verfügbarkeit von Nebenversionen Als Ziel für automatisches Upgrade festlegen Wann sollte dieser Kanal verwendet werden?
Rapid

1–2 Wochen nach der vorgelagerten allgemeinen Open-Source-Verfügbarkeit

Alpha-Patchversionen sind nur für Alpha-Cluster bis zu vier Monate vor der Bereitstellung der Nebenversion für alle Cluster in Rapid verfügbar.

 1–2 Monate nach der Veröffentlichung in Rapid

Sie erhalten die neueste Kubernetes-Version so früh wie möglich und können neue GKE-Features sofort verwenden, wenn sie allgemein verfügbar sind. Ihr Cluster wird von GKE regelmäßig aktualisiert, um die neueste verfügbare Patchversion zu behalten und neue Kubernetes-Funktionen bereitzustellen. Cluster, die den Rapid Channel abonniert haben, verwenden GA-Versionen. Wir empfehlen jedoch den Rapid Channel, um neuere Kubernetes-Versionen und API in Vorproduktionsumgebungen zu testen.

Der Rapid Channel wird für Alpha-Cluster empfohlen, die alle Kubernetes-Alpha-Feature-Gates und Alpha-APIs zum Testen aktivieren. Auf Alphaclustern im Rapid Channel können Alphapatchversionen der kommenden Nebenversionen bis zu vier Monate vor der allgemeinen Verfügbarkeit der Nebenversion in GKE ausgeführt werden.
Regular (Standard) Etwa 2 Monate nach der Veröffentlichung in Rapid Etwa 3 Monate nach der Veröffentlichung in Regular Der Zugriff auf GKE- und Kubernetes-Features erfolgt bald nach ihrer allgemeinen Verfügbarkeit, jedoch in einer Version, die über einen längeren Zeitraum qualifiziert wurde. Es bietet ein ausgewogenes Verhältnis zwischen Funktionsverfügbarkeit und Releasestabilität. Dieses Vorgehen wird für die meisten Nutzer empfohlen.
Stabil 3–4 Monate nach der Veröffentlichung in Regular Etwa 2 Monate nach der Veröffentlichung als stabile Version Stabilität hat Vorrang vor neuen Features. GKE führt Änderungen und neue Versionen in diesem Kanal zuletzt ein, nachdem sie in den Kanälen „Rapid“ und „Regular channel“ validiert wurden. Dadurch bleibt noch mehr Zeit für die Validierung.
Erweitert Abstimmung auf den Regular Channel Abstimmung auf den Regular Channel Verwenden Sie diesen Channel, um Langzeitsupport zu erhalten und einen Cluster so lange wie möglich mit einer Nebenversion auszuführen. Weitere Informationen finden Sie unter Langzeitsupport mit dem Extended Channel erhalten.
Kein Release-Kanal (verworfen) Abstimmung auf den Regular channel Abstimmung auf den Stable Channel Steuerungsebene und Knoten werden automatisch entsprechend den Regular- und Stable-Channels aktualisiert. Wenn Sie automatische Knotenupgrades auf Knotenpoolebene deaktivieren müssen, können Sie stattdessen eine Release-Version verwenden und eine der folgenden Aktionen ausführen: Weitere Informationen zu „Kein Kanal“ finden Sie im Vergleich zwischen Clustern, die in einer Release-Version registriert sind und nicht.

Wenn Sie einen Cluster in einem Releasekanal registrieren, wird dieser Cluster automatisch ab dem Datum aktualisiert, das in der Spalte Automatisches Upgrade des GKE-Releasezeitplans angegeben ist.

Wenn eine Version Nutzung angesammelt hat und im Rapid-Channel clusterübergreifend stabil ist, wird sie zum Regular-Channel hochgestuft. Schließlich wird die Version zum Stable Channel hochgestuft, der nur Updates mit hoher Priorität erhält. Jede Hochstufung signalisiert ein abgestuftes Maß an Stabilität und Produktionsbereitschaft, basierend auf der beobachteten Leistung von Clustern, die diese Version ausführen.

Alle Release-Versionen erhalten wichtige Sicherheitspatches, um Ihre Cluster und die Infrastruktur von Google zu schützen. In seltenen Notfallsituationen führt GKE möglicherweise automatische Upgrades für Cluster auf Versionen durch, die in der jeweiligen Release-Version noch nicht verfügbar sind.

Welche Versionen sind in einem Kanal verfügbar?

Jede Release-Version bietet mehrere Nebenversionen. Diese Versionen haben die Qualifikationsstandards für diesen Kanal erfüllt. Diese Gruppe verfügbarer Versionen enthält eine Standardversion für die Clustererstellung, die aus einer Gruppe verfügbarer Versionen aus diesem Kanal ausgewählt wird. Wenn Sie sehen möchten, welche Versionen in einer Release-Version verfügbar sind, folgen Sie der Anleitung unter Standardversion und verfügbare Versionen für Release-Versionen ansehen.

  • Neue Patchversionen sind nach folgender Zeit verfügbar:
    • Mindestens eine Woche, bevor sie im jeweiligen Channel zum Ziel für das automatische Upgrade werden
    • Mindestens zwei Wochen, nachdem sie in der vorherigen Version verfügbar gemacht wurden
  • Neue Nebenversionen sind nach folgender Zeit verfügbar:
    • Mindestens vier Wochen, bevor sie im Rapid Channel als Ziel für das automatische Upgrade festgelegt werden
    • Mindestens acht Wochen, bevor sie in den Kanälen „Regulär“ und „stabile Version“ als Ziel für das automatische Upgrade festgelegt werden

Wenn Sie anstehende Kubernetes-Nebenversionen testen möchten, sind Alpha-Patchversionen im Rapid Channel bis zu vier Monate vor der Bereitstellung dieser Nebenversion für alle Cluster im Rapid Channel verfügbar. Alphapatch-Versionen sind nur für Alphacluster verfügbar.

Sie können eine neu verfügbare GKE-Version testen, bevor Sie die Produktionsumgebung aktualisieren. So können Sie beispielsweise Upgrade-Benachrichtigungen abonnieren, um über neu verfügbare Versionen informiert zu werden, und dann proaktiv eine Vorproduktionsumgebung auf die neue Version aktualisieren, bevor diese zum Ziel für automatische Upgrades für Cluster in Ihrer Produktionsumgebung wird.

Wenn Sie einen Cluster auf einer bestimmten Version beibehalten müssen, um beispielsweise neuere Versionen vor dem Upgrade zu validieren oder zu testen, empfehlen wir die Verwendung von Wartungsausschlüssen.

Nachdem eine Nebenversion in einer Release-Version verfügbar gemacht wurde, bleibt sie in dieser Release-Version für neue oder bestehende Cluster verfügbar, bis sie das Ende des Supports erreicht.

Was passiert, wenn eine Version in einer Release-Version zum Ziel für automatische Upgrades wird?

Die GKE aktualisiert Cluster im Laufe der Zeit automatisch auf neue automatische Upgradeziele. Wenn neue Ziele für automatische Upgrades verfügbar sind, prüft GKE, ob Ihr spezifischer Cluster auf diese neue Version aktualisiert werden sollte. GKE berücksichtigt, ob für Ihren Cluster Wartungsrichtlinien oder andere Einschränkungen gelten, die automatische Upgrades verhindern. Diese Gründe werden nur in seltenen Notfallsituationen ignoriert.

So können Sie Ziele für automatische Upgrades für Ihre Cluster finden:

  • Informationen zum Abrufen von Zielen für automatische Upgrades für einen bestimmten Cluster finden Sie unter Informationen zu Cluster-Upgrades abrufen.
  • In der Tabelle mit aktuellen Versionen finden Sie eine Liste der aktuellen Ziele für automatische Upgrades für jede Release-Version. Die spezifische Version, die für Ihren Cluster gilt, hängt von der Nebenversion des Clusters und bestimmten Einschränkungen ab.
  • In den GKE-Versionshinweisen sind neue Ziele für automatische Upgrades für Cluster aufgeführt, auf denen bestimmte Nebenversionen mit Versionsupdates ausgeführt werden, z. B. der Hinweis 2024-R33.

Wenn 10 Tage vergangen sind, nachdem eine neue Version zu einem Ziel für automatische Upgrades für die Nebenversion Ihres Clusters in der Release-Version wurde, und die automatischen Upgrades für Ihren Cluster noch nicht begonnen haben, könnte die Verzögerung auf einen der folgenden Gründe zurückzuführen sein:

  • Ihr Cluster ist für automatische Upgrades vorübergehend nicht berechtigt. Das kann folgende Gründe haben:
    • Der Cluster befindet sich außerhalb des Zeitraums eines konfigurierten Wartungsfensters.
    • Der Cluster befindet sich innerhalb eines Wartungsausschlusses.
    • Automatische Upgrades werden pausiert, da der Cluster verworfene Kubernetes-Features verwendet, die in der nächsten Nebenversion entfernt werden.
    • Der Cluster wurde vor weniger als 24 Stunden automatisch auf eine Patchversion aktualisiert.
    • Der Cluster wurde vor weniger als 30 Tagen automatisch auf eine Nebenversion aktualisiert und das Ziel für das automatische Upgrade ist eine neue Nebenversion.
  • GKE hat die Einführung des neuen Ziels für automatische Upgrades aus technischen oder geschäftlichen Gründen pausiert:
    • Bei der neuen Version wurden technische Probleme erkannt.
    • Ein Produktionsstopp wird aufgrund einer geschäftskritischen Jahreszeit, wie dem Black Friday, festgelegt.

Das empfohlene Ziel für automatische Upgrades ist die Version, auf die GKE Ihre Cluster im Laufe der Zeit aktualisiert. Von allen Zielen für automatische Upgrades in einer Release-Version nähert GKE Ihre Cluster bei automatischen Upgrades dieser Version an.

Bei mehreren automatischen Upgrades aktualisiert GKE Ihre Cluster schrittweise auf das empfohlene automatische Upgradeziel des Release-Channels, sofern keine Einschränkungen vorliegen, die automatische Upgrades verhindern, bis Ihr Cluster das Ziel erreicht. Nachdem das Ziel erreicht wurde, verwendet Ihr Cluster kontinuierlich das vorhandene empfohlene Ziel für automatische Upgrades und wechselt zum neuen empfohlenen Ziel, wenn es veröffentlicht wird.

Was ist die Standardversion?

Wenn Sie einen Cluster in einer Release-Version erstellen, verwendet der Cluster standardmäßig die Standard-Patchversion für die Clustererstellung in der ausgewählten Release-Version. Sie können jedoch eine andere verfügbare Version angeben, wenn Sie einen Cluster in der Release-Version erstellen.

In Release-Versionen sind mehrere Nebenversionen verfügbar und die Standardversion kann manchmal eines der automatischen Upgradeziele für eine Release-Version sein.

Patchversionen früher erhalten

Mit den in diesem Abschnitt beschriebenen Methoden können Sie Patch-Versionen früher erhalten, indem Sie automatische oder manuelle Upgrades verwenden.

Beschleunigte automatische Upgrades von Patches

GKE führt eine neue Patchversion zuerst in einer Release-Version ein, indem die Version für die Erstellung neuer Cluster und manuelle Upgrades verfügbar gemacht wird. Nachdem GKE festgestellt hat, dass die Patchversion qualifiziert ist, legt GKE die neue Patchversion als Ziel für automatische Upgrades fest. Das bedeutet, dass GKE automatisch mit dem Upgrade von Clustern auf diese neue Patchversion beginnt. Die Zeitspanne von der Verfügbarkeit einer Version bis zu automatischen Upgrades beträgt in der Regel mindestens eine Woche, hängt jedoch vom Release-Version und den spezifischen Umständen der Qualifizierung der Version ab.

So rufen Sie Informationen zur Verfügbarkeit der aktuellen Version auf:

Wenn Sie Patch-Upgrades erhalten möchten, sobald die Version verfügbar ist und bevor GKE die Version als Ziel für automatische Upgrades im Channel festlegt, können Sie beschleunigte automatische Patch-Upgrades verwenden. Diese Einstellung kann nützlich sein, wenn Sie Sicherheitspatches so schnell wie möglich durch automatische Upgrades erhalten möchten.

Sie müssen die Risiken verstehen, die mit dem automatischen Upgrade des Clusters nach einem beschleunigten Zeitplan verbunden sind, bevor GKE feststellt, dass Cluster im Channel automatisch auf die neue Patchversion aktualisiert werden sollten. Bei diesem beschleunigten Zeitplan wird ein Schritt im Qualifizierungsprozess für Patchversionen in Release-Versionen übersprungen. Alle Patchversionen, nicht nur Patchversionen mit Sicherheitspatches, werden mit diesem beschleunigten Zeitplan aktualisiert. Diese Einstellung wirkt sich nicht auf Upgrades von Nebenversionen aus und ist nur für Cluster verfügbar, die in einer Release-Version registriert sind.

Diese Einstellung wirkt sich nur auf den Zeitpunkt aus, zu dem GKE ein automatisches Upgrade eines Clusters auf eine neue Patchversion durchführt. Die GKE hält sich weiterhin an Wartungsfenster und -ausschlüsse, folgt der Reihenfolge einer Roll-out-Sequenz und wendet alle anderen Standardverfahren an, die normalerweise für automatische Upgrades verwendet werden.

Weitere Informationen zum Einrichten dieser Funktion finden Sie unter Automatische Upgrades für beschleunigte Patches verwenden.

Alternativ können Sie Ihre Cluster manuell upgraden, wenn Sie ein Upgrade auf eine bestimmte Patchversion durchführen möchten, sobald die Version verfügbar ist und bevor sie als Ziel für automatische Upgrades festgelegt wird.

Patchversionen aus einem neueren Kanal ausführen

Zusätzlich zu den aufgelisteten verfügbaren Patchversionen für eine Release-Version können Sie Patchversionen aus neueren Release-Versionen als der, in der Ihr Cluster registriert ist, ausführen, wenn die Nebenversion in der Release-Version des Clusters verfügbar ist und Sie die gcloud CLI oder die GKE API verwenden.

Wenn beispielsweise die folgenden Versionen im Rapid Channel und im Regular Channel verfügbar sind:

  • Rapid: 1.23.2-gke.700, 1.22.4-gke.1500
  • Regular: 1.21.4-gke.400, 1.22.1-gke.400

Ein Cluster, der für den Regular Channel registriert ist, auf dem die GKE-Version 1.22.1-gke.400 ausgeführt wird, kann manuell auf 1.22.4-gke.1500, aber nicht auf 1.23.2-gke.700 aktualisiert werden, da es eine andere Nebenversion ist.

Für ein manuelles Upgrade auf eine Patchversion auf einem neueren Kanal muss die Steuerungsebene Ihres Clusters einen Patchrelease mit derselben Nebenversion ausführen. Wenn im Cluster beispielsweise 1.21.3-gke.200 ausgeführt wird, müssen Sie den Cluster zuerst manuell auf eine Patchversion aktualisieren, die in der aktuellen Release-Version 1.22.1-gke.400 verfügbar ist. Anschließend können Sie den Cluster auf 1.22.4-gke.1500 aktualisieren.

Sie können auch einen neuen Cluster erstellen, auf dem 1.22.4-gke.1500 ausgeführt wird und der im Regular Channel registriert ist.

GKE behält die Patchversion des neueren Kanals für den Cluster bei, bis ein neueres Ziel für automatische Upgrades im registrierten Kanal für den Cluster verfügbar ist.

Das ist neu in einem Kanal

In den Versionshinweisen erhalten Sie Informationen zu den Neuerungen in einer Release-Version. Für jede Release-Version gibt es zusätzlich zu den allgemeinen Versionshinweisen separate Versionshinweise.

Releasekanal Versionshinweise
Rapid Channel HTML- oder Atom-Feed
Regular Channel HTML- oder Atom-Feed
Stable Channel HTML- oder Atom-Feed

Die beste Release-Version für Ihren Cluster auswählen

Jeder Kanal steht für einen anderen Grad an Qualität und Reife der Kubernetes- und GKE-Releases. Das folgende Diagramm veranschaulicht den Akzeptanzzyklus für Release-Versionen:

Adoptionszyklus für Release-Versionen

Wie aus diesem Diagramm hervorgeht, verwenden die verfügbaren Release-Versionen Versionen inmitten des Einführungszyklus, einschließlich Erste Nutzer (Rapid Channel) Erste Mehrheit (Regular Channel) und Mehrheit Stable Channel). Der früheste Teil des Einführungszyklus sind die Innovators, die die neuesten Funktionen mithilfe des vorgelagerten Kubernetes-Release testen. Der letzte Teil des Einführungszyklus ist die Späte Mehrheit. Hier verwenden Sie eine Version, die fast verworfen wurde und auf eine unterstützte Version umgestellt werden muss.

Verwenden Sie in Ihren Vorproduktionsumgebungen den Rapid Channel für neuere Versionen, in denen Sie Funktionen testen können, sobald sie allgemein verfügbar sind.

Für Produktionsarbeitslasten, die eine neuere Funktionalität benötigen, empfehlen wir die Verwendung des regulären (Standardkanals) oder der Stable Channel.

  • Wenn Sie neue Funktionen genau erfassen möchten, sollten Sie den Kanal „Regular“ verwenden, der einen Ausgleich zwischen Stabilität und Aktualität der Kubernetes OSS-Version bietet.
  • Wenn Ihre Anforderung für die Produktionscluster Reifegrad ist, verwenden Sie den Stable Channel.

GKE aktualisiert Cluster auf eine neuere Version, die den Qualitätsstandards des Kanals entspricht. Wir empfehlen jedoch, im Voraus ein Upgrade Ihrer Cluster durchzuführen, da dies folgende Vorteile bietet:

  • Bessere Kontrolle über Upgrades und Abstimmung auf Ihre Arbeitszeiten.
  • Bessere Vorhersagebarkeit, da GKE automatische Cluster-Upgrades übersprungen, die das Releaseziel erfüllen (d. h. Cluster, die manuell auf die nächste Zielversion aktualisiert wurden). Knoten werden im ausgewählten Kanal automatisch auf die empfohlene Version aktualisiert, um sie an die Version der Steuerungsebene anzupassen und vor Sicherheitslücken und Inkompatibilität durch nicht unterstützte Versionen zu schützen.

Langzeitsupport mit dem Extended Channel erhalten

GKE bietet Langzeitsupport für Kubernetes-Nebenversionen über den Extended-Kanal. Mit diesem Channel können Sie eine Nebenversion bis zu 24 Monate lang verwenden. Nach dem 14-monatigen Standardsupportzeitraum erhält Ihr Cluster während des erweiterten Supportzeitraums ungefähr 10 weitere Monate lang Sicherheitspatches.

So aktualisiert GKE Cluster im Extended Channel automatisch

Bei Clustern, die für den Extended Channel registriert sind, führt GKE automatisch ein Upgrade der Cluster durch:

  • Während des Standard-Supportzeitraums: GKE führt Upgrades von Clustern auf neuere Patchversionen derselben Nebenversion im selben Rhythmus wie beim Regular Channel durch.
  • Während des erweiterten Supportzeitraums: GKE stellt weiterhin Sicherheitspatch-Updates für die Nebenversion bereit. Etwa zwei Monate vor dem Ende des erweiterten Supports beginnt die GKE mit dem Upgrade von Clustern auf die nächste Nebenversion, es sei denn, der Cluster verwendet verworfene Funktionen oder APIs. Mit Wartungsausschlüssen können Sie Nebenversionsupgrades bis zum Ende des erweiterten Supports verhindern.
  • Am Ende des erweiterten Supports: GKE führt Upgrades aller Cluster durch, auf denen die jetzt nicht mehr unterstützte Nebenversion ausgeführt wird. Aspekte, die diesen Vorgang blockieren, werden nicht berücksichtigt. Nach diesem Datum können Sie keine Wartungsausschlüsse mehr konfigurieren, außer als vorübergehende Notfallmaßnahme mit dem Bereich „Keine Upgrades“.

Weitere Informationen zu den verschiedenen Verfügbarkeitszeiträumen und den Upgrades, die GKE während des erweiterten Supportzeitraums bereitstellt, finden Sie unter Lebenszyklus von GKE-Nebenversionen.

Einschränkungen beim Registrieren eines Clusters im erweiterten Kanal

Beachten Sie die folgenden Einschränkungen für Cluster, die im Extended-Channel registriert sind:

Preise für den erweiterten Support

Wenn Sie einen Cluster für den erweiterten Kanal registrieren möchten, sollten Sie die Preise für erweiterten Support gelesen haben. Die Kosten werden nach Nutzung abgerechnet, wenn Ihr Cluster für die Release-Version „Erweitert“ registriert ist und der erweiterte Supportzeitraum für die Nebenversion des Clusters beginnt.

Best Practices für den Extended Channel

Sehen Sie sich die folgenden Szenarien an, um zu erfahren, wie Sie den erweiterten Kanal verwenden können, um Unterbrechungen durch Upgrades auf Nebenversionen zu minimieren.

Die unterstützten Szenarien erfordern im Laufe der Zeit einige manuelle Aktionen, um den Kanal optimal zu nutzen. Wir empfehlen nicht, einen Cluster in der Release-Version „Extended Channel“ zu registrieren, wenn Sie nicht planen, zur nächsten Nebenversion zu wechseln. GKE führt schließlich ein Upgrade des Clusters auf neuere Nebenversionen mit derselben Häufigkeit wie bei anderen Release-Versionen durch. Ihr Cluster verursacht dann möglicherweise höhere Kosten und erhält neue Funktionen zuletzt.

Unterstützte und nicht unterstützte Szenarien

Weitere Informationen zu unterstützten und nicht unterstützten Szenarien finden Sie in der folgenden Tabelle und unter Erweiterten Kanal für Langzeitsupport verwenden. Ein Häkchen () weist auf ein unterstütztes Szenario hin:

Upgrade-Szenario Unterstützt Zusammenfassung Zeit zwischen Änderungen der Nebenversion Manuelle Maßnahme erforderlich
Nebenversion vorübergehend länger nutzen Eine Nebenversion beibehalten, um ein Problem zu beheben, das Upgrades verhindert Gleiche durchschnittliche Häufigkeit, mit Unterbrechung für zusätzliche Zeit bei einer Nebenversion.
  • Cluster vorübergehend in die erweiterte Version und wieder zurück verschieben.
  • Führen Sie bei Bedarf ein manuelles Upgrade des Clusters auf die neue Nebenversion durch.
1- bis 2-mal pro Jahr manuell ein Upgrade auf die nächste Nebenversion durchführen Sie erhalten neue Funktionen, aber weniger häufige Nebenversionsupgrades, wenn dies für die Arbeitslasten im Cluster optimal ist. Ein- bis zweimal pro Jahr
  • Cluster manuell auf eine neuere Nebenversion aktualisieren.
Nichts tun und Nebenversionsupgrades mit derselben Häufigkeit erhalten Sie erhalten Upgrades für Nebenversionen mit derselben Häufigkeit wie andere Channels und neue Funktionen so spät wie möglich. Durchschnittlich alle vier Monate.
  • Überwachung automatischer Upgrades von Nebenversionen von nicht unterstützten Versionen.

Cluster, die nicht für eine Release-Version registriert sind

Sie können einen Standardcluster nicht in einer Release-Version registrieren. Wenn Sie sich jedoch nicht registrieren, wird der Zugriff Ihres Clusters auf bestimmte Funktionen eingeschränkt. Außerdem ist diese Konfigurationsoption veraltet und wird entfernt. Unabhängig von der Registrierung in einer Release-Version werden die Steuerungsebenen aller Cluster automatisch aktualisiert. Wenn eine Version das Ende des Supports erreicht, werden die Steuerungsebenen und Knoten des Clusters automatisch aktualisiert.

Informationen zum Migrieren von dieser Konfigurationsoption finden Sie unter Vorhandenen Cluster registrieren.

Wenn Sie einen Cluster nicht für eine Release-Version registrieren möchten, weil Sie einzelne Knotenpools haben, die nicht automatisch aktualisiert werden können, und Sie diese Knoten stattdessen manuell aktualisieren müssen, können Sie dasselbe Verhalten mit Release-Versionen erreichen. Wenn Sie bei Release-Versionen automatische Knotenupgrades für alle Knotenpools bis zum Ende des Supports deaktivieren müssen, können Sie einen Wartungsausschluss für Cluster mit dem Bereich „Keine Nebenversions- oder Knotenupgrades“ verwenden. Wenn Sie einen Cluster haben, in dem Sie automatische Upgrades für einige, aber nicht alle Knotenpools deaktivieren möchten, verwenden Sie einen Wartungsausschluss für Knotenpools.

Vergleich zwischen Clustern, die in einer Release-Version registriert sind und solchen, die nicht registriert sind

In der folgenden Tabelle finden Sie die Ähnlichkeiten und Unterschiede zwischen der Registrierung und der Registrierung Ihres Clusters in einer Release-Version:

Funktion Cluster in einer Release-Version registriert Cluster ist nicht für eine Release-Version registriert
Verhalten bei gemeinsam genutzten Upgrades
Zeitpunkt des Upgrades Abstimmung auf die jeweilige Release-Version
  • Gleiches Startdatum für das automatische Upgrade wie bei der Stable Channel für Nebenversionen
  • Gleiche Nebenversionen, automatische Patch-Upgrade-Versionen und Standardversion wie der Regular Channel
  • Dieselben Patchversionen wie der Rapid Channel für die Nebenversionen, die im Regular Channel verfügbar sind
Beschleunigte automatische Patch-Upgrades Verfügbar Nicht verfügbar
Kontrolle über Knotenpoolunterbrechungen
  • Standardmäßig automatische Knotenupgrades
  • Sie können automatische Knotenupgrades auf folgende Arten deaktivieren:
    • Auf Clusterebene für bis zu 90 Tage, indem Sie einen Wartungsausschluss mit dem Bereich „Keine Upgrades“ erstellen
    • Auf Knotenpoolebene bis zum Ende des Supports für die Nebenversion durch Deaktivieren automatischer Knotenupgrades. Sie können dasselbe Ergebnis mit Release-Versionen erzielen, indem Sie einen Wartungsausschluss für Knotenpools erstellen.
Wartungsfenster Verfügbar Verfügbar
Wartungsausschlüsse Sie sind auf den Bereich „Keine Upgrades“ beschränkt (bis zu 90 Tage)
Rollout-Sequenzierung Verfügbar Nicht verfügbar
Langzeitsupport Nur mit der erweiterten Release-Version verfügbar Nicht verfügbar
Autopilot Verfügbar Nicht verfügbar

Rapid Channel für Alphacluster auswählen

Über den Rapid Channel erhalten Sie so früh wie möglich Zugriff auf neue Versionen für Ihren GKE-Cluster, einschließlich Alpha-Patchversionen der kommenden Nebenversionen. Mit Alphaclustern können Sie neue Funktionen testen, die zuerst in neueren Versionen verfügbar sind. In einem Alpha-Cluster sind alle Kubernetes APIs, einschließlich Alpha-APIs, aktiviert. Alle Kubernetes-Alphafunktionen sind standardmäßig aktiviert. Sie können bestimmte Alpha- und Beta-Feature-Gates umschalten. Machen Sie sich vor der Bereitstellung von Alphaclustern mit den Einschränkungen vertraut.

Sie können Ihren Alpha-Cluster auch in den Release-Versionen „Regular“ oder „Stable“ registrieren. Sie können dann jedoch nicht auf die neuesten Kubernetes-Versionen, einschließlich Alpha-Patch-Versionen, in diesen Release-Versionen zugreifen. Wenn Sie Ihren Cluster nicht in einer Release-Version registrieren, ist das eine veraltete Konfigurationsoption, die entfernt wird. Weitere Informationen finden Sie im vorherigen Abschnitt Cluster, die nicht für eine Release-Version registriert sind.

Nächste Schritte