Skip to main content
Welcome to GitOps and Continuous Delivery. Imagine this scenario: it’s two a.m. and your pager goes off — production is down. You SSH into the cluster to investigate and find something has changed, but there is no record of what was changed, when, or by whom. You’re effectively flying blind. That is the world before GitOps. In this lesson we explain what GitOps solves, define the four pillars of GitOps, show how the reconciliation loop works, and describe drift detection and remediation patterns that restore order and auditability to production.
A slide titled "Learning Objectives" with a blue gradient sidebar and four colorful numbered markers. The items list GitOps topics: problems GitOps solves, the four pillars (declarative, versioned, pulled, reconciled), the reconciliation loop, and drift detection/self-healing.
Problem statement Many Kubernetes environments still allow developers and operators to make live changes directly with tools like kubectl. These ad-hoc edits, often made under time pressure, create a fragmented change history and reduce visibility:
  • No central record of changes, authors, or timestamps.
  • Conflicting or overlapping edits from multiple teams.
  • Harder root-cause analysis, longer outages, and fragile recovery procedures.
When changes are applied directly to clusters without a single source of truth, production stability depends on memory and manual coordination rather than on an observable, auditable deployment process.
A diagram titled "Deployment Roulette" showing three uncoordinated teams (Team A Dev, Team B Ops, Team C SRE) each pushing into a single production cluster, resulting in a warning box labeled "Conflicting changes."
Why this happens The root cause is the imperative model: you run commands that change the cluster immediately, and unless you also persist those changes into a versioned store, the cluster becomes a source of truth that is hard to audit. Common imperative commands:
These commands mutate live state but do not automatically create a versioned, auditable record of the intended desired state. Declarative model and GitOps In the declarative model you express the desired state as files (YAML/JSON, Helm charts, Kustomize overlays), commit them to Git, and let automated controllers converge the cluster to that desired state. Git provides:
  • Version history and timestamps
  • Commit authorship for auditability
  • Simple rollback by reverting commits
GitOps is the operational model that treats Git as the single source of truth: you “declare” the desired state and automation continuously reconciles the cluster to match that declaration.
A presentation slide titled "Git as the Single Source of Truth" showing a Git repository icon labeled "Git Repositories (Source of Truth)" with an arrow pointing to a document icon labeled "Declarative Description (YAML/JSON)" under the heading "GITOPS: AN OPERATIONAL MODEL."
The four pillars of GitOps Below is a concise reference for the four core principles every GitOps workflow implements.
A slide titled "Git as the Single Source of Truth" showing four colored pillars labeled Declarative, Versioned, Pulled, and Reconciled with small icons and short explanations. Each pillar summarizes a Git principle — desired-state files, full history/rollback, agents pulling from Git, and continuous drift detection/correction.
Pull-based GitOps improves security posture: controllers running inside the cluster (with scoped credentials) fetch declarative manifests from Git. CI systems don’t need permanent cluster admin credentials to deploy changes.
Reconciliation loop — the engine of GitOps The reconciliation loop is the continuous cycle controllers use to enforce Git as the source of truth. Conceptually it runs through these stages:
  • Code & push: Developers change manifests and push commits to Git.
  • Watch / Detect: The GitOps controller (e.g., Argo CD or Flux) sees the change via webhook or polling.
  • Compare: The controller diffs the desired state in Git against the live cluster, resource-by-resource.
  • Sync / Apply: If differences exist, the controller creates the necessary create/update/delete operations to converge the cluster to Git.
These steps repeat continuously: the controller is always watching, comparing, and ready to synchronize.
A colorful circular diagram titled "The Reconciliation Loop" showing four stages—Code & Push, Detect & Compare, Sync & Deploy, and Continuous Watch—illustrating a continuous deployment/reconciliation process.
Example flow
  • You update a Deployment manifest to change an image tag from v1.0 to v2.0 and push the commit to Git.
  • The controller detects the commit (webhook or polling) and diffs the live Deployment.
  • The image mismatch is found; the controller updates the Deployment to v2.0.
  • No human intervention is required; the controller continuously enforces the declared state.
Drift detection and remediation strategies Drift occurs when the live cluster diverges from Git. Controllers can be configured to remediate drift in multiple ways depending on governance and risk tolerance:
  1. Auto-sync (self-healing)
    • The controller automatically reverts out-of-band changes to match Git. This strictly enforces Git-as-source-of-truth and reduces long-lived divergence.
  2. Alert + manual sync
    • The controller detects drift and alerts operators. A human inspects and triggers a sync if appropriate — useful in environments with strict change control.
  3. Diff + PR workflow
    • If an intentional change was made directly in the cluster, the controller can create a pull request to update Git, preserving the intentional change while keeping Git authoritative.
Auto-sync can unintentionally overwrite emergency fixes applied directly to the cluster. If you use auto-sync, implement safeguards (alerts, maintenance windows, or temporary disabling) to avoid losing critical incident work.
A presentation slide titled "Drift Detection and Self-Healing" showing a GitHub response icon and three remediation options: Auto‑Sync (self‑healing), Alert + Manual Sync, and Diff + PR Workflow. Short descriptions say the controller can auto‑revert to Git, alert a human to approve a sync, or create a PR to update Git.
Common sources of drift The guiding principle remains: either reconcile the cluster to Git, or update Git with intentional, approved cluster changes.
A presentation slide titled "Drift Detection and Self‑Healing" with a blue panel listing common causes: 1) manual kubectl changes ("quick fix"), 2) emergency incident response, and 3) other controllers (HPA, VPA).
Key takeaways
  • Treat Git as the single source of truth: all desired state should live in version-controlled repositories.
  • Prefer the declarative model over imperative commands: describe what you want, and let automation handle how to get there.
  • Use continuous reconciliation to prevent and correct drift.
  • Pull-based controllers improve security by minimizing the need for external systems to hold cluster credentials.
Controllers continuously compare live cluster state to Git and act according to configured policies (auto-sync, manual approval, or PR-driven updates). Relying on Git and continuous reconciliation gives you auditability, reproducibility, and safer production operations.
A presentation slide titled "Key Takeaways" that lists three points about Git/GitOps: Git as the single source of truth, GitOps using a declarative model with automation to enforce desired state, and the pull-based approach improving security by letting the cluster pull changes from Git.
Links and references

Watch Video