Release channels

This topic introduces release channels, which provide Google Kubernetes Engine (GKE) best practices for versioning and upgrading your GKE clusters.

Overview

Kubernetes releases updates often, to deliver security updates, fix known issues, and introduce new features. Release channels offer customers the ability to balance between stability and the feature set of the version deployed in the cluster.

When you enroll a new cluster in a release channel, Google automatically manages the version and upgrade cadence for the cluster and its node pools. All channels offer supported releases of GKE and are considered GA (although individual features may not always be GA, as marked). The Kubernetes releases in these channels are official Kubernetes releases and include both GA and beta Kubernetes APIs (as marked). New Kubernetes versions are first released to the Rapid channel, and over time will be promoted to the Regular, and Stable channel. This allows you to subscribe your cluster to a channel that meets your business, stability, and functionality needs.

What channels are available?

The following release channels are available. Each channel offers a trade-off between feature availability and update churn. While each channel has a different qualification bar, all channels offer tested GA versions of Kubernetes.

Channel New Kubernetes release availability Properties
Rapid Several weeks after upstream open source GA Get the latest Kubernetes release as early as possible, and be able to use new GKE features the moment they go GA. Your cluster is frequently updated to stay on the latest available patch version, and deliver newer Kubernetes capabilities.
Regular (default) 2-3 months after releasing in Rapid Access GKE and Kubernetes features reasonably soon after they debut, but on a version that has been qualified over a longer period of time. Offers a balance of feature availability and release stability, and is what we recommend for most users.
Stable 2-3 months after releasing in Regular Prioritize stability over new functionality. Changes and new versions in this channel are rolled out last, after being validated on the Rapid, and Regular channels which allows even more time for validation.

When you enroll a cluster in a release channel, that cluster is upgraded automatically when a new version is available in that channel.

When a minor version has accumulated cumulative usage and demonstrated stability in the Rapid channel, it is promoted to the Regular channel. Eventually, the minor version is promoted to the Stable channel, which only receives high-priority updates. Each promotion signals a graduating level of stability and production-readiness, based on observed performance of clusters running that version.

Critical security patches are delivered to all release channels, to protect your clusters and Google's infrastructure.

Exact release schedules depend on multiple factors, including the open source release and patching schedule, and therefore are subject to change. To stay informed with the latest information, review the GKE release notes or subscribe to the RSS feed for your channel.

What versions are available in a channel?

Each release channel offers a default version, and a set of available versions for that channel, providing you with the ability to qualify your workloads operability with new available versions prior to upgrading your production environment. These versions have met the qualification bar for that specific channel.

  • New patch releases become available one week prior to becoming default.
  • New minor releases become available four weeks prior to becoming default.

GKE recommends testing available versions to mitigate upgrade-related disruption. Subscribing a pre-production environment to receive all versions made available in a channel is one such approach. In the event that more time is required for testing or validation, GKE recommends using exclusion windows to postpone auto-upgrade.

GKE automatically upgrades clusters to the default version gradually. If more control over the upgrade process is necessary, we recommend upgrading ahead of time to an available version. The GKE auto-upgrade process does not modify cluster resources when those resources have a version that is equal to or greater than the auto-upgrade target. Clusters or nodes can be manually upgraded in advance in order to skip the auto-upgrade process.

To view the default and available versions for release channels, run the following command, replacing compute-zone with your compute zone:

gcloud container get-server-config --format "yaml(channels)" --zone compute-zone

Learning what's new in a channel

To learn what's new in a release channel, review the release notes. There are separate release notes for each release channel, in addition to the overall release notes.

Release channel Release notes
Rapid channel HTML or Atom feed.
Regular channel HTML or Atom feed.
Stable channel HTML or Atom feed.

What channel should I use?

Channels include only GA versions of Kubernetes, and each channel represents a different level of quality and maturity of the Kubernetes and GKE releases. The following diagram illustrates the adoption cycle for release channels:

Release channels adoption cycle

We recommend using the Rapid channel for workloads relying on newer Kubernetes APIs and features, and for early access to test and validate new releases before the releases mature and are promoted to the Regular and Stable channels.

For production workloads that require maturity over newer functionality, we recommend using the Regular (default) channel or the Stable channel.

  • If you need to closely track new features, consider using the Regular channel, which offers a balance between stability and freshness of the Kubernetes OSS version.
  • If your requirement is maturity, especially for production clusters, use the Stable channel.

GKE upgrades clusters to a newer version that meets the channel's quality bar. However, we recommend upgrading your clusters ahead of time because this provides you with:

  • Better control of your upgrades, and alignment with your working hours.
  • Better predictability because GKE skips auto-upgrading clusters that meet the release target (i.e., clusters that were manually upgraded to the next target version). Nodes are automatically upgraded to the recommended version in their selected channel to align with the control plane (master) version and to protect you from vulnerabilities and unsupported version skew.

Enrolling a cluster in a release channel

You can enroll a new or existing cluster in a release channel.

Enrolling new clusters

You can create and enroll a new cluster in a release channel using gcloud or the Google Cloud Console.

Console

  1. Visit the Google Kubernetes Engine menu in Cloud Console.

    Visit the Google Kubernetes Engine menu

  2. Click the Create cluster button.

  3. Under Master version, select Release channel.

  4. In the Release channel drop-down list, select a release channel to enroll the cluster in.

  5. Continue creating the cluster as desired.

  6. Click Create.

gcloud

To create and enroll a cluster in a release channel, run the following command:

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

Replace the following:

  • cluster-name: the name of your new cluster.
  • compute-zone: the compute zone for your cluster.
  • channel: the type of release channel: one of rapid, regular, or stable.
  • additional-flags: any other flags you need to specify when creating your cluster. For the full list of optional flags, refer to the gcloud container clusters create documentation.

Enrolling existing clusters

You can enroll an existing cluster in a release channel, provided that the cluster control plane version is upgradeable to the release channel default. This means that the release channel default version must be the same or at most one minor version greater than the existing control plane version.

To enroll, update the cluster release channel to the desired channel.

Finding your cluster's channel

You can determine your cluster's release channel using gcloud or the Google Cloud Console.

Console

  1. Visit the Google Kubernetes Engine menu in Google Cloud Console.

    Visit the Google Kubernetes Engine menu

  2. Select the desired cluster.

  3. Under Cluster details, read the value in the Release Channel field (for example, "Regular Channel").

gcloud

gcloud container clusters describe cluster-name \
    --zone compute-zone --format="value(releaseChannel.channel)"

Replace the following:

  • cluster-name: the name of your cluster.
  • compute-zone: the compute zone for your cluster.

Selecting a new release channel

Migrating between release channels is supported in limited scenarios.

A transition that results in a single minor version upgrade, such as migrating from Stable to Regular, is supported.

Downgrades, such as migrating from Regular to Stable, are not possible due to the risk in downgrading across Kubernetes minor versions. Similarly, upgrades of more than a single minor version, such as migrating from Stable to Rapid, are not supported.

To select a new release channel, update the cluster release channel to the desired channel.

In cases where selecting a new release channel is not supported, we encourage you to create a new cluster in the desired channel and migrate your workloads.

Unsubscribing from a release channel

If you choose to unsubscribe from a channel, the node pools for the cluster will continue to have auto-upgrade and auto-repair enabled, even after disabling release channels.

To unsubscribe, update the cluster release channel with a channel of None.

Updating the cluster release channel

To edit the release channel property of an existing cluster, run the following command:

gcloud container clusters update cluster-name \
    --release-channel channel

Replace the following:

  • cluster-name: the name of your cluster.
  • channel: the desired release channel, which can be one of rapid, regular, stable, or None.

Caveats

Keep the following caveats in mind when using release channels.

Differences between Rapid-channel clusters and alpha clusters

Clusters created using the Rapid release channel are not alpha clusters. Here are the differences:

  • Clusters that use release channels can be upgraded, and auto-upgrade is enabled and cannot be disabled. Alpha clusters cannot be upgraded.
  • Clusters that use release channels do not expire. Alpha clusters expire after 30 days.
  • Alpha Kubernetes APIs are not enabled on clusters that use release channels.

Retrieve upgrade targets (sample script)

You can use the following sample script to retrieve the upgrade targets for your clusters. The script performs the following tasks:

  • Pulls the latest valid versions for each release channel using the get-server-config API.
  • Checks the current versions for the cluster's control plane and node pool. If the current version is older than the latest valid version, the script starts a custom upgrade orchestration (control plane, then node pools). If the cluster doesn't use release channels, the script checks against the latest valid stable version.

Sample script: retrieve cluster upgrade targets

#!/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

What's next