GitOps with ArgoCD

Automate deployments by treating Git as the single source of truth for your cluster state.

advanced75 minRead → Lab → Quiz → Practice

🧠 Brain Warm-Up

🧠 Brain Warm-Up: If kubectl apply is the way to deploy to Kubernetes, why does running it from a CI/CD pipeline create problems at scale — with drift detection, multi-team collaboration, and audit trails? Think about what “who changed what and when” means without a canonical source of truth.

What is GitOps?

GitOps is an operational framework where the desired state of your infrastructure and applications is declared in Git, and an automated agent continuously reconciles the live cluster state toward that declaration.

The four GitOps principles (OpenGitOps):

Declarative — desired state described as data (YAML), not scripts
Versioned and immutable — Git history is the audit trail; every change is a commit
Pulled automatically — an in-cluster agent pulls from Git (no push credentials leave the cluster)
Continuously reconciled — the agent detects and corrects drift automatically

GitOps vs Traditional CI/CD

Traditional (Push-based CI/CD)        GitOps (Pull-based)
─────────────────────────────         ────────────────────────────
CI pipeline has kubectl + kubeconfig  Cluster agent pulls from Git
Pipeline pushes changes to cluster    No cluster credentials in CI
Drift is not detected                 Drift auto-corrected every ~3 min
Rollback = re-run pipeline            Rollback = git revert (instant)
Audit trail is CI logs                Audit trail is git history

ArgoCD Architecture

ArgoCD is the most widely-adopted GitOps controller. It runs inside the cluster and watches a Git repository, continuously applying changes.

Git Repository (desired state)
  ├── apps/
  │   ├── deployment.yaml
  │   ├── service.yaml
  │   └── ingress.yaml
  └── config/
      └── configmap.yaml
         │
         │  (ArgoCD polls every 3 minutes or via webhook)
         ▼
┌─────────────────────────────────┐
│           ArgoCD Server         │
│  ┌──────────────────────────┐   │
│  │   Application Controller │   │
│  │  (Compares live vs Git)  │   │
│  └──────────┬───────────────┘   │
│             │ diff detected     │
│             ▼                   │
│  ┌──────────────────────────┐   │
│  │    Sync Engine           │   │
│  │  (kubectl apply, Helm    │   │
│  │   template, Kustomize)   │   │
│  └──────────────────────────┘   │
└──────────────┬──────────────────┘
               │ applies manifests
               ▼
        Kubernetes API Server

ArgoCD Application Resource

The core object in ArgoCD is an Application — a CRD that links a Git repo path to a cluster namespace:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/myorg/k8s-manifests
    targetRevision: main
    path: apps/my-app
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true       # delete resources removed from Git
      selfHeal: true    # auto-fix manual drift

Sync Strategies

Strategy	Behavior
Manual	ArgoCD shows OutOfSync but waits for human approval
Automated	Syncs automatically on every Git change
Automated + selfHeal	Also reverts manual kubectl changes that drift from Git
Automated + prune	Also deletes resources removed from Git

App of Apps Pattern

For managing many applications, ArgoCD supports a hierarchical pattern where one “parent” Application manages multiple “child” Applications:

root-app (Application)
  └── apps/ directory in Git
      ├── frontend-app.yaml   (Application)
      ├── backend-app.yaml    (Application)
      └── monitoring-app.yaml (Application)

This lets you bootstrap an entire cluster's worth of applications with a single ArgoCD Application.

←

Production Readiness Checklist

Service Mesh with Istio

→