KubernetesCVI · Package Management Anti-PatternsPackage management anti-patterns
Configuration drift — detecting and correcting divergence
What you'll learn
- Recognise configuration drift as an anti-pattern
- Detect drift with helm diff and Argo CD selfHeal
- Correct drift with helm upgrade
- Apply the operational discipline of preventing drift
Prerequisites
Verified against Kubernetes 1.34.x · kubeadm 1.34.x · kubectl 1.34.x · etcd 3.6.x · CoreDNS 1.11.x · containerd 1.7.x / 2.x · 2026-08-16
Configuration drift is when the cluster’s actual state diverges from the Helm release state. This lesson walks the sources, detection, correction, and the operational discipline.
The drift problem
flowchart LR
A["Helm release: desired state"] --> B["Cluster: actual state"]
A -.->|drift| B
C["kubectl edit / apply"] -.->|bypass| B
Helm manages a release; the cluster has the actual resources. Drift occurs when the cluster state changes without Helm knowing:
- kubectl edit / apply from a laptop. Bypasses Helm.
- CI pipeline with cluster credentials. Applies manifests directly, so the release Secret never records the change.
- Auto-scaling changes replicas. If Helm’s values specify a fixed count, HPA-induced drift is reported.
Detection with helm diff
# Compare the current cluster state with the rendered chart
helm diff upgrade myrelease mychart/ -f values.yaml
# Output:
# mychart/templates/deployment.yaml:
# spec:
# replicas: 3 (desired)
# - replicas: 5 (actual)
The helm-diff plugin shows what would change. If there are unexpected changes, drift is present.
Detection with Argo CD selfHeal
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: myapp
spec:
syncPolicy:
automated:
prune: true
selfHeal: true
Argo CD’s selfHeal continuously reconciles the cluster state toward the desired state in Git. Drift is detected and corrected automatically.
Sources of drift
flowchart LR
A[Sources of drift] --> B[kubectl edit from laptop]
A --> C[kubectl apply from laptop]
A --> D[CI pipeline bypassing Helm]
A --> E["Auto-scaling (HPA)"]
A --> F[Out-of-band scripts]
The sources:
- kubectl edit / apply from laptop. Imperative changes bypass Helm.
- CI pipeline with cluster credentials. Pushes manifests without Helm.
- Auto-scaling. HPA changes replicas; if Helm’s values specify a fixed count, drift is reported.
- Out-of-band scripts. CronJobs or operators that modify resources directly.
Correction
# Bring the cluster back to the desired state
helm upgrade myrelease mychart/ -f values.yaml --atomic --wait
The helm upgrade with the correct values renders the desired state and applies it. Drift is corrected.
For HPA-induced drift, configure Helm to ignore the replicas field (Helm 3 has no direct equivalent of Kustomize’s ignoreDifferences; the workaround is to not manage replicas from Helm when HPA is enabled).
Quiz
Knowledge check · 4 questions
Q1. How is drift between a Helm release and the live cluster most directly detected?
Q2. A Helm release Secret reflects the current state of the cluster's resources.
Q3. Reinstate a scheduling constraint that a routine Helm upgrade silently removed.
During an incident last Tuesday an operator ran `kubectl -n prod-app edit deployment/payments` and added `nodeSelector: {disktype: ssd}` to keep the Pods off a set of degraded nodes. This morning's unrelated `helm upgrade payments` — an image bump — removed it, and `kubectl -n prod-app get pods -o wide` shows four Pods back on the degraded nodes with latency climbing.
Q4. Helm has no equivalent of Argo CD's `ignoreDifferences`. How do you run an HPA against a Helm-managed Deployment without the two fighting?
Passing score: 75%. Answers are checked in this browser.
The operational discipline
Configuration drift in production rests on five non-negotiable elements:
- Never bypass Helm. All changes go through
helm upgrade. - Enable Argo CD selfHeal. Drift is detected and corrected automatically.
- Monitor drift. Alert on drift that is not auto-corrected.
- Document expected drift. HPA, etc. — list the sources of expected drift.
- Investigate every drift event. A drift event is a signal of a process failure.
Drift is the symptom of a process failure. The discipline is to prevent the process failure, not just to correct the drift.