In November 2025 the Kubernetes project announced that the community Ingress NGINX controller would be retired. Best-effort maintenance continued until March 2026; after that, no further releases, bug fixes or security updates. Existing deployments keep running and the artefacts stay available1. In January 2026 the Steering and Security Response Committees put it more bluntly: staying on Ingress NGINX after retirement leaves you and your users vulnerable to attack2.
It is now October. If a cluster you are responsible for still runs it, the internet-facing entry point to your platform is a component nobody is patching. That makes this a risk item for the board as much as an engineering task.
What is and isn't changing
- Retired: the community
kubernetes/ingress-nginxcontroller. Commercial NGINX products from F5 are separate projects5. - Not removed: the Ingress API itself. Google's open source team notes it remains available with no immediate plans for removal, but it is feature-frozen3.
- Recommended: Gateway API, which the Kubernetes project calls the modern replacement for Ingress1.
So you have two legitimate paths: swap to another Ingress controller, or move to Gateway API. For anything you expect to run for more than a year or two, I recommend Gateway API. Swapping controllers still means translating annotations, so you pay most of the migration cost without the long-term benefit.
Why Gateway API is the better destination
Ingress put everything in one resource and pushed anything beyond host and path routing into controller-specific annotations. Gateway API splits responsibilities across roles: infrastructure providers define a GatewayClass, platform teams run Gateway listeners, and application teams attach HTTPRoute resources4.
That split matters in organisations. Application teams can change their own routes without touching shared listeners or certificates, and features like header matching, traffic splitting and cross-namespace references are part of the API rather than annotation conventions.
The playbook
- Find every instance. List clusters running the community controller, including forgotten ones in staging, CI and edge sites. Include Helm charts and vendor products that bundle it.
- Inventory annotations. Export every Ingress object and count the annotations in use. This is where the real effort lives; the WZ-IT migration write-up describes how most behaviour beyond simple routing was expressed through annotations5. Sort them into three buckets: covered by core Gateway API, covered by your chosen implementation's policies, and not supported.
- Pick an implementation. Choose a Gateway API implementation that covers your bucket-two needs, and check its conformance and support model. There is no drop-in replacement, as the Kubernetes statement says2, so this choice decides how much translation you do.
- Convert, then review by hand. Use a conversion tool such as ingress2gateway to generate a first draft of Gateway and HTTPRoute resources, then review each one. Generated configuration is a starting point, not a migration.
- Run both in parallel. Stand up the new Gateway alongside the old controller with its own load balancer, and test with real traffic patterns: TLS, redirects, timeouts, body sizes, WebSockets, rate limits.
- Shift traffic gradually. Move hostnames one at a time using DNS weighting or a front-end load balancer, with a tested rollback.
- Remove the old controller and its RBAC, webhooks and CRDs, and add a policy check so it can't come back through a chart dependency.
Budget most of the time for step 2. The YAML conversion is quick. Discovering that a critical service depends on an obscure annotation is what turns a two-week migration into a two-month one.
Where teams get caught out
| Area | What to check |
|---|---|
| Custom snippets | Configuration injected as raw NGINX snippets has no equivalent and needs redesign |
| Authentication | External auth annotations need an implementation-specific policy or a move into the application or a gateway layer |
| TLS | Certificate references, redirects and minimum TLS versions move to Gateway listeners |
| Observability | Access log formats and metrics change; update dashboards and alerts before cutover, using the approach in LLM observability with OpenTelemetry where relevant |
| Infrastructure as code | Update modules and pipelines, as in Terraform module design, so new services don't keep creating Ingress objects |
A note for AI platforms
If you serve models on Kubernetes, Gateway API is also where inference-aware routing is heading, with the Gateway API Inference Extension designed for model serving traffic6. Moving now puts your entry point on the same foundation, which pairs well with the GPU scheduling changes in Kubernetes DRA for GPUs.
How I can help
I plan and lead platform migrations like this one, from annotation inventory to staged cutover, and review Kubernetes estates for unsupported components as part of technical due diligence. Or analyse your challenge and bring the result to a call.
- 1Ingress NGINX Retirement: What You Need to KnowKubernetes blog · 11 Nov 2025
- 2Ingress NGINX: Statement from the Kubernetes Steering and Security Response CommitteesKubernetes blog · 29 Jan 2026
- 3The End of an Era: Transitioning Away from Ingress NGINXGoogle Open Source Blog · Feb 2026
- 4Gateway APIKubernetes documentation
- 5
- 6Introducing Gateway API Inference ExtensionKubernetes blog · 5 Jun 2025