GKE versioning and support

This page explains versioning in Google Kubernetes Engine (GKE), and the policies for version support. You can see the current versions rollout and support schedule in the GKE release schedule.

Version support

The Kubernetes Open Source Software (OSS) community currently releases a minor version with new features and enhancements approximately every 3 months. Starting with Kubernetes 1.19, OSS supports each minor version for 12 months. Major bugs and security vulnerabilities found in a supported minor version are fixed with the release of an ad hoc patch version. The Kubernetes community may revise their version support calendar from time to time.

Google provides a total of 14 months of support for each GKE minor version once the version has been made available in the Regular channel. Nodes and node pool versions can be up to two minor versions older than the control plane, but cannot be newer than the control plane version due to the Kubernetes OSS version skew policy. To ensure supportability and reliability, nodes should use a supported version regardless of following a valid version skew.

After 12 months, a supported version will enter a 2-month maintenance period before reaching end of life.

GKE minor version life cycle

The first phase of the minor version life cycle begins with the release of a supported GKE version. Clusters running a supported minor version will receive regular patches to fix bugs and security issues that have been reported. Based on the current Kubernetes OSS community version support policy, GKE plans to maintain supported minor versions for 14 months, including the 12 months after the release in the Regular channel, and a 2-month maintenance period.

At the end of the 12-month release period, GKE provides a 2-month maintenance period. During the 2 months of the maintenance period, no new cluster creations will be allowed for a maintenance version, but existing clusters that run a maintenance version will continue to remain in operation.

At the end of the maintenance period, a maintenance version reaches end of life and officially becomes unsupported. GKE minor versions that have reached end of life will no longer receive security patches and/or bug fixes.

Google cannot commit to providing patches or updates for end of life versions.

Please note that in rare cases, it may be necessary to revise the maintenance period or end of life for GKE versions, due to shifts in policy in the Kubernetes OSS community, or the discovery of vulnerabilities, or other technical issues that cannot be reasonably resolved. To get the latest available versions, see the GKE release notes.

Versioning scheme

GKE appends a GKE patch version to the Kubernetes semantically versioned industry standard (x.y.z-gke.n):

Kubernetes major version (x)
Major versions typically are incremented if any backwards incompatible changes are introduced to the public API. A major version increments the Kubernetes version from x.y to x+1.y.
Kubernetes minor version (y)
Kubernetes releases a new minor version approximately every three months. A minor version increments the Kubernetes version from 1.y to 1.y+1; for example, Kubernetes 1.19 is the minor release that follows Kubernetes 1.18.
Kubernetes patch release (z)
New Kubernetes patch releases (such as 1.18.6) for use with GKE typically become available each week. Patch releases are rolled out to each zone incrementally.
GKE patch release (-gke.a)
A patch release with a -gke.a suffix (such as 1.18.6-gke.a) includes security updates and/or bug fixes for GKE alongside the open source upstream Kubernetes software. These updates or fixes are required for compatibility and interoperability with Google Cloud.

Checking available and default versions

For information on available versions, see the GKE release notes.

You can also check which Kubernetes versions are available and default in a given zone from Google Cloud Console or by using the gcloud command-line tool.

Use gcloud tool to check versions

To see which versions are available and which are default, run one of the following gcloud commands for your cluster type. Each tab provides commands to check versions for a specific release channel, or for no channel (static).

Rapid

To see the default and available versions in the Rapid release channel, run the following commands:

Default version

gcloud container get-server-config --flatten="channels" --filter="channels.channel=RAPID" \
    --format="yaml(channels.channel,channels.defaultVersion)"

Available versions

gcloud container get-server-config --flatten="channels" --filter="channels.channel=RAPID" \
    --format="yaml(channels.channel,channels.validVersions)"

Regular

To see the default and available versions in the Regular release channel, run the following commands:

Default version

gcloud container get-server-config --flatten="channels" --filter="channels.channel=REGULAR" \
    --format="yaml(channels.channel,channels.defaultVersion)"

Available versions

gcloud container get-server-config --flatten="channels" --filter="channels.channel=REGULAR" \
    --format="yaml(channels.channel,channels.validVersions)"

Stable

To see the default and available versions in the Stable release channel, run the following commands:

Default version

gcloud container get-server-config --flatten="channels" --filter="channels.channel=STABLE" \
    --format="yaml(channels.channel,channels.defaultVersion)"

Available versions

gcloud container get-server-config --flatten="channels" --filter="channels.channel=STABLE" \
    --format="yaml(channels.channel,channels.validVersions)"

No channel

To see the default and available versions for no channel (static), run the following commands:

Default version

gcloud container get-server-config --format="yaml(defaultClusterVersion)"

Available control plane versions

gcloud container get-server-config --format="yaml(validMasterVersions)"

Available node versions

gcloud container get-server-config --format="yaml(validNodeVersions)"

Use Google Cloud Console to check versions

To see which versions are available and default, perform the following steps:

  1. In the Cloud Console, go to the Google Kubernetes Engine page.

    Go to Google Kubernetes Engine

  2. Click Create.

  3. Choose the Standard cluster mode, then click Configure.

  4. In the Location type section, choose a location type and the desired location for your cluster.

  5. In the Control plane version section, select a release channel. All currently available versions are listed for that channel. The default version is automatically selected.

Specifying cluster version

This section applies only to clusters created in the Standard mode.

When you create or upgrade a cluster using the gcloud tool, you can specify a cluster version using the --cluster-version flag. You can use a specific version, such as 1.9.7-gke.N. You can also use a version alias:

  • latest: Specifies the highest supported Kubernetes version currently available on GKE in the cluster's zone or region.
  • 1.X: Specifies the highest valid patch+gke.N patch release in the 1.X minor version
  • 1.X.Y: Specifies the highest valid gke.N patch in the 1.X.Y patch release.
  • -: For cluster control planes, specifies the default Kubernetes version for control planes. For node upgrades, specifies the version that the cluster control plane is currently running.

Creating or upgrading a cluster by specifying the version as latest does not provide automatic upgrades. Enable node auto-upgrades to ensure that the nodes in your cluster are up-to-date with the latest stable version.

Specifying node version

This section applies only to clusters created in the Standard mode. In Autopilot clusters, nodes are upgraded automatically.

When you create or upgrade a node pool, you can specify its version. By default, nodes run the same version of GKE as the control plane. Nodes can be no more than two minor versions older than control planes.

With rare exceptions, node versions remain available even if the cluster version is no longer available.

Version support FAQ

How long is a Kubernetes minor version supported by GKE?

GKE provides 14 months of support for each Kubernetes minor version that is made available.

When does the support window start for each minor version?

Support for a Kubernetes minor version starts when it’s first made available for new cluster creation in the Regular release channel.

What’s the difference between the maintenance and end of life periods for a GKE minor version?

The maintenance period means a version is expected to soon enter the end of life period, and may only receive critical security patches and bugs. During the end of life period, the GKE minor version will not receive any security patches, bug fixes, or new features.

When does support end for a Kubernetes version in GKE?

A Kubernetes minor version becomes unsupported in GKE when it reaches end of life, after 14 months of support.

What happens on the maintenance start date?

GKE will notify customers about upcoming maintenance and end of life versions through existing touchpoints such as: release notes, emails to project contacts, and GKE notifications, where applicable. Existing clusters running a maintenance version will continue to function, and new cluster creation for the maintenance version will be disabled.

What happens on the end of life date?

Customers running an end of life version will be notified through an email to the project contact prior to the end of life of a version. GKE will also begin to gradually auto-upgrade clusters and nodes (regardless of auto-upgrade enablement) running end of life versions for security and compatibility purposes because no new security patches or bug fixes will be provided for end of life versions. Before engaging with Cloud Customer Care for any issues with a cluster or nodes running an end of life version, you must first upgrade your cluster and nodes to a supported version.

When exactly will my cluster be automatically upgraded after the end of life date?

You should expect your clusters to be automatically upgraded to supported versions within one month of the end of life date.

Can I skip multiple GKE versions during a cluster upgrade?

Kubernetes OSS allows version skipping on worker nodes. For example, a node pool can be upgraded from version 1.19.x to 1.21.x while skipping version 1.20.x. However, control planes do not support version skipping; therefore, each new minor version requires a control plane upgrade.

For example, to upgrade control planes from version 1.19.x to 1.21.x, control planes must first be upgraded from version 1.19.x to 1.20.x, and then upgraded from 1.20.x to 1.21.x.

Alternatively, you can create a new cluster with the desired version, and redeploy your workloads.

As a good practice, we recommended that you continuously upgrade your nodes to match the control plane’s version, and avoid version skew and version skipping when possible. Skipping versions usually implies a larger testing scope that, although manageable, requires more consideration.

Can I leave my cluster on a Kubernetes version indefinitely?

No, each GKE version is supported for 14 months and operating a cluster using an end of life GKE version carries significant security, reliability, and compatibility risk because no security patches or bug fixes will be provided for end of life versions.

How often should I expect to upgrade a Kubernetes version to stay in support?

We recommend that you opt into a release channel and enable node auto upgrades to help reduce the operational burden involved with upgrading GKE versions. However, when manually upgrading, we recommend planning to upgrade no later than every six months to gain access to new features and remain on a supported version.

What is the rollout policy for GKE control planes?

Cluster control planes are always upgraded on a regular basis, regardless of whether your cluster is enrolled in a release channel or whether node auto- upgrade is disabled. Learn more in Automatic upgrades.