Ingress-NGINX Is Retiring, and Kubernetes Already Has Favorites
For the better part of a decade, if you spun up a Kubernetes cluster and needed a way to get traffic into it, you reached for Ingress-NGINX. It wasn't an official default, but it may as well have been. So when maintainers announced that the project is heading into retirement in March 2026, the reaction across the community mixed nostalgia, annoyance, and a flood of "ok… so what replaces it?" threads.
What's interesting is that people weren't caught off guard. The shift away from Ingress-NGINX has been happening in the background for years, and the retirement just made the trend visible. Operators already have their favorites, and many were running them in production long before the announcement.
Traefik is everywhere, maybe more than anyone expected
If the conversation had a single dominant theme, it was how often Traefik came up. Operators love its straightforward setup, its clean integration with cert-manager and Let's Encrypt, and the way it straddles both Ingress and Gateway API without making you choose on day one. That dual-language model is a big deal, because it lets teams migrate gradually instead of rewriting dozens or even hundreds of manifests at once.
Traefik's new Ingress-NGINX compatibility layer doesn't hurt either. A drop-in path that doesn't require touching existing resources is exactly what tired platform teams want right now.
Some folks complained about the pricing of the enterprise edition, but most weren't using it at all. For most environments, the open-source version covers everything they need.
Envoy Gateway is having a moment
Envoy has long been the silent engine behind much of the cloud-native world, powering Istio, Contour, Cilium, and half the proxies you interact with without realizing it. Envoy Gateway takes that core and wraps it in a clean, modern controller built directly around Gateway API.
People like that it's fast to get running, doesn't require mesh complexity, and doesn't create surprise infrastructure. The project has a healthy contributor culture, and operators see it as a strong future-facing gateway with a lot of headroom. For teams that want something more modern than NGINX but lighter than a mesh, Envoy Gateway hits the sweet spot.
Cilium users are going all-in on Cilium Gateway API
Cilium shops tend to lean hard into consolidation. They already run Cilium as their CNI, eBPF engine, kube-proxy replacement and BGP implementation, and often as a security boundary too. When Cilium added Gateway API support, many teams saw a chance to reduce components rather than add new ones. The appeal is simple: fewer pods, fewer daemons, fewer layers, and one coherent data plane.
There are gaps. TCPRoute support isn't fully there yet, and operators miss the centralized HTTP logs they used to get from Ingress-NGINX, but most users seem confident those features will catch up. If your cluster already runs on Cilium, the pull toward its gateway is strong.
Istio keeps showing up, even for teams not using it as a mesh
Every time someone mentioned Istio, someone else replied with "but it's a whole service mesh." And yet many engineers run Istio purely for its ingress capabilities, with no sidecars and no full mesh, just the gateways.
Operators described setups with multiple gateways, some public and some private, with cert-manager and ExternalDNS handling the usual plumbing. It's stable and flexible, and it has a clear path to Gateway API without forcing mesh adoption.
Istio's reputation for being heavy doesn't match how people use it today. For some teams, it's simply a well-engineered, battle-tested gateway that happens to have mesh features they never turn on.
Contour is the low-key, reliable option that keeps coming up
Contour doesn't trend as loudly as the others, but it earned a steady stream of praise. It's built on Envoy, supports Gateway API, and has a reputation for being boring in exactly the way platform teams appreciate, with no drama, no surprises and no heroic debugging sessions. For operators who want something stable without a lot of magic, Contour is often the pick.
The HAProxy crowd is smaller but very loyal
HAProxy doesn't dominate the conversation, but the people running it are very confident in the choice. Some use the OpenShift router, which is HAProxy-based, while others run haproxytech's helm charts or are experimenting with the new HAProxy Unified Gateway that supports both Ingress and Gateway API. Its performance and transparency make it appealing, especially for teams who live and die by detailed logs.
A surprising number of people are still using nginx-ingress (the F5 one)
One of the most confusing parts of this shift is the naming collision. ingress-nginx is the community controller being retired, while nginx-ingress is the F5/NGINX Inc. controller, which is still actively maintained.
Plenty of operators plan to switch to the F5-maintained controller because it's the closest thing to "business as usual." If your entire cluster already speaks NGINX annotations, this path barely disrupts anything, and that familiarity matters more than anyone wants to admit.
Some teams are skipping ingress entirely and leaning on cloud-native paths
A smaller but notable slice of operators don't want another controller running in the cluster at all. Some route traffic through Cloudflare Tunnels, the AWS Load Balancer Controller, Azure Managed NGINX, or GCP load balancers. Others use ALBs with selective nginx rewrites, or Kong, Gloo or KGateway for API-heavy environments.
The reasoning is simple: if the cloud can handle the entrypoint for you, maybe you don't need to maintain a whole ingress layer anymore.
A real anxiety point: Gateway API adds workflow friction
With Ingress, everything was compact and friendly. Devs created one object, and cert-manager and ExternalDNS picked up the work with no extra coordination and no extra roles.
Gateway API splits responsibilities across multiple resources. Certificates live on Gateways, hostnames live on HTTPRoutes, and load balancers get created at different layers depending on the controller. Developers also lose the ability to own the full pipeline unless they're given permissions many platform teams don't want to hand out.
Several operators said they're sticking with Ingress because Gateway API complicates their workflows in ways that feel unnecessary, even though they have nothing against Gateway API itself. The hope is that HTTPRoutes eventually learn how to manage certificates, which would restore the simplicity people miss.
The final mood: a little sad, a little frustrated, but already moving forward
Ingress-NGINX shaped Kubernetes networking for years. It was the teaching tool, the default answer and the dependable workhorse. Plenty of people are sentimental about its retirement, and that makes sense, since it powered everything from homelabs to massive multicluster deployments.
The replacements are already in place, though. Traefik is becoming the pragmatic go-to, and Envoy Gateway is the forward-looking choice. Cilium is pushing toward an integrated network layer, Istio is carving out a simpler gateway role, and Contour and HAProxy remain steady and trusted. For some teams, cloud-native load balancers are replacing full-blown ingress controllers altogether.
The retirement didn't cause panic. It revealed where operators had already moved. Ingress-NGINX had a long, influential run. There is no single successor, just a set of strong alternatives that are already powering workloads today.