Releasekanäle

In diesem Abschnitt werden Releasekanäle vorgestellt, die Best Practices für die Versionsverwaltung und Aktualisierung Ihrer GKE-Cluster in Google Kubernetes Engine (GKE) bereitstellen.

Übersicht

Kubernetes veröffentlicht häufig Updates, um Sicherheitsupdates bereitzustellen, bekannte Probleme zu beheben und neue Features einzuführen. Release-Versionen bieten Kunden die Möglichkeit, ein Gleichgewicht zwischen Stabilität und Funktionen zu finden, der im Cluster bereitgestellt wird.

Wenn Sie einen neuen Cluster in einer Release-Version registrieren, verwaltet Google automatisch die Version und den Aktualisierungsrhythmus des Clusters und seiner Knotenpools. Alle Kanäle bieten unterstützte Versionen von GKE und sind allgemein verfügbar. 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. Neue Kubernetes-Versionen werden zuerst im Rapid Channel veröffentlicht und im Laufe der Zeit zum Regular Channel und Stable Channel hochgestuft. So können Sie Ihren Cluster für einen Kanal abonnieren, der Ihren geschäftlichen, stabilen und funktionalen Anforderungen entspricht.

Standardmäßig werden neue in GKE erstellte Cluster im Releasekanal Regular registriert.

Welche Kanäle sind verfügbar?

Die folgenden Releasekanäle sind verfügbar. Jeder Kanal bietet einen Kompromiss zwischen der Verfügbarkeit von Funktionen und der Aktualisierung von Abwanderungen. Obwohl jeder Kanal einen anderen Qualifizierungsstandard hat, bieten alle Kanäle getestete GA-Versionen von Kubernetes an.

Kanal Neue Kubernetes-Releaseverfügbarkeit Attribute
Rapid 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 regelmäßig aktualisiert, um die neueste verfügbare Patchversion zu behalten und neue Kubernetes-Funktionen bereitzustellen. Obwohl Cluster, die den Rapid Channel abonniert haben, GA-Versionen verwenden, ist der Rapid Channel am besten geeignet, um neuere Kubernetes-Versionen und API in Vorproduktionsumgebungen zu testen. Da der Rapid Channel die neuesten GKE-Versionen bereitstellt, sind diese Versionen von der GKE-SLA ausgenommen und können Probleme ohne bekannte Abhilfemaßnahmen enthalten.
Regular (Standard) Zwei bis drei Monate nach Veröffentlichung in Rapid * Der Zugriff auf GKE- und Kubernetes-Features erfolgt bald nach ihrer Einführung, 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.
Stabile Version Zwei bis drei Monate nach Veröffentlichung in Regular * Stabilität hat Vorrang vor neuen Features. Änderungen und neue Versionen in diesem Kanal werden zuletzt eingeführt, nachdem sie auf den Kanälen „Rapid“ und „Regular“ validiert wurden. Dadurch bleibt noch mehr Zeit für die Validierung.

*Die genauen Releasepläne hängen von mehreren Faktoren ab, z. B. vom Open-Source-Release- und Patching-Zeitplan und können sich daher ändern. Damit Sie hinsichtlich der neuesten Informationen auf dem Laufenden bleiben, lesen Sie die GKE-Versionshinweise oder abonnieren Sie den RSS-Feed für Ihren Kanal.

Wenn Sie einen Cluster in einem Releasekanal registrieren, wird dieser Cluster automatisch aktualisiert, wenn eine neue Version verfügbar ist.

Wenn eine Version kumulative Nutzung angesammelt hat und im Rapid Channel 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.

Kein Kanal

Für eine direktere Verwaltung der Steuerungsebene und Knotenversionen Ihres Clusters können Sie sich dafür entscheiden, dass der Cluster nicht in einer Release-Version (d. h. keinem Kanal) registriert wird. Dazu geben Sie eine statische GKE-Version an. Es wird jedoch empfohlen, Ihren Cluster in einer Release-Version zu registrieren, da diese automatisch Sicherheit, Leistung und Stabilität gewährleistet. Mit Release-Versionen können Sie auch den Zeitpunkt und den Umfang von Upgrades über Wartungsfenster und -ausschlüsse steuern.

Aktualisierungen der Steuerungsebene

Auch wenn der Cluster nicht in einer Release-Version registriert ist, aktualisiert GKE die Steuerungsebene des Clusters regelmäßig auf neuere Versionen. GKE aktualisiert die Steuerungsebenen an ihrem geplanten Startdatum für Upgrades auf die nächste Nebenversion. Sehen Sie die Versionshinweise für die neuesten Information über geplante Upgrades

Knotenupgrades

Wenn Sie einen Cluster mit einer statischen Version ("kein Kanal") ausführen, können Sie entweder das automatische Knotenupgrade aktiviert lassen oder automatische Knotenupgrades deaktivieren und Ihre Knotenupgrade-Strategie verwalten. Wir empfehlen, die automatische Knotenaktualisierung aktiviert zu lassen, damit die Knotenversionen nach den Upgrades der Steuerungsebene automatisch aktualisiert werden.

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 Version 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

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. Ein neuer Cluster kann auch mit 1.22.4-gke.1500 erstellt und im Regular Channel registriert werden.

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

Welchen Kanal sollte ich verwenden?

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

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

Sie können einen neuen oder vorhandenen Cluster in einer Release-Version registrieren.

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.

  1. Rufen Sie in der Cloud Console die Seite Google Kubernetes Engine auf:

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie auf Erstellen.

  3. Klicken Sie unter Standard auf Konfigurieren.

  4. Unter Version der Steuerungsebene ist standardmäßig die Option Release-Version ausgewählt.

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

  6. Fahren Sie mit der Erstellung des Clusters wie gewünscht fort.

  7. 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_REGION und geben Sie die Region für Ihren Cluster an.
  • Verwenden Sie bei zonalen Clustern das Flag --region COMPUTE_ZONE und geben Sie die Zone für Ihren Cluster an.
  • CHANNEL: Typ der Release-Version: rapid, regular oder stable.
  • 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 zu gcloud container clusters create. Eine vollständige Liste der optionalen Flags für Autopilot-Cluster finden Sie in der Dokumentation zu gcloud container clusters create-auto.

Vorhandene Cluster registrieren

Sie können einen vorhandenen Cluster in einem Releasekanal registrieren, sofern die Version der Cluster-Steuerungsebene auf die Releasekanal-Standardversion aktualisiert werden kann. Dies bedeutet, dass die Standardversion des Releasekanals die gleiche oder zumindest eine Nebenversion größer als die vorhandene Version der Steuerungsebene sein muss.

Für die Registrierung aktualisieren Sie die Clusterversion auf das gewünschte CHANNEL.

Releasekanal des Clusters finden

Sie können den Releasekanal Ihres Clusters mithilfe von gcloud oder der Google Cloud Console ermitteln.

Console

  1. Rufen Sie in der Cloud Console die Seite Google Kubernetes Engine auf:

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie auf den Namen des Clusters, den Sie prüfen möchten.

  3. 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_NAME: Der Name Ihres Clusters.
  • COMPUTE_ZONE ist die Computing-Zone für Ihren Cluster.

Neuen Release-Kanal auswählen

Die Migration zwischen Releasekanälen wird in bestimmten Fällen unterstützt.

Ein Übergang, der zu einer einzigen Nebenversion führt, wie die Migration von stable auf Regular, wird unterstützt.

Downgrades, beispielsweise bei der Migration von Regular zu Stable, sind wegen des Risikos des Downgrades der Kubernetes-Nebenversionen nicht möglich. Ebenso werden Upgrades für mehrere Nebenversionen, wie etwa die Migration von Stable zu Rapid, nicht unterstützt.

Um eine neue Release-Version auszuwählen, aktualisieren Sie die Cluster-Release-Version aktualisieren auf den gewünschten CHANNEL.

Wenn die Auswahl einer neuen Release-Version nicht unterstützt wird, empfehlen wir, einen neuen Cluster im gewünschten Kanal zu erstellen und Ihre Arbeitslasten zu migrieren. Wenn Sie Ihren vorhandenen Cluster nutzen möchten, gehen Sie wie unter Releasekanäle nicht mehr erhalten beschrieben vor und warten Sie, bis die Ziel-Release-Version die Kubernetes-Nebenversion Ihres Clusters bereitstellt. Halten Sie sich anschließend an die Anleitung, um den vorhandenen Cluster in der Release-Version des Ziels zu registrieren.

Releasekanäle nicht mehr erhalten

Wenn Sie sich von einem Kanal abmelden, werden die Knotenpools für den Cluster auch nach der Deaktivierung der Release-Versionen weiter aktualisiert und automatisch repariert. Sobald ein Cluster nicht mehr Teil einer Release-Version ist, können Sie automatische Knotenupgrades deaktivieren und automatische Knotenreparaturen manuell deaktivieren.

Wenn ein Cluster von einem Release-Kanal entfernt wird, unterliegen manuelle Upgrades weiterhin den folgenden Einschränkungen:

Wenn Sie das Release eines Release-Kanals beenden möchten, aktualisieren Sie den Release-Kanal des Clusters auf den Wert None:

gcloud container clusters update CLUSTER_NAME \
    --release-channel None

Cluster-Release-Version aktualisieren

Führen Sie den folgenden Befehl aus, um das Release-Attribut eines vorhandenen Clusters zu bearbeiten:

gcloud container clusters update CLUSTER_NAME \
    --release-channel CHANNEL

Dabei gilt:

  • CLUSTER_NAME: Der Name Ihres Clusters.
  • CHANNEL: die gewünschte Release-Version entweder rapid, regular, stable oder None.

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