After Ingress-NGINX: What Actually Replaces the Retired Controller
In March 2026 the controller that routed roughly half of Kubernetes traffic went dark for good. Here's what actually happened, what the official tooling does and doesn't solve, and what's genuinely still missing.
If you run workloads on Kubernetes, there is a good chance a piece of software you depend on every day quietly stopped being maintained this year, not because it failed, but because the small number of people keeping it alive, unpaid, ran out of runway. This is the honest version of that story, and of what to do next.
1. The retirement, plainly
On January 29, 2026, the Kubernetes Steering Committee and the Kubernetes Security Response Committee published a joint statement retiring ingress-nginx, the community-maintained Ingress controller. Active, best-effort maintenance continued only until March 2026. After that: no more releases, no bug fixes, no security patches, no CVE fixes, ever. The repository is now archived and read-only.
The committees were candid about why. In their own words, the project had been "maintained solely by one or two people working in their free time," on top of technical debt and design decisions that had made ongoing security maintenance genuinely untenable. This wasn't a product decision to sunset something obsolete. It was a maintainer-capacity problem that finally became impossible to keep absorbing quietly.
| ~50% | of cloud native environments run ingress-nginx, per Datadog research cited in the committees' own statement |
| 1–2 | volunteer maintainers keeping the project alive at the time of retirement |
| 0 | security patches issued for any future CVE, from March 2026 onward |
Three things are commonly conflated here, and it's worth being precise, because the confusion causes real harm:
- Retired: the community
kubernetes/ingress-nginxcontroller specifically. - Not retired: the Kubernetes
IngressAPI itself. It's still supported, just feature-frozen, meaning no new capabilities will be added to it going forward. - Not retired: F5/NGINX Inc.'s separate, commercially maintained
nginxinc/kubernetes-ingresscontroller, a different codebase that happens to share a name.
The committees' own recommendation is direct: begin migration planning immediately, toward Gateway API or another actively maintained controller, while candidly noting that "none of the available alternatives are direct drop-in replacements." Staying on ingress-nginx past retirement means running unpatched, internet-facing infrastructure indefinitely.
2. What Gateway API actually is
Gateway API is an official Kubernetes SIG-Network project, described by its maintainers as "the next generation of Kubernetes Ingress, Load Balancing, and Service Mesh APIs." It isn't a product you install. It's a specification, a set of resource types that any number of controllers (Envoy Gateway, Istio, Cilium, Kong, cloud-managed options, and others) can implement.
The old Ingress API had one resource type trying to do everything, and leaned hard on controller-specific annotations to do anything beyond basic path routing. Gateway API instead splits the problem along the lines of who actually owns each decision:
Infrastructure team owns→ GatewayClass → Gateway
Application team owns→ HTTPRoute / GRPCRoute / TCPRoute
GatewayClass names which controller implements traffic handling. Gateway is where traffic enters the cluster. Routes describe how it's sent to Services, with each layer editable by the team that should actually own it.
That split is the practical payoff: platform teams can run shared, centrally governed ingress infrastructure while individual application teams safely self-serve their own routing rules, without stepping on each other or needing annotations no one fully documents. Gateway API also makes things natively expressive that Ingress could only fake through vendor annotations, such as traffic weighting for canary releases, header-based matching, and typed backend protocols, as real, portable, spec-defined fields instead of magic strings a specific controller happens to interpret.
It is not a fringe or unproven spec. Gateway, GatewayClass, and HTTPRoute graduated to GA on October 31, 2023, meaning they carry the same backward-compatibility guarantees as any other stable Kubernetes API. Development hasn't slowed since: the project shipped v1.5 in early 2026, moving more experimental features to stable, with monthly releases of its experimental channel. It's the direction the ecosystem has converged on, not a bet on an unfinished idea.
The honest caveat is that Gateway API being GA doesn't hand you a running system. You still have to choose and operate a specific implementation, and every implementation covers a different slice of what your current ingress-nginx annotations actually do. That gap is the whole second half of this story.
3. ingress2gateway: the automated part
ingress2gateway is an official tool maintained under the Gateway API SIG-Network subproject, not a third-party script; it comes from the same community that owns the spec. It reads your existing Ingress resources and provider-specific CRDs, builds an intermediate representation, and emits the equivalent Gateway API YAML. It ships with translation support for nine providers, including ingress-nginx, nginx, kong, istio, cilium, and traefik.
It genuinely works, and it genuinely helps: it will correctly translate hosts, paths, and backend references, which is real, tedious, error-prone work you no longer have to do by hand. But the project is unusually clear-eyed about its own boundaries, and that's worth quoting directly:
"Ingress2gateway is not intended to copy annotations from Ingress to Gateway API."
(kubernetes-sigs/ingress2gateway project documentation)
The project goes further, warning plainly that "widely used provider-specific annotations and/or CRDs may still not be supported" even where translation logic exists at all. That's not a bug report. It's a stated, intentional scope boundary from the people who built the tool. They translate the routing skeleton: which hosts, which paths, which backend Services. They do not, and say they will not, translate the annotations layered on top of that skeleton.
4. Why the gap still matters
The routing skeleton is rarely where the risk lives, which is easy to lose sight of once "there's already a migration tool" becomes the whole story.
A real ingress-nginx deployment, the kind that's been in production for years, typically carries a dozen or more nginx.ingress.kubernetes.io/* annotations per Ingress: basic-auth policies, rate limits, rewrite rules with regex capture groups, session affinity, mTLS client-certificate verification, and often raw custom NGINX configuration snippets injected directly into the proxy. Those annotations aren't decoration; they are the production behavior, and they are exactly, explicitly, the part ingress2gateway does not translate.
Some of that behavior maps cleanly onto a Gateway API implementation's native features. Other parts need an implementation-specific extension policy that behaves differently from what you had, and a few, a hand-written NGINX snippet, say, have no equivalent anywhere and have to be rebuilt from scratch on a controller that may not even offer an escape hatch for it. Nothing in the translation step tells you which of those three buckets any given annotation falls into. You find out by reading the fine print yourself, or by shipping it and watching what breaks.
Even a perfectly correct translation doesn't answer the question that actually matters under a hard deadline: does the new stack behave the same as the old one, under your real traffic? That's not a question a static YAML-to-YAML converter can answer. It depends on how a specific target implementation actually implements the equivalent policy, if an equivalent exists at all, and the only way to know for certain is to compare real responses from both stacks side by side.
Knowing what won't translate, proving the replacement behaves the same, and moving traffic over without guessing: that's the gap Ingress Shift exists to close. It's a small, fully open-source (MIT-licensed) toolset, built as an early-stage project rather than a mature product with a customer roster to point to yet. It's three tools, meant to be used in this order:
| Tool | What it does |
|---|---|
| 01 · Analyzer (Annotation Coverage Analyzer) | A read-only kubectl plugin that checks every annotation actually in use in your cluster against a maintained, versioned knowledge base, and tells you honestly which ones translate directly, which need manual extension work, and which have no Gateway API equivalent at all. Before you migrate, not after something breaks. |
| 02 · Harness (Shadow & Diff Harness) | Mirrors real production traffic to the old and candidate stacks side by side and diffs the actual responses, producing a signed report. "It looks right" becomes provable parity data, instead of a translation you're trusting on faith. |
| 03 · Orchestrator (Cutover Orchestrator) | Once the parity data holds up, shifts traffic over in small staged steps, watching error rate and latency, with automatic rollback in seconds if anything regresses. |
The project is young: the analyzer has shipped its first tagged release, and the harness and orchestrator are open source and tested against real clusters but not yet independently released. The source is public, the license is MIT, and the annotation knowledge base is meant to keep improving with every real migration that uses it, not sit as a finished, closed artifact.
None of this replaces reading your own Ingress objects carefully or testing your own traffic patterns; it's aimed at a narrower problem, which is finding out in production, after cutover, that a rewrite rule silently changed behavior or a rate limit quietly disappeared. Given how the retirement happened, avoiding that seems worth the extra step.
Sources
- Kubernetes Steering & Security Response Committees, "Ingress NGINX: Statement from the Kubernetes Steering and Security Response Committees," kubernetes.io, January 29, 2026.
- Gateway API: Introduction, official documentation, kubernetes-sigs/gateway-api.
- Kubernetes Blog, "Gateway API v1.0: GA Release," October 31, 2023.
- Kubernetes Blog, "Gateway API v1.5: Moving features to Stable," 2026.
- kubernetes-sigs/ingress2gateway, project repository and documentation.
- dpuig/ingress-shift, project repository.