Kubernetes Version Upgrade and End of Support Security Guide: Plan AKS, EKS and GKE Upgrades Before Support Ends

A Kubernetes cluster that drifts past its supported minor version stops receiving security fixes, and the managed services will eventually upgrade it for you on their timetable rather than yours. Upstream Kubernetes ships roughly three minor releases a year and patches each one for about a year, so every cluster faces at least one minor upgrade a year just to stay supported. This guide covers the upstream lifecycle and version skew rules, the end of support and extended support models of Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) and Google Kubernetes Engine (GKE), how to find removed APIs before they break workloads, and a tested upgrade and rollback approach. It is written for platform engineers, cluster owners and the security teams who track unsupported components. Platforms are listed alphabetically; order is never a ranking. Dates and prices were checked on 13 November 2026 and change with every release, so confirm them against the sources below before planning.

Key takeaways

• Support is short by design. Upstream Kubernetes 1.19 and newer receive approximately one year of patch support, and only the three most recent minor versions are maintained.
• Extended support buys time, not safety forever. AKS Long Term Support, EKS extended support and the GKE Extended channel each stretch a minor version to roughly two years, at extra cost, and then upgrade the cluster automatically.
• Upgrades go one minor at a time. The control plane cannot skip minor versions, and nodes far behind the control plane must catch up first, so a cluster that falls three versions behind needs three sequential upgrades.
• Removed APIs are the real breakage risk. Find deprecated API calls through API server warnings, metrics and audit annotations, then fix manifests, Helm charts, operators and admission webhooks before the control plane moves.
• A forced upgrade is the worst kind. Platform-initiated upgrades at end of support can ignore maintenance windows, deprecated API usage and Pod Disruption Budgets, so plan your own upgrade well before the date.

The upstream lifecycle and why it matters for security

The Kubernetes project maintains release branches for the three most recent minor versions. On 13 November 2026 the releases page listed 1.37 (end of life 28 October 2027), 1.36 (28 June 2027) and 1.35 (28 February 2027), with 1.34 having reached end of life on 27 October 2026. The end of life dates fall about four months apart, which reflects the cadence of roughly three minor releases a year. The project states that Kubernetes 1.19 and newer receive approximately one year of patch support.

Fixes for vulnerabilities in the API server, kubelet and kube-proxy land only in supported branches. The kubeadm upgrade documentation says it plainly: the project recommends upgrading to the latest patch releases promptly and running a supported minor release, because doing so helps you stay secure. For this reason an unsupported cluster version belongs in the same risk register as an unsupported operating system. See the Operating System End of Life and Extended Support Guide for the general approach.

Three practical consequences follow:

• Patch versions are routine. Automate them where the platform allows.
• Minor versions are change projects. They can remove API versions and change defaults, so they need inventory, testing and a rollback plan.
• Add-ons have their own lifecycle. CNI, CoreDNS, CSI drivers, ingress controllers, policy engines and operators each support a range of Kubernetes versions.

For the wider control set that applies once a cluster is current (RBAC, admission, network policy, audit logging), see the Kubernetes Security Guide. This page stays on lifecycle and upgrades.

Version skew rules that shape every upgrade

The upstream version skew policy defines how far each component may drift from the API server. These rules decide the order of work and how far behind node pools can safely sit.

The policy sets out an upgrade order: the API server first, then the controller manager, scheduler and cloud controller manager, then kubelets and kube-proxy. Before the API server moves, admission webhooks must be able to handle the new version's resources and fields; the policy suggests updating webhook configurations or using matchPolicy: Equivalent. Nodes must be drained before a minor kubelet upgrade because in-place minor kubelet upgrades are not supported. The API server must be upgraded one minor version at a time, even in single-instance clusters, and nodes running kubelet or kube-proxy three minors behind must be upgraded before the control plane can move. The project also recommends moving to the latest patch of the current minor before upgrading to the latest patch of the target minor.

A cluster on 1.32 that must reach 1.35 therefore needs three tested control plane upgrades.

Managed service lifecycles: AKS, EKS and GKE

Each managed service runs its own support calendar on top of upstream, adds an optional longer support window, and upgrades clusters that run past the final date. The table summarises each provider's own documentation as checked on 13 November 2026.

Availability and cost notes

• AKS: LTS requires moving the cluster to the Premium tier and selecting the LTS support plan. Only the two most recent patch versions of each minor receive LTS support, so Microsoft suggests the patch auto-upgrade channel. During platform support Microsoft supports Azure platform issues only; Kubernetes API support, security patches and cluster creation are not part of it.
• EKS: The EKS pricing page lists $0.10 per cluster per hour for standard Kubernetes version support and $0.60 per cluster per hour for extended support (standard plus $0.50). Turning extended support off means the cluster is auto-upgraded at the end of standard support instead.
• GKE: Pay-per-use charges apply when a cluster is enrolled in the Extended channel and its minor version enters the extended support period; rates are on the GKE pricing page. Clusters not enrolled in a channel use "No channel", which Google lists as deprecated.

What the automatic upgrade does and does not touch

• AKS: Microsoft documents that platform-initiated upgrades do not follow your maintenance window, do not stop for deprecated API usage and can override a Pod Disruption Budget that blocks a node drain. The documentation states this applies from 1 June 2027 to clusters still unsupported after the 60-day grace period. An LTS cluster that reaches LTS end moves to the next supported LTS version rather than to a community-supported one.
• EKS: The automatic upgrade covers the control plane only. EKS Auto Mode nodes may update automatically, while self-managed nodes and EKS managed node groups remain on the previous version, which can push node pools toward the edge of the skew window.
• GKE: Maintenance exclusions can hold minor upgrades until the end of extended support, but cannot be set past that date except as a temporary emergency measure using the "No upgrades" scope.

For the wider hardening of each service, see the Azure Kubernetes Service Security Hardening Guide, the Amazon EKS Security Hardening Guide and the GKE Security Hardening Guide. Self-managed kubeadm clusters are never upgraded automatically, so an unowned one can sit unsupported indefinitely.

Decision guidance: upgrade now or buy extended support

Extended support is a loan against a future upgrade that still runs one minor at a time.

Small organisations: one or two clusters are easier to keep current than to keep extended. Pick a release channel or auto-upgrade setting for patches, and schedule two minor upgrades a year as standing work. Large organisations: treat cluster version as a fleet compliance attribute, report it centrally and give each platform team a target such as "no production cluster within 60 days of end of standard support". Record extended support approvals in the Technology End of Life Policy Template.

Finding deprecated and removed APIs before the upgrade

Upgrades usually fail on manifests, charts and controllers that still call a removed API version. The upstream deprecation guide lists every removal by release.

Several of these removals are security relevant. The v1.25 removal of PodSecurityPolicy meant clusters had to replace it with Pod Security Admission or a policy engine before upgrading, or lose pod-level controls entirely; see the Kubernetes Admission Control Guide. The v1.22 removal of v1beta1 webhook configurations and RBAC objects touched the components that enforce policy and authorisation.

Where to look

• API server warnings: since 1.19 the API server returns a warning header when a client calls a deprecated API, and kubectl prints it. Capture these warnings in CI runs that apply manifests.
• Metrics: the API server exports the apiserver_requested_deprecated_apis gauge, labelled with group, version, resource and removed release. Any non-zero series for an API removed in your target version is a blocker.
• Audit log: requests to deprecated APIs carry the k8s.io/deprecated and k8s.io/removed-release audit annotations. Group by user and user agent to find the caller. See the Kubernetes Audit Log Detection Guide.
• Managed service checks: EKS upgrade insights scan clusters against a list of upgrade-impacting issues; GKE holds automatic minor upgrades for clusters using deprecated features or APIs until close to the end of extended support; AKS lists the issue on the cluster in the portal.
• Source repositories: scan Git, Helm values and rendered chart output, not just what is live.
• Simulate the removal: on a self-managed test cluster the deprecation guide suggests starting the API server with --runtime-config=<group>/<version>=false to switch off an API version before it is removed upstream.

To convert manifests, the kubectl convert plugin rewrites an object to a newer API version. It is not installed by default, and the deprecation guide warns that conversion may use non-ideal default values, so review every converted file. For chart supply chain hygiene, see the Helm Security Guide.

Where identity fits

Upgrades change how workloads and pipelines authenticate, and they are the moment when legacy credentials either get cleaned up or carried forward.

• Service account tokens: Kubernetes 1.24 stopped auto-generating long-lived secret-based service account tokens, but tokens created before that remain valid until deleted. An upgrade is a good point to inventory and remove them. See the Kubernetes Service Account Token Guide and How to rotate a Kubernetes service account token and detect old token use.
• Upgrade automation identities: the CI runner, GitOps controller or Terraform role that performs upgrades usually holds cluster-admin and cloud permissions to change the control plane. Scope it, store its credentials in a secrets manager and log every upgrade it performs. See How to audit Kubernetes cluster admin bindings.
• Workload identity integrations: cloud workload identity agents and webhooks are add-ons with their own supported version ranges. Test that pods still obtain cloud credentials after the upgrade before promoting it. See the Kubernetes Workload Identity Checklist.

A tested upgrade and rollback approach

1. Inventory. List every cluster with its control plane version, node pool versions, add-on versions, owner and the provider's end of standard and extended support dates. EKS exposes these dates through describe-cluster-versions; AKS through az aks get-versions; GKE on the release schedule.
2. Patch first. Move to the latest patch of the current minor and confirm node pools are within the allowed skew.
3. Read the release notes. Check upstream and provider notes for removed APIs, changed defaults and feature gate changes.
4. Scan for removed APIs. Use the metric, audit annotations, provider insights and repository scans above. Fix every blocker in source control, not by editing live objects.
5. Check add-on compatibility. Confirm the CNI, CSI drivers, ingress controllers, service mesh, policy engine, operators and workload identity components support the target minor. Upgrade them first where their supported range overlaps both versions.
6. Back up. Take an application-level backup of cluster objects and persistent volumes and, on self-managed clusters, an etcd snapshot. See Kubernetes Backup and Recovery.
7. Upgrade in rings. Development, staging, a low-risk production cluster, then the rest, holding each ring through a business cycle.
8. Upgrade the control plane, then nodes. For nodes, prefer creating a new node pool on the target version and draining workloads across (blue/green) over in-place upgrades; it gives a clean rollback by moving workloads back while the old pool exists.
9. Validate. Run smoke tests and confirm admission policy, audit logging, workload identity, ingress and DNS still work.
10. Plan the rollback honestly. On AKS, plan upgrades as forward only, as Microsoft's version support page describes. EKS documents rollback readiness insights for clusters upgraded within the last seven days; read the provider's current rollback documentation before relying on it. For self-managed clusters, rollback means restoring the control plane from backup. In practice the safe rollback is at the node and workload layer, which is why the blue/green node pool and the ring approach matter.

Fold minor upgrades into normal patch governance; the Patch Management Guide covers rings and exception handling across platforms.

Detection and measurement

Monitor the lifecycle as continuously as you monitor vulnerabilities:

• Version drift: collect control plane and kubelet versions from every cluster daily and compare against a lifecycle table built from the provider and upstream pages.
• Deprecated API calls: alert when apiserver_requested_deprecated_apis shows a series whose removed release is at or below your next target version.
• Unexpected upgrades: alert on control plane version changes that did not come from your change pipeline; on managed services this is the signature of a platform-initiated upgrade.

Metrics that show the programme is working:

• Percentage of clusters on a minor version within upstream or provider standard support (target 100 per cent for production).
• Median days from a provider making a new minor available to production adoption.
• Number of clusters in extended or long term support, each with a dated, approved exception.
• Number of clusters with node pools more than one minor behind the control plane.
• Count of deprecated API calls to versions removed in the next target release (target zero before the upgrade window).
• Platform-initiated upgrades in the last 12 months (target zero).

Common failure patterns

• Treating extended support as the plan. Teams buy a year of extended support, then arrive at its end three minors behind with three sequential upgrades and a forced deadline.
• Forgetting node pools. Old node images keep running long after the control plane moves, drifting toward the edge of the skew window.
• Scanning only the live cluster. Charts used only for disaster recovery or month-end batch still reference removed APIs and fail at the worst time.
• Breaking policy enforcement silently. Admission webhooks or policy engines that do not support the new version can fail open, leaving pods admitted without the controls the security team assumes are in place.
• Disabling extended support without a calendar. On EKS, switching extended support off means an automatic upgrade at the end of standard support, which surprises teams that changed the setting to save cost.

Framework mapping

Practitioner checklist

• Build a lifecycle table for every cluster: control plane, node pools, add-ons, owner, end of standard and extended support dates.
• Set a target such as "no production cluster within 60 days of end of standard support" and report against it monthly.
• Automate patch versions through the provider's release channel or auto-upgrade setting.
• Decide explicitly whether each cluster uses extended or long term support, record who approved it and set an end date.
• Alert on non-zero apiserver_requested_deprecated_apis for APIs removed in the next target release, and scan repositories as well as live clusters.
• Confirm admission webhooks, policy engines and workload identity components support the target minor before the control plane moves.
• Upgrade in rings, prefer blue/green node pools, and document the rollback path the provider actually supports.
• Inventory and remove legacy secret-based service account tokens and review the permissions of the upgrade automation identity.

Standards and references

• Kubernetes: Releases
• Kubernetes: Version Skew Policy
• Kubernetes: Deprecated API Migration Guide
• Microsoft Learn: Supported Kubernetes versions in Azure Kubernetes Service
• Microsoft Learn: AKS long-term support for Kubernetes versions
• AWS: Understand the Kubernetes version lifecycle on EKS
• AWS: Amazon EKS cluster insights
• Google Cloud: GKE release channels

Related NHI Mgmt Group resources: Kubernetes Security Guide · Kubernetes Platform Health Check · Container Image Vulnerability Management Guide · Kubernetes NHI Security Guide