Server Load Balancer:Use ALB multi-cluster gateways of ACK One to implement geo-disaster recovery

How it works

The solution combines two traffic control mechanisms: an ALB multi-cluster gateway for intelligent in-flight routing, and Global Traffic Manager (GTM) for DNS-level failover as a last resort.

Region 1 hosts ACK Cluster 1, the ACK One Fleet instance, and the ALB multi-cluster gateway. Region 2 hosts ACK Cluster 2 with an ALB Ingress controller installed; installing the controller automatically creates an ALB instance (ALB 2) that serves as a cold backup.

The ACK One Fleet instance routes traffic to ACK Cluster 1 and ACK Cluster 2 based on request headers or by using the zero round-trip time (0-RTT) feature of the Quick UDP Internet Connections (QUIC) protocol. This way, ACK Cluster 1 and ACK Cluster 2 serve as the backup of each other.

The two clusters are connected via Cloud Enterprise Network (CEN) or Virtual Private Cloud (VPC) peering connections, with traffic forwarded across regions through Express Connect circuits. Data synchronization relies on ApsaraDB RDS and has middleware dependencies.

Use cases

This solution fits well when:

• Resources in your primary region are insufficient and you need cross-region high availability — for example, GPU resource shortages during high AI demand.

• Your workloads can tolerate some latency increase but require centralized multi-cluster traffic management.

Prerequisites

Before you begin, make sure you have:

• A GTM instance purchased

• The Fleet management feature enabled

• The kubeconfig file of the Fleet instance, obtained from the ACK One console, with kubectl connected to the Fleet instance

Step 1: Plan the cluster network and configure cross-region communication

1. Plan the network layout:

   1. Place ACK Cluster 1 and ACK Cluster 2 in different regions. The node CIDR block and pod CIDR block of the two clusters must not overlap.

   2. Place the ACK One Fleet instance and ACK Cluster 1 in the same region and VPC.

   3. Connect the VPC in Region 1 to the VPC in Region 2. For details, see Network connectivity. If you use CEN, see Manage inter-region connections.

   4. After connecting the VPCs, configure security groups for ACK Cluster 1 and ACK Cluster 2 to allow inbound access from the VPC where the ALB multi-cluster gateway resides. For details, see Configure security groups for clusters.

   For an end-to-end network design reference, see Network design for Fleet management.

2. Associate ACK Cluster 1 and ACK Cluster 2 with the ACK One Fleet instance. For details, see Manage associated clusters.

Step 2: Configure the ALB multi-cluster gateway

For a complete walkthrough, see Build a zone-disaster recovery system.

1. Distribute your application to ACK Cluster 1 and ACK Cluster 2 using GitOps or the application distribution feature to keep application state consistent across clusters.

2. On the Fleet instance, configure an AlbConfig to create the ALB multi-cluster gateway, then add both ACK Cluster 1 and ACK Cluster 2 to the gateway.

3. Create routing rules and Ingresses on the Fleet instance. The following example assigns 20% of traffic to Cluster 1 and 80% to Cluster 2. For more routing options, see Traffic management in different scenarios and Configure Ingresses.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     annotations:
       alb.ingress.kubernetes.io/listen-ports: |
        [{"HTTP": 8001}]
       alb.ingress.kubernetes.io/cluster-weight.${cluster1-id}: "20"
       alb.ingress.kubernetes.io/cluster-weight.${cluster2-id}: "80"
     name: web-demo
     namespace: gateway-demo
   spec:
     ingressClassName: alb
     rules:
     - host: alb.ingress.alibaba.com
       http:
         paths:
         - path: /svc1
           pathType: Prefix
           backend:
             service:
               name: service1
               port:
                 number: 80

Step 3: Back up Ingresses regularly

Back up the Ingresses and AlbConfigs in the ACK One Fleet instance in Region 1 on a regular schedule. If Region 1 fails, the system synchronizes the backup Ingresses to ACK Cluster 2, allowing ALB 2 to route traffic to backend services there.

You can use custom backup methods. For example, store backups in an Object Storage Service (OSS) bucket in Region 2.

Step 4: Configure primary/secondary disaster recovery with GTM

After completing Steps 1–3, the ALB multi-cluster gateway handles failover automatically when cluster or service errors occur in either region. To protect against geological disasters or ALB failures in Region 1 — scenarios where the gateway itself becomes unavailable — configure GTM as an additional failover layer.

1. In ACK Cluster 2, use an ALB Ingress to create an ALB instance in Region 2. For details, see Create an AlbConfig.

2. In GTM, specify the IP address of the ALB multi-cluster gateway in Region 1 and the domain name of ALB 2 in Region 2, configured in primary/secondary mode. GTM switches traffic to Region 2 based on health check results when Region 1 becomes unhealthy. For setup instructions, see Use GTM to implement primary/secondary disaster recovery.

When GTM switches traffic, your service may remain interrupted for a long period of time due to the DNS cache on clients.

What's next

• Build a zone-disaster recovery system

• Traffic management in different scenarios

• Network design for Fleet management