About release channels


Use release channels for Google Kubernetes Engine (GKE) to pick versions for your clusters with your chosen balance between feature availability and stability.

GKE automatically upgrades all clusters over time, including those not enrolled in a release channel, to ensure that they receive security updates, fixes to known issues, new features, and run a supported Kubernetes version. You can control the timing of upgrades with maintenance windows and exclusions.

We recommend enrolling your cluster in a release channel, as this gives you the most control with regards to the scope of maintenance exclusions—temporarily preventing specific types of upgrades instead of all upgrades—and sequencing the rollout of cluster upgrades. Autopilot clusters can only be enrolled in a release channel.

If you don't enroll your Standard cluster in a release channel, you can disable node auto-upgrades for selected node pools and manually manage upgrades to the nodes in these node pools. However, all clusters' control planes are automatically upgraded, and when a version reaches end-of-life, cluster control planes and nodes are automatically upgraded regardless of release channel enrollment. To learn more, see when not to enroll your cluster in a release channel.

What channels are available

The following table explains the properties of available release channels, each offering a trade-off between feature availability and update churn. All channels offer supported releases of GKE and are considered generally available (GA), although individual features might not always be GA, as marked. The Kubernetes releases in these channels are official Kubernetes releases and include both GA and beta Kubernetes APIs.

Channel New Kubernetes release availability When to use this channel
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. GKE upgrades your cluster frequently to stay on the latest available patch version, and deliver newer Kubernetes capabilities. Clusters subscribed to the Rapid channel use GA versions, however we recommend to use the Rapid channel to test newer Kubernetes versions and API on pre-production environments.
Regular (default) 2-3 months after releasing in Rapid Access GKE and Kubernetes features reasonably soon after they go GA, 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 features. GKE rolls out changes and new versions in this channel 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 on or after the date specified in the Upgrade column of the GKE release schedule.

When a version has accumulated usage and demonstrated stability across clusters in the Rapid channel, it is promoted to the Regular channel. Eventually, the 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.

What versions are available in a channel

Each release channel offers a default version, selected from a set of available versions for that channel. These versions have met the qualification standards for that specific channel. Over time, GKE automatically upgrades clusters to the default version.

  • New patch releases become available at least one week prior to becoming default for all channels.
  • New minor releases become available:
    • at least two weeks prior to becoming default for the Rapid channel.
    • at least four weeks prior to becoming default for the Regular and Stable channels.

You can test a newly available GKE version prior to upgrading your production environment. For example, you can subscribe to upgrade notifications to be informed of newly available versions, and then proactively upgrade a pre-production environment to the new version before it becomes the default version.

If you need to keep a cluster on a specific version, for example to validate or test newer versions prior to upgrading, we recommend using maintenance exclusions.

For versions 1.19 and later, after a minor version has been made available in a release channel, it will remain available in that release channel for new or existing clusters until it reaches its end of life date.

View the default and available versions for release channels

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

To view the available versions for clusters not enrolled in a release channel, run this equivalent command for release channels, replacing "yaml(channels)" in the command with "yaml(validMasterVersions)".

What happens when a new version becomes default in a release channel

When a new GKE version becomes default in a release channel:

  • New clusters are created using the new default version in the selected release channel.
  • Existing eligible clusters are automatically upgraded within 10 days after a new version becomes default in its release channel.

If 10 days have passed after a new version became default in the release channel and automatic upgrades have not started for your cluster, the delay might be due to one of the following reasons:

  • Your cluster is temporarily ineligible for automatic upgrades. This might occur because:
    • The cluster is outside the timeframe of a configured maintenance window.
    • The cluster is within the timeframe of a maintenance exclusion.
    • Automatic upgrades are paused because your cluster uses deprecated Kubernetes features that are removed in the next minor version.
    • The cluster was automatically upgraded to a patch version less than 24 hours ago.
    • The cluster was automatically upgraded to a minor version less than 30 days ago and the new default version is a new minor version.
  • GKE paused the roll out of the new default version for technical or business reasons:
    • Technical issues were discovered with the new version.
    • A production freeze is in place due to a critical business season, such as Black Friday.

Run patch versions from a newer channel

In addition to the listed available versions for a release channel, GKE provides limited access to the patch versions of less mature release channels. A cluster enrolled in a release channel may use patch versions from a newer channel if the minor version in the newer channel is the same as the minor version available in the cluster's own release channel.

For example, if the following versions were available in the Rapid and Regular channels:

  • Rapid: 1.23.2-gke.700, 1.22.4-gke.1500
  • Regular: 1.21.4-gke.400, 1.22.1-gke.400

A cluster enrolled in the Regular channel that is running GKE version 1.22.1-gke.400 could upgrade to 1.22.4-gke.1500, but not to 1.23.2-gke.700 as it is a different minor version.

To upgrade to a patch version on a newer channel, your cluster's control plane must run a patch release with the same minor version. For example, if the cluster is running 1.21.3-gke.200, you must first upgrade the cluster to a patch version available in its current release channel, 1.22.1-gke.400. You can then upgrade the cluster to 1.22.4-gke.1500.

You can also create a new cluster that runs 1.22.4-gke.1500 and is enrolled in the Regular channel.

The cluster will remain on the patch version from the less mature channel until the default version of the channel that the cluster is enrolled in becomes greater than the cluster version. At that time, the cluster will be auto-upgraded to the default version.

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

Choose the best release channel for your cluster

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

As this diagram shows, the available release channels use versions in the middle of the adoption cycle, including Early adopters (Rapid channel), Early majority (Regular channel), and Majority (Stable channel). The earliest part of the adoption cycle is the Innovators, who test the newest features using the upstream Kubernetes release. The last part of the adoption cycle is the Late majority, where you are using a version that is nearing deprecation and need to transition to a supported version.

In your pre-production environments, use the Rapid channel for newer versions where you can test features as soon as they are generally available.

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 standards. 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 version and to protect you from vulnerabilities and unsupported version skew.

Enroll a cluster in a release channel

This section shows you how to select a release channel for new clusters, or for existing clusters that didn't previously use a release channel. You can also change the release channel for an existing cluster that is already enrolled in a release channel.

This change does not require any downtime. However, as GKE might have different automatic upgrades available in the release channel, we recommend using maintenance windows and exclusions to control the timing of upgrades.

Enroll new clusters

You can create and enroll a new cluster in a release channel using gcloud CLI or the Google Cloud console. By default, new clusters are automatically enrolled in the Regular release channel.

Console

For GKE Standard clusters, you can choose to specify a different channel during creation in the Google Cloud console.

  1. Go to the Google Kubernetes Engine page in the Google Cloud console.

    Go to Google Kubernetes Engine

  2. Click Create.

  3. In the Standard section, click Configure.

  4. Under Control plane version, the Release channel option is selected by default.

  5. In the Release channel drop-down list, select a release channel to enroll the cluster in, or leave the default value of Regular channel.

  6. Continue creating the cluster as desired.

  7. Click Create.

gcloud

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

gcloud container clusters create CLUSTER_NAME \
    --zone COMPUTE_ZONE \
    --release-channel CHANNEL \
    ADDITIONAL_FLAGS

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

gcloud container clusters create-auto CLUSTER_NAME \
    --region=COMPUTE_REGION
    --release-channel CHANNEL \
    ADDITIONAL_FLAGS

Replace the following:

  • CLUSTER_NAME: the name of your new cluster.
  • For regional clusters, use the --region COMPUTE_REGION flag and specify the region for your cluster.
  • For zonal clusters, use the --region COMPUTE_ZONE flag and specify the 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 for Standard clusters, refer to the gcloud container clusters create documentation. For the full list of optional flags for Autopilot clusters, refer to the gcloud container clusters create-auto documentation.

You can also create a cluster with a specific version using the --cluster-version flag. If you don't specify a release channel, GKE enrolls your cluster in the most mature release channel where that version is available.

Or, if you don't specify the release channel or cluster version, the cluster defaults to the regular release channel on the default version.

Enroll existing clusters

You can enroll an existing cluster in a release channel, provided that the cluster's control plane version is available in the target release channel. To check if your cluster's control plane version is available in the target release channel, view the default and available versions for release channels. To learn more about aligning your cluster's control plane version with the available versions for your target release channel, see Select a new release channel.

To enroll, update the cluster release channel to the target CHANNEL.

Find your cluster's release channel

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

Console

  1. Go to the Google Kubernetes Engine page in the Google Cloud console.

    Go to Google Kubernetes Engine

  2. Click the name of the cluster you want to inspect.

  3. Under Cluster basics, check 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.

Change your cluster's release channel

You can change the release channel of your cluster if the control plane's version is available in the target release channel. You might need to upgrade or downgrade your cluster's control plane to an available version.

To check if your cluster's control plane version is available in the target release channel, view the default and available versions for release channels. The version must be available in the target channel.

  • If your cluster's control plane version is already available in the target release channel, you can select the new release channel.
  • If your cluster's control plane version is not available in the target release channel, you can upgrade the cluster's control plane to an available version. Alternatively, if the target channel only has earlier versions available, you can downgrade the cluster, provided that the target version is an earlier patch release from the same minor version.

To select a new release channel, update the cluster release channel to the target CHANNEL. If you want to temporarily prevent the cluster from being automatically upgraded when you select the new channel, configure a maintenance exclusion before selecting the new channel.

If you can't select the target release channel because your cluster is running a version that is not available in that release channel, you can create a new cluster in the target channel and migrate your workloads. Alternatively, if you need to use your existing cluster, do the following:

  1. Configure a maintenance exclusion with a scope of "No minor upgrades".
  2. Wait for the target release channel to make available the Kubernetes minor version of your cluster.
  3. Enroll the existing cluster in the target release channel.

Update the cluster release channel

You can change your cluster's release channel using the gcloud CLI or the Google Cloud console.

Console

  1. Go to the Google Kubernetes Engine page in the Google Cloud console.

    Go to Google Kubernetes Engine

  2. Click the name of the cluster you want to inspect.

  3. Under Cluster basics, in the Release channel field, click .

  4. In the Release channel dropdown, select the target release channel.

  5. Read and acknowledge the warning by selecting I acknowledge the conditions.

  6. Click Save Changes.

gcloud

Change the release channel property of an existing cluster:

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

Replace the following:

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

When to not enroll your cluster in a release channel

You can choose not to enroll a Standard cluster in a release channel (known as "no channel" and "static"). Due to the limitations with clusters not enrolled in release channels, use this option only if some node pools can't be automatically upgraded, and you must manually upgrade those nodes instead. If your cluster is not enrolled in a release channel, you can disable node auto-upgrade for selected node pools.

If you want to temporarily prevent automatic upgrades for the entire cluster or all of its nodes, use a maintenance exclusion with your cluster enrolled in a release channel. With maintenance exclusions, you can temporarily disable node auto-upgrades for all node pools, whereas you can disable node auto-upgrades at the node pool level if your cluster is not enrolled in a release channel.

Review the following table to understand the similarities and differences between enrolling and not enrolling your cluster in a release channel:

Feature Cluster enrolled in a release channel Cluster not enrolled in a release channel
Shared upgrade behavior
Upgrade timing Aligned with the respective release channel
  • Same auto-upgrade start date as the Stable channel for both minor and patch versions
  • Same available minor versions as the Regular channel
  • Same available patch versions as the Rapid channel for those minor versions available in the Regular channel
Control of node pool disruption
Maintenance windows Available Available
Maintenance exclusions Available maintenance exclusion scopes:
  • "No upgrades" (30 days)
  • "No minor upgrades" (6 months)
  • "No minor or node upgrades" (6 months)
Restricted to "No upgrades" scope (30 days)
Rollout sequencing Available with fleet-based and scope-based sequences Not available
Autopilot Available Not available

Unsubscribe from a release channel

You can unsubscribe your Standard cluster from a release channel using the Google Cloud console, the gcloud CLI, or the Kubernetes Engine API. You can also specify that you don't want to enroll your cluster in a release channel during cluster creation.

Console

  1. Go to the Google Kubernetes Engine page in the Google Cloud console.

    Go to Google Kubernetes Engine

  2. Click the name of the cluster you want to inspect.

  3. Under Cluster basics, in the Release channel field, click .

  4. Select the Static version radio button.

  5. Read and acknowledge the warning by selecting I acknowledge the conditions.

  6. Click Save Changes.

gcloud

Update the cluster's release channel to a value of None:

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

API

Specify "releaseChannel": { "channel": UNSPECIFIED} when you create or update a cluster.

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 don't expire. Alpha clusters expire after 30 days.
  • Alpha Kubernetes APIs are not enabled on clusters that use release channels.

What's next