What is GitOps, and how do tools like ArgoCD/Flux fit into a Kubernetes deployment pipeline?

The traditional CI/CD "push" model

CI pipeline (on a code merge):
   → builds image
   → runs kubectl apply / helm upgrade DIRECTLY against the cluster

In this model, the CI system needs direct write credentials to the production cluster, and the cluster's actual state can drift from what's in git if someone runs an ad-hoc kubectl edit or kubectl apply outside the pipeline — there's no ongoing verification that the cluster still matches what's declared in source control after the initial deploy.

The GitOps "pull" model

Git repository (source of truth for desired state)
        ▲
        │ (continuously watched/pulled)
        │
ArgoCD/Flux controller, running INSIDE the cluster
        │
        ▼
Cluster's actual state, continuously reconciled to match git

Instead of CI pushing changes into the cluster, a controller running inside the cluster (or with cluster access) continuously watches a designated git repository and applies whatever it finds there — and, crucially, keeps re-applying it on an ongoing basis, not just once at deploy time. This means the GitOps controller will detect and automatically correct any drift — if someone manually edits a Deployment directly with kubectl, the next reconciliation cycle reverts it back to match git, since git (not whatever's currently running) is the authoritative source of truth.

Why this maps naturally onto Kubernetes's own reconciliation model

This is precisely the same control-loop pattern that runs through the rest of Kubernetes (see the fundamentals topic's reconciliation question) — ArgoCD/Flux are, at their core, another reconciliation controller, just operating one level up: instead of reconciling "desired replica count" against "actual running Pods" the way a Deployment controller does, they reconcile "desired cluster state, as declared in git" against "actual cluster state," continuously.

Security and operational benefits

• No CI system needs direct cluster write credentials — the GitOps controller, running inside the cluster, pulls changes rather than the CI pipeline pushing them in, meaningfully shrinking the set of external systems with standing write access to production.
• Git history is the audit trail and rollback mechanism — reverting a bad change is a normal git revert, and the GitOps controller picks up and applies the reverted state automatically, without needing separate rollback tooling.
• Drift detection and correction — manual, undocumented changes made directly against the cluster are automatically reverted (or at least flagged, depending on configuration) rather than silently persisting and diverging from what's documented in git.
• A single, reviewable place to see a cluster's entire intended configuration — anyone can read the git repository to understand exactly what should be running, without needing direct cluster access at all.

ArgoCD vs. Flux, briefly

Both accomplish the same core GitOps loop; ArgoCD is commonly noted for its rich built-in web UI (visualizing application sync status, diffs, and health directly), while Flux is often used more as a set of composable, script/CLI-friendly controllers, frequently favored in setups leaning more heavily on command-line/automation-first workflows. Both are CNCF projects with broad adoption, and the choice between them is often driven more by team preference and ecosystem fit than a sharp functional gap.

Explaining GitOps as "continuous reconciliation against git as the source of truth," and explicitly connecting it back to the same control-loop pattern that underlies the rest of Kubernetes, demonstrates a deeper conceptual grasp than simply describing it as "using git for deployments."