With ingress-nginx being phased out, has anyone seriously considered taking over its maintenance? The project is deeply embedded in many clusters, especially older production environments, and it still works for a lot of existing workloads. While Gateway API is clearly the direction Kubernetes is moving toward, migrating large, established deployments takes time and effort. Is there a community fork, commercial effort, or practical replacement that could provide a smoother transition?
4 Answers
There are still alternatives if you do not want to adopt Gateway API immediately. The commercially supported NGINX products and other maintained NGINX-based projects may be a better option than trying to resurrect an abandoned controller. Some organizations are also maintaining private forks, mainly to keep the NGINX or OpenResty components current and apply internal performance fixes.
A lot of people think moving on is the better choice. ingress-nginx has security and scalability concerns, handles dynamic configuration changes less gracefully, and is based on an older API model. Gateway API implementations such as Istio or Envoy Gateway require some migration work, but they offer better support for modern routing and traffic management.
The main problem is usually maintainer bandwidth. A widely used open-source project can accumulate a huge backlog of issues, security work, and feature requests without enough funding or people available to handle them. Unless an organization is willing to commit long-term engineering resources, simply reviving the repository probably would not solve much.
Gateway API is more involved than the old Ingress format, but it supports more expressive routing and traffic on ports beyond the usual HTTP and HTTPS pair. Envoy Gateway is another option, and the initial setup mostly comes down to learning how gateways, HTTP routes, and TLS routes fit together. For a new deployment, investing in that migration is probably more sustainable than rebuilding the old controller.
We had a similar experience. Moving to Gateway API with Istio improved performance and made zero-downtime updates easier, while also giving us capabilities we did not have with the old setup. The migration was work, but it forced us to choose a more deliberate long-term design.