🔄 The GitOps Model
GitOps is an operating model where Git is the single source of truth for both application code and infrastructure state. A controller continuously reconciles the live cluster state to match what's declared in the Git repository — the same reconciliation pattern Kubernetes uses internally, extended to the deployment level.
Four GitOps Principles (OpenGitOps)
1. Declarative
The entire system — apps, configs, infra — is described declaratively. No imperative scripts.
2. Versioned & Immutable
Desired state is stored in Git. Every change is a commit. History is the audit trail. Rollback is a git revert.
3. Pulled Automatically
A software agent pulls from Git and applies changes — no CI system needs cluster credentials pushed into it.
4. Continuously Reconciled
The agent detects and corrects drift automatically. Manual kubectl apply changes are overwritten on the next sync.
Key ArgoCD Concepts
| Concept | What it is |
|---|---|
| Application | CRD that links a Git source (repo + path + revision) to a cluster destination (cluster + namespace) |
| AppProject | Groups Applications; defines allowed source repos, destination clusters, and permitted resource kinds |
| Sync | The act of applying Git state to the cluster. Can be manual or automatic |
| Sync Status | Synced (matches Git) or OutOfSync (drift detected) |
| Health Status | Healthy / Progressing / Degraded / Missing — based on resource readiness |
| ApplicationSet | Generates many Applications from a template — one per cluster, environment, or Git directory |
| App of Apps | An Application whose manifests are other Application manifests — bootstraps a whole cluster from Git |
⚡ ArgoCD Quick Start & Core Patterns
Install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd \
-f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# Access the UI
kubectl port-forward svc/argocd-server -n argocd 8080:443
# Get initial admin password
argocd admin initial-password -n argocdDeclare an Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/my-org/my-app-config
targetRevision: HEAD
path: environments/production
destination:
server: https://kubernetes.default.svc
namespace: my-app
syncPolicy:
automated:
prune: true # delete resources removed from Git
selfHeal: true # revert manual kubectl changes
syncOptions:
- CreateNamespace=trueApp of Apps Pattern
Bootstrap an entire cluster by pointing one root Application at a directory of Application manifests. Adding a new app is a Git commit — no manual ArgoCD UI interaction required.
my-cluster-apps/
├── root-app.yaml ← the App of Apps Application
└── apps/
├── cert-manager.yaml
├── ingress-nginx.yaml
├── monitoring.yaml
└── my-app.yaml ← each is an Application CRDArgoCD vs Flux v2
| Dimension | ArgoCD | Flux v2 |
|---|---|---|
| UI | Rich built-in web UI | CLI-first; optional Weave GitOps UI |
| Multi-cluster | Hub-and-spoke (central ArgoCD manages N clusters) | Agent per cluster (pull model) |
| Helm support | Native (renders server-side) | HelmRelease CRD (Helm Controller) |
| Image automation | Argocd Image Updater (addon) | Built-in ImagePolicy controller |
| CNCF status | Graduated | Graduated |
| Best for | Teams wanting visibility and UI-driven ops | Teams wanting pure GitOps automation, agent model |
📝 Knowledge Check
kubectl scale deployment my-app --replicas=5 directly on a cluster managed by ArgoCD with selfHeal: true. What happens next?selfHeal: true, ArgoCD continuously compares live state to Git state. When it detects the replica count drifted from what Git declares, it automatically applies the Git state — overwriting the manual change. Git is the only way to change the cluster.