Introduction
If you’re using Azure Kubernetes Service (AKS), you will need a mechanism for accepting and routing HTTP/S traffic to applications running in your AKS cluster. Until recently, this was typically handled by Azure’s Application Gateway Ingress Controller (AGIC) or another Ingress product such as NGINX.
With the introduction of the upstream Kubernetes Gateway API project, there’s now a more evolved solution for ingress traffic management. This article will discuss Application Gateway for Containers (AGC) – which is Azure’s latest load balancing solution that implements Gateway API.
This post is not an instructional on how to deploy AGC, but it will address the following:
- What is Gateway API and why is it needed?
- How does AGC work?
- How is high availability and resiliency incorporated into AGC?
- What AGC is not
The goal is that you will come away with an understanding of the inner workings of AGC and how it ties into the AKS environment. Let’s get started!
Gateway API Overview
Before the introduction of Gateway API, Ingress API was the de facto method for routing Layer 7 traffic to applications running in Kubernetes. It provides a simple routing process for HTTP/S traffic but has limitations. For instance, it requires the use of vendor specific annotations for the following:
- URL rewriting or header modification
- Routing for gRPC, TCP or UDP based traffic
To address these limitations, The Kubernetes Network Special Interest Group (SIG) introduced Gateway API. It consists of a collection of Custom Resource Definitions (CRDs) which extends the Kubernetes API to allow for the creation of custom resources.
Fig. 1.1. A comparison of traffic flow between Ingress and Gateway API
Gateway API is a more flexible, portable and extensible solution in comparison to its Ingress predecessor. It consists of three components:
- Gateway Class – provides a standard on how Gateway objects should be configured and behave
- Gateway – an instantiation of a Gateway Class that implements its configuration
- Routes – defines routing and protocol-based rules that are mapped to Kubernetes backend services
As seen in Fig.1.1, the relative independence of each component in Gateway API allows for a separation of concerns type resource model. For example, developers can focus on creating routes for their apps and platform teams can manage the gateway resources that are utilized by routes. The other benefit is the portability of routes. For example, ones created in AKS can be used with Gateway API deployments in other environments. This flexibility is not possible with Ingress API, due to a lack of standardization across different Ingress controller implementations.
Application Gateway for Containers Overview
Not to be confused with Application Gateway, Application Gateway for Containers is a load balancing product designed to manage layer 7 traffic intended for applications running in AKS. It supports advanced routing capabilities by leveraging components that bootstrap Gateway API into AKS.
Fig. 1.2. Diagram of Application Gateway for Containers traffic flow
The above figure is an illustration of AGC, AKS and how they work together to manage incoming traffic. Let’s break down the diagram in detail to get a better understanding of AGC.
Fig. 1.3. AGC Frontend Resource in the Azure Portal
The Application Gateway for Containers Frontend serves as the public entry point for client traffic. It is a child resource of AGC and is given an auto-generated FQDN during setup. To avoid using the FQDN, it can be mapped to a CNAME record for DNS resolution. Also, you can have multiple Frontend resources (up to 5) in a single AGC instance.
Fig.1.4. Azure Portal view of the Association child resource
The Association child resource is the point of entry into the AKS Cluster and defines where the proxy components live. In the above pic, you will notice a subnet linked to it, which is established via subnet delegation. This is a dedicated subnet that’s also used by the proxy components which send traffic to destination AKS pods. The ALB Controller (which will be described shortly), deploys the proxies into the subnet.
Fig.1.5. Subnet used by the Association for Proxying traffic
Here’s a view of the ALB Controller subnet. It must use a /24 or smaller CIDR and cannot be used for any other resources. In this case, the ALB subnet is deployed within the AKS Virtual Network (VNet), however this is not a requirement. It can be in a separate VNet that is peered with the AKS virtual network.
So, we’ve determined how traffic flows from the AGC frontend resource and to the proxy components. But two questions remain: 1) How do the proxy components know which backend services are intended for the incoming request? 2) How is Gateway API leveraged by AGC to utilize advanced routing patterns? This is where the ALB controller comes into play.
Fig.1.6. ALB Controller pods
Before creating the AGC instance, the ALB controller is deployed into AKS. It’s responsible for monitoring HTTP route and Gateway resource configurations. As you can see in the above pic, ALB controller runs as three pods in AKS: two controller pods and one for bootstrapping.
Fig.1.7. Diagram showing how ALB Controller uses Managed Identity
The ALB controller pods have a direct connection to AGC and are responsible for replicating resource configurations to it. To accomplish this, a federated Managed Identity is used which has the AppGW for Containers Configuration Manager role on the AGC Resource Group. Also, the ALB Controller uses this Managed Identity to provision AGC. Alternatively, you can create your own AGC resource via Azure portal, CLI, PowerShell or Infrastructure as Code (IAC). The latter deployment method is done through Azure Resource Manager (ARM).
Fig.1.8 ALB Controller bootstrap pod
By default, the bootstrap pod is how Gateway API is installed. However, you can disable this behavior by setting the albController.installGatewayApiCRDs parameter to false when you install the ALB Controller using Helm. In Fig.1.8, a kubectl describe command is executed against the bootstrap pod to display its specs. You will notice an Init container applies the Gateway API CRDs into AKS. Init Containers are used to perform initialization tasks that must precede the startup of a main application container.
Fig.1.9. Gateway Class object definition output
Recall from earlier that Gateway API consists of three resources: Gateway class, Gateway resource and Routes. The ALB Controller will create a Gateway Class object with the name azure-alb-external, as shown above.
Fig.1.10. Gateway Resource and HTTPRoute configuration files
Fig.1.11. Diagram of traffic splitting between backends
The final steps to complete the puzzle are to deploy a Gateway resource which listens for traffic over a protocol/port combination and a Route to define how traffic coming via the Gateway maps to backend services. The Gateway definition has a gatewayClassName spec that references the name of the Gateway Class. In the above example, it listens for HTTP traffic on port 80. And there’s a corresponding HTTPRoute config that splits the traffic across two backend services: backend-v1 receiving 50% of the traffic on port 8080 and backend-v2 receiving the remaining traffic using the same port.
High Availability & Resiliency in AGC
When you create an Application Gateway for Containers resource, it’s automatically deployed across Availability zones within the selected region. An Availability Zone (AZ) is a physically unique group of one or more datacenters. Its purpose is to provide inner-regional resiliency at the datacenter level. There are typically three AZs in a region where they are supported. Therefore, if one datacenter in the region goes down, AGC is not impacted.
If Availability zones aren’t supported in the selected region, fault and update domains in the form of Availability sets will be leveraged to mitigate against outages and maintenance events. This link provides a list of Azure regions that support Availability zones.
To mitigate against regional outages, you can leverage Azure Front Door or Traffic Manager with AGC. Azure Front Door is a Layer 7 routing service that load-balances incoming traffic across two regions. It provides Content Deliver Networking (CDN), Web-application firewall (WAF), SSL termination and other capabilities for HTTP/HTTPS traffic. Whereas Traffic Manager uses DNS to direct client requests to the appropriate endpoint based on a specified routing method such as priority, performance, weight or others.
What AGC is Not
Application Gateway for Containers is not a replacement for Application Gateway. Rather, it’s a new service within the family of Azure load balancing services. Although AGC doesn’t currently have Web Application Firewall (WAF) capabilities like Application Gateway, the feature is currently in private preview and will soon be available.
Lastly, AGC is designed specifically for routing requests to containerized applications running in AKS. And unlike Application Gateway, it does not service backend targets such as Azure App Services, VMs, and Virtual Machine Scale Sets (VMSS).
Conclusion
Over time, it became evident that a new way of managing ingress traffic for containerized workloads was needed. The initial implementations for ingress traffic management were sufficient for simple routing requests but lacked native support for advanced routing needs. In this article, we discussed Microsoft Azure’s newest load balancing solution called Application Gateway for Containers, which builds on the Gateway API for Kubernetes. We explored the components of AGC, how it manages traffic and addressed any potential misconceptions regarding it. For some additional resources, check out the following:
What is Application Gateway for Containers? | Microsoft Learn
Introduction - Kubernetes Gateway API
Published May 01, 2025
Version 1.0
richardburrs
Microsoft
Microsoft