Skip to main content

Application Gateway for Containers (ALB)

Terminology: ALB

In this document and official documentation, ALB refers to the ALB Controller (Application Load Balancer Controller) or its custom resources, which manage Application Gateway for Containers. Please note that this is distinct from Azure Load Balancer, which is Azure's Layer 4 load balancer service.

Application Gateway for Containers is a new application (Layer 7) load balancing and dynamic traffic management solution designed for workloads running in Kubernetes clusters such as Azure Kubernetes Service (AKS).

It is an evolution of the traditional Application Gateway Ingress Controller (AGIC) and supports the Kubernetes Gateway API.

Overview​

Application Gateway for Containers consists of the following three main components:

  1. Application Gateway for Containers Resource: A management plane resource on Azure.
  2. Frontend: The entry point that accepts traffic.
  3. Association: The connection definition between the gateway and the backend (VNet/Subnet).

Architecturally, it sits outside the AKS cluster data plane and is managed by the ALB Controller (Application Load Balancer Controller).

Kubernetes Gateway API​

Application Gateway for Containers implements the Gateway API, the new standard for Kubernetes. The Gateway API is designed as the successor to the Ingress API, providing more expressive and extensible traffic routing.

Key Resource Models​

The Gateway API adopts a resource model that is aware of role separation (role-oriented).

  • GatewayClass: Defined by the infrastructure provider. A template for gateways with common configurations.
  • Gateway: Defined by the cluster operator. An instance of a load balancer that handles traffic.
  • HTTPRoute: Defined by the application developer. Rules for routing HTTP requests to backend services.

This allows infrastructure administrators and application developers to manage configurations within their respective areas of responsibility.

Key Features and Benefits​

Application Gateway for Containers offers advanced features such as:

  • Traffic Splitting / Weighted Round Robin: Useful for canary releases and blue/green deployments.
  • Advanced Routing: Routing based on hostname, path, header, query string, method, and port.
  • Header Rewriting: Modifying request/response headers.
  • Mutual Authentication (mTLS): mTLS support for frontend and backend.
  • Auto Scaling: Automatic scaling based on traffic volume.
  • Zone Redundancy: Supports availability zones for high resilience.

Deployment Strategies​

There are two main deployment strategies for Application Gateway for Containers:

1. Managed by ALB Controller​

Deploy the ALB Controller within the Kubernetes cluster, which detects changes in Kubernetes custom resources (Gateway API or Ingress API) and automatically manages the lifecycle of Azure resources (such as Application Gateway for Containers).

2. Bring Your Own (BYO) Deployment​

Azure resources (Application Gateway for Containers, Frontend, Association) are pre-provisioned using Terraform, Azure CLI, etc., and referenced from the Kubernetes configuration. This is suitable when you want to completely separate infrastructure management from application deployment.

Best Practices for Multiple Frontend Applications​

When hosting multiple frontend applications in an AKS cluster, it is recommended to share a single Application Gateway for Containers.

Application Gateway for Containers natively supports multi-site hosting, allowing you to efficiently host multiple applications on a single Gateway resource.

Benefits:

  • Cost Reduction: No need to create multiple Application Gateway for Containers instances, minimizing Azure resource costs.
  • Simplified Management: Fewer infrastructure management points, enabling unified configuration and monitoring.
  • Resource Efficiency: Efficiently leverage the auto-scaling capabilities of Gateway resources for optimal resource allocation based on traffic volume.
  • Advanced Routing: Flexible routing based on hostname, path, and headers from a single entry point.

Implementation Patterns​

Pattern 1: Hostname-based Routing (Multiple Domains)​

When providing multiple frontend applications with different domains, define multiple HTTPRoutes on a single Gateway resource.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gateway
  namespace: gateway-infra
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: wildcard-tls-secret
---
# Application 1 Route
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app1-route
  namespace: app1-namespace
spec:
  parentRefs:
  - name: shared-gateway
    namespace: gateway-infra
  hostnames:
  - "app1.contoso.com"
  rules:
  - backendRefs:
    - name: app1-service
      port: 80
---
# Application 2 Route
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app2-route
  namespace: app2-namespace
spec:
  parentRefs:
  - name: shared-gateway
    namespace: gateway-infra
  hostnames:
  - "app2.contoso.com"
  rules:
  - backendRefs:
    - name: app2-service
      port: 80

Pattern 2: Path-based Routing (Single Domain)​

When providing multiple applications on the same domain, separate routing by path prefix.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: multi-app-route
  namespace: gateway-infra
spec:
  parentRefs:
  - name: shared-gateway
  hostnames:
  - "portal.contoso.com"
  rules:
  # Route requests to /admin/* to admin app
  - matches:
    - path:
        type: PathPrefix
        value: /admin
    backendRefs:
    - name: admin-app-service
      port: 80
      namespace: admin-namespace
  # Route requests to /api/* to API service
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 80
      namespace: api-namespace
  # Route other requests to frontend app
  - backendRefs:
    - name: frontend-service
      port: 80
      namespace: frontend-namespace

Namespace Isolation and Security​

The Gateway API supports Cross-Namespace References, enabling the following isolation configuration:

  • Gateway Resource: Placed in a namespace for infrastructure team management (e.g., gateway-infra)
  • HTTPRoute Resource: Placed in each application team's namespace (e.g., app1-namespace, app2-namespace)

Access Control with ReferenceGrant: When allowing cross-namespace references, explicitly grant permissions with the ReferenceGrant resource.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-gateway-routes
  namespace: gateway-infra
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: app1-namespace
  to:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: shared-gateway

When to Create Separate Gateways​

Consider creating multiple Application Gateway for Containers instances in the following cases:

  1. Complete Environment Isolation Required

    • Need to completely separate production and development environments
    • Compliance or security requirements demand complete separation into different VNets or subnets

  2. Different SLA Requirements

    • Some applications require dedicated scaling configurations or high availability setups
    • Want to completely isolate mission-critical applications from development applications

  3. Independent Cost Management Required

    • Need to clearly separate and track Azure resource costs per project or tenant

  4. Deployment in Different Geographic Regions

    • Need to deploy applications in different Azure regions

Summary​

ConfigurationRecommended ScenarioBenefitsDrawbacks
Single Shared GatewayMultiple apps in same cluster, microservices architectureCost reduction, simplified management, resource efficiencyPotential for one app's failure to affect others
Multiple Separate GatewaysEnvironment isolation (prod/dev), complete independence requiredComplete isolation, independent SLA, cost trackingIncreased cost, management complexity

Best Practice: Unless there are special requirements, it is recommended to share a single Application Gateway for Containers and logically separate routing with HTTPRoute.

Differences from AGIC (Ingress Controller)​

Compared to traditional AGIC, Application Gateway for Containers excels in the following areas:

  • Performance: Updates are reflected in near real-time.
  • Functionality: Support for Gateway API enables more complex routing.
  • Isolation: The data plane is separated from the AKS cluster, making it less likely to impact cluster resources.

Comparison with Nginx Ingress Controller​

IMPORTANT: Nginx Ingress Controller Retirement

The Kubernetes community has announced the retirement of the Ingress NGINX project. Maintenance will cease in March 2026, after which no security updates will be provided. Therefore, it is not recommended for new projects. Migration to the Gateway API is strongly recommended. Details: Ingress NGINX Retirement: What You Need to Know

Here are the main differences when compared to the OSS Nginx Ingress Controller.

FeatureApplication Gateway for Containers (ALB)Nginx Ingress Controller (Deprecated)
TypeAzure Managed Service (PaaS)In-cluster Software
Data PlaneRuns outside the AKS clusterRuns inside the AKS cluster (as Pods)
Resource UsageUses Azure resources (no cluster load)Consumes cluster CPU/Memory
ScalingAzure auto-scales based on trafficRequires HPA (Horizontal Pod Autoscaler) configuration
ExtensibilityGateway API standard, Azure integrationRich community plugins, Lua scripts
CostALB usage fees applyIncluded in compute resource (VM) costs

Scenarios to choose ALB:

  • When you want to focus cluster resources on application processing (offloading SSL termination, etc.).
  • When you need SLA and support as an Azure managed service.
  • When you want to natively use the advanced routing capabilities of the Gateway API.
  • When you want to ensure future support and security (due to the retirement of Nginx Ingress Controller, alternatives like ALB are essential).

Scenarios to choose Nginx:

  • (Deprecated) When you have existing assets and need to maintain them only until migration.
  • When specific Nginx modules or advanced customizations are required (only if security risks are acceptable).

Manifest Comparison​

Nginx Ingress Controller uses the Ingress resource, while Application Gateway for Containers (Gateway API) uses Gateway and HTTPRoute resources.

Nginx Ingress Controller (Ingress API):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - example.com
    secretName: my-tls-secret
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

Application Gateway for Containers (Gateway API):

In the Gateway API, the gateway definition and routing definition are separated.

# Gateway: Load Balancer Definition
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: alb-gateway
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: my-tls-secret
---
# HTTPRoute: Routing Rule Definition
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: alb-route
spec:
  parentRefs:
  - name: alb-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: my-service
      port: 80

TLS Certificate Handling​

FeatureApplication Gateway for Containers (ALB)Nginx Ingress Controller
StorageKubernetes Secret or Azure Key VaultKubernetes Secret
ManagementCentralized management via Azure Key Vault integrationTypically in-cluster management via cert-manager
Configurationlisteners in Gateway resourcetls in Ingress resource
Auto-renewalSupported (via Key Vault + CSI Driver)Supported (via cert-manager)

Nginx Ingress Controller: You create a Kubernetes Secret (kubernetes.io/tls) and reference it in the Ingress resource. It is common to use cert-manager to automatically issue Let's Encrypt certificates.

Application Gateway for Containers: While it is possible to reference Kubernetes Secrets, it is recommended to directly reference certificates stored in Azure Key Vault. This allows you to offload certificate lifecycle management to the Azure platform and improve security.

About Azure App Service Certificate Auto-renewal: Certificates purchased and managed via Azure App Service Certificate are stored in Azure Key Vault. When using these with Application Gateway for Containers, you can support automatic certificate renewal by syncing them to Kubernetes Secrets using the Azure Key Vault Provider for Secrets Store CSI Driver. By configuring the rotationPollInterval of the CSI Driver, certificates updated in Key Vault are automatically reflected in the cluster Secrets, and the ALB Controller detects this change to update the load balancer configuration.

References​