Release-Versionen

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

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. Es bietet ein ausgewogenes Verhältnis zwischen Featureverfügbarkeit und Releasestabilität und wird den meisten Nutzern 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 Verwenden Sie diesen Channel, um langfristigen Support 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 Channel (nicht empfohlen) Abstimmung auf den Regular Channel Diese Option wird nicht empfohlen. Steuerungsebene und Knoten werden automatisch entsprechend den Regular- und Stable-Channels aktualisiert. Wenn Sie automatische Knotenupgrades auf Knotenpoolebene deaktivieren müssen, 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 für eine Release-Version registriert sind, und Clustern, die nicht für eine Release-Version 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 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. In seltenen Notfallsituationen führt GKE möglicherweise automatische Upgrades von Clustern auf Versionen durch, die in der Release-Version noch nicht verfügbar sind.

Welche Versionen sind in einem Kanal verfügbar?

Jeder Releasekanal bietet mehrere Nebenversionen. Diese Versionen haben die Qualifikationsstandards für diesen Kanal erfüllt. Diese Reihe verfügbarer Versionen enthält eine Standardversion für die Clustererstellung, die aus einer Reihe verfügbarer Versionen dieses Kanals 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 mindestens eine Woche verfügbar, bevor sie für alle Channels als Ziel für automatische Upgrades festgelegt werden.
  • Neue Nebenversionen sind verfügbar:
    • mindestens zwei Wochen, bevor sie zum Ziel für das automatische Upgrade für den Rapid Channel werden.
    • 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 des Supports erreicht.

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

GKE aktualisiert Cluster im Laufe der Zeit automatisch auf neue Ziele für automatische Upgrades. Wenn neue Ziele für automatische Upgrades verfügbar sind, prüft GKE, ob Ihr 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.

Sie können die Ziele für automatische Upgrades für Ihre Cluster auf folgende Weise ermitteln:

  • Informationen zu automatischen Upgradezielen 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 den spezifischen Einschränkungen ab.
  • In den GKE-Versionshinweisen werden neue Ziele für automatische Upgrades für Cluster aufgeführt, auf denen bestimmte Nebenversionen mit Versionsupdates ausgeführt werden, z. B. die Hinweis zu 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 nach und nach aktualisiert. Von allen Zielen für automatische Upgrades in einer Release-Version führt GKE Ihre Cluster bei automatischen Upgrades näher an diese Version heran.

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 weiterhin 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 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. 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 Patch-Upgrades

GKE führt eine neue Patchversion zuerst in einem Release-Channel ein, indem die Version für die Erstellung neuer Cluster und für 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-Channel und den spezifischen Umständen der Qualifizierung der Version ab.

So rufen Sie weitere 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. GKE hält sich weiterhin an Wartungsfenster und ‑ausschlüsse, folgt der Reihenfolge einer Rollout-Sequenz und wendet alle anderen Standardverfahren an, die normalerweise für automatische Upgrades verwendet werden.

Weitere Informationen zum Festlegen dieser Funktion finden Sie unter Beschleunigte automatische Patch-Upgrades 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 das automatische Upgrade 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, für die 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 und 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 im registrierten Kanal für den Cluster ein neueres Ziel für automatische Upgrades 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:

Adoptionszyklus 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 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 für den erweiterten Kanal erhalten

GKE bietet Langzeitunterstützung für Kubernetes-Nebenversionen über den Extended-Channel. Mit diesem Channel 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 etwa 10 weitere Monate lang Sicherheitspatches.

So führt GKE automatische Upgrades von Clustern im Extended Channel durch

Bei Clustern, die für den Extended Channel registriert sind, führt GKE automatische Upgrades von Clustern auf folgende Weise 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 Supports: GKE stellt weiterhin Updates für Sicherheitspatches 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, sofern der Cluster keine verworfenen Funktionen oder APIs verwendet. 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.

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

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

Die unterstützten Szenarien erfordern im Laufe der Zeit einige manuelle Maßnahmen, um den größtmöglichen Nutzen aus dem Channel zu ziehen. Wir empfehlen nicht, einen Cluster für den 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 Channels 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:

Upgradeszenario Unterstützt Zusammenfassung Zeit zwischen Änderungen der Nebenversion Manuelle Maßnahme erforderlich
Nebenversion vorübergehend länger verwenden Eine Nebenversion beibehalten, um ein Problem zu umgehen, das Upgrades verhindert Gleiche durchschnittliche Häufigkeit, mit Unterbrechung für zusätzliche Zeit bei einer Nebenversion.
  • Cluster vorübergehend in den erweiterten Kanal verschieben und daraus entfernen
  • Führen Sie ein manuelles Upgrade des Clusters auf die neue Nebenversion durch, wenn Sie bereit sind.
Nebenversion 1–2 Mal pro Jahr manuell aktualisieren 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 Nebenversions-Upgrades mit derselben Häufigkeit wie bei anderen Channels und neue Funktionen so spät wie möglich. Durchschnittlich alle vier Monate.
  • Automatische Nebenversionsupgrades von nicht unterstützten Versionen beobachten.

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, nicht. 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 Releaseversionen können Sie dasselbe Ergebnis auf Clusterebene für alle Knotenpools erzielen. Unabhängig von der Registrierung in einer Release-Version werden die Steuerungsebenen aller Cluster jedoch automatisch aktualisiert. Wenn eine Version das Ende des Supports 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 eine Releaseversion 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 für eine Release-Version registriert sind und nicht

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
Wartungsfenster Verfügbar Verfügbar
Wartungsausschlüsse Verfügbare Wartungsausschlussbereiche:
  • „Keine Upgrades“ (30 Tage)
  • „Keine Nebenversionsupgrades“ (bis zum Ende des Supports)
  • „Keine Nebenversions- oder Knotenupgrades“ (bis zum Ende des Supports)
 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