GitOps made simple: orchestrating multi-cluster app delivery with Argo CD ApplicationSet and Image Updater

GitOps is like a well-curated playlist: you want the source (your Git repo) to define the order, the versions, and the mood — and the player (your cluster) to follow it without someone manually changing the track mid-play. Argo CD already acts as that player. Two relatively recent pieces in the Argo CD ecosystem—ApplicationSet and Argo CD Image Updater—make that playlist scale across many clusters and keep the songs (container images) fresh automatically. This article explains how those two fit together, what they buy you, and where the scratches on the record can happen.

What each piece does, in plain language

• ApplicationSet: Think of it as a generator + template. It can take a list of clusters, Git directories, or other inputs and produce many Argo CD Application resources from a single, templated spec. That makes spinning the same app across 10 clusters feel like editing one file and pressing “generate.” (argo-cd.readthedocs.io)
• Argo CD Image Updater: This controller watches image registries for new tags (or digests) and can apply updates either by calling the Argo CD API (setting parameter overrides) or by committing changes back to your Git repo (the preferred GitOps-friendly mode). It supports configurable write-back methods, including pushing commits or opening pull requests. (argocd-image-updater.readthedocs.io)
• The operator integration: If you run Argo CD via the operator, the Image Updater can be enabled as an optional workload through the ArgoCD CR, simplifying lifecycle management. (argocd-operator.readthedocs.io)

Why combine them? A compact use case

• You maintain a single repo of “desired manifests” (or an app-of-apps structure).
• ApplicationSet templates one app per cluster (or per environment), so 50 clusters = one source-of-truth manifest that generates 50 Applications.
• Image Updater watches the registries you build into (CI-built images). When a new approved image appears, it writes the new tag back to the Git-managed manifest (or updates via the API if you accept that trade-off).
• Argo CD then reconciles each generated Application across clusters, keeping the runtime in lockstep with Git.

A minimal conceptual ApplicationSet snippet

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
spec:
  generators:
    - cluster:
        selector:
          matchLabels:
            environment: prod
  template:
    metadata:
      name: '-myapp'
    spec:
      source:
        repoURL: https://github.com/myorg/myapp-configs
        path: apps/myapp
      destination:
        server: ''
        namespace: myapp

That one template can expand to one Application per cluster selected by label. The generator does the heavy lifting so you don’t copy-paste 50 manifests. (argo-cd.readthedocs.io)

How Image Updater keeps the playlist current Image Updater can run as a separate controller and decide whether to:

• Make an imperative override via the Argo CD API (fast, but the deployed value lives in Argo CD, not Git), or
• Commit the change to the config repo (keeps Git as the single source of truth). The latter is best aligned with strict GitOps practice, and the Image Updater supports configuring credentials and modes (including pull-request workflows). (argocd-image-updater.readthedocs.io)

Practical wins and the trade-offs (the good and the honest) Wins

• Scale without repetition: One ApplicationSet can generate dozens or hundreds of Applications, keeping your repo tidy. (argo-cd.readthedocs.io)
• Safer automation: Image Updater removes the “someone manually edits the tag” step and integrates image discovery with the GitOps loop. (argocd-image-updater.readthedocs.io)
• Operator-friendly: If you use the Argo CD operator, Image Updater can be managed like other Argo workloads. (argocd-operator.readthedocs.io)

Trade-offs and gotchas

• Write-back trust and credentials: letting a controller commit to your repo requires credential management and audit thinking—this is an operational and security decision. (argocd-image-updater.readthedocs.io)
• Timing and race conditions: if multiple systems (CI, Image Updater, manual updates) are writing the same manifests or if auto-sync triggers before the registry and values converge, you can hit race conditions that produce failed rollouts or unexpected versions. Planning sync windows, promotion gates, or pull-request workflows helps mitigate that. Operational write-ups and community experience have flagged these timing pitfalls. (burrell.tech)
• API overrides vs Git truth: updating via the Argo CD API breaks the canonical Git history. If strict auditability matters, prefer Git write-back modes or pull requests. (argocd-image-updater.readthedocs.io)

A few realistic patterns (non-prescriptive descriptions)

• Git-first automation: Image Updater writes a commit (or opens a PR) with the new tag; team reviews or CI checks; Argo CD syncs once merged. This preserves audit trails.
• Fast-track for internal builds: Image Updater updates via API for short-lived branches or internal feature clusters where Git noise is undesirable; however, this sacrifices single-source-of-truth guarantees.
• Hybrid: use ApplicationSet for mass templating + Image Updater with PR-based write-back for production clusters and API mode for developer sandboxes.

Closing note — the orchestra conductor, not the soloist ApplicationSet and Image Updater together turn Argo CD from a great single-cluster player into a conductor for a multi-cluster orchestra, with Git as the score and registries as the instrument tuners. They’re practical, increasingly mature tools—and like any music setup, the improvements come with tuning: access control, timing, and testing matter. Official docs and operator integrations continue to evolve, and operator-enabled Image Updater options and write-back modes are now first-class considerations in a production GitOps setup. (argocd-operator.readthedocs.io)