This page explains how feature and API deprecations that are caused byKubernetes and other dependencies work with Google Kubernetes Engine (GKE). Thispage also includes tables with information aboutspecific upstream deprecations. To learn how toview your exposure to upcoming deprecations, seeViewing deprecation insights and recommendations.

What are Kubernetes deprecations?

GKE clusters are powered by theKubernetesopen source cluster management system. The feature set of Kubernetes evolvesover time, and just as new features are introduced over time, sometimes afeature might need to be removed. Or, a feature maygraduatefrom the Beta phase to the GA phase.Kubernetes deprecation policya deprecated feature or API before it is removed.

After its deprecation period, when a feature or API is removed, you can nolonger use it starting with the corresponding GKE minor version.If a cluster was dependent on a feature or API that was deprecated,functionality could be impaired.

Deprecations caused by other upstream dependencies

Apart from Kubernetes features and APIs, GKE also providesfeatures that are powered by other providers, such as Windows node images backedby Microsoft, and Ubuntu node images backed by Canonical. When these upstreamproviders deprecate or end support for a feature, GKE might haveto remove the corresponding feature. The tables on this page also provideinformation about upcoming deprecations and removals that are caused by upstreamdependencies apart from Kubernetes.

How Kubernetes deprecations work with GKE

Running applications on GKE involvesshared responsibilitybetween you and GKE.

As a user, you must assess and mitigate any exposure to deprecated features andAPIs that are removed in upcoming Kubernetes minor versions. In the nextsections, learn about how GKE makes this process easier bydetecting usage of deprecated Kubernetes features and APIs, sharing insightsabout this usage, and providing recommendations about how to migrate to featuresand APIs compatible with upcoming minor versions.

If GKE detects that a cluster is using a feature that isremoved in an upcoming minor version of Kubernetes, automatic cluster upgrades tothe next minor version are paused, and GKE shares a deprecationinsight and recommendation.

Warning: GKE cannot guarantee the detection of all usage ofdeprecated features or APIs, and cannot guarantee that upgrades will be paused.As part of theshared responsibilitymodel, you must review upcoming deprecations, assess your clusters for exposure,and mitigate any exposure to deprecations. To ensure that a cluster is notupgraded, usemaintenance exclusions.

What happens when GKE pauses automatic upgrades?

If GKE detects usage of a deprecated feature or API,GKE pausesautomatic upgradesto prevent your cluster from being upgraded into a broken state. Upgrades to thenextKubernetes minor versionare paused, but GKE continues to deliverpatch upgradesto the cluster on the current minor version. For example, if a cluster is onversion 1.21.11-gke.1100 and has calls to deprecated APIs that are removed fromversion 1.22, GKE pauses the automatic upgrade to version 1.22.However, GKE does not pause the automatic upgrade to a new patchversion, 1.21.11-gke.1900.

As GKE cannot guarantee that all usage is detected, GKEcannot guarantee that upgrades are always paused when a deprecated feature orAPI is used. To ensure that a cluster is not upgraded, you must usemaintenance exclusions.

When does GKE resume automatic upgrades?

Once GKE hasn't detected usage of the deprecated feature or callsto deprecated APIs for 30 days, the cluster is automatically upgraded if thenext minor version is the auto-upgrade target for your cluster in the cluster'srelease channel, and yourcluster doesn't have other factors preventing upgrades such as an activemaintenance exclusion. To see when the minor version becomes an auto-upgradetarget in your cluster's release channel, see thereleaseschedulefor an estimated date, and thereleasenotes for the specific announcement. Toget auto-upgrade targets for a specific cluster, seeGet information about acluster's upgrades.

If GKE continues to detect usage of the deprecated feature on thecluster, then GKE keeps the cluster on its current minor versionuntil the version'send of supportdate.

The dates for the end of support of minor versions are available in theReleaseSchedule. As the end of support datefor a minor version depends on release channel enrollment, ensure that you referto the correct date that is reflective of your cluster's release channel:

• Release channels other than Extended: If your cluster is enrolled in theRapid, Regular, Stable channels or the cluster isn't enrolled in a releasechannel, this date is the minor version'send of standardsupport.
• Extended channel: If your cluster is enrolled in theExtendedchannel,GKE won't automatically upgrade your cluster from the minorversion until theend of extendedsupport.

Once this date is reached, the cluster is automatically upgraded to the nextminor version and the cluster environment might be impaired as the removedfeature is still being used. To learn more, read aboutAutomatic upgrades atthe end of support.

Important: After June 30, 2024—when1.26 reaches end of standardsupport—GKE begins to automatically upgrade clusters still using version1.26 and deprecated APIs (removed in version 1.27) to version 1.27.GKE will stoppausing automaticupgradesafter June 30, 2024 for clusters still usingdeprecated APIs removed inversion 1.27. We recommend thatyou upgrade your clusters to version 1.27 as soon as possible asGKE minor versions that have reached end of support will nolonger receive security patches and bug fixes. To learn more about theGKE minor version lifecycle, seeGKE versioningand support.

What are deprecation insights and recommendations?

If GKE detects that a cluster is using a feature that is removedin an upcoming minor version of Kubernetes, GKE shares a deprecationinsight andrecommendation,notifying you of your cluster's usage of a deprecated feature. This insightprovides information about last detected usage, and further details dependingon the type of deprecation. To learn about viewing this information, seeViewing deprecation insights and recommendations.

Assess and mitigate exposure to upcoming Kubernetes deprecations

GKE provides migration guides that instruct you how to migratefrom deprecated features and APIs to those compatible with the upcoming minorversion. For a list of upcoming deprecations and their migration guides, seeKubernetes deprecations information.

While GKE shares insights about clusters it has detected areexposed to a deprecation, detection of all exposures to upcoming deprecations isnot guaranteed. For example, if a deprecated feature has not been used in thelast 30 days, GKE does not detect any usage, and an insight andrecommendation is not generated.

You must independently assess your cluster environment's exposure to anyupcoming deprecations before you upgrade your cluster to the next minor version.You can exercise control over the upgrade process by choosing arelease channel, usingmaintenance windows and exclusions,ormanually upgrading your clustersif you have determined that they are not exposed to deprecations on the nextminor version.

Resolving exposure to Kubernetes deprecations

You can take action by reviewingupcoming deprecations.View deprecation insights and recommendations,to assess if your cluster is exposed, and use migration guides to mitigate theexposure before the last available minor version supporting the feature reachesitsend of support.

After you make changes to stop usage of deprecated APIs or features in yourcluster, GKE waits until it has no longer observed use ofdeprecated APIs or features for 30 days, and then unblocks automatic upgrades.Automatic upgrades proceed according to therelease schedule.

You can alsoupgrade your cluster manuallyif you've confirmed that the upgrade does not cause disruption to yourcluster environment. You can do this by first creating a test cluster andchecking whether the upgrade causes any disruption. If it does not, you canmanually upgrade your cluster.

When you dismiss a recommendation, you only hide it for all users. Automaticupgrades remain paused until you migrate out of the deprecated features andGKE does not detect usage of the deprecated features for 30consecutive days.

Kubernetes deprecations information

The following sections provide information about ongoing deprecations, includingguides explaining how to migrate to features or APIs compatible with availableKubernetes minor versions. You can check these tables to see if GKEdetects and reports usage withinsights and recommendations.

These tables only provide information about ongoing deprecations, and omitpreviously included information for features or APIs that were deprecated withversions that are significantly past their end of support date.

Kubernetes feature deprecations

The following table outlines ongoing GKE feature deprecations,as well as the version in which those features are no longer supported:

Name	Deprecated	Removed	More information	Does GKE detect and report usage?
Container Registry	May 15, 2023	March 18, 2025	Transition from Container Registry to Artifact Registry in GKE	No
GKE Compliance dashboard (Preview)	January 28, 2025	June 30, 2025	Posture management feature deprecations	No
Workload vulnerability scanning GKE security posture dashboard	Standard tier: July 23, 2024 Advanced Vulnerability Insights: June 16, 2025	Standard tier: July 31, 2025 Advanced Vulnerability Insights: June 16, 2026	Vulnerability scanning removal from GKE Standard edition	Yes
Supply chain concerns - Binary Authorization (Preview) GKE security posture dashboard	January 28, 2025	March 31, 2025	Posture management feature deprecations	No
Kubernetes security posture - advanced tier (Preview) GKE security posture dashboard	January 28, 2025	March 31, 2025	Posture management feature deprecations	Yes
containerd 1.7 features	GKE version 1.32	GKE version 1.33	Migrate nodes to containerd 2	Yes
Linux cgroupv1 mode	GKE version 1.31	TBD	Migrate nodes to Linux cgroupv2	No
Vulnerability scanning removal from GKE standard edition	July 23, 2024	July 31, 2025	Vulnerability scanning removal from GKE Standard edition	No
TLS certificates signed with SHA-1 algorithm	GKE version 1.24	GKE version 1.29	SHA-1 TLS certificates support removal	Yes
Built-in authentication plugin for Kubernetes clients	GKE version 1.22	GKE version 1.25	Deprecated authentication plugin for Kubernetes clients	No
PodSecurityPolicy	GKE version 1.21	GKE version 1.25	PodSecurityPolicy deprecation	Yes
Docker-based node images	GKE version 1.20	GKE version 1.24	Docker node image deprecation	Yes
X.509 Common Name field in webhook certificates	GKE version 1.19	GKE version 1.23	Webhook certificates CN field deprecation	Yes

Kubernetes API deprecations

The following table provides an overview of Kubernetes APIs that are deprecatedand no longer served, sorted by Kubernetes version:

Kubernetes version	More information	Does GKE detect and report usage?
1.32	Kubernetes 1.32 deprecated APIs	Yes
1.29	Kubernetes 1.29 deprecated APIs	Yes
1.27	Kubernetes 1.27 deprecated APIs	Yes
1.26	Kubernetes 1.26 deprecated APIs	Yes
1.25	Kubernetes 1.25 deprecated APIs	Yes
1.22	Kubernetes 1.22 deprecated APIs, Kubernetes Ingress Beta APIs removed in GKE 1.23	Yes

Other feature deprecations

The following table provides information on deprecations and removals that arecaused by other upstream providers that are not part of the Kubernetes opensource project.

Name	Deprecated	Removed	More information	Does GKE detect and report usage?
Windows Server Semi-Annual Channel (SAC) node images	N/A	August 9, 2022	Windows Server SAC end of servicing	No
Saxml for multi-host serving on TPUs and GKE	N/A	April 24, 2025	Release note	No

What's next

• Viewing deprecation insights and recommendations