Ingress NGINX Retirement: The Migration Most Teams Have Not Scheduled
The upstream Kubernetes project retired Ingress NGINX in March 2026. There will be no further releases for bug fixes or security patches. Clusters running it today continue to serve traffic, and that is precisely the trap — nothing breaks, so nothing gets prioritized, and an unpatched component stays in the request path indefinitely.
Why a drop-in swap does not exist
None of the alternatives are direct replacements. Annotation behavior, rewrite semantics, and TLS handling all differ, so a migration is an engineering project with a testing plan rather than a manifest edit.
Where to go
- Gateway API is the direction the ecosystem is moving, with a richer and more explicit model than Ingress. Best choice if you are willing to rewrite routing configuration once and be current for years.
- A vendor or third-party controller is faster to adopt and often closer to existing behavior, at the cost of a support relationship or a new operational surface.
How to sequence it
Inventory every annotation actually in use across your ingress resources first — most teams find they depend on far fewer than they expect, which makes the translation tractable. Run the new controller in parallel behind a separate hostname, shift a low-risk service, verify TLS and header behavior end to end, then move traffic service by service.
The work is unglamorous and entirely schedulable. The alternative is discovering the dependency during an incident.