If you run workloads on Azure Kubernetes Service, you may have recently received an email from Microsoft notifying you that support for NGINX Ingress on AKS is coming to an end. This post explains what is happening, why it is happening, and what it means for your specific situation.
Why This Is Happening: A Bit of Background
It’s vital to grasp what actually triggered Microsoft’s position first.
Bye Bye Ingress API
An Ingress resource is a Kubernetes configuration file that describes how external traffic should reach services inside a cluster. The spec was always intentionally minimal: just host and path rules. But cloud load balancers (from AWS, Azure, GCP and others) are capable of far more: timeouts, retries, authentication, canary routing, header manipulation. Since the Ingress spec couldn’t express any of this, vendors (the companies building the ingress controllers that power those load balancers) had to expose these capabilities through annotations, essentially freeform configuration bolted onto the side of the resource. Every vendor did it differently, and the result was a fragmented, unportable mess.
Gateway API is the community’s answer to this. It replaces Ingress with structured, typed resources that can express rich routing behaviour natively, with a clean separation between platform teams and application teams. It has been stable since Kubernetes 1.28 and is the direction the entire ecosystem is moving.
NGINX Ingress Controller Retired
With Ingress on its way out, it was only natural that ingress-nginx, the most widely deployed Ingress controller in the Kubernetes ecosystem, would follow. The project had been running on a handful of volunteers, accumulating technical debt and serious security vulnerabilities for years. In November 2025, the Kubernetes SIG Network and Security Response Committee made it official: maintenance ends in March 2026, after which there will be no releases, no bug fixes, and no security patches.
Microsoft had no real choice but to follow suit. They set their own end date of November 2026 to give AKS customers extra runway, and began investing in what comes next.
What Does This Mean For You
If your AKS clusters use NGINX Ingress today, whether self-managed or through the Application Routing add-on, migration is unavoidable.
If you self-installed ingress-nginx via Helm, you are directly exposed to the upstream retirement in March 2026. After that date, any new vulnerability discovered in NGINX Ingress will remain unpatched indefinitely. Running it in production becomes an increasing security liability.
If you use the AKS Application Routing add-on (the managed NGINX option enabled with --enable-app-routing), you have until November 2026. Microsoft will keep patching critical security issues until then. This buys time to plan, but is not a long-term solution.
If you are not using NGINX Ingress at all (for example, if you are already on Traefik, Istio, or another controller) this announcement does not directly affect you, though the broader shift toward Gateway API is worth keeping an eye on.
At Trailhead, we have already been engaged by multiple clients navigating exactly this transition. Whether you are assessing the scope of your migration, need help translating complex annotation configurations to Gateway API resources, or want a structured migration plan that minimizes production risk, we can help. Reach out to our team and we will get you moving in the right direction.
References:
