This page explains versioning in Google Kubernetes Engine (GKE), and the policiesfor version support. Over time, GKE upgrades clusters to newerversions of Kubernetes. To learn more about how upgrades work, seeAboutGKE cluster upgrades.

You can see the current versions rollout and support schedule in theGKE release schedule.

Version support

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

How Kubernetes supports a minor version

The Kubernetes Open Source Software (OSS) community releases a minor versionwith new features and enhancementsthree times ayear. Each release cycle isapproximately 15 weeks long.

Kubernetes supports each minor version for 14 months. Major bugs and securityvulnerabilities found in a supported minor version are fixed with the release ofan ad hoc patch version. The Kubernetes community sometimes revises theirversion support calendar, as necessary. To learn more, seeSupportperiod.

How GKE supports a minor version

After Kubernetes releases a new minor version, GKE firstintroduces the minor version in theRapid channel. GKE providespatch versions during that time, but as the Rapid channel provides the newestGKE versions, these versions are excluded from theGKE SLA and may contain issues withoutknown workarounds.

After the initial availability in the Rapid channel, GKE promotesthe new minor version to the Regular channel. GKE provides up toa total of24 months of support for a minor version after the version has beenmade available for new cluster creation in theRegular channel. Thissupport includes around 14 months ofstandard support andapproximately an additional 10 months ofextended support available with theExtendedchannel. To see the availability of specific minor versions, review theGKE release schedule.

GKE minor version lifecycle

The lifecycle of a GKE minor version lifecycle includes thefollowing key steps:

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

Adjustments of version availability

GKE might revise the end of support for GKEversions, due to shifts in policy in the Kubernetes OSS community, the discoveryof vulnerabilities, or other technical issues that cannot be reasonablyresolved. GKE might also extend end of support dates around keybusiness periods such as Black Friday and Cyber Monday.

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

To get the latest available versions, see theGKE releasenotes. GKE regularlyupdates 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 aKubernetes minor version:

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

Period of Rapid-only availability

GKE first releases a new minor version in the Rapid channel.The version first accumulates usage and demonstrates stability acrossclusters in this channel before being promoted to the Regular channel. Onlyclusters enrolled in the Rapid channel can run a new minor version during thisperiod of availability.

This period typically lasts around 1-2 months, however the exact timing dependson each minor version. For details, seeEstimated schedule for releasechannels.

Period of standard support

The period of standard support for a GKE minor version beginswhen the version is released to the Regular channel. All GKEclusters, regardless of release channel enrollment, can run a minor version instandard support. During this period, GKE automatically upgradesclusters 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 supportedminor versions, or patch versions of the same minor version.
• Extended: GKE only automatically upgrades to newer patchversions of the same minor version.

For clusters not enrolled in the Extended release channel, GKEeventually automatically upgrades clusters to the next supported minor versionbefore the end of standard support, based on the schedule for the cluster'srelease channel. For details, seeEstimated schedule for releasechannels.However, GKE doesn't upgrade clusters during this period if theyusedeprecated features orAPIs.You can use amaintenanceexclusionto temporarily prevent GKEfrom upgrading your cluster to the next minor version.

End of standard support (formerlyend of life)

After the standard support period, the minor version reaches theend ofstandard support (formerly known asend of life) and becomes unsupported and unavailable for all clusters notenrolled in the Extended channel.

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

GKE minor versions that have reached the end of support no longerreceive security patches or bug fixes. Patch versions of a minor version thathas reached the end of support are unsupported and unavailable.GKE automatically upgrades all clusters not enrolled in theExtended channel. To learn more, seeAutomatic upgrades at the end ofsupport.

Period of extended support

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

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

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

End of extended support

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

Automatic upgrades at the end of support

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

During the standard support period, and extended support period for clustersenrolled in the Extended channel, you can prevent this minor version upgrade witha maintenance exclusion, and GKEwon't upgrade clusters using deprecated features or APIs.

However, at the end of standard support, or at the end of extended support forclusters enrolled in the Extended channel, GKEautomatically upgrades clusters to the next supported minor version to ensurethat the cluster remains performant, available, and secure.

Each GKE version is supported for 14 months of standard supportand for 24 months of total support including extended support. You can't keepyour cluster on a version indefinitely, because operating a cluster using anunsupported GKE version carries significant security,reliability, and compatibility risk as GKE doesn't providesecurity patches or bug fixes for end of support versions. GKEcan'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 controlplanes to supported versions when the control plane version is no longeravailable for new cluster creation.
• Nodes: GKE automatically upgrades nodes that are runningan unsupported version after the version has reached end of support toensure cluster health and alignment with theGKE versionskew policy. Nodes running unsupported versions aretypically scheduled for an automated upgrade to a supported version withinone month ofend of supportdate.Nodes running unsupported versions might not be upgraded immediately uponversion end of life, and actual timing can vary at Google's discretion.

Identify clusters running a minor version past the end of standard support

GKE identifies clusters that meet both of the followingconditions:

• The control plane runs a minor version that has reached theend of standardsupport.
• The cluster isn't enrolled in theExtendedchannel.

GKE recommends that you upgrade these clusters because of therisks associated with running an unsupported minor version. GKEupgrades clusters to the next supported minor version if the existing versionisn't supported in the cluster's release channel.

GKE delivers this guidance with an insight and recommendationthrough theRecommender service. Thisguidance doesn't apply to clusters that are enrolled in the Extended channel,which can continue to run a minor version until theend of extendedsupport. To learn moreabout how to manage insights and recommendations from Recommender, seeOptimize your usage of GKE with insights andrecommendations.

To find clusters where the control plane is running a version past the end ofsupport, you can use one of the following ways:

• Use the Google Cloud console.
• Use the gcloud CLI or Recommender API, by specifying theCLUSTER_VERSION_END_OF_LIFErecommendersubtype.

For instructions, see how toview insights andrecommendations.

To implement this recommendation,upgrade your cluster's controlplane to asupported minor version. For supported minor versions and end of support dates,see the GKE releaseschedule. Or,change your cluster tothe Extendedchannel ifyou want to continue to use the existing minor version until the end of extendedsupport.

Container-Optimized OS updates during the extended support period

During theperiod of extended support for aGKE minor version, GKE provides patch upgrades forthe cluster. These patch upgrades might include Container-Optimized OSupdates to the existing Container-Optimized OS milestone used by theGKE minor version. GKE minor versions typicallyuse one milestone during the period of standard support through the beginning ofthe period of extended support.

However, the Container-Optimized OS milestone used by theGKE minor version reaches its own end of support, typicallyduring the extended support period for a GKE minor version. Whenthis occurs, GKE builds all subsequent GKE patchversions with the next Container-Optimized OSmilestone. To learn more about milestone lifecycles, see theversioningscheme forContainer-Optimized OS.

Review the following scenario to understand how automatic upgrades proceed, andwhat decisions cluster administrators must make when GKE can nolonger introduce Container-Optimized OS updates in the same milestone fora GKE minor version.

The Container-Optimized OS milestone reaches the end of support before the minor version end of extended support

TheContainer-Optimized OSmilestone reaches itsown end of support before theend of extendedsupport for the minor version that uses themilestone. In this scenario, GKE uses the next availableContainer-Optimized OS milestone for future patch upgrades.GKE performs this update before the Container-Optimized OSmilestone that's used by the minor version reaches the end of support.

Cluster administrators must evaluate whether to upgrade the cluster's workernodes, because GKE won't automatically upgrade these nodes to thenext patch version with the new milestone. You can manually upgrade the nodes tothe next GKE patch version, which contains a new milestone. Or,you can keep the nodes running the same GKEpatch version to not use the new milestone. However, the nodes won't receivesecurity patches until upgrading to the next patch or minor version.

Automatic upgrades for the new Container-Optimized OS milestone

The next patch version for a GKE minor version in the extendedsupport period uses a newer Container-Optimized OS milestone from previouspatch versions. GKE automatically upgrades clusters in thefollowing ways when the new patch version becomes an auto-upgrade target:

• Control plane upgrades:
  • GKE upgrades the control plane to the next patch version,as normal.
• Node upgrades:
  • GKE doesn't upgrade nodes to the next patch version.
  • GKE upgrades the nodes to the next minor version towardsthe end of extended support, as normal. To learn more, seeAutomaticupgrades at the end ofsupport.

Because the new milestone version might introduce changes that are incompatiblewith your workloads, GKE pauses automatic node upgrades to thenext patch version. You can manually upgrade to the new patch version if you'vedetermined that your workloads are compatible with the nextContainer-Optimized OS milestone. If you manually upgrade your nodes to apatch version which uses the new Container-Optimized OS milestone,GKE resumes automatic patch upgrades of the nodes because thenodes now run the new milestone.

Cluster notification when new patch versions use the new milestone

GKE sends aclusternotification informingyou when this situation occurs. This notification is sent when the first patchversion that uses the new Container-Optimized OS milestone becomesavailable in the Extended channel.

When you receive this notification, evaluate whether you want to manuallyupgrade the nodes to the next patch or minor version, or receive no later patchversions for this minor version during the period of extended support. To learnmore, seeNew patch versions change to new Container-Optimized OSmilestone during extended support.

Versioning scheme

GKE appends a GKE patch version to the Kubernetessemantically versioned industry standard(x.y.z-gke.N):

Kubernetes major version (x)

Major versions typically are incremented if any backwards incompatible changesare introduced to the public API. A major version increments the Kubernetesversion from x.y to x+1.y.

Kubernetes minor version (y)

Kubernetes releases a new minor versionthree times a year. Each release cycle is approximately 15 weeks long.DeprecatedAPIs maybe removed with a new minor version, for example with1.22. A minorversion 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 GKEtypically become available each week. Patch releases are rolled out to eachzone incrementally.

GKE patch release (-gke.N)

A patch release with a -gke.N suffix (such as 1.32.6-gke.N) can includesecurity updates and bug fixes for GKE alongside the open sourceupstream Kubernetes software. These updates or fixes are required forcompatibility and interoperability with Google Cloud.

Checking available and default versions

For information on available versions, see theGKE release notes.

You can also check which Kubernetes versions are available and default in agiven zone from the Google Cloud console or by using the Google Cloud CLI.

Use the Google Cloud console to check versions

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

   Go to Google Kubernetes Engine

2. Clickadd_boxCreate.

3. Choose theStandard cluster mode, then clickConfigure.

4. In theLocation type section, choose a location type and the intended location for your cluster.

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

To see which versions are available and which are default, run one of thefollowinggcloud commands for your cluster type. Each tab provides commandsto check versions for a specificrelease channel,or for no channel (formerlystatic).

gcloudcontainerget-server-config\--flatten="channels"\--filter="channels.channel=RAPID"\--format="yaml(channels.channel,channels.defaultVersion)"\--location=COMPUTE_LOCATION

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

gcloudcontainerget-server-config\--flatten="channels"\--filter="channels.channel=REGULAR"\--format="yaml(channels.channel,channels.defaultVersion)"\--location=COMPUTE_LOCATION

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

gcloudcontainerget-server-config\--flatten="channels"\--filter="channels.channel=STABLE"\--format="yaml(channels.channel,channels.defaultVersion)"\--location=COMPUTE_LOCATION

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

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

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

gcloudcontainerget-server-config\--format="yaml(defaultClusterVersion)"\--location=COMPUTE_LOCATION

gcloudcontainerget-server-config\--format="yaml(validMasterVersions)"\--location=COMPUTE_LOCATION

gcloudcontainerget-server-config\--format="yaml(validNodeVersions)"\--location=COMPUTE_LOCATION

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 canspecify a cluster version using the--cluster-version flag. You can use aspecific version, such as 1.9.7-gke.N. You can also use aversion alias:

• latest: Specifies the highest supported Kubernetes versioncurrently 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 minorversion
• 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 forcontrol planes. For node upgrades, specifies the version that the cluster controlplane is running.

Creating or upgrading a cluster by specifying the version aslatest does notprovide automatic upgrades. Enablenode auto-upgradesto ensure that the nodes in your cluster are up-to-date with the latest stableversion.

Specifying node version

This section applies only to clusters created in the Standard mode.In Autopilot clusters, nodes are upgraded automatically to the controlplane version, and you can't specify a version.

When youcreate or upgrade a node pool,you can specify its version. By default, nodes run the same version ofGKE as the control plane. Nodes can be no more than two minorversions older than control planes.

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

GKE version skew policy

The GKE version skew policy ensures that a GKEcluster maintains compatibility between the control plane and nodes. In aGKE cluster, nodes can match the control plane version or run upto two minor versions earlier than the control plane.

The nodes can't run versions newer than the control plane version. For example,if the cluster's control plane runs version 1.31, the nodes can run thefollowing versions: 1.31, 1.30, or 1.29, but not 1.28 or earlier. The version ofthe nodes can't be newer than the control plane version due to theKubernetesOSS version skewpolicy.

To ensure supportability and reliability, nodes should use a supported versionregardless of following a valid version skew.

Identify clusters with an unsupported version skew

GKE identifies clusters in which the nodes are running a versionthat is incompatible with the control plane due to version skew.GKE recommends that you upgrade the nodes running thisunsupported version, delivering this guidance with an insight and recommendationthrough theRecommender service. To learnmore about how to manage insights and recommendations from Recommender,seeOptimize your usage of GKE with insights andrecommendations.

To find clusters with an unsupported version skew, you can use one of the followingways:

• Use the Google Cloud console.
• Use the gcloud CLI or Recommender API, by specifying theCLUSTER_VERSION_SKEW_UNSUPPORTEDrecommendersubtype.

For instructions, see how toview insights andrecommendations.

To implement this recommendation,upgrade anynodes thatare running a minor version that is more than two minor versions earlier thanthe control plane version.

Support for skipping minor versions

GKE does not allow skippingminor versionsfor the cluster control plane, however you can skippatchversions. Worker nodes can skip minor versions. Forexample, a node pool can be upgraded from version 1.32 to 1.34 while skippingversion 1.33.

To upgrade a cluster across multiple minor versions, upgrade your control planeone minor version at a time and upgrade your worker nodes to the same versioneach time. For example, to upgrade your control plane from version 1.32 to1.34, upgrade it from version 1.32 to 1.33 first, then upgrade your workernodes to match the control plane version, and then repeat the process to upgradefrom version 1.33 to 1.34.

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

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