AWS just handed platform teams a predictable 26-month runway for a Kubernetes minor release — and that changes how you should schedule upgrades.
Amazon EKS and EKS Distro now support Kubernetes 1.36: you can create new clusters or upgrade existing clusters to 1.36 via the EKS console, eksctl, or the EKS APIs. Upstream 1.36 is receiving patch releases, and AWS has restated the EKS lifecycle: 14 months of standard support plus up to 12 months of extended support per minor version, totaling a 26-month supported window for each Kubernetes minor release.
Why that matters
Most teams treat a Kubernetes minor version like a six-to-nine-month sprint: upgrade quickly, rinse, repeat. A firm 26-month supported window changes the economics. With two full years of support, platform teams can stagger control-plane, CNI, and node-image upgrades, amortize testing across multiple release waves, and avoid the operational sprint that used to accompany each new minor release.
But there are two important caveats: extended support is a runway, not a feature-backport guarantee, and your surface area still includes node images, CNIs, CSI drivers, and etcd. EKS supporting upstream 1.36 reduces one kind of uncertainty — but doesn’t absolve teams from validating vendor and third-party component compatibility across that 26-month period.
What platform teams should do differently
- Treat the 26-month window as scheduling capital, not permission to defer. Use the extra time to automate upgrade testing (canary upgrades, gating by API compatibility and CRD behavior), not to avoid upgrades entirely.
- Pin and manage node images and lower-level components separately. EKS support doesn’t freeze your OS or CNI lifecycle; you still need to track image CVEs and CNI stability patches.
- Coordinate with upstream patch releases. Track upstream fixes and apply patches promptly when they affect your workloads.
This release also clarifies a practical compatibility concern: EKS Distro gives you the same Kubernetes build you can run outside managed EKS, which is useful for air-gapped or on-prem staging environments and helps align testing with production.
A couple of operational notes
- You can upgrade to 1.36 from the EKS console, eksctl, or the EKS APIs; plan your kubelet, CNI, and driver upgrades around the control-plane upgrade window.
- Don’t forget to test controller-manager and scheduler flags if you’ve diverged from defaults; small flag differences between minor releases can surface in scaled clusters.
Context and signals
AWS reiterating a 14+12 month policy is the right call. The alternative — leaving teams to chase short upstream timelines or stitch together ad-hoc backports — is what creates emergency upgrade churn and brittle patching practices. This policy turns part of Kubernetes lifecycle management into planning rather than crisis management.
That said, the ecosystem moves fast: tooling and CI images are migrating to 1.36 images. Use that alignment to run your upgrade rehearsals against the same node images you’ll see in CI, and automate pinning where necessary to avoid surprising patch skew.
Final take
A predictable 26-month window is overdue and welcome. It rewards teams that invest in automated, staged upgrade pipelines and punishes those that treat upgrades as tribal knowledge. Expect platform teams to shift from "panic upgrades" to planned, test-driven migrations — but only if you use the extra time to build the automation and tests that make longer lifecycles an operational win rather than a slow-motion failure mode.
Sources
- Amazon EKS and Amazon EKS Distro now supports Kubernetes version 1.36
- Amazon EKS and Amazon EKS Distro Now Support Kubernetes 1.36 (AWS Builder announcement)
- Understand the Kubernetes version lifecycle on Amazon EKS
- Review release notes for Kubernetes versions on standard support (Amazon EKS)
- Kubernetes 1.36 Release Details