GitOps Principles

GitOps is a modern approach to continuous delivery that uses Git as the single source of truth for declarative infrastructure and applications. It was first introduced by Weaveworks in 2017 and has since become a standard practice for managing Kubernetes deployments.

What is GitOps?

GitOps is a set of practices that brings infrastructure and application management into version control. Instead of manually applying changes or using push-based CI/CD pipelines, GitOps uses a pull-based model where a controller continuously reconciles the desired state (defined in Git) with the actual state in your cluster.

graph TB A[Developer] --> B[Git Repository] B --> C[GitOps Controller] C --> D[Kubernetes Cluster] D --> E[Reconciliation Loop] E --> C F[Configuration Drift] --> E E --> G[Detect Difference] G --> H[Apply Changes] H --> D style B fill:#e1f5ff style C fill:#e8f5e9 style D fill:#fff4e1 style E fill:#f3e5f5

Core Principles

GitOps is built on four fundamental principles:

1. Declarative Configuration

Everything is defined as code. Your infrastructure, applications, and configurations are stored as declarative manifests (YAML, JSON, or other formats) in Git.

Example declarative manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web
        image: myregistry/web-app:v1.2.3
        ports:
        - containerPort: 8080

This manifest declares the desired state: “I want 3 replicas of web-app running version v1.2.3.” The GitOps controller ensures this state is maintained.

2. Git as Single Source of Truth

Git becomes the authoritative source for all configuration. Every change goes through Git:

Code changes
Configuration updates
Infrastructure changes
Rollbacks (via Git revert)

Benefits:

Complete audit trail of all changes
Easy rollbacks by reverting commits
Standard Git workflows (branches, pull requests, reviews)
Collaboration through familiar tools

3. Continuous Reconciliation

The GitOps controller continuously monitors both:

Desired state - What’s defined in Git
Actual state - What’s running in the cluster

When differences are detected, the controller automatically applies changes to bring the cluster back to the desired state.

graph LR A[Git State] --> B[Controller] C[Cluster State] --> B B --> D{States Match?} D -->|No| E[Apply Changes] D -->|Yes| F[Wait & Monitor] E --> C F --> B style A fill:#e1f5ff style C fill:#fff4e1 style B fill:#e8f5e9 style E fill:#ffe1e1

4. Automated Deployments

Deployments happen automatically when changes are merged to the main branch (or configured branch). No manual kubectl apply commands needed.

GitOps vs Traditional CI/CD

Traditional CI/CD uses a push-based model, while GitOps uses a pull-based model.

Push-Based Model (Traditional CI/CD)

graph LR A[Developer] --> B[Git Push] B --> C[CI Pipeline] C --> D[Build Image] D --> E[Push to Registry] E --> F[Deploy to Cluster] F --> G[kubectl apply] G --> H[Kubernetes] style C fill:#ffe1e1 style F fill:#ffe1e1 style G fill:#ffe1e1

Characteristics:

CI/CD pipeline pushes changes to the cluster
Requires cluster credentials in CI/CD system
Cluster must be accessible from CI/CD
Changes happen immediately when pipeline runs

Challenges:

Security risk: CI/CD system needs cluster access
No automatic drift detection
Harder to audit what’s actually running
Manual rollbacks required

Pull-Based Model (GitOps)

graph LR A[Developer] --> B[Git Push] B --> C[Git Repository] C --> D[GitOps Controller] D --> E[Pulls from Git] E --> F[Compares States] F --> G{Drift Detected?} G -->|Yes| H[Apply Changes] G -->|No| I[Wait] H --> J[Kubernetes] I --> D style C fill:#e1f5ff style D fill:#e8f5e9 style H fill:#fff4e1

Characteristics:

GitOps controller pulls from Git
Controller runs inside the cluster
No external system needs cluster credentials
Continuous reconciliation detects and fixes drift

Benefits:

Better security: No external credentials needed
Automatic drift detection and correction
Complete audit trail in Git
Easy rollbacks via Git revert

The GitOps Workflow

Here’s how a typical GitOps workflow operates:

sequenceDiagram participant Dev as Developer participant Git as Git Repository participant CI as CI Pipeline participant Reg as Container Registry participant Ctrl as GitOps Controller participant K8s as Kubernetes Cluster Dev->>Git: 1. Commit code changes Dev->>Git: 2. Update manifests (image tag) Git->>CI: 3. Trigger CI pipeline CI->>Reg: 4. Build & push new image CI->>Git: 5. Update manifest with new tag Ctrl->>Git: 6. Poll for changes Git->>Ctrl: 7. Return updated manifests Ctrl->>K8s: 8. Apply changes K8s->>Ctrl: 9. Report status Ctrl->>Git: 10. Update status (optional)

Step-by-step:

Developer commits code - Pushes application code to Git
Update manifests - Updates Kubernetes manifests with new image tag
CI pipeline runs - Builds container image
Image pushed - New image pushed to container registry
Manifest updated - CI updates Git with new image tag (or developer does this)
Controller polls - GitOps controller periodically checks Git for changes
Changes detected - Controller sees updated manifests
Apply changes - Controller applies manifests to cluster
Status reported - Controller monitors deployment status
Status updated - Optional: Controller updates Git with deployment status

Benefits of GitOps

1. Complete Audit Trail

Every change is tracked in Git with:

Who made the change (author)
When it was made (timestamp)
What changed (diff)
Why it changed (commit message)

# View deployment history
git log --oneline deployments/

# See what changed
git show <commit-hash>

# Rollback to previous version
git revert <commit-hash>

2. Easy Rollbacks

Rolling back is as simple as reverting a Git commit:

# Revert the last deployment
git revert HEAD
git push

# GitOps controller automatically applies the rollback

3. Improved Security

No cluster credentials in CI/CD systems
All changes go through Git (can enforce reviews)
RBAC can be applied to Git repositories
Secrets can be managed separately (e.g., Sealed Secrets, External Secrets)

4. Faster Recovery

If your cluster is destroyed or corrupted:

Provision a new cluster
Install GitOps controller
Point it to your Git repository
Controller automatically restores everything

5. Better Collaboration

Teams use familiar Git workflows:

Feature branches for testing
Pull requests for reviews
Code review for infrastructure changes
Merge to main for deployment

6. Consistency

The same Git repository can deploy to:

Development clusters
Staging clusters
Production clusters
Multiple regions

Each environment uses the same process, reducing errors.

GitOps Tools

Popular GitOps tools for Kubernetes:

ArgoCD

Declarative continuous delivery
Web UI for visualization
Multi-cluster support
Application health monitoring

Flux

CNCF graduated project
GitOps Toolkit (modular components)
Image automation
Helm and Kustomize support

Jenkins X

Full CI/CD solution
Built-in GitOps
Preview environments
Automated promotion

Common GitOps Patterns

App-of-Apps Pattern

A parent application manages multiple child applications:

graph TB A[Root Application] --> B[App 1] A --> C[App 2] A --> D[App 3] B --> E[Deployment] B --> F[Service] C --> G[StatefulSet] C --> H[ConfigMap] style A fill:#e1f5ff style B fill:#e8f5e9 style C fill:#e8f5e9 style D fill:#e8f5e9

Environment Promotion

Promote applications through environments using Git branches or directories:

graph LR A[dev branch] --> B[staging branch] B --> C[production branch] D[dev/ directory] --> E[staging/ directory] E --> F[production/ directory] style A fill:#e1f5ff style B fill:#fff4e1 style C fill:#ffe1e1

Best Practices

1. Separate Repositories

Consider separate repositories for:

Application code
Infrastructure manifests
Configuration (per environment)

2. Use Kustomize or Helm

Don’t duplicate manifests for each environment. Use:

Kustomize - Native Kubernetes tool for overlays
Helm - Package manager with templating

3. Pin Image Versions

Always use specific image tags, not latest:

# Good
image: myapp:v1.2.3

# Bad
image: myapp:latest

4. Automate Image Updates

Use tools like:

Flux Image Automation
ArgoCD Image Updater
Renovate Bot

5. Protect Main Branch

Require pull request reviews
Enforce branch protection rules
Run automated tests before merge

6. Monitor and Alert

Set up alerts for:

Failed deployments
Configuration drift
Sync failures
Application health

When to Use GitOps

GitOps is ideal when you:

✅ Manage Kubernetes clusters
✅ Need audit trails
✅ Want automated deployments
✅ Require easy rollbacks
✅ Have multiple environments
✅ Need compliance and governance

GitOps may not be suitable if you:

❌ Don’t use Kubernetes
❌ Need immediate deployments (GitOps has polling delay)
❌ Have very simple, single-environment setups
❌ Require complex, imperative operations

Getting Started

To adopt GitOps, you need:

Git repository - Store your Kubernetes manifests
GitOps tool - Choose ArgoCD, Flux, or another tool
Container registry - Store your application images
CI/CD pipeline - Build and push images (optional: update manifests)

Start small:

Set up a Git repository with your manifests
Install a GitOps controller (ArgoCD or Flux)
Create your first application
Gradually migrate more workloads

Summary

GitOps transforms how you manage Kubernetes deployments by:

Making Git the single source of truth
Automating deployments through reconciliation
Providing complete audit trails
Enabling easy rollbacks
Improving security and collaboration

The pull-based model ensures your cluster always matches what’s defined in Git, automatically detecting and correcting any drift. This makes Kubernetes operations more reliable, secure, and maintainable.