GitOps with Argo CD and Flux

GitOps makes Git the single source of truth for what runs in a cluster. A controller in the cluster continuously compares the live state to the manifests in a Git repository and reconciles any difference. You change the cluster by changing Git; the controller does the applying.

It is the reconcile loop extended to delivery: desired state lives in version control, and a controller drives the cluster toward it, forever. Argo CD and Flux are the two dominant implementations.

The GitOps Model

The principles are simple: the desired state of the system is declared in Git; a controller continuously pulls from Git and reconciles the cluster to match; and changes happen through Git commits and pull requests, not kubectl. This makes the repository an auditable, reviewable record of every change, gives you rollback by reverting a commit, and means the cluster self-corrects drift — if someone edits a live object, the controller changes it back to what Git says.

Pull vs Push

GitOps is pull-based: a controller inside the cluster watches Git and applies changes. This differs from push-based CI/CD, where a pipeline outside the cluster runs kubectl apply with cluster credentials. Pull-based is more secure (no cluster credentials handed to CI) and self-healing (drift is corrected continuously, not only at deploy time). It is the reason GitOps and plain CI deployment are different things, covered next topic.

Argo CD and Flux

Argo CD is application-centric with a strong UI: it models Application resources, shows sync status and diffs visually, and supports the app-of-apps pattern for managing many applications. Flux is a set of composable controllers, GitOps-toolkit style, with no built-in UI but deep native support for Helm and Kustomize sources. Both reconcile Git to cluster, detect drift, and sync; the choice is largely UI-and-app-centric (Argo) versus controller-and-composable (Flux).

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web
spec:
  source:
    repoURL: https://github.com/example/manifests
    path: overlays/prod
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: shop
  syncPolicy:
    automated:
      selfHeal: true
      prune: true

Drift, Secrets, and Promotion

Three practical concerns. Drift and self-heal: with automated sync the controller reverts manual changes — powerful, but it means break-glass edits get undone unless you pause sync. Secrets: you cannot commit plaintext secrets to Git, so GitOps pairs with sealed secrets or an external secrets operator. Promotion: moving a change from staging to prod is a Git operation — a commit or PR that updates the prod path or image tag — which is what makes the whole pipeline auditable. A common structure is a separate repo or directory per environment.