Container Service for Kubernetes:Zone-disaster recovery with an ACK One MSE multi-cluster gateway

Deploy using the Argo CD UI

1. Log on to the ACK One console. In the left-side navigation pane, choose Fleet > Multi-cluster Applications.

2. On the Multi-cluster GitOps page, click GitOps Console.

   If GitOps is not yet enabled, click Enable GitOps. To access GitOps over the public network, see Enable public access to Argo CD.

3. Add the application repository.

   1. In the Argo CD left-side navigation pane, click Settings, then choose Repositories > + Connect Repo.

   2. Configure the following parameters and click CONNECT.

      Section	Parameter	Value
      Choose your connection method	—	VIA HTTP/HTTPS
      CONNECT REPO USING HTTP/HTTPS	Type	git
      	Project	default
      	Repository URL	https://github.com/AliyunContainerService/gitops-demo.git
      	Skip server verification	Select this checkbox

      

      When the connection succeeds, CONNECTION STATUS shows Successful.

      

4. Create an application for each cluster. On the Applications page, click + NEW APP and configure the following parameters. Repeat this step for Cluster 2, substituting the cluster URL and envCluster value accordingly.

   Section	Parameter	Value
   GENERAL	Application Name	A unique name for the application
   	Project Name	default
   	SYNC POLICY	Manual (sync on demand) or Automatic (Argo CD checks the Git repository every 3 minutes and deploys changes automatically)
   SYNC OPTIONS	—	Select AUTO-CREATE NAMESPACE
   SOURCE	Repository URL	https://github.com/AliyunContainerService/gitops-demo.git
   	Revision	Branches: gateway-demo
   	Path	manifests/helm/web-demo
   DESTINATION	Cluster URL	Select the URL for Cluster 1 (or Cluster 2 for the second app)
   	Namespace	gateway-demo
   Helm > Parameters	envCluster	cluster-demo-1 for Cluster 1, cluster-demo-2 for Cluster 2

Deploy using the Argo CD CLI

1. Add the Git repository.

   argocd repo add https://github.com/AliyunContainerService/gitops-demo.git --name ackone-gitops-demos

   Expected output:

   Repository 'https://github.com/AliyunContainerService/gitops-demo.git' added

2. Verify the repository was added and confirm both clusters are registered.

   argocd repo list

   Expected output:

   TYPE  NAME  REPO                                                       INSECURE  OCI    LFS    CREDS  STATUS      MESSAGE  PROJECT
   git         https://github.com/AliyunContainerService/gitops-demo.git  false     false  false  false  Successful           default

   argocd cluster list

   Expected cluster list output:

   SERVER                          NAME                                        VERSION  STATUS      MESSAGE                                                  PROJECT
   https://1.1.XX.XX:6443      c83f3cbc90a****-temp01   1.22+    Successful
   https://2.2.XX.XX:6443      c83f3cbc90a****-temp02   1.22+    Successful
   https://kubernetes.default.svc  in-cluster                                           Unknown     Cluster has no applications and is not being monitored.

3. Create the application manifest. Replace repoURL with your actual repository URL, and replace ${cluster1_url} and ${cluster2_url} with the cluster API server URLs from the previous step. apps-web-demo.yaml

   apiVersion: argoproj.io/v1alpha1
   kind: Application
   metadata:
     name: app-demo-cluster1
     namespace: argocd
   spec:
     destination:
       namespace: gateway-demo
       # https://1.1.XX.XX:6443
       server: ${cluster1_url}
     project: default
     source:
       helm:
         releaseName: "web-demo"
         parameters:
         - name: envCluster
           value: cluster-demo-1
         valueFiles:
         - values.yaml
       path: manifests/helm/web-demo
       repoURL: https://github.com/AliyunContainerService/gitops-demo.git
       targetRevision: gateway-demo
     syncPolicy:
       syncOptions:
       - CreateNamespace=true
   ---
   apiVersion: argoproj.io/v1alpha1
   kind: Application
   metadata:
     name: app-demo-cluster2
     namespace: argocd
   spec:
     destination:
       namespace: gateway-demo
       server: ${cluster2_url}
     project: default
     source:
       helm:
         releaseName: "web-demo"
         parameters:
         - name: envCluster
           value: cluster-demo-2
         valueFiles:
         - values.yaml
       path: manifests/helm/web-demo
       repoURL: https://github.com/AliyunContainerService/gitops-demo.git
       targetRevision: gateway-demo
     syncPolicy:
       syncOptions:
       - CreateNamespace=true

4. Deploy the applications.

   kubectl apply -f apps-web-demo.yaml

5. Verify both applications are synced and healthy.

   argocd app list

   Expected output:

   NAME                      CLUSTER                  NAMESPACE  PROJECT  STATUS  HEALTH   SYNCPOLICY  CONDITIONS  REPO                                                       PATH                     TARGET
   argocd/web-demo-cluster1  https://10.1.XX.XX:6443             default  Synced  Healthy  Auto        <none>      https://github.com/AliyunContainerService/gitops-demo.git  manifests/helm/web-demo  main
   argocd/web-demo-cluster2  https://10.1.XX.XX:6443             default  Synced  Healthy  Auto        <none>      https://github.com/AliyunContainerService/gitops-demo.git  manifests/helm/web-demo  main

Active zone-redundancy

In active zone-redundancy mode, traffic is load-balanced across all cluster backends by replica ratio. If a cluster becomes unhealthy, the gateway automatically reroutes its traffic share to the remaining healthy clusters.

Example: With 9 replicas in Cluster 1 and 1 replica in Cluster 2, 90% of traffic goes to Cluster 1 and 10% to Cluster 2 by default. If all Cluster 1 backends fail, 100% of traffic shifts to Cluster 2.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-demo
spec:
  ingressClassName: mse
  rules:
  - host: example.com
    http:
      paths:
      - path: /svc1
        pathType: Exact
        backend:
          service:
            name: service1
            port:
              number: 80

kubectl apply -f ingress-demo.yaml -n gateway-demo

Primary/secondary disaster recovery

In primary/secondary mode, all traffic goes to Cluster 1 (primary) under normal conditions. If Cluster 1 becomes unhealthy, the gateway automatically reroutes traffic to Cluster 2 (secondary).

This mode uses two MSE-specific annotations to pin Ingress routes to a specific cluster:

For a complete list of MSE Ingress annotations, see Annotations supported by MSE Ingress gateways.