CNCF Retires the Ingress Nginx Controller for Kubernetes

Running the Ingress Nginx controller for your Kubernetes clusters? You have until March to migrate to the Gateway API, or some other option, the Cloud Native Computing Foundation decreed KubeCon+CloudNativeCon North America last week.

It was news that many knew was coming but were still surprised by, especially the quick turnaround asked of them.

“So you’ve got a lot of people scrambling around the conference today looking for a replacement, because Ingress is the default ingress controller for Kubernetes,” said HAProxy’s vice president of engineering and operations, Frank Mancina, in a booth interview with TNS at the event.

Kubernetes SIG Network and the Security Response Committee plan to put Ingress Nginx to rest in March 2026. After that, the software will not be supported: No further releases, no bugfixes, and no updates to resolve any security vulnerabilities.

The code will remain on GitHub for archival purposes, as well as supporting software such as the Helm operator.

Those who continue to operate the controller after March do so at their own risk.

Wondering if your cluster runs Ingress Nginx? At a command line with cluster administration rights, type this:

kubectl get pods \--all-namespaces \--selector app.kubernetes.io/name=ingress-nginx

Networking for Kubernetes

Networking support came late for Kubernetes. The CNCF had worked on the Gateway API for four years, releasing version 1 last year. The Gateway routes traffic on and off the cluster, both Layer 4 (the TCP/IP layer) and Layer 7 traffic (for application traffic).

The Ingress itself is a set of API rules to direct external network traffic accessing a cluster. The Ingress Nginx controller was born as a Kubernetes project. It used the open source Nginx reverse proxy, now managed by network company F5 Inc., as the base. The Ingress Nginx controller went on to be one of a number of controllers that popped up to implement the Ingress API.

The Kubernetes networking and security groups in charge of the project found it a challenge to maintain, however. Finding folks to help maintain the code base was a challenge, especially after the Gateway API project got underway. Plus, the ability to add arbitrary NGINX configuration directives, known as snippets, became a security issue.

Built on a set of Kubernetes Custom Resource Definitions (CRDs), the Gateway API was introduced in 2023, and it has since become CNCF’s preferred and future-proof way of doing ingress (inbound) and egress (outbound traffic) for Kubernetes.

“You have much more specification and control with Gateway API spec. That’s why people would probably migrate to it. And Kubernetes moves very, very quickly, and this seems to be the specification that’s gaining the most traction,” Mancina further explained.

Companies Respond

Reverse proxy software provider HAProxy Technologies LLC is one company responding to the Gateway API initiative. It has long offered HAProxy Ingress and has expanded its support for Gateway API with the newly-launched HAProxy Unified Gateway — a free, open source product providing Kubernetes-native application routing for both Gateway API and Ingress.

“What we’ve seen is that we have customers who have their workflow which is already established with Ingress rules, and they don’t want to change it,” HAProxy director of product Baptiste Assmann, in an interview with TNS.

The Unified Gateway is designed to provide a way to easily transition into the Gateway API as time permits. Or run both side-by-side.

“Instead of having one product for Ingress rules and one product for Gateway APIs and having people choose one or the other, the strategy is to have the new product also support Ingress rules, so people can start using Ingress rules and then switch to Gateway API when they are ready,” Assmann said.

Switching from one to another may take some work, he advised, because of their different architectures.

While Ingress runs on a central controller model, the Gateway API runs on the Kubernetes operator model. “It’s a totally different way to configure things,” he added.

The Gateway API has superior separation of concerns, further explained Mancina. For instance, it distinguishes between objects that can be controlled by the platform team, those that are controlled by the operations team, and those by the applications team.

HAProxy is also working, bringing over a select number of Nginx annotations over to the unified gateway.

Other platforms offering Gateway API support include the Nginx Gateway Fabric (read TNS analysis Janakiram MSV’s deep dive here) as well as Envoy, Istio, Cilium, and CNCF’s own KGateway.