Master Multi‑Cluster GitOps with ACK One and ArgoCD – A Step‑by‑Step Guide

Overview

ACK One is Alibaba Cloud’s distributed cloud container platform that unifies management of Kubernetes clusters across Alibaba Cloud, edge, on‑premises data centers, and other clouds. Its GitOps feature enables declarative, Git‑driven continuous delivery across multiple clusters.

GitOps Basics

GitOps stores application deployment manifests in a Git repository, treating the repository as the single source of truth. The system continuously reconciles the desired state in Git with the actual state in each Kubernetes cluster.

Key Advantages

Simple to learn – developers are already familiar with Git.

Strong reliability – version control, fast rollback, and audit capabilities.

High security – only Git repository permissions are required, no direct cluster access.

Continuous deployment – automatic synchronization between Git and clusters.

ACK One GitOps Features

Hosted ArgoCD with native CLI and UI.

Dedicated ArgoCD console domain integrated with Alibaba Cloud SSO and multi‑user permissions.

Automatic association of managed clusters to ArgoCD for multi‑cluster application distribution.

Support for ArgoCD Applicationset to simplify multi‑cluster deployments.

Out‑of‑the‑box experience, no additional operations required.

Prerequisites

Enable multi‑cluster management in ACK One (see the “Enable Multi‑Cluster Management” documentation).

Add the target clusters to the control‑plane instance (e.g., ackpro-cluster1 and ackpro-cluster2).

Obtain the control‑plane KubeConfig and connect with kubectl.

Install the latest Alibaba Cloud CLI and configure credentials (grant AliyunAdcpFullAccess to sub‑accounts if needed).

Install the ArgoCD CLI.

Step 1 – Enable GitOps on the Control Plane

Run the following command, replacing <clusterid> with your control‑plane instance ID:

aliyun adcp UpdateHubClusterFeature --ClusterId <clusterid> --ArgoCDEnabled true

The command creates an Elastic Container Instance (ECI) that runs the ArgoCD server, exposes it via an internal SLB, and generates a domain name such as:

https://argocd.<ackone‑cluster‑id>.<region>.alicontainer.com

Verify the deployment:

# List ArgoCD pods
kubectl get pod -n argocd
# Show ArgoCD server URL
kubectl get cm argocd-cm -n argocd -o json | jq .data.url

Step 2 – Deploy an Application via the ACK One Console

Log in to the ArgoCD server using SSO (the CLI opens a browser for authentication).

Add the Git repository:

argocd repo add https://github.com/AliyunContainerService/gitops-demo.git --name echo-server

Create the application targeting a specific cluster:

argocd app create echo-server \
  --repo https://github.com/AliyunContainerService/gitops-demo.git \
  --path manifests/helm \
  --revision one-demo \
  --dest-namespace default \
  --dest-server https://10.0.47.122:6443

Synchronize the application to deploy it: argocd app sync echo-server After sync, the application status shows Healthy and Synced . You can view the resource topology and details in the ArgoCD UI.

Step 3 – Verify Deployment

Connect to the control‑plane instance and list resources in the target cluster:

# List managed clusters
kubectl amc get managedcluster
# Show resources in the default namespace of cluster <code>cexxx</code>
kubectl amc get all -n default -m cexxx

Access the LoadBalancer service to confirm the running version:

curl http://39.xxx.xxx.xxx:8080/version
"Hello Echo Server v1.0"

Step 4 – Upgrade Application Version

Update the image tag in the Git repository from v1.0 to v2.0. ArgoCD detects the change, marks the application OutOfSync , and you can trigger a sync: argocd app sync echo-server After sync, the service returns "Hello Echo Server v2.0".

Step 5 – Roll Back to a Previous Version

Use the ArgoCD UI “History and Rollback” feature to select version v1.0 and roll back. The application becomes OutOfSync until you sync again.

Managing User Permissions

ArgoCD RBAC is configured via a ConfigMap. Example policy:

data:
  policy.csv: |
    g, "26xxx", role:admin   # admin user
    g, "27xxx", role:readonly   # read‑only user

Roles role:admin and role:readonly are built‑in. Custom policies can be added as needed.

Multi‑Cluster Deployment with Applicationset

Applicationset generates multiple ArgoCD Application objects from a list of clusters. Example manifest:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: echo-server
  namespace: argocd
spec:
  generators:
  - list:
      elements:
      - cluster: production
        url: https://10.xxx.xxx.xxx:6xxx
      - cluster: staging
        url: https://10.xxx.xxx.xxx:6xx
  template:
    metadata:
      name: '{{cluster}}-gitops-demo'
    spec:
      project: default
      source:
        repoURL: https://github.com/AliyunContainerService/gitops-demo.git
        targetRevision: one-demo
        path: manifests/directory/{{cluster}}
      destination:
        server: '{{url}}'
        namespace: one-demo

After applying, two applications are created, each pulling manifests from the corresponding directory (production or staging) and deploying to its cluster.

CI/CD Integration with ArgoCD Image Updater

ACK One GitOps bundles the open‑source ArgoCD Image Updater, extended to support Alibaba Cloud Container Registry (ACR). When a new image is pushed to ACR, the updater modifies the Git repository’s image tag, triggering ArgoCD to sync and deploy the new version automatically.

For a full end‑to‑end CI + CD workflow, see the Image Updater documentation linked in the references.

References

ACK One product page: https://www.aliyun.com/product/aliware/adcp

ACK One console: https://cs.console.aliyun.com/one

ArgoCD official docs: https://argo-cd.readthedocs.io

ArgoCD Applicationset: https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/

ArgoCD Image Updater: https://argocd-image-updater.readthedocs.io/