GitOps Core Concepts — Git as the Source of Truth

Why GitOps Matters

GitOps is a paradigm shift in how we manage infrastructure and applications. Instead of manually running kubectl commands or clicking in a dashboard, you declare your desired state in Git, and an automated operator continuously reconciles the actual state with the desired state.

Why this matters for your career:

  • GitOps is the standard deployment model for Kubernetes in enterprises
  • Git provides a complete audit trail — every change is a commit
  • Automated reconciliation prevents configuration drift
  • GitOps enables self-service deployments with proper governance

What Is GitOps?

GitOps is an operational framework that applies DevOps best practices — version control, CI/CD, collaboration — to infrastructure automation. The key principles:

  1. Declarative configuration: The entire system is described declaratively
  2. Git as single source of truth: The desired state is stored in Git
  3. Automated reconciliation: An operator continuously ensures actual state matches desired state
  4. Pull-based deployments: The operator pulls changes from Git (vs. push-based CI/CD)

GitOps vs. Traditional CI/CD

| Aspect | Traditional CI/CD | GitOps | |--------|-------------------|--------| | Deployment trigger | Push (CI/CD pipeline pushes to cluster) | Pull (operator pulls from Git) | | Source of truth | CI/CD pipeline state | Git repository | | Drift detection | Manual or external monitoring | Automatic (operator continuously reconciles) | | Rollback | Re-run pipeline with old version | Revert commit in Git | | Audit trail | Pipeline logs | Git history (every change is a commit) | | Access control | CI/CD permissions | Git permissions + code review | | Secret management | CI/CD secrets | Sealed secrets or external secret store | | Infrastructure changes | Separate tools (Terraform, CloudFormation) | Unified in Git alongside app config |

The GitOps Workflow

Developer → Git Commit → Pull Request → Code Review → Merge to Main
                                                            ↓
                                                 GitOps Operator (ArgoCD/Flux)
                                                            ↓
                                              Syncs cluster to match Git state

Step-by-Step

  1. Developer updates Kubernetes manifests (or Terraform, or Helm values)
  2. Developer creates a Pull Request
  3. Team reviews the PR (code review for infrastructure changes!)
  4. PR is merged to the main branch
  5. GitOps operator detects the change
  6. Operator automatically applies the change to the cluster
  7. Operator continuously monitors for drift and corrects it

ArgoCD Architecture

ArgoCD is the most popular GitOps operator for Kubernetes:

┌──────────┐     ┌──────────┐     ┌────────────┐
│ Git Repo │────►│ ArgoCD   │────►│ Kubernetes │
│ (desired │     │ (diff &  │     │ (actual    │
│  state)  │     │  sync)   │     │  state)    │
└──────────┘     └──────────┘     └────────────┘
                      │
                      ▼
              ┌────────────────┐
              │ Web UI / CLI   │
              │ (monitor &     │
              │  manage)       │
              └────────────────┘

Key Components

| Component | Purpose | |-----------|---------| | API Server | Exposes ArgoCD API and web UI | | Repository Server | Caches Git repos for performance | | Application Controller | Continuously reconciles desired vs. actual state | | ApplicationSet Controller | Manages multiple applications from templates | | Dex / OIDC | Authentication (SSO, LDAP, GitHub OAuth) |

GitOps Benefits

| Benefit | Description | |---------|-------------| | Faster deployments | Automated, pull-based = no waiting for CI/CD | | Increased reliability | Desired state is always in Git — repeatable | | Better security | Git permissions + PR review for all changes | | Complete audit trail | Every change is a commit with author info | | Easy rollback | Revert a commit = rollback the deployment | | Self-service | Developers update Git, operator handles the rest | | Drift prevention | Operator corrects any manual changes to the cluster | | Disaster recovery | Deploy a new cluster from Git in minutes |

GitOps for Non-Kubernetes

GitOps principles apply beyond Kubernetes:

| Tool | What It Manages | GitOps Style | |------|----------------|--------------| | Terraform | Cloud infrastructure | Terraform Cloud, Atlantis | | Crossplane | Infrastructure composability | GitOps for any cloud resource | | Flux | Kubernetes + Terraform | Full GitOps platform | | Ansible | Configuration management | Pull-based with Ansible Tower |

Common Mistakes

| Mistake | Why It's Wrong | |---------|---------------| | Pushing directly to cluster (kubectl apply) | Bypasses Git — no audit trail, no review | | Storing secrets in Git | Security risk — use SealedSecrets or external store | | Not using PRs for infra changes | Infrastructure changes need review too | | Ignoring drift (manual changes) | Operator will revert them — or worse, hide them | | Too many repos | One app per repo is ideal; monorepos need careful organization | | No sync policy | Manual sync defeats the purpose of GitOps |

Summary

GitOps is the modern standard for deploying and managing Kubernetes applications. By using Git as the single source of truth and an operator for automated reconciliation, you get faster deployments, better security, complete audit trails, and automatic drift prevention.

Key takeaways:

  • Git is the single source of truth for desired state
  • Operator continuously reconciles actual state with Git
  • Pull-based model: operator pulls from Git, not push from CI/CD
  • Every change is a commit — complete audit trail
  • Rollback = revert a commit
  • ArgoCD is the most popular GitOps operator
  • Apply GitOps to infrastructure too (Terraform, Crossplane)
  • Never bypass Git — no direct kubectl apply to production
  • Use PRs for all infrastructure changes

What's Next: ArgoCD Application Management

The next chapter covers managing applications with ArgoCD — creating Applications, sync policies, health checks, and multi-cluster deployment.

Installing ArgoCD

# Create namespace
kubectl create namespace argocd

# Install ArgoCD
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Check installation
kubectl get pods -n argocd -w

# Access the UI
kubectl port-forward svc/argocd-server -n argocd 8080:443
# Open https://localhost:8080

# Get the admin password
kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d

Creating Your First GitOps Application

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/my-app-config.git
    targetRevision: HEAD
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: my-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Deploy with:

kubectl apply -f application.yaml
argocd app sync my-app
argocd app get my-app

Flux vs. ArgoCD

| Feature | ArgoCD | Flux | |---------|--------|------| | Web UI | ✅ Rich UI with visualization | ❌ CLI-focused (web UI available via Weave) | | Multi-cluster | ✅ Native support | ✅ Native support | | SSO integration | ✅ Built-in (Dex, OIDC, LDAP) | ⚠️ Via Weave GitOps | | Health assessment | ✅ Built-in for K8s resources | ✅ Built-in | | Image updates | ⚠️ Requires separate tool | ✅ Image Automation controller | | Secrets management | ⚠️ External | ✅ Mozilla SOPS integration | | Kustomize | ✅ Built-in | ✅ Built-in | | Helm | ✅ Built-in | ✅ Built-in | | Community | Large (CNCF graduated) | Large (CNCF graduated) |

Both are CNCF graduated projects. Choose ArgoCD if you want a rich UI and SSO. Choose Flux if you want image automation and SOPS integration built-in.

GitOps Maturity Model

| Level | Description | Capabilities | |-------|-------------|-------------| | 1 | Ad-hoc | Manual kubectl, no Git | | 2 | Scripted | Shell scripts, YAML files in Git | | 3 | CI/CD push | GitHub Actions pushes to cluster | | 4 | GitOps pull | ArgoCD/Flux pulls from Git, automated sync | | 5 | Full GitOps | Multi-cluster, SSO, image updates, secrets management, DR |

Most organizations are at level 2-3. GitOps moves to level 4-5, providing significantly better reliability, security, and auditability.

Disaster Recovery with GitOps

With GitOps, disaster recovery becomes trivial:

# A new cluster is created
# Install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# ArgoCD automatically syncs all applications from Git
# The cluster is restored to the exact desired state

This is the "push-button disaster recovery" that GitOps promises — from a new cluster to fully operational in minutes.

Member Exclusive Free Tutorial

This chapter is free exclusive content for registered members! Please login or register to unlock immediately.

Login / Register Now