On this page
The Kubernetes project retired Ingress NGINX in March 2026 and archived the kubernetes/ingress-nginx repository, read-only, on 24 March 2026. Clusters that still run it keep working, but there are no more releases, bug fixes or security updates. The job is to find every instance, list what your Ingress resources use, pick a destination and move hostnames one at a time beside the old controller.
This is about the community controller, not NGINX itself. NGINX open source, NGINX Plus and F5's NGINX Ingress Controller are separate products and are not part of the retirement. A reverse proxy on a virtual machine needs none of this. AceMQ's NGINX services page covers both the web tier and this migration, and managed Kubernetes covers running the clusters.
The announcement is months old, so the realistic reader found out late. The Kubernetes Steering and Security Response Committees warned in January 2026 that you may not know you are affected unless you check, and that no alternative is a direct drop-in replacement. They also cited Datadog research that about half of cloud native environments relied on the controller.
Step 1: Find every instance
Run the check the Kubernetes project publishes (it works in most cases), with cluster administrator permissions, in every cluster you own:
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginxThe retirement post notes the controller shipped as part of many hosted Kubernetes platforms, so check clusters you did not install it in, and clusters nobody owns any more. Helm charts and container images remain available, but the repository README tells anyone not already using it not to deploy it.
Step 2: List what your Ingress resources use
Effort is set by annotations, not by the number of Ingress objects. For each one, record the annotations (rewrites, authentication, rate limits, canary rules, CORS, backend protocol), any snippet annotations, the global ConfigMap settings, the TLS secrets and the team that owns the hostname. The retirement post names snippet annotations, which allow arbitrary NGINX directives, as flexibility that became technical debt and a security risk, so they get their own list.
| Ingress-NGINX behavior | Where it goes |
|---|---|
| TLS redirects, header changes, traffic splitting, matching on header, query or method | Standard fields in HTTPRoute |
| Authentication, connection timeouts, health checks | Implementation-specific extensions or policies, per the Gateway API guide |
| Snippets and custom directives | Not part of Gateway API, whose extension points are extensionRef, implementation-specific types and policies, not annotations. F5's controller maps them to snippet annotations, and four Ingress-NGINX annotations (limit-connections, limit-rate, limit-rate-after, limit-whitelist) still need snippets there |
| Default backend | No direct equivalent. You define a catch-all rule |
| Canary by header, cookie and weight | Ingress-NGINX evaluates them in that order, and F5's guide says migrated manifests must keep the same order |
Gateway API is a different model, not a renamed Ingress. Listeners and TLS belong to a Gateway owned by the cluster operator, routes belong to application teams, and annotations are not an extension point.
Step 3: Choose a destination
- A Gateway API implementation. This is the Kubernetes project's recommendation. The Gateway API site lists conformant implementations including NGINX Gateway Fabric, Envoy Gateway, Istio, Cilium and Traefik. Its migration guide suggests weighing conformance reports, the proxy underneath and what your cloud or CNI already offers. If you run a mesh already, see Istio support and upgrades.
- F5's NGINX Ingress Controller. It keeps the Ingress API. Annotations change prefix from nginx.ingress.kubernetes.io to nginx.org on the Ingress path, and many ConfigMap keys are renamed. F5 publishes a guide for replacing an Ingress-NGINX cluster with it.
- Another Ingress controller from the list of Ingress controllers in the Kubernetes documentation, if it already serves part of your estate. Ask who maintains it, since a thin maintainer base is what ended this one.
Step 4: Run beside it, then move hostnames
Install the replacement next to Ingress NGINX with its own external address, so you can test without touching production. Convert resources with ingress2gateway as a starting point: version 1.0 reads ingress-nginx resources and emits standard Gateway API resources. It reports what it could not translate, it is not intended to copy annotations, and its README warns that widely used annotations may still be unsupported. The Gateway API guide says to test and verify every conversion.
Then move hostnames one at a time through DNS or the upstream load balancer, watching error rates and latency at each step. Keep Ingress NGINX until its traffic is gone, and remove it afterwards.
Where AceMQ fits
AceMQ turns the four steps into an inventory, a written destination recommendation, a parallel run and a cutover, delivered with partner NGINX specialists, followed by 24/7 NGINX support if you want it. A typical engagement is described in Ingress NGINX to Gateway API migration assessment. AceMQ does not patch or backport the retired controller; while you migrate, the inventory shows which hostnames and annotations still depend on it.
Sources
- Ingress NGINX Retirement: What You Need to Know, kubernetes.io, 11 November 2025.
- Ingress NGINX: Statement from the Kubernetes Steering and Security Response Committees, kubernetes.io, 29 January 2026.
- kubernetes/ingress-nginx repository, archived by the owner on 24 March 2026.
- Gateway API guides and ingress2gateway README, read 4 November 2026.
- F5 guide to migrating from Ingress-NGINX to NGINX Ingress Controller, read 4 November 2026.
Frequently Asked Questions
Is Ingress NGINX the same as NGINX?
No. Ingress NGINX is the community Kubernetes ingress controller in the kubernetes/ingress-nginx repository, which was retired and archived on 24 March 2026. NGINX open source, NGINX Plus and F5's NGINX Ingress Controller are separate products and are not affected by that retirement.
Will my cluster stop working because of the retirement?
No. The Kubernetes project says existing deployments keep functioning and the Helm charts and images remain available. What stops is maintenance: no releases, no bug fixes and no security updates for newly found vulnerabilities.
Is there a tool that converts Ingress to Gateway API?
ingress2gateway, a Kubernetes SIG Network project, converts Ingress resources, including ingress-nginx ones, to Gateway API resources. It reports what it cannot translate and is meant as a starting point, so every converted route still needs testing.
Author
Talk to an engineer
Need a hand with NGINX?
Senior engineers who run it in production. Get a quote or a free consultation, no sales pitch.
Guides, comparisons and research
Go deeper on support and version lifecycles
Comparisons
9- PostgreSQL vs MySQL: Where They Differ and How to Choose
- OpenSearch vs Elasticsearch: How the Fork Has Diverged
- Enterprise Support Compared 2026: Databricks, Snowflake, MuleSoft, Boomi, Datadog and Splunk
- Kong Alternatives and Competitors Compared
- Splunk Alternatives and Replacements Compared
- MuleSoft Alternatives and Competitors Compared
