What “Automated Reconciliation” means (deep, but simple)
1) Two states exist all the time
-
Desired state (Source of Truth): what you declared in Git
(Helm values, Kustomize overlays, Kubernetes YAMLs, etc.) -
Actual state: what is really running in the Kubernetes cluster
(Deployments/Services/Ingress/ConfigMaps as they currently exist)
A GitOps tool/controller (Argo CD / Flux) continuously compares these.
2) Continuous comparison (the control loop)
Think of a controller doing this loop forever:
-
Fetch desired state from Git (and render it if needed: Helm/Kustomize).
-
Read live state from the cluster (via Kubernetes API).
-
Diff them (desired vs live).
-
If different → mark as OutOfSync (drift detected or change pending).
This is exactly like a thermostat:
-
Desired temp = Git
-
Current temp = Cluster
-
Thermostat checks repeatedly and decides if action is needed
3) Drift: how it happens (two common cases)
A) Intentional change in Git
-
You update Git: image
1.4.1 → 1.4.2 -
Cluster still running
1.4.1 -
Tool detects diff → OutOfSync
-
Then it applies and becomes Synced
B) Unwanted manual change (real drift)
-
Someone runs:
kubectl scale deployment api --replicas=10 -
Git still says
replicas=3 -
Tool detects drift → OutOfSync
-
Reconciliation will bring it back to
3(if auto-sync/self-heal enabled)
So drift can be either:
-
“pending deployment” (Git ahead of cluster)
-
“configuration drift” (cluster changed without Git)
4) “Auto-fix drift” (Self-heal)
When auto-sync + self-heal is enabled:
-
The tool automatically applies Git’s desired state back onto the cluster.
-
That “fix” is usually done by kubectl apply-like patching (server-side apply / strategic merge / replace depending on tool settings).
So reconciliation is:
-
Detect drift
-
Correct drift
-
Repeat forever
