Mit Release-Versionen für Google Kubernetes Engine (GKE) können Sie Versionen für Ihre Cluster mit dem gewünschten Ausgleich zwischen Verfügbarkeit und Stabilität der Features auswä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.
Wir empfehlen, Ihren Cluster in einer Release-Version zu registrieren. Auf diese Weise erhalten Sie die größte Kontrolle über den Umfang von Wartungsausschlüssen und können bestimmte Arten von Upgrades verhindern, statt alle Upgrades, und die Einführung von Cluster-Upgrades sequenzieren. Autopilot-Cluster können nur in einer Release-Version registriert werden.
Wenn Sie Ihren Standardcluster nicht für eine Release-Version registrieren, können Sie automatische Knotenupgrades für ausgewählte Knotenpools deaktivieren und Upgrades der Knoten in diesen Knotenpools manuell verwalten. Die Steuerungsebenen aller Cluster werden jedoch automatisch aktualisiert. Wenn eine Version das Ende der Supportphase erreicht, werden die Steuerungsebenen und Knoten des Clusters unabhängig von der Registrierung für die Release-Version automatisch aktualisiert. Weitere Informationen finden Sie im Vergleich zwischen Clustern, die in einer Release-Version registriert sind, und solchen, die nicht registriert 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.
| Version | Neue Kubernetes-Releaseverfügbarkeit | Wann sollte dieser Kanal verwendet werden? |
|---|---|---|
| Schnell | Mehrere Wochen nach der vorgelagerten allgemeinen Open-Source-Verfügbarkeit | 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. |
| Regular (Standard) | Zwei bis drei Monate nach Veröffentlichung in Rapid | 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. Bietet ein ausgewogenes Verhältnis zwischen Featureverfügbarkeit und Releasestabilität. Dieses Vorgehen wird für die meisten Nutzer empfohlen. |
| Stabil | Zwei bis drei Monate nach Veröffentlichung in Regular | Stabilität hat Vorrang vor neuen Features. GKE führt Änderungen und neue Versionen in diesem Kanal zuletzt ein, nachdem es in den Versionen "Rapid" und "Regular" validiert wurde. Dadurch bleibt noch mehr Zeit für die Validierung. |
| Erweitert | Abstimmung auf den Regular Channel | Mit diesem Kanal erhalten Sie langfristigen Support und können einen Cluster so lange wie möglich mit einer Nebenversion ausführen. Weitere Informationen finden Sie unter Langzeitsupport mit dem Extended Channel erhalten. |
| Kein Channel (nicht empfohlen) | Abstimmung auf den Regular Channel | Diese Option wird nicht empfohlen. Steuerungsebene und Knoten werden automatisch gemäß den Regular- und Stable-Channels aktualisiert. Wenn Sie automatische Knotenupgrades auf Knotenpoolebene deaktivieren möchten, können Sie diese Konfigurationsoption verwenden. Alternativ können Sie mit Release-Versionen automatische Knotenupgrades auf Clusterebene deaktivieren. Weitere Informationen finden Sie im Vergleich zwischen Clustern, die in einem Release-Kanal registriert sind, und Clustern, die nicht registriert sind. |
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 im Rapid Channel clusterübergreifend genutzt wurde und sich als stabil erwiesen hat, 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 Releasekanäle erhalten wichtige Sicherheitspatches, um Ihre Cluster und die Infrastruktur von Google zu schützen. In seltenen Notfallsituationen führt GKE möglicherweise automatisch ein Upgrade von Clustern auf Versionen durch, die noch nicht in ihrem Release-Kanal verfügbar sind.
Welche Versionen sind in einem Kanal verfügbar?
Jeder Release-Kanal bietet mehrere Nebenversionen. Diese Versionen haben die Qualifikationsstandards für diesen Kanal erfüllt. Dieser Satz verfügbarer Versionen enthält eine Standardversion für die Clustererstellung, die aus einer Reihe verfügbarer Versionen aus diesem Kanal ausgewählt wird. Wenn Sie wissen möchten, welche Versionen in einer bestimmten Release-Version verfügbar sind, folgen Sie der Anleitung unter Standardversion und verfügbare Versionen für Release-Versionen ansehen.
- Neue Patchversionen sind mindestens eine Woche verfügbar, bevor sie für alle Kanäle als Ziel für die automatische Aktualisierung festgelegt werden.
- Neue Nebenversionen sind verfügbar:
- mindestens zwei Wochen vor dem automatischen Upgrade auf den Rapid-Channel.
- mindestens vier Wochen, bevor sie für die Kanäle „Regulär“ und „Stabil“ als Ziel für automatische Upgrades festgelegt werden.
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 der Supportzeit erreicht.
Was passiert, wenn eine Version in einer Release-Version als Ziel für automatische Upgrades festgelegt wird
GKE führt im Laufe der Zeit automatisch Upgrades für Cluster auf neue Ziele für automatische Upgrades durch. Wenn neue Ziele für automatische Upgrades verfügbar sind, prüft GKE, ob Ihr Cluster auf diese neue Version umgestellt werden soll. 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 finden Sie Ziele für automatische Upgrades für Ihre Cluster:
- Informationen zum Abrufen von Zielen für automatische Upgrades für einen bestimmten Cluster finden Sie unter Informationen zu Upgrades eines Clusters abrufen (Vorabversion).
- In der Tabelle „Aktuelle Versionen“ finden Sie eine Liste der aktuellen Ziele für automatische Upgrades für jeden Release-Kanal. Die spezifische Version, die für Ihren Cluster gilt, hängt von der Minorversion des Clusters und von 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. die 2024-R33-Mitteilung.
Wenn 10 Tage vergangen sind, nachdem eine neue Version zum Upgradeziel für die Nebenversion Ihres Clusters in der Release-Version geworden ist, 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 das Roll-out 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.
Was ist das empfohlene Ziel für automatische Upgrades?
Das empfohlene Ziel für automatische Upgrades ist die Version, auf die GKE Ihre Cluster im Laufe der Zeit nach und nach aktualisiert. Von allen automatischen Upgrade-Zielen in einem Release-Kanal nähert GKE Ihre Cluster dieser Version an, wenn automatische Upgrades ausgeführt werden.
Sofern keine Einschränkungen vorliegen, die automatische Upgrades verhindern, werden Ihre Cluster von GKE in mehreren automatischen Upgrades schrittweise auf das empfohlene automatische Upgradeziel des Release-Channels aktualisiert, bis das Ziel erreicht ist. Nachdem das Ziel erreicht wurde, verwendet Ihr Cluster kontinuierlich das vorhandene empfohlene Ziel für automatische Upgrades und wechselt zum neuen empfohlenen Ziel, sobald 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 das Erstellen von Clustern in der ausgewählten Release-Version. Sie können jedoch beim Erstellen eines Clusters im Release-Kanal eine andere verfügbare Version angeben.
Für Release-Versionen sind mehrere Nebenversionen verfügbar. Die Standardversion kann manchmal eines der Ziele für automatische Upgrades für einen Release-Kanal sein.
Patchversionen aus einem neueren Kanal ausführen
Zusätzlich zu den aufgeführten verfügbaren Patchversionen für eine Release-Version können Sie Patchversionen aus neueren Release-Versionen ausführen als derjenigen, in der Ihr Cluster registriert ist, wenn die Nebenversion im Release-Kanal des Clusters verfügbar ist und Sie die gcloud CLI oder die GKE API verwenden.
Wenn beispielsweise die folgenden Versionen im Rapid- und im Regular-Channel verfügbar sind:
- Schnell: 1.23.2-gke.700, 1.22.4-gke.1500
- Normal: 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 auf 1.22.4-gke.1500, aber nicht auf 1.23.2-gke.700 aktualisiert werden, da es sich um eine andere Nebenversion handelt.
Für ein 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 auf eine Patchversion aktualisieren, die in der aktuellen Release-Version 1.22.1-gke.400 verfügbar ist. Sie können den Cluster dann 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 für den 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
Kanäle umfassen nur GA-Versionen von Kubernetes, die jeweils einen anderen Grad an Qualität und Reifesgrad der Kubernetes- und GKE-Releases darstellen. Das folgende Diagramm veranschaulicht den Akzeptanzzyklus für Releasekanäle:
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-Kanal 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 stabilen Version.
- 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-Kanal.
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 für den erweiterten Kanal erhalten
GKE bietet über den Extended-Kanal langfristigen Support für Kubernetes-Nebenversionen. Dort können Sie eine Nebenversion bis zu 24 Monate lang behalten. Nach dem 14-monatigen Standardsupportzeitraum erhält Ihr Cluster während des erweiterten Supportzeitraums noch ungefähr 10 Monate lang Sicherheitspatches.
So führt GKE automatische Upgrades von Clustern im Extended Channel durch
Bei Clustern, die für den erweiterten Kanal registriert sind, führt GKE automatische Upgrades auf folgende Weise durch:
- Während des Standard-Supportzeitraums: GKE führt Upgrades von Clustern auf neuere Patchversionen derselben Nebenversion mit derselben Taktung wie im Regular Channel durch.
- Während des erweiterten Supports: GKE stellt weiterhin Sicherheits-Patch-Updates für die Nebenversion bereit. Etwa zwei Monate vor dem Ende des erweiterten Supports beginnt 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 Upgrades auf Nebenversionen 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.
Weitere Informationen zu den verschiedenen Verfügbarkeitszeiträumen und den Upgrades, die GKE während des erweiterten Supports anbietet, finden Sie im Lebenszyklus der GKE-Nebenversion.
Einschränkungen bei der Registrierung eines Clusters im erweiterten Kanal
Sie können nur Standardcluster mit Version 1.27 oder höher im Extended Channel registrieren. Sowohl die Steuerungsebene als auch die Knoten des Clusters müssen Version 1.27 oder höher ausführen.
Sie können einen Cluster nicht für den erweiterten Kanal registrieren, wenn Sie die folgenden Funktionen verwenden:
- Autopilot-Clustermodus
- Alphacluster
- Explizit aktivierte Kubernetes Beta APIs
- Gateway
- Windows Server-Knotenpools
- Benutzerdefinierte sysctl-Konfigurationsoptionen
- Sicherung für GKE
- Config Connector
- Die folgenden Multi-Cluster-Funktionen:
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. Sie können einen Cluster ohne zusätzliche Kosten im erweiterten Kanal registrieren, wenn für das Projekt GKE Enterprise aktiviert ist. Oder für Cluster der GKE Standard-Version fallen nutzungsabhängige Kosten an, wenn Ihr Cluster für den erweiterten Kanal registriert ist und die Nebenversion Ihres Clusters in den erweiterten Supportzeitraum wechselt.
Best Practices für den erweiterten Kanal
In den folgenden Szenarien erfahren Sie, wie Sie mit dem erweiterten Kanal Unterbrechungen durch Upgrades auf Minor-Versionen minimieren können.
Für die unterstützten Szenarien sind im Laufe der Zeit einige manuelle Aktionen erforderlich, um den Kanal optimal zu nutzen. Wir empfehlen nicht, einen Cluster in diesem Kanal zu registrieren, wenn Sie nicht vorhaben, auf die nächste Nebenversion umzustellen. GKE führt dann mit derselben Häufigkeit wie bei anderen Kanälen ein Upgrade auf neuere Nebenversionen durch. Außerdem fallen für Ihren Cluster möglicherweise höhere Kosten an und Sie erhalten neue Funktionen als Letzter.
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 () gibt an, dass ein Szenario unterstützt wird:
| Upgradeszenario | Unterstützt | Zusammenfassung | Zeit zwischen Änderungen an Nebenversionen | Manuelle Maßnahme erforderlich |
|---|---|---|---|---|
| Vorübergehend länger bei einer Nebenversion bleiben | Beibehalten Sie eine Nebenversion, um ein Problem zu vermeiden, das Upgrades verhindert. | Gleiche durchschnittliche Häufigkeit, Unterbrechung für zusätzliche Zeit bei einer Nebenversion. |
|
|
| Manuelles Upgrade auf die Nebenversion 1–2 Mal pro Jahr | Sie erhalten neue Funktionen, aber mit weniger häufigen Minor-Upgrades, wenn dies für die Arbeitslasten im Cluster optimal ist. | Ein- bis zweimal pro Jahr. |
|
|
| Nichts tun und mit derselben Häufigkeit kleinere Upgrades erhalten | Sie erhalten Upgrades auf Nebenversionen mit derselben Häufigkeit wie andere Kanäle und neue Funktionen so spät wie möglich. | durchschnittlich alle 4 Monate. |
|
Cluster, die nicht für eine Release-Version registriert sind
Wir empfehlen diese Konfigurationsoption aufgrund der Einschränkungen bei Clustern, die nicht in Release-Versionen registriert sind. Sie können jedoch einen Standardcluster nicht in einer Release-Version registrieren (auch als kein Kanal und früher als statisch bezeichnet). Verwenden Sie diese Option nur, wenn einzelne Knotenpools nicht automatisch aktualisiert werden können und Sie diese Knoten stattdessen manuell aktualisieren müssen. Wenn Ihr Cluster nicht für eine Release-Version registriert ist, können Sie automatische Knotenupgrades für ausgewählte Knotenpools deaktivieren. Mit Release-Versionen können Sie dasselbe Ergebnis auf Clusterebene für alle Knotenpools erzielen. Die Steuerungsebenen aller Cluster werden jedoch unabhängig von der Registrierung der Release-Version automatisch aktualisiert. Wenn eine Version das Ende der Supportphase erreicht, werden die Steuerungsebenen und Knoten des Clusters automatisch aktualisiert.
Wenn Sie automatische Upgrades für den gesamten Standardcluster oder alle Knotenpools verhindern möchten, empfehlen wir die Verwendung eines Wartungsausschlusses, wenn Ihr Cluster für einen Release-Kanal registriert ist. Mit Wartungsausschlüssen können Sie automatische Knotenupgrades für alle Knotenpools deaktivieren. Sie können automatische Knotenupgrades jedoch für alle Knotenpools deaktivieren, wenn Ihr Cluster nicht für eine Releaseversion registriert ist.
Vergleich zwischen Clustern, die in einem Release-Kanal registriert sind, und Clustern, 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 |
|
| Kontrolle über Knotenpoolunterbrechungen |
|
|
| Wartungsfenster | Verfügbar | Verfügbar |
| Wartungsausschlüsse |
Verfügbare Wartungsausschlussbereiche:
|
Sie sind auf den Bereich „Keine Upgrades“ beschränkt (30 Tage) |
| Rollout-Sequenzierung | Verfügbar mit flottenbasierten und bereichsbasierten Sequenzen | Nicht verfügbar |
| Langzeitsupport | Nur mit der erweiterten Release-Version verfügbar | Nicht verfügbar |
| Autopilot | Verfügbar | Nicht verfügbar |
Unterschiede zwischen Rapid-Kanalclustern und Alphaclustern
Cluster, die mithilfe des Rapid-Releasekanals erstellt wurden, sind keine Alphacluster. Es gibt folgende Unterschiede:
- Cluster, die Releasekanäle verwenden, können aktualisiert werden. Die automatische Umstellung ist außerdem aktiviert und kann nicht deaktiviert werden. Für Alphacluster kann kein Upgrade durchgeführt werden.
- Cluster, die Releasekanäle verwenden, haben kein Ablaufdatum. Alphacluster laufen nach 30 Tagen ab.
- Alpha Kubernetes APIs sind in Clustern, die Releasekanäle verwenden, nicht aktiviert.
Nächste Schritte
- Release-Versionen verwenden
- Upgrade für Cluster durchführen
- Übersicht über Clusterupgrades (Vorabversion)
- Cluster-Upgrade-Benachrichtigungen erhalten
- Informationen zum Verwalten automatischer Cluster-Upgrades in verschiedenen Umgebungen finden Sie unter Roll-out-Sequenzierung.