Amazon EKS 1.36 Upgrade Guide: What Breaks and How to Prepare Before You Run It
Amazon EKS now supports Kubernetes 1.36, and for any business running production workloads on Kubernetes that one line in the AWS What’s New feed is the start of a clock. Cluster upgrades are the moment platform teams most often get caught out, because a version that looks like a routine bump quietly removes APIs, drivers and behaviours your manifests have depended on for years. Get the upgrade right and nobody notices. Get it wrong and you find out at the worst possible time, when a deploy fails or traffic stops flowing and the root cause is a feature that Kubernetes told everyone was going away three releases ago.
The short answer is this. Before you upgrade any EKS cluster to 1.36, audit your workloads for the things 1.36 actually removes or changes, then upgrade a non production cluster first. The headline removals and deprecations in 1.36 are the gitRepo volume driver, IPVS mode in kube-proxy, the Portworx in-tree storage driver, flex-volume support in kubeadm, the legacy AppArmor annotations, and the deprecation of Service externalIPs. On top of that, Ingress NGINX reached retirement in March 2026, so many clusters carry a controller that no longer receives fixes. If none of those touch your cluster, the upgrade is usually smooth. If even one of them does, you want to know now and not during the rollout. This EKS 1.36 Upgrade guide explains what breaks, what changes, and how to prepare your Amazon EKS clusters before upgrading to Kubernetes 1.36.
Why an EKS Version Number Is a Business Problem, Not Just an Engineering One
It is tempting to file Kubernetes upgrades under pure engineering housekeeping, but the impact lands on the business. AWS only supports a given EKS version for a fixed window of standard support, after which you move into extended support and start paying a premium per cluster hour to stay on the old version. A scale-up running several clusters can watch that cost add up quickly, and it is money spent on standing still rather than shipping. There is also a security dimension. Each Kubernetes release tightens defaults and closes holes, and 1.36 is squarely in that pattern, so a cluster left behind is a cluster accumulating known issues that attackers and auditors both care about.
The other reason this is a leadership concern is concentration of risk. Upgrades that are deferred do not get easier, they get harder, because version skew rules mean you cannot jump several minor versions at once. You have to walk the cluster up one release at a time, and every release you skipped is another set of removed APIs to handle in a single painful project. The teams that treat upgrades as a steady cadence spend an afternoon per release. The teams that treat them as something to avoid eventually spend a quarter on a migration nobody enjoys.
What Actually Changes in Kubernetes 1.36
The most operationally significant removal is the gitRepo volume driver. It has been deprecated since version 1.11 because it allowed code to run as root on a node, and in 1.36 it is gone for good. If any of your pods still mount a gitRepo volume, those pods will not schedule after the upgrade. The fix is to move that pattern to an init container that clones the repository into an emptyDir, but the important step is finding out whether you use it at all before the cluster changes underneath you.
IPVS mode in kube-proxy has also been removed after being deprecated in 1.35. Most EKS clusters run kube-proxy in iptables mode and are unaffected, but anyone who switched to IPVS for performance reasons on large services needs to plan that change, ideally toward eBPF based networking rather than back to iptables. Alongside this, the Portworx in-tree storage driver and flex-volume support in kubeadm are removed, and the legacy AppArmor annotations finally give way to the formal appArmorProfile field. Each of these is narrow, but narrow is exactly how upgrades bite. The problem is rarely the change everyone is talking about, it is the one obscure driver a single team adopted years ago.
Service externalIPs is the change to watch even though it is a deprecation rather than a full removal. The externalIPs field let unprivileged users claim arbitrary addresses, which has long been a man in the middle risk, and in 1.36 the relevant feature gate stops kube-proxy programming rules for those addresses. If you rely on externalIPs to expose anything, that traffic path can stop working. Full removal of the gate and the admission controller is expected around 1.46, so this is your early warning to migrate to a proper load balancer or ingress pattern while you still have a runway.
The New Features That Are Worth the Upgrade
It is not all removals. Kubernetes 1.36 promotes User Namespaces to general availability, which is a real security win because it maps the root user inside a container to an unprivileged user on the host. A container process that thinks it is root is now far less dangerous if it escapes, and for any business running untrusted or multi tenant workloads that is a meaningful reduction in blast radius. Turning it on is worth a deliberate look rather than leaving it as a footnote.
The other feature that earns its place is Mutating Admission Policies. These let you mutate resources as they are created using CEL expressions evaluated in the API server, with no webhook to deploy, secure, scale or keep alive. Plenty of platform teams run a mutating webhook just to inject a label, a sidecar config or a default setting, and every one of those webhooks is a piece of infrastructure that can fail and take admission with it. Moving that logic into a built in policy removes a moving part from the critical path, which is the kind of simplification that pays off every day rather than once.
Don’t Forget the Ingress NGINX Retirement
Separate from the version bump, but landing on the same clusters, is the retirement of Ingress NGINX in March 2026. A very large share of Kubernetes clusters route their inbound traffic through this controller, and a retired project means no more security patches or fixes. If your EKS ingress still runs on it, you are carrying an unmaintained component on the most exposed part of your stack, the bit that faces the public internet. Pairing the 1.36 upgrade with a migration to a supported ingress, whether that is the AWS Load Balancer Controller, a Gateway API implementation or another maintained controller, kills two risks with one project and saves you doing the cluster work twice.
What to Do About It
Start with discovery, because you cannot plan around what you have not found. Scan your manifests and running workloads for gitRepo volumes, IPVS configuration, Portworx and flex-volume usage, AppArmor annotations and any reliance on externalIPs, and note which clusters use Ingress NGINX. Tools that flag deprecated API usage against a target version make this far faster than reading YAML by hand, and AWS surfaces some of this in the upgrade insights for your clusters. Once you know your exposure, upgrade a development or staging cluster first, run your full deploy and smoke tests against it, and only then schedule production. Walk the version up one minor release at a time, check that your add-ons and controllers support 1.36 before you go, and keep the change inside a normal maintenance window with a rollback plan rather than treating it as a leap of faith. Done this way the upgrade is boring, and boring is exactly what you want from infrastructure.
If your team is stretched thin and an EKS upgrade keeps slipping down the backlog, or you are not sure what is hiding in your clusters, HAZERCLOUD can help. We run EKS upgrade assessments and managed Kubernetes operations for growing UK, US and European businesses, finding the deprecations that will bite, planning the rollout, and carrying the on call load so your engineers can keep building. Book a free consultation and cluster assessment at https://hazercloud.com/contact/ and we will tell you exactly what stands between you and a clean 1.36 upgrade.
