A platform team running a mid-size EKS fleet out of Pune opened a routine dependency audit in early 2026 and found their ingress controller — the thing routing every external request into every cluster they operate — had quietly become unmaintained infrastructure. Not deprecated-with-a-warning. Actually retired: no releases, no CVE fixes, repository archived. That's the situation roughly half of internet-facing Kubernetes clusters were in as of March 2026, when the community-maintained ingress-nginx project reached end-of-life.
This piece isn't really "Nginx vs Traefik vs Gateway API" as three permanent competing options. It's "what do you migrate to, and do you migrate to a controller or to a new API model" — because those are two different decisions bundled into one deadline.
This trips up almost every team doing this migration, so it's worth being explicit before anything else:
[Ingress](/glossary/ingress)-NGINX (kubernetes/ingress-nginx)
NGINX Ingress Controller (nginxinc/kubernetes-ingress)
Kubernetes Ingress API
If you're planning a migration, the first step is confirming which of these you're actually running — "ingress-nginx" in a values.yaml or Helm chart name almost always means the retired community project.
This wasn't a funding decision or a corporate pivot. The Kubernetes Steering and Security Response Committees stated plainly that fundamental architectural limitations render long-term maintenance impossible, after years of public warnings that the project lacked enough contributors and maintainers to sustain it. The annotation-based configuration model that made ingress-nginx flexible also made it hard to secure — a large share of its historical CVEs traced back to annotation injection, and the underlying reload-based architecture doesn't propagate config changes without a proxy restart, which doesn't hold up well against Kubernetes-native expectations of near-instant reconciliation.
The committees' own language was unusually direct for a Kubernetes SIG announcement: continuing to run the retired controller after end-of-life leaves you and your users vulnerable to attack, and no available alternative is a direct drop-in replacement — meaning this migration requires actual engineering time, not a Helm chart swap.
Path 1: Swap to Traefik (Ingress-compatible, buy time).
Traefik is a Kubernetes-native reverse proxy that watches the API server directly and updates routing in real time rather than reloading a config file, which sidesteps ingress-nginx's core architectural weakness. It supports both the standard Ingress resource and its own IngressRoute CRD, plus Gateway API, so it works as a like-for-like Ingress replacement today while giving you a path to Gateway API later without another controller migration.
Path 2: Go straight to Gateway API with a Gateway-API-native controller (Envoy Gateway, Istio Ambient, Cilium, Kong). These skip the Ingress compatibility layer and route through Gateway API resources (Gateway, HTTPRoute, GRPCRoute) from day one. Update latency — how fast a new route becomes live after you push it — varies meaningfully across these: Istio and Kong propagate route changes in milliseconds, while NGINX Gateway Fabric and Traefik can take seconds, which matters if you're doing high-frequency deploys through CI/CD.
Path 3: Stay on a vendor-supported NGINX fork temporarily. SUSE, for instance, is extending support for NGINX-based ingress under Rancher Prime beyond the community EOL date specifically to give Rancher/RKE2 customers breathing room, with Traefik as their recommended eventual target. This buys planning time but isn't a permanent answer — it's explicitly a bridge.
Migration urgency and effort:
| Factor |
Traefik (Ingress mode) |
Gateway-API-native (Envoy Gateway/Istio/Kong) |
| Effort to migrate from ingress-nginx |
Lower — similar mental model, drop-in annotations differ |
Higher — new resource model (Gateway/HTTPRoute) |
| Update latency (route propagation) |
Seconds |
Milliseconds (Istio, Kong) to seconds (Envoy Gateway varies) |
| Best fit |
Teams needing to hit the EOL deadline fast |
Teams already investing in service mesh or standardization |
Operational shape:
| Factor |
Traefik |
Istio Ambient (Gateway API) |
| Adds a service mesh? |
No — pure ingress/edge proxy |
Yes — covers east-west traffic too |
| Config model |
Kubernetes CRDs / Docker labels, dynamic |
Gateway API CRDs, GA standard |
| Licensing |
Open source core, Traefik Hub for API management |
Open source (CNCF graduated) |
If you're up against the March 2026 deadline with limited migration bandwidth, moving to Traefik in Ingress-compatible mode is the pragmatic first step — it removes the unpatched-software risk immediately, keeps your existing Ingress manifests mostly intact, and doesn't foreclose a later Gateway API migration since Traefik supports both models natively.
If you were already planning to standardize on Gateway API or invest in a service mesh, treat this retirement as the forcing function to do that migration now rather than twice — go straight to Envoy Gateway (if you want ingress without mesh complexity) or Istio Ambient (if east-west traffic security is also on your roadmap), since routing everything through Gateway API resources from the start avoids a second migration in twelve months.
Whichever path you choose, budget real engineering time for it. The Kubernetes Security Response Committee's own statement was explicit that none of the alternatives are drop-in replacements — annotation behavior, TLS handling, and rate-limiting semantics all differ enough between controllers that a lift-and-shift migration without testing is how outages happen, not how they get avoided.
INFORMATIONReferences and Further Reading
Discussion0