After the ingress-NGINX retirement, what your migration plan owes production
Maya Okonkwo
The status of the controller
As of March 2026, the Kubernetes SIG Network stopped maintaining ingress-nginx. That is the controller a lot of clusters have been running for years. A CNCF blog post published July 9 walks operators through the state of play. The headline for anyone still on it is short: unpatched CVEs, and no more feature work.
The post names two operational risks explicitly. New security issues will not receive upstream fixes. Feature updates and community support have stopped. If your ingress plane is a piece of infrastructure you have not touched in a while, this is the reason to pull it up in this quarter's planning doc.
What it means at 3am
An ingress controller sits between the internet and your services. When it drops a request, you find out from your users. When it takes a CVE and no one is patching, you find out from a scanner or from a report. Neither is a good discovery path.
The controller also carries the exact set of annotations, TLS defaults and rewrite rules your workloads rely on. Nothing about a retirement changes the version you have in production today, so the immediate blast radius is zero. The risk is on the calendar, not on the pager. That is the kind of risk teams reliably defer until a scanner flags an unpatched CVE.
The two paths CNCF lays out
The post frames the choice as a fork.
Path A is a lateral swap to another Ingress controller. The example named is Contour, described in the post as Envoy-based. This keeps you on the Ingress API and mostly moves the problem of who is patching.
Path B is modernization to the Gateway API, described in the post as the upstream-backed successor to Ingress. The CNCF post points at ingress2gateway to automate the translation, and recommends an incremental rollout: run the new plane in parallel and move non-critical workloads first.
The stopgap version is a mix. Adopt Contour to buy time on maintained code, then schedule the Gateway API move on your own calendar rather than under duress.
What to verify before the cutover
Ingress annotations do not port cleanly between controllers. The affinity, timeout and rewrite rules your services depend on are dialect, and each controller speaks its own. A migration that treats the manifests as one-to-one produces quiet regressions on the traffic paths that carry the most annotations, which is to say the paths that matter most.
A short list of things to check before you flip DNS or change the IngressClass:
- Health-check semantics. Idle timeouts and slow-start behavior vary across implementations.
- TLS behavior. Certificate reload, SNI handling and default cipher policies are all controller-specific.
- Rewrite and canonicalization rules. Trailing slashes and path prefixes are the classic source of a silent 404 after a swap.
Rollback path: keep the old controller running in the cluster on a different IngressClass until the new one has held a production week without a page. Cutover by class, not by cluster.
The wider shape
The specific news is the retirement. The shape is familiar. A workhorse project ends its maintenance window, and the community points at both a like-for-like replacement and a longer-term API. In this case the CNCF post treats the Gateway API as the destination and Contour as the shorter road to a maintained plane. The reasoning offered is straightforward: the Gateway API is the upstream-backed successor to Ingress, so anything you build against it should still be there when the next controller cycles out.
None of that changes if you do nothing this week. It changes when the next CVE lands on a controller no one is fixing.
Source: CNCF (cncf.io)