What replaces ingress-nginx, and should you move to Gateway API?

Ingress NGINX, the community Ingress controller from the Kubernetes project, was retired in March 2026 and receives no further releases, bug fixes or security patches. The Kubernetes project recommends Gateway API as the replacement. Teams that want to keep their Ingress resources can switch to another Ingress controller instead, because the Ingress API is frozen but not removed. None of the alternatives is a drop-in replacement, so either path needs planning and testing.

What happened to ingress-nginx

Kubernetes SIG Network and the Security Response Committee announced the retirement on 11 November 2025. Best-effort maintenance ran until March 2026. After that, the project stopped issuing releases, bug fixes and fixes for newly discovered vulnerabilities, and its GitHub repository is now archived as read-only.

The announcement gives two reasons. For years, one or two people maintained the project in their spare time. And features that once made it popular became security liabilities, such as the snippets annotations that inject arbitrary NGINX configuration. InGate, the planned successor, never matured and was retired too.

In a January 2026 statement, the Kubernetes Steering and Security Response Committees cited Datadog research that about half of cloud native environments relied on ingress-nginx. Existing deployments keep working and the Helm charts and images stay available, which is the risk: nothing breaks visibly, and a vulnerability found later stays unpatched. To check whether a cluster runs it:

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

The retirement covers the kubernetes/ingress-nginx project. The NGINX Ingress Controller from F5 is a separate product with its own maintainers.

Ingress compared with Gateway API

The Kubernetes Ingress documentation now states that the Ingress API is frozen: it stays generally available with no plans to remove it, but it gets no further changes. New routing features go into Gateway API.

How the Gateway API model works

Gateway API splits what an Ingress object does into separate resources with separate owners:

• GatewayClass names the controller that implements the Gateway, similar to an IngressClass. The implementation usually supplies it.
• Gateway defines listeners: addresses, ports, protocols and TLS certificates. The platform team owns it and decides which namespaces may attach routes.
• HTTPRoute defines hostnames, path and header matches, weights and backend Services. Application teams own their routes in their own namespaces and attach them to a Gateway.

This split lets a platform team run one shared entry point while application teams change routing without access to certificates or load balancer settings. The same route resources also configure service meshes through the GAMMA initiative, which is one reason to pick Gateway API over another Ingress controller. See what a service mesh is and when you need one.

Annotations are the hard part

Most ingress-nginx setups depend on annotations for rewrites, authentication, rate limits, CORS and custom NGINX snippets. Annotations do not carry over to any other controller. Some features map to standard Gateway API fields, some to implementation-specific policy resources, and some, such as raw NGINX snippets, have no equivalent and need a different design.

Inventory them before you choose a replacement:

kubectl get ingress --all-namespaces -o json \
  | jq -r '.items[].metadata.annotations // {} | keys[]' | sort | uniq -c

A migration path

1. Pick an implementation from the conformance list. The Gateway API implementations page lists which controllers pass the conformance tests for which version, and which extended features each supports. Match that against your annotation inventory rather than a ranking.
2. Translate the manifests. ingress2gateway, from Kubernetes SIG Network, reached 1.0 in March 2026. It reads Ingress resources with the ingress-nginx provider and prints Gateway API resources, with warnings for fields it cannot translate. It does not copy annotations and does not apply anything to the cluster, so review the output.
3. Move certificates. cert-manager creates certificates for Gateway listeners from the same cert-manager.io/cluster-issuer annotation, placed on the Gateway. Its Gateway API support must be turned on with the config.gatewayAPI.enabled Helm value, and HTTP-01 challenges use a gatewayHTTPRoute solver.
4. Run both side by side. The new Gateway gets its own load balancer address. Test it with curl --resolve, then move DNS one hostname at a time with a low TTL.
5. Remove ingress-nginx once its access logs show no traffic.

When staying on Ingress is reasonable

If you have a few simple host and path rules and no annotations, switching to another maintained Ingress controller is the smaller change. Several projects, including Cilium, Istio and Traefik, implement both Ingress and Gateway API, so you can replace the controller first and convert resources later. Clusters without a cloud load balancer also need an address for the new controller; see how LoadBalancer Services work on bare metal.

Gateway API on Cloudfleet

Cloudfleet Kubernetes Engine (CFKE) creates cloud load balancers for LoadBalancer Services, which is how a Gateway or Ingress controller receives traffic. You install and operate the Gateway API implementation or Ingress controller of your choice, as described in network security.