Using Argo CD ApplicationSet to Deploy the Same App Across Multiple Clusters

The problem: repetitive Application manifests for each cluster

When you operate several Kubernetes clusters (dev, staging, prod) and want to run the identical set of services in each, you typically copy‑paste an Application manifest for every environment. Any change to the source repository, Helm chart version, or sync policy requires editing each file, which is error‑prone and tedious.

Thesis: ApplicationSet lets you define a single template and let a generator create one Application per cluster automatically

Argo CD’s ApplicationSet controller watches a custom ApplicationSet resource. A generator (e.g., List, Cluster, Git, Matrix) produces a list of items; for each item the controller renders an Application from a shared template. The generated Applications inherit the template’s source, destination, and sync policy, and can be further customized with template overlays.

Worked example: deploying a guestbook app to three clusters using a List generator

1. Prerequisites: Argo CD v2.0+ installed with the ApplicationSet controller enabled (default). You have kubectl and argocd CLI configured with a user that can create ApplicationSet and Application objects in the argocd namespace (typically cluster‑admin or a role bound to the applicationsets.argoproj.io resource).
2. Create the ApplicationSet manifest (save as guestbook-appset.yaml):

   apiVersion: argoproj.io/v1alpha1
   kind: ApplicationSet
   metadata:
     name: guestbook-cluster-set
     namespace: argocd
   spec:
     generators:
       - list:
           elements:
             - cluster: dev
               url: https://dev-cluster.example.com:6443
             - cluster: staging
               url: https://staging-cluster.example.com:6443
             - cluster: prod
               url: https://prod-cluster.example.com:6443
     template:
       metadata:
         name: '{{cluster}}-guestbook'
       spec:
         project: default
         source:
           repoURL: https://github.com/argoproj/argocd-example-apps.git
           targetRevision: HEAD
           path: guestbook
         destination:
           server: '{{url}}'
           namespace: guestbook
         syncPolicy:
           automated:
             prune: true
             selfHeal: true
   

3. Apply the manifest (run on your admin workstation): kubectl apply -f guestbook-appset.yaml
4. Verify generated Applications:
   kubectl get applications -n argocd -l argocd.argoproj.io/application-set=guestbook-cluster-set
   You should see three Applications named dev-guestbook, staging-guestbook, and prod-guestbook, each pointing to its respective cluster.
5. Inspect one generated Application (optional): argocd app get dev-guestbook Check that the destination.server matches the dev cluster URL and that the sync policy is automated.

Trade‑off and limitation: extra controller load and potential for unexpected Application counts

The ApplicationSet controller adds a reconciliation loop that watches the generator and updates generated Applications. For a modest number of clusters (as in the example) the impact is negligible. However, if you use a Matrix generator with many dimensions or a Git generator that scans a large repository, the controller may create dozens or hundreds of Applications, increasing API server pressure and sync latency. Argo CD recommends running a dry‑run first: set spec.syncPolicy.automated.prune: false and spec.syncPolicy.automated.selfHeal: false temporarily, or use argocd app set --prune=false --self-heal=false on the ApplicationSet to observe the generated list without mutating the cluster.

Practical way to check the result after any change: run kubectl get applications -l argocd.argoproj.io/application-set=<your‑set> -o wide and verify that the NAME, DESTINATION, and SYNC STATUS columns match expectations. If you see an unexpected surge in Application objects, inspect the generator output with kubectl get applicationset <name> -o yaml and adjust the generator or add a limit field.

Actionable closing: start small, monitor, then scale

Begin with a simple List or Cluster for a handful of environments. Use the kubectl get applications command to confirm the generated Applications appear as expected. Monitor API server request rates (e.g., via kubectl top nodes or your cluster’s metrics) while you scale the number of generated Applications. If latency rises, consider splitting the ApplicationSet into multiple sets or pruning unused generators. By treating the ApplicationSet as a single source of truth for your multi‑cluster deployments, you reduce manifest duplication and gain consistent sync behavior across all clusters.