Public Preview ETA*: March 2026

*ETA's are estimates and not commitments. Timelines may change.

Is your feature request related to a problem? Please describe. The Application Routing add-on currently supports ingress configuration through the Kubernetes Ingress API and an ingress controller implementation. As Kubernetes traffic management evolves, customers increasingly expect Gateway API support as the standard, extensible, and future-proof model for ingress and L7 routing. Without Gateway API support, Application Routing lags behind upstream Kubernetes direction and limits customers’ ability to adopt newer routing capabilities within the add-on.

Context: The upcoming retirement of the ingress-nginx controller increases the urgency of providing a modern, supported ingress model, but the core problem is the lack of Gateway API support in Application Routing.

Describe the solution you’d like Add native Gateway API support to the Application Routing add-on, allowing customers to configure ingress using Gateway, HTTPRoute, and related resources while retaining the simplicity and managed experience of the add-on. The feature should integrate cleanly with existing App Routing workflows and provide a long-term, supported path for ingress traffic management.

Describe alternatives you’ve considered Customers can use Application Gateway for Containers or the Istio Service Mesh add-on (Ingress API or Gateway API) to obtain Gateway API functionality today. These options are valid but introduce additional infrastructure, operational considerations, or architectural changes that are not necessary for customers who prefer the lightweight Application Routing model.

Additional context Gateway API is the successor to the Kubernetes Ingress API and is rapidly becoming the industry standard for ingress and L7 traffic management. Adding Gateway API support to Application Routing aligns AKS with upstream Kubernetes direction, simplifies customer adoption, and provides a supported evolution path as ingress technologies mature, including the eventual retirement of ingress-nginx.

what's the point when there is already direction for other options? https://blog.aks.azure.com/2025/11/13/ingress-nginx-update?utm_source=chatgpt.com#alternative-migration-paths

@majidaldo good question. There are two options listed in the blog and both have some other considerations but are viable paths if chosen but in short, if customers continue to need a simple to manage, lightweight ingress solution, app routing add on will continue to provide this capability.

1. Istio Service Mesh add on is a great solution for l7 traffic management but customers bay not need full service mesh capabilities yet.
2. App Gateway is another great option and comes with some more advanced features and integrates with a lot of scenarios. This approach is a little different architecturally with it being a cluster external solutions that customers need to consider before moving.

@majidaldo good question. There are two options listed in the blog and both have some other considerations but are viable paths if chosen but in short, if customers continue to need a simple to manage, lightweight ingress solution, app routing add on will continue to provide this capability.

1. Istio Service Mesh add on is a great solution for l7 traffic management but customers bay not need full service mesh capabilities yet.
2. App Gateway is another great option and comes with some more advanced features and integrates with a lot of scenarios. This approach is a little different architecturally with it being a cluster external solutions that customers need to consider before moving.

cost of 2 is approaching cost of vm! i didn't have to worry about this when using app routing.

Good and urgent topic. In the blogpost, it's stated that Application Routing with Gateway API is planned for H1 2026, which means that it should be there, but we don't have any ETA. We can also see that there is an undocumented Preview Feature, the name leads to it az feature list --namespace "Microsoft.ContainerService" --> AppRoutingIstioGatewayAPIPreview

This means that maybe there is a Private Preview out-there and that they will soon announce a Public Preview or maybe GA

Can MS folks shed more light on that topic ?

Using Istio-Full-Mesh is overkill for just an ingress endpoint exposition, using App gateway for containers means managing a service outside AKS, and an additional cost Thanks

@SamirFarhat in terms of timeline, please follow this issue to get updates https://github.com/Azure/AKS/issues/5515

The updated AKS baseline architecture diagram in the Microsoft documentation here shows Traefik being used as the ingress controller. Does this imply that Traefik is considered, and is expected to replace NGINX Ingress Controller in App routing add-on?

Traefik positioned ahead of alternative ingress solutions and has already gained wide community adoption and support.

The updated AKS baseline architecture diagram in the Microsoft documentation here shows Traefik being used as the ingress controller. Does this imply that Traefik is considered, and is expected to replace NGINX Ingress Controller in App routing add-on?

Not sure where your "updated" diagram coming from, but in 2024, it is already "Traefik":

Src: https://github.com/MicrosoftDocs/architecture-center/blob/a55b33e78f810f5121daf4e771d51941dd80a449/docs/reference-architectures/containers/aks/baseline-aks-content.md#network-topology

Src: https://github.com/MicrosoftDocs/architecture-center/blob/a55b33e78f810f5121daf4e771d51941dd80a449/docs/reference-architectures/containers/aks/baseline-aks-content.md#ingress-traffic-flow

And the "retirement" announcement is on Nov 11, 2025: https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/

So, when and where did you see this "updated AKS baseline architecture diagram"? @geowalrus4gh

---

Traefik positioned ahead of alternative ingress solutions and has already gained wide community adoption and support.

So far I remember, non-intergrated add-ons are not under support due to support policy (as it does not come with AKS). I do not remember traefik is being intergrated.

Apologies for the confusion earlier. I may have been referring to other references where NGINX is used as the ingress controller. For example, the following article on the AKS baseline architecture demonstrates an implementation using NGINX: https://techcommunity.microsoft.com/blog/appsonazureblog/azure-kubernetes-service-baseline---the-hard-way/4130496

Coming back to the core issue:

Our current production architecture follows the flow Internet → Application Gateway → Internal Load Balancer → NGINX Ingress → Application.

The Application Gateway in use is a centrally managed corporate gateway that routes traffic to multiple teams’ AKS clusters as well as to non-AKS services. We do not want to disrupt this setup, nor do we want to introduce additional cost or operational complexity by adding another gateway into the architecture.

Additionally, we do not prefer to introduce a service mesh into the existing deployment. Given these constraints, we would recommend a like-for-like replacement of the NGINX Ingress controller with a proxy-based ingress solution such as Traefik, rather than being required to adopt Istio or Application Gateway Ingress Controller (AGIC).

Apologies for the confusion earlier. I may have been referring to other references where NGINX is used as the ingress controller. For example, the following article on the AKS baseline architecture demonstrates an implementation using NGINX: https://techcommunity.microsoft.com/blog/appsonazureblog/azure-kubernetes-service-baseline---the-hard-way/4130496

Please check carefully: the article you are referring to never uses an Ingress Controller, so it is completely irrelevant.

The obvious evidence is:

No, it is not ingress controller. Nginx and Nginx ingress controller are not the same thing.

---

Coming back to the core issue:

Our current production architecture follows the flow Internet → Application Gateway → Internal Load Balancer → NGINX Ingress → Application.

The Application Gateway in use is a centrally managed corporate gateway that routes traffic to multiple teams’ AKS clusters as well as to non-AKS services. We do not want to disrupt this setup, nor do we want to introduce additional cost or operational complexity by adding another gateway into the architecture.

Additionally, we do not prefer to introduce a service mesh into the existing deployment. Given these constraints, we would recommend a like-for-like replacement of the NGINX Ingress controller with a proxy-based ingress solution such as Traefik, rather than being required to adopt Istio or Application Gateway Ingress Controller (AGIC).

Given that you used an Nginx example above and confused it with the NGINX Ingress Controller, I am now questioning whether your team is using Nginx or the Nginx Ingress Controller.

Besides that, you can totally use Nginx Fabric Gateway if you are not going to use any products other than Nginx-based products.

Meantime, be aware that App Routing is supported by Azure, but both the Nginx Ingress Controller and the Nginx Fabric Gateway Controller are out of support from Azure (as you install it on your own and Azure did not provide this). Using the Nginx Ingress Controller or the Nginx Fabric Gateway does not change this fact. If you get support when NOT using App Routing, it is only the Azure support enginner does not reject to do so.

I am not sure what you are into. If your team is using the Nginx Ingress Controller instead of App Routing, then go for it. The retirement does not mean that it will stop working.

If your team wants to focus on the new API, then proceed with the new one. Using the Gateway API does not mean you have to use a service mesh. It even includes a note below:

You should check out this page, it is telling how to migrating from Ingress to Gateway API: https://gateway-api.sigs.k8s.io/guides/getting-started/migrating-from-ingress-nginx/

Also, using AGIC does not mean you have to create a new Gateway, and there is a tutorial that explains this: https://learn.microsoft.com/en-us/azure/application-gateway/ingress-controller-install-existing

Your question does not involve service mesh or cost concerns. You are overthinking it. Try seeking advice from a CSA if you have no idea what are these. Your company should pay for it right? @geowalrus4gh

This issue is about the App Routing Gateway API integration progress report. The solution-seeking topic should not be discussed here.