Argo CD and Flux — One Application Controller versus a Set of Controllers

In one line

In Argo CD, three components — the API server, the repository server, and the application controller — revolve around a single resource called Application, while Flux is assembled from source, kustomize, helm, notification, and image controllers, each handling its own CRDs. For notifications and metrics, both tools attach in standard ways (annotations/CRDs, Prometheus).

Why this was needed

The Tooling domain (14%) of CGOA does not stop at knowing that "Argo CD and Flux exist as reconcilers." It asks that the two tools implement the same principles with different structures, and so they differ in how they handle Helm, in whether there is a UI, and in how they solve multi-tenancy. In practice too, when choosing a tool, "which structure fits our team" is closer to the answer than "which one is better."

How it works

Argo CD — three components and the Application

These are the three components from the official architecture documentation. The API server is a gRPC/REST server that provides the API used by the Web UI, the CLI, and CI/CD systems, and it handles application management and status reporting, invoking operations such as sync and rollback, managing repository and cluster credentials (K8s Secrets), delegating authentication to an external IdP, RBAC, and receiving Git webhooks. The repository server maintains a local cache of Git repositories and generates manifests, taking the repository URL, revision, path, and template settings (parameters, values) as input. The application controller continuously watches running applications, compares the actual state with the desired state, detects OutOfSync, and invokes the PreSync, Sync, and PostSync hooks.

Git/Helm/OCI  ──►  repo-server (렌더: helm template / kustomize build)
                        │
                        ▼
              application-controller ──► 클러스터(들)   비교·sync·훅
                        ▲
UI / CLI / CI  ──►  api-server (RBAC, 인증, 웹훅 수신)

Flux — a combination of GitOps Toolkit controllers

Flux is a bundle of dedicated controllers, composable APIs, and Go packages called the "GitOps Toolkit," and each controller handles only its own CRDs.

Controller	CRD	What it does
source-controller	GitRepository, OCIRepository, HelmRepository, HelmChart, Bucket	Checks sources periodically, produces artifacts (tar.gz), and serves them inside the cluster
kustomize-controller	Kustomization	Builds an artifact with Kustomize and applies it, SOPS decryption, service account impersonation, health assessment, depends-on ordering, cleanup of removed objects (prune)
helm-controller	HelmRelease	Performs real Helm actions (install, upgrade, test, rollback, uninstall) from HelmChart artifacts and takes automatic remediation on failure
notification-controller	Provider, Alert, Receiver	Receives outside events (Receiver) to wake reconciliation, and sends controller events outward (Provider/Alert)
image-reflector/automation	ImageRepository, ImagePolicy, ImageUpdateAutomation	Scans a registry to find new tags that match a policy and writes them back to Git as a commit

A Source defines "where the repository comes from and the conditions for obtaining it (credentials, version selector)," checks at a set interval, and produces a new artifact if there is a new version. A single source can be shared by multiple consumers. A Kustomization reconciles every 5 minutes by default, and anything changed with kubectl edit/patch/delete is soon reverted. All Flux CRDs are registered in a resource category, so a single kubectl get fluxcd -A shows all of them. Bootstrap is the procedure that applies the Flux components themselves as a GitRepository and a Kustomization so that Flux manages itself.

The differences the structure creates

The most frequently asked difference is Helm. Argo CD only renders with helm template and manages the lifecycle itself, so it does not rely on Helm release history or Helm hook semantics. Flux's helm-controller watches a HelmRelease, runs real Helm installs and upgrades, and provides automatic remediation including Helm tests and rollback. The second is the screen. In Argo CD, the API server and Web UI are core components, while in Flux the CLI is the default and the UI is pointed to through a list of separate projects such as Flux Operator, Capacitor, the Headlamp plugin, and Weave GitOps. The third is multi-tenancy. Flux assigns a service account per Kustomization using "real Kubernetes RBAC through impersonation," while Argo CD divides with AppProject and its own RBAC.

Notifications — what attaches where

Argo CD Notifications watches application state changes and produces notifications with triggers and templates. The catalog has useful triggers and templates you can use as they are, services are registered in argocd-notifications-cm and argocd-notifications-secret, and subscriptions are attached to an Application or Project with an annotation such as notifications.argoproj.io/subscribe.on-sync-succeeded.slack: <채널> (the placeholder is the channel). In Flux, the controllers emit a Kubernetes event on every resource state change, and the notification-controller sends them outward with a Provider (type: slack and so on, secretRef) and an Alert (providerRef, kind/name selection through eventSources, eventSeverity info/error). The difference is that the GitHub, GitLab, Gitea, Bitbucket, and Azure DevOps providers report back as a commit status instead of chat.

Observability — Prometheus metrics

Argo CD emits a different set of metrics per server, and the application controller metrics are scraped from argocd-metrics:8082/metrics. Representative ones are argocd_app_info (a gauge with sync_status and health_status labels), argocd_app_sync_total (a counter), and argocd_app_reconcile (a histogram). Flux controllers by default emit, on /metrics at port 8080, reconciliation-duration histograms such as gotk_reconcile_duration_seconds_bucket{kind,name,namespace,le} and controller_runtime_reconcile_total{controller,result}. The state metrics of the Flux resources themselves are not emitted by the controllers but collected with kube-state-metrics, and the flux2-monitoring-example repository provides a ready-made setup.

Integration with CI

Neither tool runs CI. There are three integration points. First, when CI changes Git, a webhook brings reconciliation forward (Argo CD /api/webhook, Flux Receiver). Second, Argo CD's API server is an API that CI/CD systems call, so a pipeline can request a sync or query the status. Third, Flux's image automation finds new tags that CI pushed to the registry and writes them back to Git as commits, so deployment continues even if CI does not edit the manifests. In every case, the only party that changes the cluster is the reconciler.

What it looks like in the field

Teams using Argo CD often ask, "It's Synced, but the actual Pods are on the old image." The cause is usually not the reconciler but something before it. CI did not change the tag, the repository server's cache still has the old revision, or no webhook came and it is waiting for the 3-minute poll. If you look at the sync_status of argocd_app_info together with Git's latest commit in the metrics, you can tell at which stage it stopped.

In Flux, looking first at kubectl get fluxcd -A gives most of the answers. If a GitRepository is not Ready, it is the source stage, and if a Kustomization is not Ready, the condition says where it got stuck among build, apply, and health assessment.

What to check in the next quiz

It asks about the boundary between IaC/CI/CD and GitOps, how webhooks are compatible with the pull principle, where credentials live in in-cluster and external reconcilers, the relationship between progressive delivery and Git declarations, the roles of Argo CD's three components, the pairing of Flux controllers and CRDs, the difference in how Helm is handled, and where notifications and metrics attach. References: Argo CD Architectural Overview, GitOps Toolkit components, Argo CD Notifications, Flux alerts, Argo CD Metrics, Flux Prometheus metrics.