The End of kubernetes/ingress-nginx: Your March 2026 Migration Playbook

# The End of kubernetes/ingress-nginx: Your March 2026 Migration Playbook ## What started the discussion Hey everyone, sharing an article I wrote about the upcoming End-of-Life for the community-maintained kubernetes/ingress-nginx controller happening in March 2026. The post covers why this matters (no future CVE patches, compliance issues), how to run a quick audit to see if your clusters are affected, and a breakdown of the most viable migration options (like Traefik or Gateway API) based on different infrastructure setups. Happy to hear what controllers everyone else is migrating to. Happy to hear ideas on how to improve the guide. Wishing you all a great day, Kubernauts :) Nino ## What stood out in the comments ### Discussion point 1 Let's be honest lots of people never upgraded ingress-nginx after they got it running in initial testing, these organisations will just stick with it until the end. ### Discussion point 2 Bigger problem for my scenario is the lack of support in gateway spec for our multi tenant use case. Binding the definition at the gateway for the listeners and their certs means I would have to keep coming back and updating the Gateway with new tenants. I know there is work being done around a ListenerSet but I can't migrate until that with cert-manager is working. https://cert-manager.io/announcements/2025/11/26/ingress-nginx-eol-and-gateway-api/ https://gateway-api.sigs.k8s.io/geps/gep-1713/ ### Discussion point 3 FWIW, I've been using the pre-release version of cert-manager with XListenerSet support and it works fine. The 1.20 Release containing support is supposed to launch today unless it's delayed. https://cert-manager.io/announcements/2025/11/26/ingress-nginx-eol-and-gateway-api/ That said, I'm surprised Gateway API launched without ListenerSets which are necessary for nearly every customer I've ever had. ### Discussion point 4 We went through this exact migration dance last year when we moved off an older ingress controller. The part that killed us wasn't picking the replacement — it was the discovery phase. We had like 60-something namespaces across 8 clusters and no one knew which teams were actually using ingress-nginx vs other controllers vs raw LoadBalancers. Ended up writing a quick script to kubectl get ingress across everything and grep for the controller class, then cross-referenced with actual pod annotations. Took forever because we had to context-switch between clusters constantly. Found a bunch of shadow deployments no one remembered existed. If I did it again I'd automate that audit part way harder upfront. Running the same diagnostic commands across the entire fleet in parallel would've saved us like two weeks of discovery work. The actual migration was smooth once we knew what we were dealing with — Gateway API worked great for our use case btw, especially if you're already on a recent k8s version. ### Discussion point 5 Sounds like the real issue there is not enforcing use of CI like Argo / Flux? ## Thread snapshot - Original subreddit: r/kubernetes - Original author: u/neo123every1iskill - Reddit score: 69 - Comment count: 34 - Original thread: https://medium.com/@housemd/kubernetes-ingress-nginx-eol-march-2026-the-complete-migration-guide-to-replace-ingress-nginx-e8f6e118fb5f