Course contentsShow
← Docker, Kubernetes & CI/CD
Lesson 709 of 80210. Deployment Strategies and GitOpsFree lesson

Configuring GitOps Drift Detection Mechanisms

Learn to configure Argo CD to continuously compare live cluster state against Git manifests to identify configuration discrepancies.

In this lesson, you will learn how to configure Argo CD to detect configuration discrepancies between your desired state in Git and the actual live state in your Kubernetes cluster.

Understanding GitOps Drift

In a GitOps workflow, the Git repository acts as the "source of truth." However, Kubernetes clusters are dynamic environments. An administrator might perform an kubectl edit to hotfix a production issue, or an automated controller might modify a resource. This divergence is known as configuration drift. Without detection, your Git repo and your cluster become desynchronized, leading to "configuration decay" where the repository no longer accurately represents what is running in production.

Configuring Automatic Detection

Argo CD identifies drift by continuously comparing the live state of the objects in your cluster against the manifests defined in your Git repository. By default, Argo CD performs a comparison every three minutes. To ensure your system remains resilient, you should configure your Application resource to handle these discrepancies automatically.

You can set the selfHeal policy, which tells Argo CD to override manual, out-of-band changes and force the cluster to match the Git state:

spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Why Self-Heal and Prune?

  • Self-Heal: When enabled, if someone manually changes a field in a Kubernetes manifest (e.g., changing the replicas count via kubectl), Argo CD will detect that the live state does not match the Git state and will automatically revert the cluster to the version stored in Git.
  • Pruning: When enabled, if you remove a manifest file from your Git repository, Argo CD will detect that the corresponding object in the cluster is now "orphaned" and will delete it to maintain parity.

When these are enabled, the Argo CD UI will transition from a Synced status to OutOfSync the moment a change is detected, immediately triggering the reconciliation loop to restore the intended state. This creates a "closed-loop" system where the cluster is forced to remain consistent with your defined infrastructure-as-code.

Key Takeaway: By enabling selfHeal and prune in your Argo CD Application manifests, you transform your cluster from a mutable environment into a deterministic one that automatically discards unauthorized manual configuration changes.