GitOps addon delivery for every cluster_

the problem

Platform addons were being installed by hand, per cluster, by whoever built the cluster. Versions drifted, security agents were missing where they mattered most, and nobody could answer "which clusters run which version of what?" without spelunking.

the design

Three GitOps primitives composed into a fleet-wide delivery system:

 ApplicationSet (cluster generator, label selector: environment)
        │  discovers every registered cluster automatically
        ▼
 app-of-apps Helm chart (per env: dev / qa / prod)
        │  one Application per addon, rendered per cluster
        ▼
 git inventory repo
   └── {account_alias}/{cluster}/enabler.yaml   ◄── one-line change
        │        "traefik: enabled, version X"        enables an addon
        ▼
 ArgoCD syncs ──► addon lands on cluster, drift auto-corrected

New clusters join the platform just by being registered with the right labels — the ApplicationSet discovers them and reconciles their addon set from the inventory. No pipelines, no tickets, no kubectl.

engineering details

Multi-source Applications. Chart logic lives in one repo, per-cluster values in another (the inventory), combined at render time — teams change what runs without touching how it runs.

Per-environment promotion. Dev, QA, and prod each have their own chart and ApplicationSet, so an addon version rolls through environments the same way application code does.

Cluster identity injected. Cluster name, account alias, environment, and app code flow into every addon via generator parameters — one chart serves hundreds of differently-named clusters with correct, cluster-specific configuration.

Everything auditable. The Git log of the inventory repo is the change history of the fleet's platform layer.

from the code

The load-bearing lines of the whole platform are in the ApplicationSet's multi-source spec — generator labels flow into both the Helm parameters and the path of the per-cluster values file (sanitized):

sources:
  - path: helm-charts/dev                # how addons deploy — one repo
    helm:
      parameters:
        - { name: global.clusterName, value: "{{name}}" }
      valueFiles:                        # what each cluster runs — inventory repo
        - $Values/inventory-dev/{{metadata.labels.account_alias}}/{{name}}/enabler.yaml
  - ref: Values

Everything else follows from that one templated path: per-cluster truth is a folder in Git, new clusters are discovered by label, and "what runs where" has exactly one source.

impact

Addon rollouts went from per-cluster manual work to a Git commit and a sync wave. Drift self-heals, security coverage is provable, and "which clusters run what" is a git grep away.