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 eine andere Qualifizierungsleiste 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 Nebenversion kumulative Nutzung angesammelt hat und im Rapid-Kanal stabil ist, wird sie zum regulären Kanal hochgestuft. Schließlich wird die Nebenversion 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 Version und Knoten 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. Wenn Sie keine Release-Version verwenden, sind Sie für die Verwaltung Ihrer Knotenupgrade-Strategie verantwortlich. Sie müssen auch die Supportrichtlinie für Kubernetes-Versionen und Versionsinkompatibilität einhalten und unterstützte GKE-Versionen verwenden.

Unabhängig davon, ob Ihr Cluster in einer Release-Version registriert ist, werden die Steuerungsebenen des Clusters immer regelmäßig aktualisiert.

Welche Versionen sind in einem Kanal verfügbar?

Jede Release-Version bietet eine Standardversion und eine Reihe von verfügbaren Versionen für diesen Kanal, sodass Sie die Möglichkeit haben, Ihre Arbeitslasten mit neuen verfügbaren Versionen vor dem Upgrade Ihrer Produktionsumgebung zu qualifizieren. Diese Versionen haben die Qualifikationskriterien für diesen Kanal erfüllt.

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

GKE empfiehlt, verfügbare Versionen zu testen, um Unterbrechungen beim Upgrade zu minimieren. Die Veröffentlichung einer Vorproduktionsumgebung ist für alle Versionen möglich, die in einem Kanal zur Verfügung gestellt werden. Wenn das Testen oder die Validierung mehr Zeit in Anspruch nimmt, empfiehlt GKE Ausschlussfenster, um automatische Upgrades zu verschieben.

GKE aktualisiert Cluster automatisch auf die Standardversion. Wenn Sie mehr Kontrolle über den Upgradeprozess haben möchten, empfehlen wir, ein Upgrade auf eine verfügbare Version durchzuführen. Durch den automatischen Upgradevorgang von GKE werden keine Clusterressourcen geändert, wenn diese Ressourcen eine Version haben, die mit dem Ziel für automatische Upgrades gleich oder größer ist. Cluster oder Knoten können manuell aktualisiert werden, um die automatische Aktualisierung zu überspringen.

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

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 der Qualitätsleiste 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 (Master) anzupassen und vor Sicherheitslücken und nicht unterstützter Versionsinkompatibilität 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 des gcloud-Tools 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 ist 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 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, Cluster-Release-Version aktualisieren, um die Option CHANNEL zu aktivieren.

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