ingress-nginx Is Unpatched: A Gateway API Migration Checklist

ingress-nginx is no longer patched. The kubernetes/ingress-nginx repository was archived on March 24, 2026, after the Kubernetes project ended best-effort maintenance. Your existing controller keeps serving traffic, and the Helm charts and images are still downloadable, but there will be no more releases, bug fixes or security updates. The fix is a planned Gateway API migration, done in parallel and cut over by DNS.

That “it still works” part is the trap. Nothing breaks on the day support ends, so the migration slides down the backlog, until the next CVE in an internet-facing component that nobody will ever fix. Remember IngressNightmare (CVE-2025-1974) in March 2025: an unauthenticated remote code execution path through the admission webhook. The next one of those will not get a patch.

This post is the planning checklist. If you want the deep dive on proving parity before cutover, our sister site has a full test plan in Gateway API Migration: How to Test It Before You Cut Over.

What exactly was retired, and what was not?

Kubernetes SIG Network and the Security Response Committee announced in November 2025 that ingress-nginx would get best-effort maintenance until March 2026 and then be retired. A follow-up statement in January 2026 said the accumulated technical debt and design decisions that made security flaws worse meant it was “no longer reasonable or even possible” to keep maintaining it. The planned successor, InGate, never matured and was retired too.

Three things people get wrong:

• The Ingress API is not deprecated. networking.k8s.io/v1 Ingress is still core Kubernetes. One controller implementation retired.
• F5’s NGINX Ingress Controller is a different project. If you run nginxinc/kubernetes-ingress or NGINX Gateway Fabric, check F5’s own support policy. This post is about the community kubernetes/ingress-nginx.
• Managed add-ons have their own dates. On AKS, Microsoft supports critical security patches for the application routing add-on’s NGINX through November 2026. We cover that path in AKS App Routing NGINX Support Ends Nov 2026.

Step 1: How do you find every ingress-nginx install and what it really uses?

Most teams underestimate this step. Before choosing a replacement, you need a complete inventory:

1. Find the controllers. Search every cluster for the controller Deployment and for IngressClasses with controller: k8s.io/ingress-nginx. Include dev and staging, and any cluster where someone installed it via a Helm umbrella chart.
2. List every Ingress per class. Export namespace, hosts, paths, TLS secrets and annotations to a spreadsheet. This becomes your migration tracker.
3. Count annotations by key. Group by annotation name across all Ingresses. In most clusters a handful of keys cover 90% of usage, and a long tail of one-offs hides the hard cases.
4. Flag snippets. Any configuration-snippet, server-snippet or auth-snippet is raw NGINX config. These never translate automatically and are often the reason a team is “stuck” on ingress-nginx.
5. Read the controller ConfigMap. Global settings such as body size, timeouts, real IP handling, custom headers and log format live there, not on the Ingress objects.
6. Map what points at the load balancer IP. DNS records, CDN or WAF origins, firewall allow lists and partner integrations all need to move at cutover.

Step 2: How do ingress-nginx annotations map to Gateway API?

This is the table we start every migration with. “Standard” means a portable field in Gateway API’s Standard channel. “Implementation” means your controller’s own policy resource.

The bottom half of that table is what drives your controller choice. If you lean heavily on rate limiting and external auth, pick an implementation whose policy resources cover them well, and test those first.

Step 3: Which Gateway API controller should replace ingress-nginx?

There is no drop-in replacement, and the January 2026 statement from the Kubernetes committees says as much. Shortlist on these criteria rather than on popularity:

• Conformance for the features you use. Read the GatewayClass status.supportedFeatures (Standard since v1.4) on a test install, not the vendor’s feature page.
• Coverage of your bottom-half annotations. Rate limits, auth, body size and IP filtering.
• Who runs it. A cloud-managed implementation (for example the AKS application routing Gateway API implementation, or your cloud provider’s load balancer controller where it supports Gateway API) moves upgrades off your plate. Self-managed Envoy Gateway, Istio, Cilium, Traefik, Kong or NGINX Gateway Fabric gives you more control.
• What you already run. If you already operate a service mesh, using its gateway is often less new surface area. Our service mesh comparison covers that trade-off, and our NGINX Ingress vs Traefik post is useful if you want to stay on the Ingress API for now.

Step 4: How do you translate and validate the routes?

1. Run ingress2gateway. Version 1.0 (March 20, 2026) handles over 30 common ingress-nginx annotations and can emit implementation-specific resources for some controllers. Commit the output to a branch and review it like any other PR.
2. Resolve every warning. Each one is a behaviour that will silently change if you ignore it.
3. Split ownership. Platform owns the Gateway and listeners, app teams own HTTPRoutes in their namespaces. This role split is one of Gateway API’s real wins, so do not flatten it back into one big file.
4. Build a parity test. Replay real requests against old and new data planes and diff status codes, headers, redirects and rewrites. The kubernetes.qa test plan walks through this in detail.

Step 5: How do you cut over without downtime?

Run both controllers side by side, each with its own load balancer IP:

1. Lower DNS TTLs to 60 seconds and wait out the old TTL.
2. Deploy the new Gateway and routes while ingress-nginx keeps serving.
3. Probe the new IP directly with curl --resolve for every host and path, including TLS, WebSockets, gRPC and large uploads.
4. Move hosts in waves, lowest risk first. Update CDN origins, WAF and firewall allow lists in the same change.
5. Watch ingress-nginx traffic fall to zero, then keep it running for a rollback window before you delete it.

Rollback is a DNS change, as long as you have not deleted the old Ingress objects or controller.

The bottom line

ingress-nginx migration is not hard because of YAML. It is hard because of the long tail of annotations and snippets, and because the cutover touches DNS, CDNs and firewalls owned by other people. Inventory first, choose the controller based on your hardest annotations, translate with ingress2gateway, prove parity, then cut over by DNS in waves.

If your team does not have the cycles, our fixed-price Ingress to Gateway API migration covers inventory, controller selection, translation, parity testing and a staged cutover with rollback, scoped per cluster up front so there are no open-ended hours. And if you are on EKS, check your clusters against the EKS extended support calendar while you are in there. Book a migration scoping call.