Kubernetes Is Retiring Its Popular Ingress NGINX Controller

During last month's KubeCon North America in Atlanta, Kubernetes maintainers announced the upcoming retirement of Ingress NGINX. "Best-effort maintenance will continue until March 2026," noted the Kubernetes SIG Network and the Security Response Committee. "Afterward, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered." In a recent op-ed for The Register, Steven J. Vaughan-Nichols reflects on the decision and speculates about what might have prevented this outcome: Ingress NGINX, for those who don't know it, is an ingress controller in Kubernetes clusters that manages and routes external HTTP and HTTPS traffic to the cluster's internal services based on configurable Ingress rules. It acts as a reverse proxy, ensuring that requests from clients outside the cluster are forwarded to the correct backend services within the cluster according to path, domain, and TLS configuration. As such, it's vital for network traffic management and load balancing. You know, the important stuff.

Now this longstanding project, once celebrated for its flexibility and breadth of features, will soon be "abandonware." So what? After all, it won't be the first time a once-popular program shuffled off the stage. Off the top of my head, dBase, Lotus 1-2-3, and VisiCalc spring to my mind. What's different is that there are still thousands of Ingress NGINX controllers in use. Why is it being put down, then, if it's so popular? Well, there is a good reason. As Tabitha Sable, a staff engineer at Datadog who is also co-chair of the Kubernetes special interest group for security, pointed out: "Ingress NGINX has always struggled with insufficient or barely sufficient maintainership. For years, the project has had only one or two people doing development work, on their own time, after work hours, and on weekends. Last year, the Ingress NGINX maintainers announced their plans to wind down Ingress NGINX and develop a replacement controller together with the Gateway API community. Unfortunately, even that announcement failed to generate additional interest in helping maintain Ingress NGINX or develop InGate to replace it." [...]

The final nail in the coffin was when security company Wix found a killer Ingress NGINX security hole. How bad was it? Wix declared: "Exploiting this flaw allows an attacker to execute arbitrary code and access all cluster secrets across namespaces, which could lead to complete cluster takeover." [...] You see, the real problem isn't that Ingress NGINX has a major security problem. Heck, hardly a month goes by without another stop-the-presses Windows bug being uncovered. No, the real issue is that here we have yet another example of a mission-critical open source program no one pays to support...

Alternatives?

[AlanObject]

Currently I am using the nginx controller with microk8s, which uses it by default. Anyone care to run down the pros and cons of the other choices?

Re:

[sg_oneill]

Yeah I wanna know this too. This is pretty alarming.

Guess thats what happens when you trust a google project.....

Re:

[anyGould]

Wasn't the whole problem that this *wasn't* a Google project (or any business support at all)?

Re:

[Himmy32]

Was mostly one dude from Giant Swarm maintaining it with a some commits from Isovalent and Red Hat. All of this in duplication to the OSS version F5 already makes and fully supports (which you can of course upgrade to the commercial version for more features).

Re:Alternatives?

[MachineShedFred]

The bad news is that the Google-maintained ingress-nginx is being deprecated. It was a functional and sane default that didn't have all the bells-and-whistles, but just proxied traffic.

The good news is that because the ingress definition for your apps are just API objects, any other ingress is more-or-less completely compatible with your ingress object as long as they aren't going off the deep end with custom resource definitions and such. For example, you can use the F5 NGINX Ingress Controller [nginx.com], maintained by NGINX for something that would be basically 1:1 - you would just need to add an `ingressClass: nginx` (or whatever the proper value for your chosen ingress controller) field to the YAML that defines the ingress (it may already be there) to tell it to use the new controller.

Because you're using microk8s, it might be interesting to know that other readymade-k8s solutions like k3s default to using Traefik [traefik.io], which does allow for some more interesting routing options without the full complexity of a service mesh.

It's very likely that now that Google has officially shut this project, the next builds of things like microk8s will just swap out their default ingress controller and call it a day.

Re:

[sinkskinkshrieks]

Istio is built on Envoy.

Re:

[itiswhatitiwijgalt]

Istio is pretty nice. Is all mTLS from the gateway to the pods(depending on your configs). The virtualservices are easy to deal with and work with external-dns.

Re:

[brickhouse98]

Ingress is pretty defined. You could swap in most and be fine. Traefik and others have middleware/annotations that can do some special stuff if needed. Otherwise you can look at the Gateway spec and choose one of those. A bit more fully featured in terms of serving not only http(s) but also tcp, grpc, etc. Just a bit less fully featured when you look at what custom annotations some ingress solutions built-in (ie. ingress-nginx and others.) Just kind of depends on your use case. If you have no special needs

Re:

[Himmy32]

• If you aren't using any NGINX specific annotations on your Ingress objects, than basically any of the other providers that support Ingress objects are probably going to work just as well.

• If you are using annotations, than migrating over to the new Gateway API is going to make things less complicated and then yet again the providers that support that API are probably going to work just as well

• If you are just looking for the most popular implementation for small k8s, that's probably Traefik which is what k3s [k3s.io]

Re:

[ls671]

Just switch to apache which comes with reverse proxy capabilities out of the box. I am pretty sure you will find modules to do what you need since the eco-system is very large.

I have been using it for ages, 25+ years and I have always resisted going to proprietary solutions like nginx and the like. The common thing you will hear is that nginx is faster because it is event based but apache mod-event supports event-based as well and that's what I use on my reverse proxies and I don't believe nginx is really f

Re:

[ls671]

I wrote;

"I am pretty sure you will find modules to do what you need since the eco-system is very large."

This looks like it and it's hosted on apache.org thus making pretty shielded from proprietary solutions:
https://apisix.apache.org/?utm... [apache.org]
more details:
https://navendu.me/posts/hands... [navendu.me]

I often hear "apache does not do this" while in fact it does...

Re:

[ls671]

Hey!
https://slashdot.org/comments.... [slashdot.org]

Looks like what you need to me. What do you think?

Re:

[AlanObject]

I'll put it on the list. There is an update to the nginx ingress controller that patches this particular exploit, but this article should be considered a wake-up call.

Thanks for the reply.

Alternatives in the official k8s documentation

[Damnshock]

You can find them at third-party-ingress-controllers [kubernetes.io]

Sometimes you have to pay.

[sabbede]

You can't expect people to provide the software you need for your business for free. Yes, there is a lot of great free software available, but this demonstrates how overreliance on it is risky.

If this is such an important project to so many companies, the developers should take it commercial and start selling it, so they can afford to maintain it.

I like free things, but if you're a business you need to make sure you aren't being penny wise but pound foolish.

As a testament to how confusing this is...

[Junta]

Ingress NGINX controller is being retired.

A viable, maintained alternative is NGINX Ingress Controller.... Totally different project....

Hypocricy

[gr8_phk]

Kubernetes: Hey, someone who uses this thing please stand up and support them! Looks in mirror... oh...

Re:

[Himmy32]

Hey, someone who uses this thing please stand up and support them!

More like, "This old style is still supported by the maker and we've been trying to get people to use the new standard for years. There's multiple good options already. But if there's enough people in the community that want to use the old style that duplicates the free commercial offering, that's great take over. But it's not a good use of limited support resources."

Because Gateway interface supersedes Ingress

[laughingskeptic]

Isn't this because the recommendation for a while now has been move the to the Gateway spec? So use NGINX Gateway Fabric or another one of the options on this page https://gateway-api.sigs.k8s.i... [k8s.io] instead of NGINX Ingress Controller.

Re:

[Himmy32]

Absolutely is that. And anyone who still wants to use the old Ingress API with NGINX can just use F5's implementation. Paying to support a product based on the old API when the maker of the product already release that is a waste of resources.

But since it is a confusing topic, it makes it seem like "oh no they are getting rid of NGINX". Rather than the more nuanced take of:

• If you are doing special stuff with provider specific Ingress annotations that makes you dependent on a implementation, you should have