With the broader move toward Gateway API, is anyone planning to continue maintaining ingress-nginx? It may not be perfect, but it still works well for many organizations, especially those running older clusters where it is deeply integrated and widely deployed. Replacing it can be a significant migration, so it seems unfortunate to abandon a tool that has not suddenly stopped working.
4 Answers
A lot of people see this as a good opportunity to move on. Ingress-nginx has accumulated security concerns, is not especially efficient at scale, and can be awkward when handling frequent configuration changes. Gateway API implementations may take more initial setup, but they provide a clearer path forward and support capabilities beyond the traditional Ingress model.
The main problem is usually maintainer capacity. Large open-source projects accumulate a huge backlog of issues, security work, and feature requests, but there may not be enough people or funding available to keep up. Without a committed group of maintainers and sponsors, simply wanting the project to continue is not enough.
There are still practical alternatives if the goal is simply to keep using nginx. Some teams are maintaining internal forks, mostly by updating the nginx or OpenResty components and applying their own performance fixes. The official nginx maintainers also provide supported open-source nginx products, so reviving this particular controller may not be the only option.
Gateway API is not the only replacement path, but it is worth considering. Tools such as Envoy Gateway can support the newer API, and the migration mainly involves learning the gateway setup plus HTTP and TLS route resources. It is more involved than the old Ingress format, but it handles traffic on ports beyond just 80 and 443 in a more structured way.
That was our experience too. We moved to Gateway API with Istio and ended up with better performance, more confidence during upgrades, and features that were difficult to implement with the old setup.