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 three times a year. Each release cycle is approximately 15 weeks long.

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 minor 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, followed by a 2-month maintenance period. During the maintenance period, no new node pool creations will be allowed for a maintenance version, but existing node pools that run a maintenance version will continue to remain in operation.

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

Starting with GKE version 1.19, GKE upgrades nodes that are running an unsupported version after the version has reached end of life to ensure cluster health and alignment with the open source version skew policy. Nodes running unsupported versions might not be upgraded immediately upon version end of life, and actual timing can vary at Google's discretion.

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 three times a year. Each release cycle is approximately 15 weeks long. Deprecated APIs may be removed with a new minor version, for example with 1.22. 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.N)
A patch release with a -gke.N suffix (such as 1.18.6-gke.N) 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 the Google Cloud console or by using the Google Cloud CLI.

Use gcloud CLI 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 the Google Cloud console to check versions

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

  1. Go to the Google Kubernetes Engine page in the Google Cloud console.

    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 CLI, 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

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.

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. Versions will receive patches for bugs and security issues throughout the support period.

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. 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 node pools running a maintenance version will continue to function, and new node pool 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 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?

Cluster control planes will be automatically upgraded to supported versions when the control plane version is no longer available for new cluster creation.

Nodes running unsupported versions will be scheduled for an automated upgrade to a supported version within one month of end of life date.

Can I skip GKE versions during a cluster upgrade?

GKE does not allow skipping minor versions for the cluster control plane, however you can skip patch versions. Worker nodes can skip minor versions. For example, a node pool can be upgraded from version 1.23 to 1.25 while skipping version 1.24.

To upgrade a cluster across multiple minor versions, upgrade your control plane one minor version at a time and upgrade your worker nodes to the same version each time. For example, to upgrade your control plane from version 1.23 to 1.25, upgrade it from version 1.23 to 1.24 first, then upgrade your worker nodes to match the control plane version, and then repeat the process to upgrade from version 1.24 to 1.25.

Upgrading your worker nodes to match versions helps you to avoid version skew. We recommend that you avoid version skipping when possible. Skipping worker node versions usually implies a larger testing scope that, although manageable, requires more consideration.

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

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.