Transitioning from AGIC to Azure Application Gateway for Containers (ALB)

The Evolution of Azure Load Balancing

For Azure users running Kubernetes (AKS), the Application Gateway Ingress Controller (AGIC) has been the standard for years. It allowed you to use the powerful Azure Application Gateway (L7 load balancer) directly via Kubernetes Ingress. However, AGIC had its challenges: slow update times, complex configuration, and a tight coupling between the Kubernetes controller and the Azure resource.

Enter Azure Application Gateway for Containers (ALB). This is not just an update to AGIC; it is a completely new architecture built from the ground up to support the Kubernetes Gateway API. It offers sub-second deployment times and a much more scalable management model.

Key Differences: AGIC vs. ALB

Migration Pre-flight Checklist

Before you start the migration, ensure you have the following in place:

• AKS Cluster: Recommended version 1.28 or higher.
• Workload Identity: ALB requires Azure Workload Identity to be enabled on your cluster to securely communicate with the Azure backend.
• Helm: The ALB Controller is installed via Helm.
• Subnet: ALB requires a dedicated subnet for its "frontend" configuration (distinct from your AKS nodes).

Step 1: Install the ALB Controller

Unlike AGIC, which was often enabled as an AKS addon, ALB is currently managed as a controller in your cluster.

# Install via Helm
helm install alb-controller oci://mcr.microsoft.com/azure-alb/charts/alb-controller \
     --namespace azure-alb-system \
     --set clusterName=$AKS_NAME \
     --set identityClientId=$IDENTITY_CLIENT_ID

Step 2: Define the Azure Infrastructure

ALB uses a new Custom Resource called ApplicationGatewayForContainers. This resource acts as the bridge between your Kubernetes manifests and the Azure infrastructure.

apiVersion: alb.networking.azure.io/v1
kind: ApplicationGatewayForContainers
metadata:
  name: my-alb
spec:
  # Reference to the Azure resource ID
  resourceId: /subscriptions/.../resourceGroups/.../providers/Microsoft.ServiceNetworking/trafficControllers/my-alb

Step 3: Creating the Gateway and Route

Now we use the standard Gateway API resources. The ALB controller recognizes the gatewayClassName: azure-alb-external.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: external-gateway
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: my-cert-secret
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
spec:
  parentRefs:
  - name: external-gateway
  rules:
  - backendRefs:
    - name: my-service
      port: 80

Why the Move is Worth It

The move to ALB provides several immediate benefits for Azure developers:

• Simplified TLS: ALB integrates seamlessly with Azure Key Vault for certificate management without needing complex CSI driver setups for certificates.
• Advanced Routing: Features like header-based routing and traffic splitting (canary) are now native and don't require obscure annotations.
• Operational Stability: The separation between the traffic controller (Azure side) and the gateway controller (K8s side) makes the whole system more resilient to updates.

"Transitioning to Azure ALB isn't just about moving to a new load balancer; it's about embracing the future of standardized Kubernetes networking on Azure."