Azure Application Gateway for Containers

Azure announced the latest addition to Azure’s Application Gateway product family – Application Gateway for Containers. This powerful tool offers layer 7 load balancing and dynamic traffic management capabilities, specifically designed to cater to workloads within a Kubernetes cluster. With its advanced features, Application Gateway for Containers streamlines operations and enhances performance, making it an excellent choice for businesses looking to optimize their containerized applications. When writing this article, this service is currently in a public preview.

How it’s different from Azure Gateway Ingress Controller (AGIC)?

The AGIC system monitors the Kubernetes cluster installed and ensures that certain services are accessible to the public via an Application Gateway. The Ingress Controller operates in a separate pod on the customer’s AKS. AGIC keeps track of specific Kubernetes Resources and updates the Application Gateway’s settings accordingly through the Azure Resource Manager (ARM). One drawback is that changes may take some time to occur in a subset of Kubernetes, which applies to AGIC utilising ARM.

The Application Gateway for Containers represents a significant upgrade to the Application Gateway Ingress Controller (AGIC). With this powerful Kubernetes application, Azure Kubernetes Service (AKS) users can harness the full potential of Azure’s native Application Gateway application load balancer.

Architecture and its components:

If you’re looking for a way to enhance the performance of your container applications, the Application Gateway for Containers is an excellent option to consider. This service offers top-notch layer seven load-balancing features that are reliable and scalable. Azure fully manages it, so you can trust that your data is in good hands. One of the benefits of using this gateway is that it stores and manages data in the same region as your resources. The configuration data can be duplicated to its region pair for added durability if necessary. With the Application Gateway for Containers, you can feel confident that your container applications will operate smoothly and efficiently. This diagram presents the structure and elements of the Container Application Gateway.

The components involved are :

• The core components are :
  • Application Gateway for Containers – The system is hosted on Azure and serves as the control center. Its primary function is coordinating the proxy configuration based on the customer’s specifications.
  • Frontends – The frontend of an Application Gateway for Containers is the entry point for client traffic. It has a unique FQDN that a customer’s CNAME record can reference. Private IP addresses are not currently supported. One Application Gateway for Containers can accommodate multiple frontends. A frontend should be unique to a single Ingress or Gateway resource. Multiple hostnames and routes can be defined in a given Gateway or Ingress resource to eliminate the need for numerous frontend resources.
  • Associations – Connections to virtual networks are established through associations. An association maps an association resource to an Azure Subnet that has been delegated, with a 1:1 ratio. It is recommended that each Association assumes a minimum of 256 available addresses in the subnet at the time of provisioning. A minimum /24 subnet mask is required for new deployments, assuming the subnet has not been previously provisioned.
  • The ALB Controller is a Kubernetes deployment that manages the configuration and deployment of the Application Gateway for Containers. It monitors Kubernetes Custom Resources and Resource configurations such as Ingress, Gateway, and ApplicationLoadBalancer. The ALB Controller utilizes the ARM and Application Gateway for Containers configuration APIs to propagate the design to the Azure deployment of the Application Gateway for Containers.
• The Azure Application Gateway for container deployment is dependent on other Azure resources.:
  • Private IP address – A  private IP address refers to a specific host address within a given virtual network’s subnet.
  • Subnet Delegation – Multiple subnets can have the same or different subnet delegation as Application Gateway for Containers. Once set, no other resources can be added to the subnet unless allowed by the service’s implementation. At this time, it supports only Azure CNI networking option.
  • User-assigned managed identity – To make changes to the Application Gateway for Containers, Azure Load Balancer Controller requires a User Managed Identity. The AppGw for Containers Configuration Manager is a pre-existing RBAC role that enables the ALB Controller to access and configure the Application Gateway for Containers resource.

Explain how the request travels through Azure Application Gateway for a container.

When utilizing Application Gateway for Containers, it’s important to note that each frontend is assigned a Fully Qualified Domain Name (FQDN) managed by Azure. Customers can use the FQDN as-is or conceal it with a CNAME record. Before sending a request to Application Gateway for Containers, the client must resolve a CNAME pointing to the front end’s FQDN or directly resolve the FQDN using a DNS server. This is crucial as the DNS resolver translates the DNS record to an IP address. Once the client sends the request, the DNS name is passed to the defined frontend on Application Gateway for Containers as a host header. From there, a set of routing rules comes into play. These rules determine how the request for that particular hostname should be directed to a defined backend target. It’s essential to remember all these factors when utilizing Application Gateway for Containers to ensure that requests are properly handled and managed.

Deployment strategies:

• Bring your own (BYO) deployment: For this deployment approach, it is assumed that the Application Gateway for Containers resource, the Association, and the Frontend resource will be deployed and managed using Azure portal, CLI, PowerShell, Terraform, or other similar tools. These resources will then be referenced in the configuration within Kubernetes.
• Managed by ALB Controller: The deployment strategy involves deploying ALB Controller in Kubernetes to manage the lifecycle of the Application Gateway for Containers resource and its sub-resources. Whenever an ApplicationLoadBalancer custom resource is created on the cluster, ALB Controller generates the corresponding Application Gateway for Containers resource, and its lifecycle is tied to the custom resource.