Day 74: Git as source of truth; sync & drift detection
GitOps: the cluster should always match Git, not the other way around
In a traditional pipeline, CI runs kubectl apply (or helm upgrade) as its last step — the cluster's actual state lives wherever that command was last run from, and Git is only a historical record, not an enforced source of truth. GitOps flips this: a Git repository IS the desired state, and a controller running *inside* the cluster continuously pulls from Git and reconciles — no external system pushes changes in.
ArgoCD is that controller. An ArgoCD Application points at a Git repo path; ArgoCD compares what's in Git against what's actually running, and shows/acts on the difference.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: api
spec:
source:
repoURL: https://github.com/you/aiopsxpert-manifests
path: apps/api
targetRevision: main
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: trueSync and drift detection
ArgoCD's UI/CLI shows each Application as Synced (cluster matches Git exactly) or OutOfSync (someone changed Git, or someone changed the cluster directly, and they now differ). Sync applies Git's state to the cluster to resolve the difference.
Why this matters more than it sounds
Because reconciliation is pull-based (ArgoCD inside the cluster pulls from Git) rather than push-based (an external CI job pushing in), the cluster never needs to expose credentials letting outside systems write to it directly — a meaningfully smaller attack surface, and the reason GitOps is treated as a security improvement, not just a workflow preference.
Key terms
- GitOps
- A model where Git is the enforced source of truth, and an in-cluster controller reconciles reality to match it.
- ArgoCD Application
- An object pointing ArgoCD at a Git path to sync into a target cluster/namespace.
- Drift
- Any difference between what Git declares and what is actually running.
Why is ArgoCD's pull-based model considered more secure than a CI job running kubectl apply directly?
