After ingress-nginx retirement, what your migration plan owes production

Kubernetes SIG Network has retired ingress-nginx, the controller many clusters have run for years. A CNCF post published July 9 confirms new CVEs will go unpatched and feature work has stopped. Production versions don't change overnight, so the risk sits on the calendar rather than the pager — exactly the kind of risk teams tend to defer until a scanner flags it.

CNCF lays out two paths: a lateral swap to Envoy-based Contour, which stays on the Ingress API and mainly shifts who patches the code, or modernization to the Gateway API, described as Ingress's upstream-backed successor. The ingress2gateway tool is recommended to automate translation, with an incremental rollout that moves non-critical workloads first. A middle path is adopting Contour to buy time, then scheduling the Gateway API move on your own terms.

The operational catch is that annotations don't port cleanly across controllers. Health-check semantics, TLS and SNI handling, and rewrite/trailing-slash rules are all controller-specific, so a naive migration risks quiet regressions on exactly the traffic paths carrying the most annotations. The suggested safety net: keep the old controller running under a different IngressClass and cut over by class, not by cluster, only after the new plane has survived a production week without an incident.