GitOps Patterns: Git as the Single Source of Truth

GitOps is an operational framework that applies DevOps best practices for infrastructure automation -- using Git as the single source of truth for declarative infrastructure and applications.

Core Principles

Declarative: the entire system is described declaratively (YAML, HCL, JSON)
Versioned and immutable: Git provides the audit trail, rollback capability, and collaboration model
Pulled automatically: software agents pull the desired state from Git and apply it
Continuously reconciled: agents detect drift and correct it automatically

Push vs Pull Model

Aspect	Push Model (traditional CI/CD)	Pull Model (GitOps)
Who deploys	CI pipeline pushes to cluster	Agent inside cluster pulls from Git
Credentials	CI needs cluster access	Only agent needs cluster access
Drift detection	None -- state can diverge silently	Continuous reconciliation
Security	Broader attack surface	Reduced -- no external cluster access needed
Tools	Jenkins, GitHub Actions, GitLab CI	ArgoCD, Flux

The pull model is the GitOps standard because it reduces credential exposure and guarantees the cluster matches the Git state.

ArgoCD vs Flux

Feature	ArgoCD	Flux
UI	Rich web UI with visualization	CLI-first, optional Weave GitOps UI
Architecture	Centralized, multi-cluster from one instance	Decentralized, agent per cluster
Multi-tenancy	Projects and RBAC built-in	Kubernetes-native RBAC
Helm support	Renders Helm charts, stores manifests	Native Helm controller
Kustomize	Built-in support	Built-in support
Notifications	Built-in notification engine	Notification controller
Community	CNCF graduated, larger community	CNCF graduated, strong ecosystem
Best for	Teams wanting visibility and a UI	Teams preferring a lightweight, composable approach

Decision: ArgoCD for teams that value a visual dashboard and centralized management. Flux for teams that prefer Kubernetes-native primitives and decentralized operation.

Multi-Environment Promotion

A typical GitOps promotion flow:

dev/ --> staging/ --> production/
  |         |            |
  Git commit flow: PR-based promotion

Strategies:

Directory-based: separate directories per environment (environments/dev/, environments/prod/)
Branch-based: environment branches (main = prod, staging, dev) -- less recommended due to merge complexity
Overlay-based: Kustomize overlays with a shared base and environment-specific patches

Promotion mechanisms:

PR from dev config to staging config
Automated promotion after successful smoke tests
Image tag updates via image automation controllers (Flux) or image updater (ArgoCD)

Secret Management in GitOps

Secrets in Git repositories require special handling:

Approach	How it works	Trade-offs
Sealed Secrets	Encrypt secrets with cluster public key, only cluster can decrypt	Simple, but cluster-specific
SOPS (Mozilla)	Encrypt with AWS KMS, GCP KMS, or PGP keys	Multi-cloud, git-diff friendly
External Secrets Operator	Sync secrets from Vault, AWS SM, etc. into K8s	Secrets never in Git, but adds dependency
Vault Agent Injector	Inject secrets at pod runtime	No K8s secrets at all, but more complex

Recommendation: External Secrets Operator for most teams -- secrets stay in a dedicated vault, never in Git, and sync automatically.

Drift Detection and Reconciliation

GitOps agents continuously compare desired state (Git) with actual state (cluster):

Auto-sync: automatically apply changes when drift is detected
Manual sync: require human approval before applying (safer for production)
Sync windows: only allow syncs during maintenance windows
Diff visualization: ArgoCD shows exactly what will change before sync
Health checks: verify application health after sync, auto-rollback on failure

Resources

:::