Application Gateway Ingress Controller for AKS

The Application Gateway Ingress Controller (AGIC) is a Kubernetes pod that bridges Azure Application Gateway with an AKS cluster. It allows you to use Application Gateway as the ingress point for traffic entering the cluster, rather than deploying a software-based ingress controller (like NGINX). AGIC monitors Kubernetes Ingress resources and updates the Application Gateway configuration accordingly, enabling features like SSL termination, URL-based routing, multi-site hosting, and Web Application Firewall (WAF) at the edge.

Traditional Kubernetes ingress controllers run as pods inside the cluster, meaning traffic must first reach the cluster's node network before being routed. This introduces latency and complexity, especially for enterprises that require centralized SSL offloading, WAF, or integration with Azure DDoS Protection. AGIC moves these responsibilities to a managed Azure service (Application Gateway), which operates at the network edge. This reduces the load on cluster nodes, simplifies certificate management, and provides a single point of policy enforcement.

AGIC runs as a pod in the AKS cluster, typically in the azure-system namespace. It uses the Azure Resource Manager API to read and modify the Application Gateway's configuration. The controller watches Kubernetes resources such as: - Ingress: Defines routing rules (host, path, backend service, port). - Service: Defines the target pods. - Pod: Used for health probing and endpoint discovery.

When an Ingress resource is created or updated, AGIC performs the following: 1. Read: AGIC reads the Ingress spec, which includes rules like host: app.contoso.com, path: /api, and backend: service: api-service port: 80. 2. Translate: It converts these rules into Application Gateway configuration objects: - Listeners: One per host:port combination (e.g., HTTP/443 for app.contoso.com). - Routing Rules: Maps listener to backend pool with path-based rules. - Backend Pools: Contains the IP addresses of the pods backing the service. - Health Probes: Configured based on the service's readiness probe. 3. Apply: AGIC uses the Azure SDK to call ApplicationGateway.Update() or CreateOrUpdate() to push changes to the Application Gateway resource.

- AGIC Version: As of 2025, the latest stable version is 1.8.x. Always check the official Microsoft documentation for the latest. - Deployment Modes: - Add-on mode: Managed by AKS, automatically deployed when you enable the AGIC add-on. Recommended for most scenarios. - Helm mode: Manual deployment via Helm chart. Offers more configuration control. - Default Namespace: azure-system for add-on mode. - Health Probe Defaults: Interval: 30 seconds, Timeout: 30 seconds, Unhealthy threshold: 3 consecutive failures. - SSL Termination: AGIC can reference Azure Key Vault for SSL certificates via Key Vault secrets or certificates. - WAF: Application Gateway WAF v2 is supported. AGIC configures WAF policies per listener or per rule. - Scaling: Application Gateway supports auto-scaling (if configured) and can handle up to 125 backend pool members per pool.

To enable AGIC add-on on an existing AKS cluster:

az aks enable-addons --addons ingress-appgw --name myAKSCluster --resource-group myResourceGroup

This creates an Application Gateway in the same node resource group (MC_*). To specify an existing Application Gateway:

az aks enable-addons --addons ingress-appgw --name myAKSCluster --resource-group myResourceGroup --appgw-id /subscriptions/.../applicationGateways/myAppGateway

To verify AGIC is running:

kubectl get pods -n azure-system -l app=ingress-appgw

To check logs:

kubectl logs -n azure-system deployment/ingress-appgw-deployment

Example Ingress resource that AGIC processes:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
spec:
  rules:
  - host: app.contoso.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

A large retailer runs a microservices-based e-commerce platform on AKS. They need to expose public-facing APIs with SSL termination and a Web Application Firewall to protect against SQL injection and cross-site scripting. They deploy AGIC with an Application Gateway WAF v2 SKU. The Ingress resources define paths for /api, /checkout, and /products, each routing to different services. SSL certificates are stored in Azure Key Vault and referenced by AGIC via a managed identity. In production, the cluster handles 10,000 requests per second, and the Application Gateway auto-scales to handle spikes during Black Friday. The team monitors backend health using Application Gateway's built-in probes and sets up alerts for unhealthy backends. A common misconfiguration is forgetting to update the health probe path when the service's readiness probe changes, causing the gateway to mark all pods as unhealthy. The fix is to either align the health probe with the readiness probe or override it using AGIC annotations.

A financial institution uses AKS for internal microservices that should not be exposed to the internet. They deploy AGIC with an Application Gateway that has a private frontend IP only, attached to the same VNet as the AKS cluster. The Ingress resources use internal DNS names (e.g., api.internal.bank.com). AGIC configures the gateway's private listeners and backend pools. Traffic from internal applications (e.g., a legacy .NET app) hits the private IP, and the gateway routes to the appropriate pod. A challenge is that the Application Gateway must be in the same VNet or a peered VNet as the AKS cluster. The team also uses Azure Private DNS zones for name resolution. They learned that AGIC's health probes must be able to reach the pods; if the gateway is in a different subnet, NSG rules must allow traffic from the gateway subnet to the pod subnet on the health probe port.

A SaaS provider hosts multiple customer applications on a single AKS cluster, each with a custom domain (e.g., customer1.contoso.com, customer2.contoso.com). They use AGIC with multi-site hosting: each customer gets a separate listener on the Application Gateway. The Ingress resources specify the host header, and AGIC creates separate listeners and backend pools. This allows the provider to apply different WAF policies per customer. The main performance consideration is the Application Gateway's listener limit (100 for Standard_v2, 50 for WAF_v2). As they onboard more customers, they need to upgrade the SKU or use a wildcard certificate with a single listener and path-based routing. A common mistake is forgetting to update DNS records to point each customer domain to the Application Gateway's frontend IP, causing traffic to never reach the gateway.