Learn GitOps with ArgoCD - ApplicationSets - Advanced Application Management

#Introduction

In episode 10 we learned to restrict access with ArgoCD Projects. But there's a practical problem we haven't touched: creating the Application itself is still manual. For 3 applications that's fine; for 10 clusters × 5 teams × 4 applications — that's 200 Applications to write, maintain, and delete. Not realistic. In this episode we discuss ApplicationSet — an ArgoCD resource that defines an Application template and a generator engine that explodes it into dozens or hundreds of Applications automatically.

Why does this matter? ApplicationSet is ArgoCD's answer to scale. With a single YAML file, you can roll applications out to all clusters at once, promote environments by changing one line, or create a preview environment for every pull request. This is the feature that separates a "demo" setup from an "enterprise" setup.

#Motivation: The Problem It Solves

Without ApplicationSet, we face three problems:

1. Repetition — one Application per application × cluster × environment combination, nearly identical in content.
2. Lag — adding a cluster means rewriting all Applications manually.
3. Inconsistency — easy to typo when copying manifests over and over.

ApplicationSet answers with a single abstraction: a template (the Application shape) + a generator (the parameter source that determines how many Applications are produced and what they look like).

#ApplicationSet Structure

applicationset-guestbook.yaml

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
  namespace: argocd
spec:
  goTemplate: true
  generators:
    - list:
        elements:
          - cluster: dev
            url: https://kubernetes.default.svc
          - cluster: prod
            url: https://eks-prod.example.com
  template:
    metadata:
      name: guestbook-{{.cluster}}
    spec:
      project: default
      source:
        repoURL: https://github.com/argoproj/argocd-example-apps.git
        path: guestbook
      destination:
        server: '{{.url}}'
        namespace: guestbook

• generators defines the set of parameters. Here, list produces two elements: the dev and prod clusters.
• template is the Application skeleton; values like the cluster and url parameters are filled in from the generator.
• The generated Applications (guestbook-dev, guestbook-prod) are fully managed by the ApplicationSet controller — if parameters change, the Application is updated too.

#Generator Types

ApplicationSet provides seven generator types:

#List Generator

The simplest — exactly like the example above: a static list of elements, each becoming one Application.

#Cluster Generator

Reads the clusters registered in ArgoCD (from episode 9) and produces an Application for every cluster matching the label selector:

Cluster generator with a selector

spec:
  generators:
    - cluster:
        selector:
          matchLabels:
            env: prod
  template:
    metadata:
      name: '{{.name}}-guestbook'
    spec:
      source:
        repoURL: https://github.com/devnull/gitops-repo.git
        path: guestbook
      destination:
        server: '{{.server}}'
        namespace: guestbook

The name parameter comes from the cluster name, server from the API address, and cluster labels can be accessed through the metadata.labels field. Adding a new cluster labeled env=prod immediately creates a new Application automatically — without changing anything.

#Git Generator

Reads the Git repository structure:

• Directories — every subdirectory matching a pattern becomes one Application, with the path and path.basename parameters.
• Files — reads JSON/YAML files in the repo; every file key becomes a parameter. Great for a tenant list: create a tenant-a.json file, and ArgoCD produces an Application for tenant-a.

Git directories generator

spec:
  generators:
    - git:
        repoURL: https://github.com/devnull/gitops-repo.git
        revision: main
        directories:
          - path: apps/*
  template:
    metadata:
      name: '{{.path.basename}}'
    spec:
      source:
        repoURL: https://github.com/devnull/gitops-repo.git
        path: '{{.path}}'

#Matrix & Merge Generator

• Matrix produces the Cartesian product of two generators — for example all cluster x environment combinations. Two generators inside one matrix produce the combination of all parameters.
• Merge combines the parameters of two generators, with the priority that a second generator's parameters override the first's when names match.

#SCM Provider & Pull Request Generator

• SCM Provider queries a GitHub/GitLab organization and produces one parameter per repository — a way to deploy every repo in an organization without manual registration.
• Pull Request produces one Application per open PR. This is the foundation of PR preview: each PR builds a temporary environment, and its Application disappears automatically when the PR is closed.

PR generator for previews

spec:
  generators:
    - pullRequest:
        github:
          owner: devnull
          repo: billing-api
          labels: [preview]
  template:
    metadata:
      name: 'billing-pr-{{.number}}'
    spec:
      source:
        repoURL: https://github.com/devnull/billing-api.git
        path: manifests/overlays/preview
        targetRevision: '{{.head_sha}}'
      destination:
        namespace: 'billing-preview-{{.number}}'

#Real Use Cases

• Multi-cluster deployments — the cluster generator rolls applications out to all labeled clusters, e.g. env=prod.
• Monorepo — the git directories generator spawns one Application per apps/* folder.
• Environment promotion — change the targetRevision value per environment in the matrix generator: dev uses the dev branch, prod uses the v1.2.3 tag.
• Tenant provisioning — the git files generator reads the tenant list from a JSON file; adding a tenant means adding a file.
• PR preview — the pull request generator builds a preview environment per PR and cleans it up when the PR is closed.

#Parameter Substitution & Label Propagation

Every template field can be filled with generator parameters — name, path, namespace, even project. Labels and annotations written in template.metadata propagate to the generated Applications, so they can be used for UI filtering and integration with other tools (e.g. per-application monitoring tags). If you want labels generated from parameters, use templating on the label values too.

#Common Pitfalls

1. Forgetting goTemplate: true. Go template syntax (parameters with a leading dot, like cluster) is only valid when Go templates are enabled; without that flag, use dot-less notation. Inconsistency between the two often leaves manifests ungenerated.
2. A template invalid for some combinations. For example an application that needs a value missing from the matrix generator — make sure every combination produces a valid manifest.
3. Deleting Applications manually. Applications produced by a generator must not be deleted manually — the controller will recreate them. Verify with argocd app list, then remove them by changing the generator or deleting the ApplicationSet.
4. Overly wide cluster selector. An empty matchLabels means all clusters — including experimental ones. Always use explicit labels.
5. Forgetting PR preview resource limits. Per-PR preview environments can drain the cluster. Set maxResources or limit the number of allowed PRs.

#Closing

This episode opened up the power of ApplicationSet: the template-plus-generator structure, the seven generator types (list, cluster, git files/directories, matrix, merge, SCM provider, pull request), use cases from multi-cluster to PR preview, and how parameters replace parts of the Application template.

The points you should take with you:

• ApplicationSet = Application template + parameter generator, automatically managed by a controller.
• The cluster generator and git generator are the backbone of multi-cluster and monorepo.
• Matrix/merge enables flexible parameter combinations and overrides.
• The PR generator opens the door to automatic preview environments.
• Applications produced by a generator must not be deleted manually.

All these applications are still defined as manifests stored in Git — and that's where the classic GitOps problem arises: what about secrets? In the next episode 12 we discuss Secrets Management: a comparison of Sealed Secrets, External Secrets Operator, and SOPS, plus best practices for encryption, rotation, and RBAC for secrets. See you in episode 12!