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.
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 vorübergehend 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, 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 des Produktzyklus erreicht, werden die Steuerungsebenen und Knoten des Clusters unabhängig von der Release-Version-Registrierung automatisch aktualisiert. Weitere Informationen finden Sie unter Zeitpunkt der Registrierung des Clusters in einer Release-Version.
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 Aktualisierung von Abwanderungen. 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. Es bietet ein ausgewogenes Feature-Verfügbarkeit und Release-Stabilitä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. |
Wenn Sie einen Cluster in einem Releasekanal registrieren, wird dieser Cluster automatisch ab dem Datum aktualisiert, das in der Spalte 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 Releasekanäle erhalten wichtige Sicherheitspatches, um Ihre Cluster und die Infrastruktur von Google zu schützen.
Welche Versionen sind in einem Kanal verfügbar?
Jede Release-Version bietet eine Standardversion, die aus einer Reihe von verfügbaren Versionen für diesen Kanal ausgewählt wurde. Diese Versionen haben die Qualifikationsstandards für diesen Kanal erfüllt. Im Laufe der Zeit aktualisiert GKE automatisch Cluster auf die Standardversion.
- Neue Patchversionen sind mindestens eine Woche verfügbar, bevor sie für alle Kanäle als Standard festgelegt werden.
- Neue Nebenversionen sind verfügbar:
- mindestens zwei Wochen, bevor Sie für den Rapid Channel als Standard festgelegt werden.
- mindestens vier Wochen, bevor sie für die Kanäle Regulär und Stabil als Standard 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 zur Standardversion 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.
Für die Versionen 1.19 und höher gilt: 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 ihrer Produktlebensdauer erreicht.
Standardversion und verfügbare Versionen für Release-Versionen ansehen
Führen Sie den folgenden Befehl aus, um die Standardversion und die verfügbaren Versionen für Releasekanäle aufzurufen. Ersetzen Sie dabei COMPUTE_ZONE durch Ihre Computing-Zone:
gcloud container get-server-config --format "yaml(channels)" --zone COMPUTE_ZONE
Führen Sie den entsprechenden Befehl für Release-Versionen aus, um die verfügbaren Versionen für Cluster anzuzeigen, die nicht in einer Release-Version registriert sind. Ersetzen Sie dabei "yaml(channels)" im Befehl durch "yaml(validMasterVersions)".
Was passiert, wenn eine neue Version in einer Release-Version als Standardversion festgelegt wird?
Wenn eine neue GKE-Version in einer Release-Version als Standard festgelegt wird:
- Neue Cluster werden mit der neuen Standardversion in der ausgewählten Release-Version erstellt.
- Vorhandene berechtigte Cluster werden innerhalb von zehn Tagen automatisch aktualisiert, nachdem eine neue Version in der Release-Version als Standard festgelegt wurde.
Wenn 10 Tage vergangen sind, nachdem eine neue Version als Standard in der Release-Version eingestellt 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 die neue Standardversion ist eine neue Nebenversion.
- GKE hat die Einführung der neuen Standardversion 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.
Patchversionen aus einem neueren Kanal ausführen
Zusätzlich zu den aufgelisteten verfügbaren Versionen für eine Release-Version bietet GKE eingeschränkten Zugriff auf die Patchversionen von weniger ausgereiften Release-Versionen. Ein Cluster, der für eine Release-Version registriert ist, kann Patch-Versionen aus einem neueren Kanal verwenden, wenn die Nebenversion im neueren Kanal mit der Nebenversion identisch ist, die in der eigenen Release-Version des Clusters verfügbar ist.
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 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 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. Anschließend können Sie den Cluster auf 1.22.4-gke.1500 aktualisieren.
Sie können auch einen neuen Cluster erstellen, der 1.22.4-gke.1500 ausführt und im Regular Channel registriert ist.
Der Cluster behält die Patchversion vom weniger ausgereiften Kanal, bis die Standardversion des Kanals, in dem der Cluster registriert ist, höher als die Clusterversion ist. Der Cluster wird dann automatisch auf die Standardversion aktualisiert.
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 Features 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.
Cluster in einer Release-Version registrieren
In diesem Abschnitt erfahren Sie, wie Sie eine Release-Version für neue Cluster oder für vorhandene Cluster auswählen, die zuvor keine Release-Version verwendet haben. Sie können auch die Release-Version für einen vorhandenen Cluster ändern, der bereits für eine Release-Version registriert ist.
Diese Änderung verursacht keine Ausfallzeiten. Da GKE jedoch verschiedene automatische Upgrades in der Release-Version haben kann, empfehlen wir die Verwendung von Wartungsfenstern und -ausschlüssen, um den Zeitpunkt von Upgrades zu steuern.
Neue Cluster registrieren
Sie können einen neuen Cluster mithilfe der gcloud CLI oder der Google Cloud Console in einer Release-Version erstellen und registrieren. Neue Cluster werden standardmäßig automatisch für die Release-Version Regular registriert.
Console
Für GKE Standard-Cluster können Sie bei der Erstellung in der Google Cloud Console eine andere Version angeben.
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie auf add_box Erstellen.
Klicken Sie unter Standard auf Konfigurieren.
Unter Version der Steuerungsebene ist standardmäßig die Option Release-Version ausgewählt.
Wählen Sie in der Drop-down-Liste Release-Version eine Release-Version aus, in der der Cluster registriert werden soll, oder behalten Sie den Standardwert Regular Channel bei.
Fahren Sie mit der Erstellung des Clusters wie gewünscht fort.
Klicken Sie auf Erstellen.
gcloud
Führen Sie den folgenden Befehl aus, um einen Standardcluster in einer bestimmten Release-Version zu erstellen und zu registrieren:
gcloud container clusters create CLUSTER_NAME \
--zone COMPUTE_ZONE \
--release-channel CHANNEL \
ADDITIONAL_FLAGS
Führen Sie den folgenden Befehl aus, um einen Autopilot-Cluster in einer bestimmten Release-Version zu erstellen und zu registrieren:
gcloud container clusters create-auto CLUSTER_NAME \
--region=COMPUTE_REGION
--release-channel CHANNEL \
ADDITIONAL_FLAGS
Dabei gilt:
CLUSTER_NAME: Der Name des neuen Clusters.- Verwenden Sie für regionale Cluster das Flag
--region COMPUTE_REGIONund geben Sie die Region für Ihren Cluster an. - Verwenden Sie bei zonalen Clustern das Flag
--region COMPUTE_ZONEund geben Sie die Zone für Ihren Cluster an. CHANNEL: Typ der Release-Version:rapid,regularoderstable.ADDITIONAL_FLAGS: Alle anderen Flags, die Sie beim Erstellen des Clusters angeben müssen. Eine vollständige Liste der optionalen Flags für Standardcluster finden Sie in der Dokumentation zugcloud container clusters create. Eine vollständige Liste der optionalen Flags für Autopilot-Cluster finden Sie in der Dokumentation zugcloud container clusters create-auto.
Mit dem Flag --cluster-version können Sie auch einen Cluster mit einer bestimmten Version erstellen. Wenn Sie keine Release-Version angeben, registriert GKE Ihren Cluster in der ausgereiften Release-Version, in der diese Version verfügbar ist.
Wenn Sie keine Release- oder Clusterversion angeben, verwendet der Cluster standardmäßig die Release-Version regular für die Standardversion.
Vorhandene Cluster registrieren
Sie können einen vorhandenen Cluster in einer Release-Version registrieren, vorausgesetzt, die Version der Steuerungsebene des Clusters ist in der Ziel-Release-Version verfügbar. Um zu prüfen, ob die Version der Steuerungsebene Ihres Clusters in der Ziel-Release-Version verfügbar ist, rufen Sie die Standardversion und die verfügbaren Versionen für Release-Versionen auf. Weitere Informationen zum Ausrichten der Version der Steuerungsebene Ihres Clusters mit den verfügbaren Versionen für Ihre Ziel-Release-Version finden Sie unter Neue Release-Version auswählen.
Für die Registrierung aktualisieren Sie die Release-Version des Clusters auf den Ziel-CHANNEL.
Release-Version des Clusters finden
Sie können die Release-Version Ihres Clusters mithilfe der gcloud CLI oder der Google Cloud Console ermitteln.
Console
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie auf den Namen des Clusters, den Sie prüfen möchten.
Prüfen Sie unter Clustergrundlagen den Wert im Feld Release-Version, z. B. Regular Channel.
gcloud
gcloud container clusters describe CLUSTER_NAME \
--zone COMPUTE_ZONE --format="value(releaseChannel.channel)"
Dabei gilt:
CLUSTER_NAMEist der Name Ihres Clusters.COMPUTE_ZONEist die Computing-Zone für Ihren Cluster.
Release-Version des Clusters ändern
Sie können die Release-Version Ihres Clusters ändern, wenn die Version der Steuerungsebene in der Ziel-Release-Version verfügbar ist. Möglicherweise müssen Sie die Steuerungsebene Ihres Clusters auf eine verfügbare Version up- oder downgraden.
Um zu prüfen, ob die Version der Steuerungsebene Ihres Clusters in der Ziel-Release-Version verfügbar ist, rufen Sie die Standardversion und die verfügbaren Versionen für Release-Versionen auf. Die Version muss im Zielkanal verfügbar sein.
- Wenn die Version der Steuerungsebene Ihres Clusters bereits in der Ziel-Release-Version verfügbar ist, können Sie die neue Release-Version auswählen.
- Wenn die Version der Steuerungsebene des Clusters in der Ziel-Release-Version nicht verfügbar ist, können Sie die Steuerungsebene des Clusters auf eine verfügbare Version aktualisieren. Wenn für den Zielkanal nur frühere Versionen verfügbar sind, können Sie ein Downgrade des Clusters ausführen, vorausgesetzt, die Zielversion ist ein früherer Patch-Release derselben Nebenversion.
Um eine neue Release-Version auszuwählen, aktualisieren Sie die Release-Version des Clusters auf den Ziel-CHANNEL. Wenn Sie vorübergehend verhindern möchten, dass der Cluster bei der Auswahl des neuen Kanals automatisch aktualisiert wird, konfigurieren Sie einen Wartungsausschluss, bevor der neue Kanal ausgewählt wird.
Wenn Sie die Ziel-Release-Version nicht auswählen können, da Ihr Cluster eine Version ausführt, die in dieser Release-Version nicht verfügbar ist, können Sie einen neuen Cluster im Zielkanal erstellen und Ihre Arbeitslasten migrieren. Wenn Sie Ihren vorhandenen Cluster verwenden müssen, können Sie alternativ Folgendes tun:
- Konfigurieren Sie einen Wartungsausschluss mit dem Bereich „Keine Nebenversionsupgrades“.
- Warten Sie, bis die Ziel-Release-Version die Kubernetes-Nebenversion des Clusters bereitstellt.
- Registrieren Sie den vorhandenen Cluster in der Ziel-Release-Version.
Release-Version des Clusters aktualisieren
Sie können die Release-Version Ihres Clusters mithilfe der gcloud CLI oder der Google Cloud Console ändern.
Console
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie auf den Namen des Clusters, den Sie prüfen möchten.
Klicken Sie unter Clustergrundlagen im Feld Release-Version auf edit.
Wählen Sie im Drop-down-Menü Release-Version die Ziel-Release-Version aus.
Lesen Sie die Warnung und bestätigen Sie sie. Wählen Sie dazu Ich bestätige die Bedingungen aus.
Klicken Sie auf Änderungen speichern.
gcloud
Ändern Sie das Release-Attribut eines vorhandenen Clusters:
gcloud container clusters update CLUSTER_NAME \ --release-channel CHANNEL
Ersetzen Sie Folgendes:
CLUSTER_NAMEist der Name Ihres Clusters.CHANNEList die Ziel-Release-Version, entwederrapid,regular,stableoderNone.
Wann Sie Ihren Cluster nicht in einer Release-Version registrieren sollten
Sie können einen Standardcluster nicht in einer Release-Version registrieren (auch als „kein Kanal“ und „statisch“ bezeichnet). Aufgrund der Einschränkungen von Clustern, die nicht für Release-Versionen registriert sind, verwenden Sie diese Option nur, wenn einige Knotenpools nicht automatisch aktualisiert werden können. Sie müssen diese Knoten stattdessen manuell aktualisieren. Wenn Ihr Cluster nicht für eine Release-Version registriert ist, können Sie automatische Knotenupgrades für ausgewählte Knotenpools deaktivieren.
Wenn Sie automatische Upgrades vorübergehend für den gesamten Cluster oder alle Knoten verhindern möchten, verwenden Sie einen Wartungsausschluss mit Ihrem Cluster, der für eine Release-Version registriert ist. Mit Wartungsausschlüssen können Sie automatische Knotenupgrades für alle Knotenpools vorübergehend deaktivieren. Sie können automatische Knotenupgrades jedoch für alle Knotenpools deaktivieren, wenn Ihr Cluster nicht für eine Releaseversion registriert ist.
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 |
| Autopilot | Verfügbar | Nicht verfügbar |
Release-Version nicht mehr erhalten
Sie können Ihren Standard-Cluster über die Google Cloud Console, die gcloud CLI oder die Kubernetes Engine API von einer Release-Version abmelden. Sie können auch angeben, dass Sie Ihren Cluster während der Clustererstellung nicht in einer Release-Version registrieren möchten.
Console
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie auf den Namen des Clusters, den Sie prüfen möchten.
Klicken Sie unter Clustergrundlagen im Feld Release-Version auf edit.
Wählen Sie das Optionsfeld Statische Version aus.
Lesen Sie die Warnung und bestätigen Sie sie. Wählen Sie dazu Ich bestätige die Bedingungen aus.
Klicken Sie auf Änderungen speichern.
gcloud
Aktualisieren Sie die Release-Version des Clusters auf den Wert None:
gcloud container clusters update CLUSTER_NAME \ --release-channel None
API
Geben Sie "releaseChannel": { "channel": UNSPECIFIED} an, wenn Sie einen Cluster erstellen oder aktualisieren.
Vorsichtsmaßnahmen
Beachten Sie bei der Verwendung von Releasekanälen die folgenden Hinweise.
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
- Upgrade für Cluster durchführen
- Cluster-Upgrade-Benachrichtigungen erhalten
- Informationen zum Verwalten automatischer Cluster-Upgrades in verschiedenen Umgebungen finden Sie unter Roll-out-Sequenzierung.