This topic introduces release channels, which provide Google Kubernetes Engine (GKE) best practices for versioning and upgrading your GKE clusters.
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.
By default, new clusters created in GKE 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 when a new version is available in that channel.
When a version has accumulated cumulative usage and demonstrated stability 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.
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.
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.
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.
Viewing 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
gcloud container get-server-config --format "yaml(channels)" --zone COMPUTE_ZONE
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.
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:
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.
For GKE Standard clusters, you can choose to specify a different channel during creation in the Google Cloud console.
Go to the Google Kubernetes Engine page in the Cloud console.
Click add_box Create.
In the Standard section, click Configure.
Under Control plane version, the Release channel option is selected by default.
In the Release channel drop-down list, select a release channel to enroll the cluster in, or leave the default value of Regular channel.
Continue creating the cluster as desired.
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_REGIONflag and specify the region for your cluster.
- For zonal clusters, use the
--region COMPUTE_ZONEflag and specify the zone for your cluster.
CHANNEL: the type of release channel: one of
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 createdocumentation. For the full list of optional flags for Autopilot clusters, refer to the
gcloud container clusters create-autodocumentation.
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
Finding your cluster's channel
You can determine your cluster's release channel using
gcloud or the Google Cloud console.
Go to the Google Kubernetes Engine page in Cloud console.
Click the name of the cluster you want to inspect.
Under Cluster basics, check the value in the Release Channel field (for example, Regular Channel).
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
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
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. Once a cluster is no longer subscribed to a release channel, you can disable node auto-upgrade and disable node auto-repair 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
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
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.