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.

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.
Regular (Standard) Zwei bis drei Monate nach Veröffentlichung in Rapid Der Zugriff auf GKE- und Kubernetes-Features erfolgt bald nach dem Ende, 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" veröffentlicht wurden. Dadurch bleibt noch mehr Zeit für die Validierung

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.

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. Um hinsichtlich der neuesten Informationen auf dem Laufenden zu bleiben, lesen Sie die GKE-Versionshinweise oder abonnieren Sie den RSS-Feed für Ihren Kanal.

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 eine Woche vor der Standardeinstellung verfügbar.
  • Neue Nebenversionen sind vier Wochen vor der Standardeinstellung verfügbar.

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 Release-Versionen anzuzeigen. 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

Es wird empfohlen, den Rapid-Kanal für Arbeitslasten zu verwenden, die auf neueren Kubernetes-APIs und -Funktionen beruhen. Außerdem empfehlen wir den Vorabzugriff, neue Versionen vor der Veröffentlichung zu testen und zu einem Teil der stabilen Version zu machen.

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 von gcloud oder der Google Cloud Console in einer Release-Version erstellen und registrieren.

Console

  1. Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

    Google Kubernetes Engine-Menü aufrufen

  2. Klicken Sie auf Cluster erstellen.

  3. Wählen Sie unter Masterversion die Option Releasekanal aus.

  4. Wählen Sie in der Drop-down-Liste Releasekanal einen Releasekanal aus, in dem der Cluster registriert werden soll.

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

  6. Klicken Sie auf Erstellen.

gcloud

Führen Sie den folgenden Befehl aus, um einen Cluster in einem Releasekanal zu erstellen und zu registrieren:

gcloud container clusters create cluster-name \
    --zone compute-zone \
    --release-channel channel \
    additional-flags

Dabei gilt:

  • cluster-name: Der Name des neuen Clusters.
  • compute-zone: die Computing-Zone für Ihren Cluster.
  • 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 finden Sie in der Dokumentation zu gcloud container clusters create.

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 Google Cloud Console das Menü von Google Kubernetes Engine auf.

    Zum Google Kubernetes Engine-Menü

  2. Wählen Sie den gewünschten Cluster aus.

  3. Lesen Sie unter "Clusterdetails" den Wert im Feld Releasekanal (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: 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.

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.

Wenn Sie sich abmelden möchten, Cluster-Release-Version aktualisieren mit einem channel von Kein Zeitplan, um die Option zu aktivieren.

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

Upgrade-Ziele abrufen (Beispielskript)

Mit dem folgenden Beispielskript können Sie die Upgrade-Ziele für Ihre Cluster abrufen. Das Skript führt die folgenden Aufgaben aus:

  • Rufen Sie mithilfe der get-server-config API die neuesten gültigen Versionen für jeden Releasekanal ab.
  • Prüft die aktuellen Versionen der Steuerungsebene und des Knotenpools. Wenn die aktuelle Version älter als die neueste gültige Version ist, startet das Skript eine benutzerdefinierte Upgrade-Orchestrierung (Steuerungsebene, dann Knotenpools). Wenn der Cluster keine Releasekanäle verwendet, prüft das Skript die neueste gültige stabile Version.

Beispielskript: Cluster-Upgrade-Ziele abrufen

#!/bin/bash

# semver_lt checks whether the first semver is less than the second semver.
# It returns 1 if it is less than, and 0 otherwise.
semver_lt() {
    # Get the smaller version by sorting them in ascending semver
    # and grabbing the first line.
    smaller=$(printf "$1\n$2" | sort -V | head -n1)
    if [[ ${1} == "${smaller}" && ${1} != ${2} ]]; then
            return 1
    fi
    return 0
}

# get_latest_valid gets the latest valid version for a release channel.
get_latest_valid() {
        channel=$1
        echo $(gcloud container get-server-config \
        --format="table(channels:format='table(channel,validVersions)')" |\
        grep ${channel} | cut -d"'" -f 2)
}

upgrade_master() {
    echo "Cluster $1 needs to upgrade to $2."
    # Actuate master upgrade.
}

upgrade_np() {
    echo "Node pool $1/$2 needs to upgrade to $3."
    # Actuate node pool upgrade.
}

# Get the latest valid channel versions from server-config.
stable_target=$(get_latest_valid "STABLE")
regular_target=$(get_latest_valid "REGULAR")
rapid_target=$(get_latest_valid "RAPID")
echo "stable version from gcloud: ${stable_target}"
echo "regular version from gcloud: ${regular_target}"
echo "rapid version from gcloud: ${rapid_target}"

# List the clusters by name, master version, zone, and release channel.
clusters=$(gcloud container clusters list \
  --format="table[no-heading](name,master_version(),zone,release_channel.channel)")

IFS=$'\n'
for cluster in ${clusters}
do
    echo ""
    cname=$(printf "${cluster}" | awk '{print $1}')
    master_version=$(printf "${cluster}" | awk '{print $2}')
    zone=$(printf "${cluster}" | awk '{print $3}')
    channel=$(printf "${cluster}" | awk '{print $4}')

    # Determine the target version (default to latest valid stable version).
    target=${stable_target}
    case ${channel} in
        "RAPID")
            target=${rapid_target}
            ;;
        "REGULAR")
            target=${regular_target}
            ;;
        "STABLE")
            target=${stable_target}
            ;;
        esac

    # Check if the master needs to upgrade to the target version.
    semver_lt "${master_version}" "${target}"
    need_upgrade=$?
    if [[ ${need_upgrade} -eq 1 ]]; then
        upgrade_master ${cname} ${target}
    else
        echo "Cluster ${cname} does not need to upgrade."
    fi

    # Then check if the cluster's node pools need to upgrade too.
    nps=$(gcloud container node-pools list --cluster ${cname} --zone ${zone} \
            --format="table[no-heading](name,version)")
    for np in ${nps}
    do
        np_name=$(printf "${np}" | awk '{print $1}')
        np_version=$(printf "${np}" | awk '{print $2}')

        semver_lt "${np_version}" "${target}"
        need_upgrade=$?
        if [[ ${need_upgrade} -eq 1 ]]; then
            upgrade_np ${cname} ${np_name} ${target}
        else
            echo "Node pool ${np_name} does not need to upgrade."
        fi
    done
done

Nächste Schritte