GitOps Philosophy & ArgoCD / Flux: Declarative state, pull-based reconciliation, and automated drift remediation.

Push-Based CI vs. Pull-Based GitOps

In traditional CI/CD (Push model), the external CI server holds cluster-admin credentials and runs kubectl apply against the cluster. In GitOps (Pull model), an agent running inside the cluster continuously synchronizes the cluster state with a Git repository.

Traditional Push Model (Security Anti-Pattern):
[ GitHub Actions / GitLab ] ----(Requires cluster-admin kubeconfig)----> [ Firewalled K8s API ]

GitOps Pull Model (ArgoCD):
[ Git Repository (Desired State) ] <--- Polling / Webhook
                                             |
                                             v
[ Kubernetes Cluster ] <---------------------+
|  +-------------------------------------+   |
|  | ArgoCD Application Controller       |   | (Pulls changes from inside cluster;
|  | Compares Desired (Git) vs Live      |   |  zero external ingress firewalls needed)
|  | State. Auto-heals configuration     |   |
|  +-------------------------------------+   |
+--------------------------------------------+

Core GitOps Principles

1. The entire system is described declaratively: All Kubernetes manifests, Helm charts, and Kustomize overlays live in Git.
2. Git is the single source of truth: No human runs kubectl edit or kubectl apply directly in production.
3. Automated Drift Detection & Self-Healing: If a developer manually edits a deployment or scales a replica set via the command line, ArgoCD instantly detects the deviation (drift) and automatically overwrites the cluster back to match Git.
4. Instant Rollbacks: Rolling back production is simply running git revert <commit>.