SYSTEM Cited by 2 sources

ArgoCD¶

ArgoCD is a CNCF-graduated GitOps continuous-delivery controller for Kubernetes. A Git repository declares the desired state of a set of Kubernetes manifests (Deployments, Services, CRDs, …); ArgoCD runs as a K8s controller that continuously compares cluster state with the repo and either syncs automatically or flags drift for operator review.

The load-bearing design property is Git as the single source of truth (gitops) — deploys happen by merging a pull request, not by running a CLI; rollbacks happen by reverting a commit; audit trail is the commit log.

ArgoCD pairs naturally with Crossplane to form a uniform Kubernetes-API control surface for both applications and infrastructure: Crossplane makes cloud resources look like K8s CRs, ArgoCD reconciles any K8s CRs including Crossplane's. One GitOps workflow covers both layers.

Multi-source Applications (v2.6+)¶

Argo CD's multi-source Application feature (GA in v2.6, early 2023) allows a single Application CRD to reference multiple sources — canonical example being one repoURL for an upstream Helm chart and a separate repoURL for the customer's values file. The Helm source references the values source via a named ref: label. This decouples chart maintenance from customer config ownership — see argocd-multi-source-helm-plus-values for the canonical wiki pattern.

Helm + Kustomize composition¶

Argo CD auto-detects the build tool from the source directory contents: Chart.yaml → Helm, kustomization.yaml → Kustomize, plain YAML → directly applied. When Kustomize is used to wrap a Helm chart via helmCharts (see kustomize-wraps-helm-chart), Argo CD needs kustomize.buildOptions: --enable-helm on the argocd-cm ConfigMap — Kustomize's Helm inflation is off by default for supply-chain reasons. Enabling it is a platform-wide toggle (affects all Applications).

Runtime-API tension¶

Under a GitOps deployment shape, runtime CRUD APIs (Kubernetes API, and increasingly application-level REST APIs like Redpanda Connect Streams-mode) can either be GitOps-aligned (automation derives calls from Git) or GitOps anti-patterns (humans mutate runtime state without Git commit). Argo CD's selfHeal: true + prune: true sync policy aggressively reverts non-Git drift — compatible with the aligned shape, hostile to the anti-pattern shape. See runtime-api-vs-gitops-source-of-truth.

Seen in¶

sources/2025-12-02-redpanda-operationalize-redpanda-connect-with-gitops — canonical Argo CD multi-source + Kustomize-Helm composition wiki instance. 2025-12-02 Redpanda unsigned tutorial ships two Argo CD Applications for Redpanda Connect — one using the multi-source Helm + values split for Standalone mode, one using Kustomize-wraps-Helm for Streams mode. kustomize.buildOptions: --enable-helm --load-restrictor LoadRestrictionsNone patched onto argocd-cm + repo-server + application-controller rollout-restart as preconditions. sync policy: { automated: { prune: true, selfHeal: true } } on both. Canonical instance of the observability stack (kube-prometheus-stack) as a parallel Argo CD Application alongside the primary workload.
sources/2026-02-26-aws-santander-catalyst-platform-engineering — Santander Catalyst's data-plane claims component is "managed by ArgoCD, a continuous delivery tool ... responsible for continuous synchronization and deployment of application stacks (integrated sets of cloud resources) and configurations, exploring the GitOps concept." Paired with Crossplane (stacks catalog) + OPA Gatekeeper (policies catalog) on the same EKS control plane cluster.

Stub page — ArgoCD internals (app-of-apps pattern, sync waves, ApplicationSet, Rollouts integration) out of scope until a future source drills into them.

ApplicationSet as tenant-provisioning control plane¶

ReadyOn uses an Argo CD ApplicationSet as Wall 1 of a four-layer EKS tenant-isolation model. Onboarding a tenant is a single entry in a Git config manifest; the ApplicationSet then generates all per-tenant resources — namespace, network policies, RBAC bindings, resource quotas, secrets configurations — so every tenant gets an identical security posture by construction, with no "legacy" tenants on weaker policies. The GitOps controller continuously reconciles live cluster state against Git and reverts any manual or unauthorized modification within seconds (a human operator never runs kubectl apply against production). Combined with zero-secrets-in-Git (the External Secrets Operator resolves references to Secrets Manager at deploy time), even repo compromise yields no usable credentials — a secure-by-construction posture (see patterns/default-on-security-upgrade). This is the canonical wiki example of Argo CD ApplicationSet used as a security templating + drift-correction control plane for multi-tenancy. (Source: sources/2026-09-18-aws-readyons-four-walls-of-tenant-isolation-on-amazon-eks)

gitops — the declarative-state-in-Git-reconciled-to- cluster property ArgoCD realizes
systems/crossplane — natural pairing for infrastructure alongside application delivery
systems/kubernetes — the target substrate
systems/helm — packaging layer Argo CD inflates when Chart.yaml is present or when Kustomize wraps a chart
systems/kustomize — overlay / generator layer Argo CD auto-detects via kustomization.yaml; needs --enable-helm for Helm-wrapping flows
systems/santander-catalyst — canonical production reference
systems/redpanda-connect — canonical Helm + Kustomize + Argo CD tutorial consumer
standalone-vs-streams-mode — deployment-mode decision that shapes which Argo CD pattern applies
configmap-hash-rollout — Kustomize mechanism Argo CD invokes for rolling restarts
runtime-api-vs-gitops-source-of-truth — Argo CD selfHeal + prune enforces this discipline
argocd-multi-source-helm-plus-values — canonical multi-source pattern
kustomize-wraps-helm-chart — canonical Helm + Kustomize composition pattern