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 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. 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 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.
For more direct management of your cluster's version and nodes, you can choose to not enroll the cluster in a release channel (that is, no channel) by specifying a static GKE version. Not using a release channel means that you are responsible for managing your node upgrade strategy. You still must also adhere to the Kubernetes version and version skew support policy, and use supported GKE versions.
Regardless of whether your cluster is enrolled in a release channel or not, cluster control planes are always upgraded on a regular basis.
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 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.
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
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:
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 tool 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.