Ingress-nginx is end of life: migrate to Gateway API before November 2026

November 12, 2025. Kubernetes, through SIG Network and the Security Response Committee, announces the retirement of ingress-nginx. March 2026. Upstream maintenance stops and the repository goes read-only. November 2026. The last patch bridge, AKS Application Routing, expires. Why it matters: a frozen ingress controller sitting in your L7 data path will never receive another security fix — migrating to Gateway API becomes a dated project, not an option.

What actually stopped in March 2026

The retirement was announced on November 12, 2025 on the Kubernetes contributors’ blog, signed by Tabitha Sable on behalf of the security steering body. The wording is unambiguous: “best-effort” maintenance until March 2026, then no further releases, no bugfixes, no fixes for newly discovered vulnerabilities. The GitHub repositories go read-only, but existing artifacts — Helm charts and container images — remain available.

Read that “remain available” for what it is: a compatibility guarantee, not a lifeline. Your current deployment keeps running, but the next CVE found in this controller will have no official patch. The distinction is exactly the one between “the binary exists” and “someone maintains it.”

The timeline left no room. On March 24, 2026, the kubernetes/ingress-nginx repository officially hit EOL and was archived. A joint statement from the Steering Committee and the Security Response Committee on January 29, 2026 had already hardened the tone on security. Ingress itself, as a core Kubernetes API, is not being removed: the retirement covers only the kubernetes/ingress-nginx controller project, the reference implementation.

Why retirement instead of yet another patch

The decision has a specific origin: an accumulation of structural flaws. The trigger is called IngressNightmare — CVE-2025-1974, a CVSS 9.8 found by Wiz Research in March 2025. Unauthenticated remote code execution passed through the controller’s admission webhook; because ingress-nginx can read every Secret in the cluster by default, RCE became cluster takeover in one step. At the time, 43% of cloud environments were exposed and more than 6,500 clusters had the webhook reachable from the internet.

On February 2, 2026, four new HIGH flaws — CVE-2026-1580, CVE-2026-24512, CVE-2026-24513 and CVE-2026-24514 — were disclosed together, all in the same family: NGINX configuration injection through annotations or paths. The underlying problem is architectural. A decade of features accreted as annotations that inject raw NGINX configuration, like the configuration-snippet annotation. Every new annotation is therefore a potential injection primitive, and because the Ingress API is frozen — no new features ever — the bug class could not be fixed in place. Retirement is the remediation.

What Gateway API actually changes

Gateway API is not a syntax swap; it is a change of ownership model. Where Ingress packed three jobs into one object — the load-balancer plumbing, the routing rules, and a pile of controller-specific annotations — Gateway API splits them by role.

Concretely, three resources replace the single object. The GatewayClass, owned by the platform team, declares the controller. The Gateway, also platform-owned, is the reconciled infrastructure. The HTTPRoute, owned by the application team, carries the routing rules. In a multi-tenant fleet, this ends the scenario where one developer breaks everyone’s TLS with a misplaced annotation.

The deeper win is portability. An nginx.ingress.kubernetes.io/rewrite-target annotation means nothing to another controller; a typed URLRewrite filter does, for any conformant implementation. Version 1.4, released in October 2025, promoted two bricks that have become essential: BackendTLSPolicy to GA for gateway-to-backend TLS, and TLSRoute to GA for SNI-based TLS passthrough. Twenty or more conformant implementations already exist.

ingress2gateway 1.0: the mechanics, not the magic

The community tool ingress2gateway reached 1.0 on March 20, 2026, timed for this migration window. It mechanically converts Ingress objects to Gateway API, covering more than 30 annotations.

The promise is real but bounded. What converts cleanly is the core: host/path rules, URL rewriting, canaries by weight, TLS by Secret. What does not convert is precisely the risky part: configuration-snippet, server-snippet, auth-url/auth-signin, and exotic canary pairs. Those annotations have no automatic equivalent because they injected raw configuration — exactly the bug class that killed the project.

The rule is simple: the output of ingress2gateway is a starting point to review, not a deliverable. A conversion without human review moves the injection risk from annotation to mistyped route without removing it.

A four-phase migration with no flag day

Every serious guide converges on four phases, made possible by one simple fact: the old and new data planes can serve the same Services in parallel.

Phase 1 — Inventory your annotations. List every Ingress object and every annotation key in use. Most fleets discover that 80% of their Ingresses use the same five annotations — issuer, rewrite, CORS, proxy timeouts, backend protocol — and that the remaining 20% concentrates all the risk. The deliverable is a three-column spreadsheet: annotation, count, Gateway API equivalent. The rows without an equivalent are your real project plan.

Phase 2 — Convert mechanically, then review. Install the tool, convert, then re-read every transformed object.

go install github.com/kubernetes-sigs/ingress2gateway@latest
ingress2gateway print --input-file ingress.yaml

Phase 3 — Dual-serve. Deploy the Gateway and HTTPRoute objects alongside the existing Ingress, shifting traffic gradually — typically by canary or by host.

Phase 4 — Cut over and purge. Once traffic is confirmed on the new path, remove the old controller and the annotations it carried. This is the only phase that removes risk instead of moving it.

Choosing an implementation for a fleet you own

Once the decision to migrate is made, the controller choice remains, and it depends on what is already in place. The ground rule: if Istio is deployed, use its Gateway — no additional controller to operate. For a greenfield project, Envoy Gateway offers the best conformance and the extensibility of the Envoy data plane. For a minimal-change transition from ingress-nginx, NGINX Gateway Fabric is the most natural fit, since the team keeps the NGINX universe and part of its configuration instincts.

On EKS, the AWS Load Balancer controller brings native ALB/NLB and IAM integration. Traefik stays relevant for small-to-mid-size fleets that want Let’s Encrypt automation built in. The deciding criterion is rarely functionality — every implementation covers the common core — but the competence already present in the team: you migrate toward what you know how to operate, not toward whatever is newest.

Verdict

Ingress-nginx died in March 2026, and the last party with a name on the line — Microsoft, through the AKS critical-patch bridge — hands back its keys in November 2026.

If your fleet still runs behind ingress-nginx, start the annotation inventory this week: the spreadsheet is always smaller than the fear it inspires, and the configuration-snippet entries always weirder than you hope. If you operate in a regulated environment, know that EOL software in the L7 path already triggers automatic findings under SOC 2, PCI-DSS, ISO 27001 and HIPAA — the delay has become an audit risk, not just a technical one. And if you are starting a new cluster, go straight to Gateway API: the cost of not migrating is now higher than the cost of migrating.

References

• Kubernetes Contributors — Ingress NGINX Retirement: What You Need to Know, November 12, 2025
• Gateway API — Migrating from Ingress
• bex.co — Your Ingress-Nginx Has an Expiry Date: What Moving to Gateway API Actually Takes, September 10, 2026
• DEV Community — Ingress-NGINX Is Officially Retired: Complete Gateway API Migration Guide, March 2026