What is Application Routing with Gateway API?
Azure Kubernetes Service now supports the Kubernetes Gateway API natively for ingress traffic management, and it’s generally available. This isn’t just another ingress controller option. The Gateway API is a different approach to routing altogether, and the AKS implementation comes with Azure DNS and Key Vault TLS integration baked in.
The Kubernetes Gateway API replaces the older Ingress API with a role-oriented resource model. Instead of cramming everything into a single Ingress resource that a cluster operator owns, Gateway API splits responsibility across three resource types: Gateway (infrastructure provider), HTTPRoute (service owner), and ReferenceGrant (cross-namespace permission). This separation matters for teams that need to let different groups manage their own routing rules without stepping on each other.
Why this matters for AKS users
The AKS Application Routing add-on has been around for a while as an ingress controller solution. What changes with Gateway API support is that you get the same add-on but with Gateway API CRDs instead of the traditional Ingress resource. The deployment uses an Istio control plane under the hood but presents a meshless architecture meaning you get the traffic management benefits without the complexity of a full service mesh.
If you have been maintaining custom Ingress-NGINX configurations or writing your own routing logic, this is worth a look. The Gateway API approach means your routing rules are defined in Kubernetes-native CRDs that tools like cert-manager and external-dns already understand. No more fumbling with annotation strings or hoping your ingress template renders correctly.
Key capabilities at GA
The GA release includes several features that make it production-ready:
- Azure DNS integration for automatic DNS record management
- Key Vault TLS termination with auto-rotation of certificates
- HPA and PodDisruptionBudget support for stable Gateway deployments
- Built-in access logging for traffic analysis
- Support for traffic splitting, header-based routing, and weighted routing
The DNS integration is genuinely useful. When you create a Gateway resource with an Azure DNS zone configured, the add-on automatically creates and manages DNS records. Similarly, TLS certificates stored in Key Vault get automatically pulled and rotated without manual intervention. These are the kind of integrations that make AKS feel like a managed platform rather than just a Kubernetes cluster you happen to run in Azure.
Migration from Ingress-NGINX
If you are already running Ingress-NGINX on AKS, the migration path is straightforward. The Application Routing add-on supports both the Ingress API and Gateway API simultaneously during the transition period. You can set up Gateway resources alongside your existing Ingress resources, validate that everything routes correctly, and then remove the old Ingress resources when you are ready.
The add-on handles the dual-mode operation through a feature flag. Enable it, deploy your Gateway and HTTPRoute resources alongside existing Ingress resources, and the add-on provisions the necessary control plane components. The Gateway API controller handles the new routes while the existing ingress controller continues processing the old ones.
Practical considerations
A few things to keep in mind if you plan to adopt this:
- Update your AKS cluster to the latest version that supports the Gateway API add-on. The feature is tied to specific AKS version ranges.
- Review the Gateway API CRD documentation before deploying. The resource model is different from Ingress and takes some getting used to if you have been reading Ingress specs for years.
- Start with a single HTTPRoute and Gateway pair in a non-production namespace. The role-oriented model means you need to set up ReferenceGrant resources for cross-namespace references, which is a new concept if you are coming from Ingress.
- If you use cert-manager, check whether it integrates with your Gateway resources or if you need to use the Key Vault integration instead.
- Enable access logging from the start. The built-in logging gives you visibility into traffic patterns that are harder to get with traditional ingress controllers.
Comparing with alternatives
The Kubernetes ecosystem has no shortage of ingress solutions. Ingress-NGINX is battle-tested and works everywhere. Contour uses Envoy and has been Gateway API-compatible for longer. Istio itself provides gateway functionality through its own resources. What the AKS Application Routing with Gateway API offers is a managed option that integrates with Azure services directly.
If you are already deep in the Azure ecosystem, the DNS and Key Vault integration alone might tip the scales. If you run multi-cloud or need portability, the standard Gateway API spec means your routing definitions can move with you, even if the Azure-specific integrations cannot.
The Istio-based control plane is also worth noting. You get the traffic management capabilities of Istio without the operational overhead. If your team has been avoiding Istio because of its complexity, this gives you a path to adoption with someone else managing the control plane.
What this means for day-to-day operations
For teams that manage multiple services across namespaces, the role-oriented model is the biggest practical change. Instead of a single person or team owning the Ingress resource and fielding requests from every service owner, Gateway API lets service teams define their own HTTPRoute resources. The platform team owns the Gateway resources (which infrastructure they expose), and service teams own their routes (how traffic reaches their apps).
This split reduces bottlenecks. A service team can add a new route for their canary deployment without waiting for the platform team to update a shared Ingress resource. The platform team retains control over which hosts and ports are exposed through the Gateway resource. ReferenceGrant resources act as the permission layer, letting the platform team control which namespaces can reference the Gateway.
If you have felt the pain of a single Ingress resource with hundreds of rules owned by one team, this is the feature that should interest you most. It is not just a new API version. It is a different way of organizing who owns what in the cluster.