AWS just flipped the switch: Kubernetes 1.36 is now generally available on Amazon EKS and in Amazon EKS Distro, with images, release artifacts, and documentation rolled out across all commercial regions and GovCloud. This isn’t a quiet patch bump — it’s a timed lifecycle update that changes the calendar for teams still running older minors.
Kubernetes 1.36 on EKS is feature-complete enough to matter in production. Key upstream capabilities included in the 1.36 baseline — user namespaces, the MutatingAdmissionPolicy API, in-place pod-level vertical adjustments (akin to VPA behaviors), and improved resource health signals — are part of EKS's compatibility and testing matrix. Practically, platform teams can start testing user-scoped namespaces for stronger tenant isolation, pilot admission-controller flows using the newer admission APIs, and adopt pod-level vertical adjustments while validating node-image and add-on compatibility.
The operational emphasis AWS highlighted is lifecycle clarity and image availability, not just feature parity. EKS and EKS Distro images and release artifacts for the recent minor branches are available in Amazon ECR Public and the EKS Distro GitHub repositories; these artifacts include patched node images and updated add-on compatibility guidance. AWS also documented a clearer EKS Kubernetes version lifecycle: each minor release receives roughly 14 months of standard support followed by up to 12 months of extended support. For customers that means the supported window is explicit and shorter than what some teams have come to expect, so treat the extended window as temporary breathing room rather than a long-term escape hatch.
That sounds generous until you look at older minors: the new timeline makes several previously supported minors approach end-of-life on an operational timescale. If you’re still on 1.33 or older, this isn’t a “plan sometime this year” message — it’s a hard deadline for many teams. Upgrading across multiple minors on EKS is supported but nontrivial: perform sequential control-plane upgrades, align kubectl and add-on versions with the control-plane minor, refresh managed node group AMIs from the published images, and use Amazon EKS upgrade insights to triage workload issues. Remember AWS provides only a short rollback window for in-place control-plane rollbacks; it helps, but it’s not a substitute for proper canarying and node-image testing.
Two operational implications to be explicit about:
-
If you treat cluster images and add-ons as afterthoughts, the upgrade will fail. Managed node group AMIs and EKS add-on versions should match the target control-plane minor; consume EKS Distro images on a release cadence that your CI can validate.
-
Extended support is a temporary bridge, not a permanent solution. The 14 + up-to-12 months model buys breathing room, not forever. Teams that delayed upgrades to avoid lift-and-shift testing will face crunches once the extended window closes.
Opinion: this is the right call from AWS. Making the lifecycle explicit and publishing distro artifacts removes ambiguity that pushed teams into brittle, ad-hoc upgrading practices. It forces a sane cadence: pick an N-2 target, automate node-image refreshes, and treat add-on compatibility as part of CI. However, the timing of near-term EOLs will sting teams that deferred upgrades through 2025; expect emergency migration projects in short order.
If you’re the person still owning clusters on 1.33 or older, three immediate actions:
- Inventory: list clusters by minor version and node-image age. Don't rely on tags.
- Smoke plan: schedule a sequential control-plane upgrade path, align add-ons and kubectl, and prepare node group AMI replacements.
- Bake images: start consuming EKS Distro/ECR Public images in your CI, run node-conformance and workload smoke tests, and validate rollback behavior in a staging region.
Expect this cadence to become AWS’s default posture: explicit EOLs, public distro artifacts, and nudges to keep customers on reasonably recent minors. If you haven’t built automation that treats minor upgrades as routine maintenance, now is the time. The longer you delay, the more likely you are to end up with an unplanned migration under a hard deadline — and no one enjoys those.
Sources
- Amazon EKS and Amazon EKS Distro now support Kubernetes version 1.36
- Amazon Elastic Kubernetes Service – AWS News Blog (Compute category feed)
- Review release notes for Kubernetes versions on standard support in Amazon EKS
- Amazon EKS Kubernetes version lifecycle and end-of-life dates
- Update the Kubernetes version of your Amazon EKS cluster