About release channels

Autopilot Standard

---

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 generally available (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.

All Autopilot clusters are automatically enrolled in a release channel. By default, new clusters are enrolled in the Regular release channel.

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 standards, 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. Although clusters subscribed to the Rapid channel use GA versions, the Rapid channel is best used to test newer Kubernetes versions and API on pre-production environments. As Rapid channel provides the newest GKE versions, these versions are excluded from the GKE SLA and may contain issues without known workarounds.
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.

^*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.

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.

No channel

Note: No channel does not apply to clusters created in the Autopilot mode.

For more direct management of your cluster's control plane and node versions, you can choose to not enroll the cluster in a release channel (that is, "no channel") by specifying a static GKE version. However, we recommend that you enroll your cluster in a release channel as it automatically ensures security, performance, and stability. With release channels, you can also control the timing and scope of upgrades through maintenance windows and exclusions.

Control plane upgrades

Even if the cluster is not enrolled in a release channel, GKE will still regularly upgrade the cluster's control plane to newer versions. GKE will upgrade control planes to the next minor version on its scheduled upgrades start date. See the release notes for the latest information about scheduled upgrades.

Node upgrades

When running a cluster with a static version ("no channel"), you can either keep node auto-upgrade enabled or disable node auto-upgrade and manage your node upgrade strategy. We recommend leaving node auto-upgrade enabled so that node versions are automatically upgraded following the control plane upgrades.

Caution: If you disable node auto-upgrade, you must periodically manually update your cluster's node pool(s) to ensure that your cluster adheres to the Kubernetes version and version skew support policy, and is using supported GKE versions. Failure to adhere to these version policies will cause incompatibility between the control plane and nodes over time, and potentially degrade the supportability and reliability of your cluster. Learn more in the Version support FAQ.

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

Note: If you create a cluster in a release channel older than the default version, it may be automatically upgraded to the default version. To ensure that a cluster remains on an older version, use maintenance exclusions.

Viewing the default and available versions for release channels

Note: Versions older than the default version for a channel are only visible through the gcloud CLI and the Kubernetes Engine API.

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

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.

Running 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. A new cluster could also be created running 1.22.4-gke.1500 and enrolled in the Regular channel.

Note: Creating or upgrading a cluster on a patch version from a newer release channel is only supported from gcloud CLI or the API.

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.

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:

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.

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

   Note: Node auto-upgrade and node auto-repair are enabled by default. Node auto-upgrade cannot be disabled for a cluster subscribed to a release channel. Node auto-repair can be disabled, however we recommend keeping the default configuration.

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.

Note: If you don't specify the --release-channel flag, the cluster defaults to the regular release channel.

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.

Note: GKE does not immediately upgrade the cluster control plane and nodes to the release channel default version when enrolling. Instead, they are gradually upgraded by the GKE auto-upgrade process.

Finding your cluster's channel

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

Note: Your cluster must be enrolled in a Release channel in order to see the release channel.

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.

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. If you'd prefer to use your existing cluster, you can follow the instructions for unsubscribing from a release channel, wait for the target release channel to make available the Kubernetes minor version of your cluster, and then follow the instructions to enroll the existing cluster in the target release channel.

Unsubscribing from a release channel

Note: For Autopilot clusters, you cannot unsubscribe from a release channel.

If you choose to unsubscribe from a channel, the node pools for the cluster will continue to have auto-upgrade enabled, even after disabling release channels. Once a cluster is no longer subscribed to a release channel, you can disable node auto-upgrade manually.

When a cluster is unsubscribed from a release channel, manual upgrades are still subject to the following limitations:

• You can only upgrade to versions that are available.
• You cannot upgrade more than one minor version at a time.
• You cannot downgrade a minor version.

To unsubscribe from a release channel, update the cluster's release channel to a value of None:

gcloud container clusters update CLUSTER_NAME \
    --release-channel 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.

What's next

• Learn more about upgrading clusters.
• Learn how to Receive cluster upgrade notifications.