In March 2026 the kubernetes/ingress-nginx project was officially retired. Don't confuse it: this is not NGINX the web server, nor the commercial nginxinc/kubernetes-ingress from F5 — what shut down is the community controller that for years was the default ingress in most clusters. In practice it means one thing: no more new releases, no bug fixes, and — more critically — no closed vulnerabilities. Existing installs keep taking traffic, but it is now unsupported infrastructure sitting right on the cluster edge.
Why it's urgent: IngressNightmare and blast radius
This is not a "next quarter" task. The trigger for the retirement was IngressNightmare — CVE-2025-1974, scored CVSS 9.8. The controller's admission webhook allowed RCE through injection into the AdmissionReview, and the default permissions granted read access to every Secret in the cluster. The chain is obvious: a controller at the entry point that nobody patches anymore, plus a class of vulnerabilities that leak all secrets at once. The blast radius is not one service but the whole cluster. Every day on a retired controller is accepted risk that grows with each new CVE that will never be fixed.
Gateway API: a split of roles, not a new logo
There is no need to panic and rewrite everything overnight — but you cannot drag it out either. The target model is already mature: Gateway API stabilised in Kubernetes 1.35. And it is not "another Ingress with a different logo" but a different ownership model.
The old Ingress mixed infrastructure and application in a single object: TLS, controller annotations and business routing lived together, annotations did not port between controllers, and behaviour depended on the vendor. Gateway API splits the roles by owner:
GatewayClassandGateway— the entry point and infrastructure behaviour, owned by the platform team;HTTPRoute— the application's traffic rules, owned by the product team.
Canary is now set by the weight field in the route itself, not by an annotation of a specific controller, and the configuration is portable across implementations. That is the main win: you stop being a hostage of one annotation vendor.
How to migrate: audit, two piles, phased cutover
Migration starts with an audit, not an installation. Sort all your Ingress objects into two piles. The simple ones (TLS plus basic routing) move to Gateway + HTTPRoute almost mechanically. The complex ones — annotation-heavy cases with rewrites, canary and canonical domains — are candidates for a redesign under the Gateway API model rather than a straight port; they are what will eat most of the time.
Next comes a parallel install. Stand up the new controller alongside the old one and shift traffic through ingressClassName in stages: non-critical services first, then critical, and high-value last. Routes on the new controller should be verified under real traffic before you flip DNS, not after.
Which controller to pick
The choice of implementation depends on the platform: Envoy Gateway (CNCF, native Gateway API), Cilium Gateway (if Cilium is already your CNI — one control plane), AWS ALB / Lattice for EKS, plus Traefik or Contour/Kong. If time is short, a workable intermediate step is Traefik as a drop-in: its Middleware CRD replaces the "annotation zoo" with reusable objects (rate-limit, basic-auth, CORS, strip-prefix). But the strategic goal is Gateway API itself: it outlives a change of controller, unlike annotations.
Don't forget upgrade hygiene
The ingress-nginx retirement is a specific case of a more general disease: deprecated-API leaks during upgrades. Make the kubent and Pluto scanners a mandatory CI step before any cluster upgrade — then you will see the next "suddenly removed" component in advance, not in production.
"Works" ≠ "supported"
The deadline is already behind us. That moves the migration out of the "technical roadmap" category and into "risk management": "works" no longer equals "supported," and on the cluster edge that difference is measured in stolen secrets.