On March 24, 2026, the kubernetes/ingress-nginx repository went read-only. No more patches. No more CVE fixes. No more releases of any kind.
Half the Kubernetes clusters running in production today were routing traffic through it.
The coverage that followed was immediate and mostly unhelpful — migration guides, controller comparisons, annotation checklists. All of it assumes you've already made the architectural decision. Most teams haven't. They're still looking at four realistic paths, each with a different cost structure and a different failure identity.
We just watched this play out with VMware. Forced change exposes architectural assumptions most teams didn't know they had. The teams that fared worst weren't the ones who moved slowly — they were the ones who picked a direction before they understood how their choice would fail.
That's what this post is about. Not which path to pick. How each path breaks.
The Annotation Complexity Trap Comes First
Before the four paths — one diagnostic question that determines how hard any of this is.
Open your ingress manifests and count the annotations. Not the objects. The annotations per object.
Teams running five or fewer annotations per ingress resource have a straightforward migration surface. Teams running twenty, thirty, or more — with nginx.ingress.kubernetes.io/configuration-snippet blocks doing custom Lua and rewrite-target gymnastics accumulated over three years — are looking at a completely different problem.
Those annotation interactions don't disappear when you swap the controller. They surface differently, in different layers, at the worst possible moment.
Audit your annotation surface first. That number shapes which path is realistic for your environment.
The Four Paths
Path 01 — Stay with NGINX (Fork or Vendor)
Run F5 NGINX Ingress Controller or a vendor-extended fork. Familiar annotation surface, maintained upstream. AKS Application Routing extends support to November 2026.
Breaks when: Security and patching burden shifts entirely to you or your vendor's timeline. You're now dependent on a commercial relationship for what was a community control plane.
Path 02 — Move to Another Ingress Controller
Traefik, HAProxy Unified Gateway, or Kong. Drop-in replacement model — controller changes, Ingress resource spec stays. Fastest migration path for low-annotation environments.
Breaks when: Annotation and behavior translation is imperfect. Rewrite-target logic, custom snippets, and auth annotations behave differently across controllers. Drift surfaces under load, not during testing.
Path 03 — Adopt Gateway API
Migrate to the Kubernetes-native successor. Role-based resource separation — platform team owns the Gateway, application teams own HTTPRoutes. ingress2gateway 1.0 now supports 30+ annotations.
Breaks when: Ecosystem and tooling maturity isn't there yet for your stack. Admission controllers, policy frameworks, and observability tooling still assume Ingress as baseline in many enterprise environments.
Path 04 — Exit the Ingress Layer Entirely
Route north-south traffic through a service mesh, cloud-native load balancer, or API gateway. Istio ambient, Cilium eBPF, or a managed cloud LB replaces the ingress controller entirely.
Breaks when: You lose Kubernetes-native routing control. Cloud LB lock-in, mesh operational overhead, and the loss of cluster-native policy enforcement create new complexity in exchange for the old.
Decision Table
| Path | Control | Complexity | Risk Profile | Breaks When |
|---|---|---|---|---|
| Stay with NGINX (vendor) | High | Low | Vendor dependency | Patching timeline slips or contract ends |
| New Ingress controller | Medium-High | Medium | Annotation drift | Behavior gaps surface under production load |
| Gateway API | High | High short-term | Tooling maturity | Adjacent stack isn't Gateway API-ready yet |
| Exit ingress layer | Low-Medium | High | Operational model shift | Kubernetes-native control requirements return |
The Security and Compliance Reality
CVE exposure from running unpatched ingress infrastructure is not theoretical. IngressNightmare — an unauthenticated RCE via exposed admission webhooks — hit in early 2025. Four additional HIGH-severity CVEs dropped simultaneously in February 2026. With the repository now archived, the next one stays open indefinitely.
For teams operating under SOC 2, PCI-DSS, ISO 27001, or HIPAA: EOL software in the L7 data path is an automatic audit finding. Compliance teams are already blocking production promotions in some organizations.
Architect's Verdict
Pick your path based on how it fails — not how it's marketed. Every option here works in a demo. Each one has a specific production failure signature, and that failure signature is what should drive the decision.
Path 1 buys time with known behavior. Path 2 is fast if your annotation surface is clean. Path 3 is the right destination for most teams, arrived at on the right timeline. Path 4 makes sense if the mesh investment is already on the roadmap.
The teams that will execute this well aren't the ones who move fastest. They're the ones who audit their annotation complexity first, map their 24-month control plane model, and select the path whose failure mode they can manage — not the one that looks cleanest in a migration guide.
This is Part 0 of the Kubernetes Ingress Architecture Series. Part 1 covers the Kubernetes-native paths: Gateway API and the controller decision in depth.
Full post with decision framework, additional resources, and FAQ: rack2cloud.com
Top comments (0)