This topic introduces release channels, which provide more control over automatic upgrades of your GKE clusters.
Kubernetes releases updates often, to deliver security updates, fix known issues, and introduce new features. Release channels provide more control over which automatic updates a given cluster receives, based on the stability requirements of the cluster and its workloads.
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, selecting only versions available in that channel. A version must meet increasing stability requirements to be eligible for a more stable channel, and more stable channels receive fewer, less frequent updates.
What channels are available?
The following release channels are available. Each has a different release cadence and targets different types of workloads.
|Channel||Approximate upgrade cadence||Intended users||Expectations|
|Rapid||Weekly||Early testers and developers who requires new features.||The latest qualified components, before any other channel. Less testing and potentially more unresolved issues than other channels, including the potential for issues with no known workarounds. Not supported for production workloads. Not covered by the GKE SLA.|
|Regular||Multiple per month||Production users who need features not yet offered in the Stable channel||These versions have passed internal validation and are considered production-quality, but don't have enough historical data to guarantee their stability. Known issues generally have known workarounds.|
|Stable||Every few months||Production users who need stability above all else, and for whom frequent upgrades are too risky||These versions have met all the requirements of the Regular channel and have been shown to be stable and reliable in production, based on the observed performance of running clusters.|
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, its new patch releases are promoted to the Regular channel, and updates happen less frequently. 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 and cannot be guaranteed.
Finding out what's new
Separate release notes are available 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|
Selecting a release channel
You can create a cluster that uses release channels to manage its version instead of using the default version or choosing a specific version. The cluster only receives updates from that release channel.
When you create a cluster, you can choose to enroll the cluster in a release channel instead of using the default version or choosing a specific version.
Visit the Google Kubernetes Engine menu in GCP Console.
Click Create cluster.
Choose the Standard cluster template or choose an appropriate template for your workload.
Choose the release channel the cluster is enrolled in.
Continue creating the cluster as normal.
To create your cluster, use a command like the following, and set the value of
--release-channel to one of
gcloud beta container clusters create [CLUSTER-NAME] \ --zone [ZONE] \ [ADDITIONAL-FLAGS] \ --release-channel [CHANNEL]
Auto-upgrade is enabled (and cannot be disabled), so your cluster is updated automatically from releases available in the chosen release channel.
Keep the following caveats in mind when using release channels.
Changing and disabling release channels
You cannot currently change the release channel for a given cluster or disable
release channels on a cluster where they are enabled. To stop using release
channels and go back to specifying an exact version, you
must recreate the cluster without the
You cannot currently enroll an existing cluster in a release channel.
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.