Ingress-NGINX Is Retiring. The Kubernetes Crowd Already Has Favorites Lined Up.

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. The interesting thing is that people weren't caught off guard. The shift away from Ingress-NGINX has been happening quietly for years, and the retirement just made the trend visible. Operators already have their favorites, and many have been 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 frequently Traefik came up. Operators love its straightforward setup, 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 huge deal: it lets teams migrate gradually instead of rewriting dozens—or 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 the majority 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 the 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 wanting something more modern than NGINX but less heavy than a mesh, Envoy Gateway is hitting 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, BGP implementation, and often as a security boundary. When Cilium added Gateway API support, many teams saw it as an opportunity 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 is already powered by Cilium, the gravitational 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 inevitably replied with "but it's a whole service mesh." And yet many engineers run Istio purely for its ingress capabilities. No sidecars, no full mesh, just the gateways. Operators described setups with multiple gateways—some public, some private—with cert-manager and ExternalDNS handling the usual plumbing. It's stable, flexible, and 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 quiet, 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. No drama, no surprises, 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 incredibly confident in the choice. Some are using 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 entire shift is the naming collision between: - **ingress-nginx** (the community controller being retired) - **nginx-ingress** (the F5/NGINX Inc. controller, 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. 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 are routing through: - Cloudflare Tunnels - AWS Load Balancer Controller - Azure Managed NGINX - GCP load balancers - ALBs with selective nginx rewrites - Kong or Gloo or KGateway for API-heavy environments The pattern 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. No extra coordination. No extra roles. Gateway API splits responsibilities across multiple resources. Certificates live on Gateways. Hostnames live on HTTPRoutes. Load balancers get created at different layers depending on the controller. And developers 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 not because they dislike Gateway API, but because it makes their workflows more complicated in ways that feel unnecessary. 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, the quiet workhorse. Plenty of people are sentimental about its retirement, and that makes sense. It powered everything from homelabs to massive multicluster deployments. But the future is already here. - **Traefik** is becoming the pragmatic go-to. - **Envoy Gateway** is the forward-looking choice. - **Cilium** is pushing toward an integrated network layer. - **Istio** is carving out a simpler gateway role. - **Contour** and **HAProxy** remain steady and trusted. - And **cloud-native load balancers** are quietly replacing full-blown ingress controllers for some teams. The retirement didn't cause panic—it just revealed where operators had already shifted. Ingress-NGINX had a long, influential run. The next generation isn't a replacement so much as a landscape of strong alternatives already powering workloads today.