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.

Note: The Kubernetes API is versioned separately from Kubernetes itself. Refer to the Kubernetes API documentation for information about Kubernetes API versioning.

Version support

GKE support for Kubernetes minor versions is based on Kubernetes open source policies. GKE supports a minor version by providing patch versions of the same minor release, and, on a regular basis, automatically upgrading clusters to those newer patches.

How Kubernetes supports a minor version

The Kubernetes Open Source Software (OSS) community releases a minor version with new features and enhancements three times a year. Each release cycle is approximately 15 weeks long.

Kubernetes supports each minor version for 14 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 sometimes revises their version support calendar, as necessary. To learn more, see Support period.

How GKE supports a minor version

After Kubernetes releases a new minor version, GKE first introduces the minor version in the Rapid channel. GKE provides patch versions during that time, but as the Rapid channel provides the newest GKE versions, these versions are excluded from the GKE SLA and may contain issues without known workarounds.

After the initial availability in the Rapid channel, GKE promotes the new minor version to the Regular channel. GKE provides up to a total of 24 months of support for a minor version after the version has been made available for new cluster creation in the Regular channel. This support includes around 14 months of standard support and approximately an additional 10 months of extended support available with the Extended channel. To see the availability of specific minor versions, review the GKE release schedule.

GKE minor version lifecycle

The lifecycle of a GKE minor version lifecycle includes the following key steps:

1. Kubernetes releases a new minor version.
2. GKE makes the new minor version available in the Rapid channel.
3. GKE makes the new minor version available in the Regular channel (start of standard support period).
4. During the standard support period, GKE provides patches for the minor version which include new features, security fixes, and bug fixes.
5. The minor version reaches the end of standard support after approximately 14 months in total, entering the period of extended support. After this time, GKE provides security patches for clusters in the Extended channel.
6. The minor version reaches the end of extended support, meaning that the minor version will receive no further security patches.

Adjustments of version availability

GKE might revise the end of support for GKE versions, due to shifts in policy in the Kubernetes OSS community, the discovery of vulnerabilities, or other technical issues that cannot be reasonably resolved. GKE might also extend end of support dates around key business periods such as Black Friday and Cyber Monday.

GKE provides at least 14 months of standard support, and up to a total of 24 months of support with extended support.

To get the latest available versions, see the GKE release notes. GKE regularly updates the release schedule to reflect the timing of auto-upgrades.

Periods of availability in the minor version lifecycle

GKE provides the following periods of availability for a Kubernetes minor version:

See the following table summarizing the periods of availability, described in detail in the next sections:

Period of availability	Approximate timespan from Regular channel availability	What support does GKE provide	Access to this period of availability
Rapid support period	Month -1 through Month 0	GKE provides patch versions with new features, security fixes, and bug fixes. However, these versions are excluded from the GKE SLA and may contain issues without known workarounds.	Rapid Channel only
Standard support period	Month 1 through Month 14	GKE provides patch versions with new features, security fixes, and bug fixes.	Rapid, Regular, Stable, Extended, No Channel
Extended support period	Month 15 through Month 24	GKE provides patch versions with security fixes.	Extended Channel only (requires GKE Enterprise or additional fee per cluster, see Get long-term support with the Extended channel)

Period of Rapid support

GKE first releases a new minor version in the Rapid channel. The version first accumulates usage and demonstrates stability across clusters in this channel before being promoted to the Regular channel. Only clusters enrolled in the Rapid channel can run a new minor version during this period of support.

Period of standard support

The period of standard support for a GKE minor version begins when the version is released to the Regular channel. All GKE clusters, regardless of release channel enrollment, can run a minor version in standard support. During this period, GKE automatically upgrades clusters on a regular basis to new patch versions, which include new features, security fixes, and bug fixes.

GKE automatically upgrades clusters in the following way:

• Rapid, Regular, Stable, No Channel: Automatic upgrades to other supported minor versions, or patch versions of the same minor version.
• Extended: GKE only automatically upgrades to newer patch versions of the same minor version.

For clusters not enrolled in the Extended release channel, GKE eventually automatically upgrades clusters to the next supported minor version before the end of standard support, based on the schedule for the cluster's release channel. For details, see Estimated schedule for release channels. However, GKE doesn't upgrade clusters during this period if they use deprecated features or APIs. You can use a maintenance exclusion to temporarily prevent GKE from upgrading your cluster to the next minor version.

End of standard support (formerly end of life)

Note: GKE previously used the term end of life to refer to the end of standard support date. With the introduction of extended support, we updated this term to reflect the multiple periods of support for a GKE minor version.

After the standard support period, the minor version reaches the end of standard support (formerly known as end of life) and becomes unsupported and unavailable for all clusters not enrolled in the Extended channel.

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

GKE minor versions that have reached the end of support no longer receive security patches or bug fixes. Patch versions of a minor version that has reached the end of support are unsupported and unavailable. GKE automatically upgrades all clusters not enrolled in the Extended channel. To learn more, see Automatic upgrades at the end of support.

Period of extended support

After the end of standard support, the minor version reaches the period of extended support (Month 15 through Month 24). During this period, GKE provides patches for security fixes, including the following types of fixes:

• Medium, high, and critical security patches for core Kubernetes components, node operating system and Google-managed containers bundled with the GKE cluster version.
• For Container-Optimized OS, the node operating system's end of support might come before the end of extended support for the GKE minor version, or introduce incompatible changes. To learn more about how GKE continues to provide support, see Container-Optimized OS updates during the extended support period.

Towards the end of extended support, GKE begins upgrading clusters to the next minor version. GKE won't upgrade clusters if they're using deprecated features or APIs. You can use a maintenance exclusion to temporarily prevent GKE from upgrading your cluster to the next minor version.

End of extended support

At the end of extended support, GKE doesn't provide any patches for security fixes, and the minor version is considered unsupported. GKE upgrades clusters still running the unsupported minor version to the next minor version, regardless of the cluster's use of deprecated features or APIs.

Automatic upgrades at the end of support

GKE schedules automatic upgrades for clusters from one minor version to the next supported minor version before the minor version reaches the end of support. The timing of this upgrade depends on the schedule for the cluster's release channel. For details, see Estimated schedule for release channels. For example, clusters enrolled in the Stable channel are upgraded to the next minor version closer to the end of standard support than clusters enrolled in the Rapid channel.

During the standard support period, and extended support period for clusters enrolled in the Extended channel, you can prevent this minor version upgrade with a maintenance exclusion, and GKE won't upgrade clusters using deprecated features or APIs.

However, at the end of standard support, or at the end of extended support for clusters enrolled in the Extended channel, GKE automatically upgrades clusters to the next supported minor version to ensure that the cluster remains performant, available, and secure.

Each GKE version is supported for 14 months of standard support and for 24 months of total support including extended support. You can't keep your cluster on a version indefinitely, because operating a cluster using an unsupported GKE version carries significant security, reliability, and compatibility risk as GKE doesn't provide security patches or bug fixes for end of support versions. GKE can't commit to providing patches or updates for versions at the end of support.

GKE upgrades the cluster in the following way:

• Control plane: GKE automatically upgrades cluster control planes to supported versions when the control plane version is no longer available for new cluster creation.
• Nodes: GKE automatically upgrades nodes that are running an unsupported version after the version has reached end of support to ensure cluster health and alignment with the open source version skew policy. Nodes running unsupported versions are typically scheduled for an automated upgrade to a supported version within one month of end of support date. Nodes running unsupported versions might not be upgraded immediately upon version end of life, and actual timing can vary at Google's discretion.

Container-Optimized OS updates during the extended support period

During the period of extended support for a GKE minor version, GKE provides patch upgrades for the cluster, which might include Container-Optimized OS updates.

The Container-Optimized OS LTS release reaches the end of support before the minor version

The Container-Optimized OS LTS release might reach the end of support before the end of extended support for the minor version using the release. In this scenario, GKE uses the next Container-Optimized OS LTS release available for future patch upgrades, if possible. GKE performs this update before the Container-Optimized OS LTS release used by the nodes' minor version reaches the end of support. Cluster administrators must evaluate whether to upgrade to the next GKE patch version, which contains a new Container-Optimized OS LTS release, or stay in the same GKE patch version to not receive updates in the node operating system, while also not receiving security patches for core Kubernetes components bundled with the GKE cluster version.

The next Container-Optimized OS LTS release introduces changes incompatible with the existing minor version

The next Container-Optimized OS LTS release might introduce incompatible changes with the GKE system components, and GKE can't provide a patch version with node operating system updates. Cluster administrators must evaluate whether to upgrade to the next GKE minor version, or consider the same tradeoffs described in the previous paragraph.

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.32 is the minor release that follows Kubernetes 1.31.

Kubernetes patch release (z)

New Kubernetes patch releases (such as 1.32.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.32.6-gke.N) can include security updates and 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 the Google Cloud console to check versions

Note: Versions earlier than the default version for a channel are only visible through the gcloud CLI and the Kubernetes Engine API.

To see default and available versions, 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 intended 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.

Note: If you use the Google Cloud console to create a cluster before a version rollout has completed, the lists of available versions might not be accurate for your zone.

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)" \
   --location=COMPUTE_LOCATION

Available versions

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

Replace the following:

• COMPUTE_LOCATION: a Compute Engine location.

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)" \
   --location=COMPUTE_LOCATION

Available versions

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

Replace the following:

• COMPUTE_LOCATION: a Compute Engine location.

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)" \
   --location=COMPUTE_LOCATION

Available versions

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

Replace the following:

• COMPUTE_LOCATION: a Compute Engine location.

Extended

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

Default version

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

Available versions

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

Replace the following:

• COMPUTE_LOCATION: a Compute Engine location.

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)" \
   --location=COMPUTE_LOCATION

Available control plane versions

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

Available node versions

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

Replace the following:

• COMPUTE_LOCATION: a Compute Engine location.

Note: For advanced get-server-config output manipulation, see the gcloud documentation on filtering and formatting.

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 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 to the control plane version, and you can't specify a version.

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 skew

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.

Support for skipping minor versions

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.32 to 1.34 while skipping version 1.33.

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.32 to 1.34, upgrade it from version 1.32 to 1.33 first, then upgrade your worker nodes to match the control plane version, and then repeat the process to upgrade from version 1.33 to 1.34.

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.