Everything you've built so far is push-based — the pipeline pushes changes to the cluster. GitOps inverts this: an agent inside the cluster pulls desired state from Git. This lesson explains why that matters and how it changes everything.

Push vs Pull: The Fundamental Difference

Push-Based CD (What you've been doing) Developer pushes code CI Pipeline build, test, scan PUSH kubectl / helm Pipeline has creds! K8s Cluster passive target ⚠️ Pipeline needs cluster credentials | No drift detection | Manual rollback Pull-Based CD — GitOps (What you're about to learn) Developer pushes code CI Pipeline build → update Git GitOps Repo desired state PULL ArgoCD (in-cluster agent) detects diff → syncs ✅ Pipeline NEVER touches cluster | Automatic drift detection | git revert = rollback
The inversion: instead of CI pushing TO the cluster, an agent IN the cluster pulls FROM Git.
Git becomes the single source of truth for your cluster's state. What's in Git IS what's running. If someone manually changes the cluster, ArgoCD reverts it. If Git changes, ArgoCD updates the cluster. This is continuous reconciliation.

The Four GitOps Principles (OpenGitOps Standard)

① Declarative System state is DECLARED, not scripted imperatively ② Versioned Desired state stored in Git (immutable history + audit trail) ③ Pulled Agents automatically pull desired state and apply it ④ Reconciled Agents continuously compare actual vs desired, correct drift Why this maps perfectly to Kubernetes: K8s is ALREADY declarative (you describe desired state, controllers reconcile). GitOps extends that model: Git = desired state SOURCE → K8s controller = ArgoCD.

Why GitOps Is Architecturally Superior

ConcernPush-BasedGitOps
Security CI pipeline has cluster admin creds (big attack surface) Only ArgoCD (in-cluster) has access. CI never touches cluster.
Audit trail Check CI logs (scattered, ephemeral) git log = complete history of every change
Drift Someone kubectl edits → cluster diverges silently ArgoCD detects drift, reverts to Git (self-heal)
Rollback Find old pipeline run, re-trigger… which version? git revert → ArgoCD auto-syncs → rolled back
Multi-cluster Pipeline per cluster (creds per cluster) One ArgoCD managing N clusters from one Git repo
Disaster recovery Rebuild cluster… then run all pipelines? In order? Point ArgoCD at Git → entire cluster restored

The Two-Repo Pattern

📁 App Repo (cicd-mastery) Source code, Dockerfile, tests CI workflows (build + push image) 📁 GitOps Repo (cicd-mastery-gitops) K8s manifests / Helm values ArgoCD Application definitions CI updates image tag ArgoCD watches this repo Change detected → sync to cluster
Separation of concerns: app developers change code in the app repo. Infrastructure state lives in the GitOps repo. ArgoCD watches only the GitOps repo.
Why two repos?
  • App devs don't need cluster access — they just push code
  • Different permissions: restrict who can change production config
  • Clean history: image tag updates don't pollute code commits
  • CI pipeline image updates are the ONLY bridge between the two repos

The GitOps Deployment Flow

1 Dev pushes code 2 CI builds image → ACR 3 CI updates GitOps repo 4 ArgoCD detects change 5 ArgoCD syncs to cluster 6 New version running ✓ Key insight: CI never touches the cluster Step 3 (CI → GitOps repo) is the ONLY bridge. CI has Git write access, not cluster access. ArgoCD has cluster access, not Git write access. Separation of privileges.

Self-Healing: The Killer Feature

Someone runs: kubectl scale deployment/api --replicas=1 -n production Git says: replicas: 3 Cluster now has: replicas: 1 ArgoCD detects: "OutOfSync!" With selfHeal: true → automatically reverts to 3 replicas Drift corrected in seconds. Git wins. Always.
Self-healing: manual cluster changes are automatically reverted to match Git. No more "who changed production?"

🧠 Recall Check

  1. What's the fundamental difference between push-based and pull-based CD?
  2. Name the four GitOps principles.
  3. Why use two separate repos (app + GitOps)?
  4. What happens in GitOps when someone manually changes the cluster?
  5. In the GitOps flow, what does the CI pipeline actually DO? (Hint: it doesn't deploy.)
Reveal answers
  1. Push: CI pipeline pushes to cluster (pipeline has creds). Pull: in-cluster agent pulls from Git (pipeline never touches cluster).
  2. Declarative (desired state declared), Versioned (stored in Git), Pulled automatically (agents pull from Git), Continuously reconciled (drift auto-corrected).
  3. Separation of concerns: different permissions, clean git history, app devs don't need cluster access, CI only bridges via Git write.
  4. ArgoCD detects the drift (actual ≠ desired) and with selfHeal: true, reverts the change to match Git.
  5. CI builds the image, pushes to registry, then updates the image tag in the GitOps repo. That's it. ArgoCD handles the actual deployment.
You already understand Kubernetes reconciliation loops (controller watches desired state, makes actual match). GitOps is the same pattern one level up: ArgoCD watches Git (desired state) and makes the cluster (actual state) match. Next: installing ArgoCD and seeing it in action.