Hello everyone, welcome back to Kloudschool! If you are running workloads on Azure Kubernetes Service (AKS), you already know how important it is to manage incoming traffic efficiently. Over my years working as a Cloud and DevOps Engineer, and while preparing for various Azure architecture and security certifications, I have spent countless hours configuring load balancers.

For a long time, the go-to solution for AKS was the Application Gateway Ingress Controller (AGIC). It was great, but as our Kubernetes environments grew, we needed something faster and more aligned with modern Kubernetes standards.

Recently, while managing my Master's degree studies in Software and Artificial Intelligence here in South Korea, I spent some serious time deep-diving into Microsoft's newest evolution: Azure Application Gateway for Containers.

In this article, I am going to share my personal experience with this new tool, explain what it is in simple basic English, and guide you on how to deploy it for your AKS clusters.

What is Application Gateway for Containers?

In simple terms, Application Gateway for Containers is a new Layer 7 application load balancing and dynamic traffic management product built specifically for workloads running on you'r Kubernetes clusters.

Think of it as the next-generation upgrade to AGIC(Application Gateway for Ingress Controller). Instead of just monitoring Kubernetes resources and slowly applying them to a traditional Azure Application Gateway, this new service is purpose-built for containers. It enable us to brand new data plane and control plane that exist outside the AKS cluster, while an internal component called the ALB Controller runs inside your cluster to manage everything.

It natively supports the modern Kubernetes Gateway API (v1) as well as the traditional Ingress API.

Why is it Better than AGIC? (My Experience)

When I first tested this, the performance difference was the most noticeable factor. If you have used AGIC, you know that updating routes or adding pods can sometimes take a little while to reflect.

Here is why Application Gateway for Containers is a massive upgrade:

1. Near Real-Time Updates: The performance has been drastically improved. When you add or remove pods, paths, or health probes, the updates happen almost instantly.
2. Traffic Splitting & Weighted Round Robin: This is a lifesaver for DevOps engineers! You can now easily route a specific percentage of traffic to a new version of your app (Canary deployments) without complex workarounds.
3. Mutual Authentication (mTLS): It supports end-to-end TLS and mTLS for frontend and backend targets, making your applications highly secure.
4. Gateway API Support: It fully implements the Kubernetes Gateway API v1, which is the future of Kubernetes routing.

Understanding the Core Components

Before we deploy anything, you need to understand the three main pieces of the puzzle. Microsoft has separated the architecture logically:

1. Application Gateway for Containers (The Parent Resource)

This is the main Azure resource that holds everything together. It acts as the control plane that orchestrates your proxy configurations.

2. The Frontend (Entry Point)

The frontend is a child resource. It defines where client traffic enters. Currently, every frontend provides a unique Microsoft-managed FQDN (Fully Qualified Domain Name). You can use this FQDN directly or create a CNAME record in your own DNS to point to it. Note: As of my latest testing, private IP addresses are not yet supported for the frontend.

3. The Association (Network Connection)

This is how your Application Gateway connects to your Virtual Network (VNet). The association requires a delegated subnet (minimum size of /24). It maps the Application Gateway to your Azure subnet so it can securely reach your AKS pods.

4. The ALB Controller

This is the "brain" inside your AKS cluster. Deployed via Helm or as an AKS Add-on, the ALB controller consists of two pods (alb-controller and alb-controller-bootstrap). It reads your Kubernetes Gateway/Ingress configurations and translates them into Azure Application Gateway rules.

Deployment Strategies: Which one to choose?

When setting this up, Azure gives you two deployment strategies. Choosing the right one depends on how your team prefers to manage infrastructure.

Strategy 1: BYOD (Bring Your Own Deployment)

In this method, you (the Cloud Engineer) use Azure CLI, Terraform, or the Azure Portal to manually create the Application Gateway, the Frontend, and the Association resources. Then, you simply reference them inside Kubernetes. I prefer this method for enterprise environments because it gives infrastructure teams full control over Azure resources.

Strategy 2: Managed by ALB Controller

If you want Kubernetes to handle everything, this is for you. You just define an ApplicationLoadBalancer custom resource inside Kubernetes. The ALB Controller will automatically talk to Azure and provision the Application Gateway and Frontend resources for you. Their lifecycle will be tied directly to your Kubernetes cluster.

Step-by-Step Guide: Deploying the ALB Controller

Let’s get our hands dirty. Here is a simplified guide on how to prepare your cluster and install the ALB controller using Azure CLI.

Step 1: Prepare Your Environment

First, make sure you have the right Azure CLI extensions installed and register the required providers.

Bash

# Log in and set your subscription

           az login

           az account set --subscription <your-subscription-id>

# Register resource providers

         az provider register --namespace Microsoft.ContainerService

         az provider register --namespace Microsoft.Network

         az provider register --namespace Microsoft.NetworkFunction

         az provider register --namespace Microsoft.ServiceNetworking

# Install the ALB extension

         az extension add --name alb

Step 2: Ensure AKS Prerequisites are Met

For this to work, your AKS cluster must meet a few critical conditions:

• It must use Azure CNI or Azure CNI Overlay.
• It must have OIDC Issuer and Workload Identity enabled.

If you have an existing cluster, you can enable Workload Identity like this:

Bash

           az aks update -g <ResourceGroupName> -n <ClusterName> --enable-oidc-issuer --enable-workload-identity

Step 3: Set up the Subnet Delegation

Your Application Gateway needs a place to live. You must create a subnet (at least /24) and delegate it to the Microsoft.ServiceNetworking/trafficControllers service.

Bash

az network vnet subnet create \

  --resource-group <VNet-Resource-Group> \

  --vnet-name <VNet-Name> \

  --name subnet-alb \

  --address-prefixes 10.0.1.0/24 \

  --delegations 'Microsoft.ServiceNetworking/trafficControllers'

Step 4: Install the ALB Controller

You can install the ALB controller easily using Helm.
First, you need to create a User-Assigned Managed Identity and grant it the AppGw for Containers Configuration Manager role over your cluster resource group, and the Network Contributor role over your delegated subnet.

Once the identity is federated with your AKS cluster's OIDC issuer, install the Helm chart:

Bash

helm install alb-controller oci://mcr.microsoft.com/application-lb/charts/alb-controller \

     --namespace azure-alb-system \

     --version 1.9.16 \

     --create-namespace \

     --set albController.namespace=azure-alb-system \

     --set albController.podIdentity.clientID=<Your-Managed-Identity-Client-ID>

Verify it is running:

Bash

   kubectl get pods -n azure-alb-system

You should see two alb-controller pods in the Running state!

Migrating from AGIC to Application Gateway for Containers

If you are already using AGIC, Microsoft highly recommends planning a migration. The migration process is designed to be zero-downtime.

The strategy is simple:

1. Install the new ALB Controller alongside your existing AGIC.
2. Translate your AGIC annotations to the new Gateway API or Ingress API configurations.
3. Run end-to-end tests using a host file or test DNS record.
4. Once verified, flip your production DNS CNAME record to point to the new Application Gateway frontend FQDN.
5. Finally, delete the old AGIC resources.

Important Note: Keep in mind that some legacy AGIC features like private IPs or listening on ports other than 80 and 443 are not yet supported in the new Application Gateway for Containers. Always check your dependencies before making the switch!☺️

Final Thoughts

The shift from standard Ingress Controllers to the Gateway API is happening fast across the cloud landscape. As a DevOps and Cloud Engineer's, adopting Azure Application Gateway for Containers early will give you a massive advantage in routing performance, traffic management, and security for your microservices.

I hope this guide cleared up how this new technology works! If you have any questions about configuring this, or if you run into issues with the ALB Controller, drop a comment below. I’d love to help you out.

Happy Automating!😜