Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure Application Gateway for Containers is a managed application layer (layer 7) load-balancing and dynamic traffic management service for workloads running in Kubernetes. It routes incoming requests to backend targets in your cluster.
When you use Azure, reliability is a shared responsibility. Microsoft provides a range of capabilities to support resiliency and recovery. You're responsible for understanding how those capabilities work within all of the services you use, and selecting the capabilities you need to meet your business objectives and uptime goals.
This article describes how Azure Application Gateway for Containers handles transient faults, availability zone failures, region-wide failures, and service maintenance. It also describes backup and restore options and key information about the service-level agreement (SLA).
Production deployment recommendations for reliability
Application Gateway for Containers is highly available by default. For production workloads:
For zone redundancy, deploy Application Gateway for Containers in a region that supports availability zones. The service is automatically zone-redundant in those regions.
Configure your Kubernetes cluster, Kubernetes resources, and backend workloads for zone resiliency. For guidance, see Resilience to availability zone failures.
For resilience to region-wide failures, deploy Application Gateway for Containers and its dependent workloads in each region, and configure cross-region traffic management. For guidance, see Custom multiregion solutions for resiliency.
If you configure network security groups (NSGs) or user-defined routes (UDRs) on the association subnet, follow the NSG guidance and user-defined route guidance.
For an example architecture and guidance on topology, traffic flow, reliability, security, and operations, see Deploy Application Gateway for Containers on Azure Kubernetes Service.
Reliability architecture overview
This section describes some of the important aspects of how the service works that are most relevant from a reliability perspective. The section introduces the logical architecture, which includes some of the resources and features that you deploy and use. It also discusses the physical architecture, which provides details on how the service works under the covers.
Logical architecture
An Application Gateway for Containers deployment includes resources in Azure and in your Kubernetes cluster.
- Azure resources: The control plane orchestrates the gateway's proxy configuration based on your configuration. The Azure-managed data plane runs outside your cluster and processes application traffic.
- Kubernetes resources: You define routing and other configuration by using Kubernetes resources. The ALB Controller runs in your cluster, watches those resources, and propagates your configuration to Application Gateway for Containers in Azure.
You can choose between two deployment strategies. With the bring your own (BYO) strategy, you manage the lifecycle of the Application Gateway for Containers, association, and frontend resources through Azure tools. With the managed by ALB Controller strategy, the ALB Controller manages the lifecycle of those Azure resources based on the Kubernetes resources you define.
For a full description of the components, see Application Gateway for Containers components.
After you deploy and configure Application Gateway for Containers, it routes incoming requests to the backend targets, which represent your application running within Kubernetes.
If the ALB Controller or the control plane is unavailable, the data plane continues to process traffic by using the last successfully applied configuration. During the outage, configuration updates aren't propagated, and the service can't program configuration required for scale-out events.
Physical architecture
Azure manages and automatically scales the data-plane infrastructure based on application traffic. Application Gateway for Containers is always deployed in a highly available configuration: in regions that support availability zones, gateways are zone-redundant; in regions that don't support availability zones, Azure uses availability sets.
Resilience to transient faults
Transient faults are short, intermittent failures in components. They occur frequently in a distributed environment like the cloud, and they're a normal part of operations. Transient faults correct themselves after a short period of time. It's important that your applications can handle transient faults, usually by retrying affected requests.
All cloud-hosted applications should follow the Azure transient fault handling guidance when they communicate with any cloud-hosted APIs, databases, and other components. For more information, see Recommendations for handling transient faults.
When you use Application Gateway for Containers, consider the following best practices:
Implement retry logic. Configure clients to retry requests after transient connection failures.
Configure health probes with tolerance. If you configure custom health probes, set the unhealthy threshold to tolerate transient faults. The unhealthy threshold specifies the number of consecutive failed probes that trigger the backend target to be marked as unhealthy. The default health probe uses an unhealthy threshold of three probes, which helps prevent a single transient probe failure from marking the backend unhealthy.
Resilience to availability zone failures
Availability zones are physically separate groups of datacenters within an Azure region. When one zone fails, services can fail over to one of the remaining zones.
When you deploy Application Gateway for Containers in an Azure region that supports availability zones, Microsoft automatically configures the control plane and data plane as zone-redundant across multiple zones. You don't select which zones the service uses.
Important
Microsoft manages zone redundancy for the Application Gateway for Containers control plane and data plane. To achieve end-to-end zone resiliency, configure your Kubernetes cluster, Kubernetes resources, and backend workloads to provide healthy targets across zones.
Requirements
Region support: To use zone redundancy, choose a region that supports both Application Gateway for Containers and availability zones. Check Application Gateway for Containers region availability and compare it with the list of regions that support availability zones.
Considerations
Shared responsibility with your Kubernetes platform: Microsoft manages traffic redirection for Application Gateway for Containers during a zone failure. For Azure Kubernetes Service (AKS), Microsoft manages the Kubernetes control plane. You're responsible for configuring zone resiliency for your cluster's node pools and other resources you manage, and for your applications' behavior during a zone outage.
Cluster: Configure your AKS node pools and other zone-bound cluster resources that you manage to span availability zones. AKS manages the control plane; see Configure availability zones for AKS node pools.
Your workloads: You're responsible for deploying multiple pod replicas, spreading them across zones, and ensuring healthy backend workloads are available to serve traffic during a zone outage. You can use node pools that span availability zones, topology spread constraints, and pod anti-affinity.
Kubernetes configuration objects: Application Gateway for Containers uses Kubernetes configuration objects stored by the cluster API. Their availability depends on the Kubernetes control plane and the configuration you manage in your cluster.
ALB Controller: You deploy the ALB Controller in your Kubernetes cluster to reconcile configuration. It isn't part of the Application Gateway for Containers data path.
The ALB Controller runs two replicas, with one acting as the leader and the other as the secondary. If the leader becomes unavailable, the secondary can become the leader and continue propagating configuration. Both replicas might run in the same availability zone, depending on how the cluster schedules them. You're responsible for configuring the cluster and controller pods for zone resiliency. Use pod topology spread constraints or pod anti-affinity to distribute the replicas across zones. For more information, see Configure availability zones for AKS node pools.
Cost
Availability zone support for Application Gateway for Containers doesn't incur extra charges beyond the standard service pricing. For pricing details, see Azure Application Gateway pricing.
Configure availability zone support
When you deploy a new gateway in a supported region, it's zone-redundant by default. You don't need to enable zone redundancy on Azure resources.
You're responsible for configuring your Kubernetes cluster, ALB Controller, and backend workloads for zone resiliency.
Behavior when all zones are healthy
This section describes what to expect when you deploy Application Gateway for Containers in a region that supports availability zones and all zones used by the service are operational.
Cross-zone operation: The Azure-managed Application Gateway for Containers data plane distributes incoming requests across infrastructure in multiple zones.
You're responsible for configuring your backend workloads to run across zones, and providing healthy targets to receive that traffic.
Cross-zone data replication: Application Gateway for Containers doesn't store application data. The platform manages configuration state through the zone-redundant control plane to provide durability and resilience.
Behavior during a zone failure
This section describes what to expect when you deploy Application Gateway for Containers in a region that supports availability zones and one of the zones used by the service has an outage.
Detection and response: Application Gateway for Containers redirects traffic to infrastructure in the remaining healthy zones during a zone outage. You don't need to take action for the gateway's traffic redistribution.
However, you're responsible for the effect of the outage on your Kubernetes cluster and backend applications.
- Notification: Microsoft doesn't automatically notify you when a zone is down. However, you can use Azure Service Health to understand the overall health of the service, including any zone failures, and you can set up Service Health alerts to notify you of problems.
Active requests: Existing connections to the failed zone are dropped. Clients should retry the requests by following the guidance in Resilience to transient faults. New connections are established to infrastructure in the remaining healthy zones.
Expected data loss: Application Gateway for Containers doesn't store application data. The platform manages configuration state through the zone-redundant control plane to provide durability and resilience.
Expected downtime: Clients might experience a brief interruption when connections to the failed zone are dropped. Clients should retry requests to establish new connections to infrastructure in the remaining healthy zones.
The Azure-managed control plane remains available during a single-zone outage. However, your ability to apply configuration updates also depends on the availability of your Kubernetes control plane and ALB Controller.
Redistribution: Application Gateway for Containers redirects traffic to infrastructure in the remaining healthy zones.
Zone recovery
Application Gateway for Containers self-recovers from underlying problems. Azure manages recovery of the gateway infrastructure.
Test for zone failures
The Application Gateway for Containers platform manages traffic routing and the response to zone failures for the gateway itself. You don't need to initiate or manage the gateway's response. If you have a Kubernetes cluster that you manage, you can use Azure Chaos Studio to test the cluster's response to zone failures. For more information, see Test for availability zone resiliency.
Resilience to region-wide failures
Application Gateway for Containers is a single-region service. If the Azure region where you deployed a gateway becomes unavailable, that gateway is unavailable.
Custom multiregion solutions for resiliency
Application Gateway for Containers doesn't provide a built-in multiregion deployment or failover solution. To design for a region outage, deploy and configure a separate gateway and Kubernetes cluster in each region. You're responsible for directing traffic between the regional gateways and configuring failover.
Configure Application Gateway for Containers consistently across regions. To simplify deployments and keep configurations aligned, define your infrastructure as code (IaC) by using tools like Bicep or Terraform.
Choose and configure a global traffic management service, such as Azure Front Door or Azure Traffic Manager, to direct clients to your regional gateways. These services use different routing models and health-probe configurations. Configure the selected service to direct traffic away from an unavailable gateway, and review its documentation to understand routing behavior and failover considerations. Azure Front Door also provides capabilities such as distributed denial-of-service (DDoS) protection, web application firewall (WAF) capabilities, and rules-based routing.
Deploy your backend applications in each region and configure them to provide healthy workloads during an outage. If your applications depend on data or other Azure services, design and configure those services for multiregion availability as well. Review the reliability guidance for each service to understand its multiregion options and limitations.
Backup and restore
Application Gateway for Containers doesn't store application data. Azure Resource Manager stores the gateway's Azure resource configuration. You can recreate these resources by redeploying their configuration.
You're responsible for preserving the configuration and Kubernetes resources that define how the gateway is deployed and routes traffic:
Define the Azure resources and their settings in infrastructure as code (IaC), such as Bicep or Terraform, and keep the definitions in version control. You can use them to redeploy the gateway resources.
Back up the Kubernetes resources that configure the gateway, such as
ApplicationLoadBalancer,Gateway, andHTTPRouteresources. Restore them to your cluster when you need to recreate the routing configuration.Preserve related configuration, including custom rules and web application firewall policies, in version control or through your standard configuration backup process. You can use deployment pipelines to recreate the Azure and Kubernetes resources consistently.
Resilience to service maintenance
Microsoft manages maintenance for Application Gateway for Containers while maintaining the service's high availability.
The required minimum subnet size of /24 for each association accounts for maintenance windows, so you don't need to allocate extra subnet IP address space for maintenance.
For more information, see Scaling and availability for Application Gateway for Containers.
Service-level agreement
The service-level agreement (SLA) for Azure services describes the expected availability of each service and the conditions that your solution must meet to achieve that availability expectation. For more information, see SLAs for online services.
The Application Gateway for Containers SLA measures the control plane and data plane separately. Both planes are factored into the overall SLA calculation.