GitOps: Infrastructure Delivery

GitOps uses Git as the single source of truth for infrastructure and application deployments. Instead of running kubectl apply manually or clicking through cloud consoles, every change goes through a Git pull request. A GitOps operator (ArgoCD, Flux) watches the repo and automatically reconciles the desired state in Git with the actual state in the cluster.

---

GitOps Principles

Principle	What It Means
Declarative	Desired state described as code, not imperative scripts
Versioned	Everything in Git — complete history, auditability
Automated	Changes applied automatically when Git changes
Self-healing	Drift detected and corrected to match Git

---

Push vs Pull Deployment

Aspect	Push (Traditional CI/CD)	Pull (GitOps)
Who deploys	CI system pushes to cluster	Operator in cluster pulls from Git
Credentials	CI needs cluster credentials	Operator runs inside cluster
Drift detection	None (deploy and forget)	Continuous reconciliation
Rollback	Redeploy old version	git revert
Audit trail	CI logs	Git history

---

ArgoCD Architecture

┌──────────┐     ┌──────────────┐     ┌──────────────┐
│ Git Repo │     │   ArgoCD     │     │  Kubernetes  │
│          │◀────│              │────▶│  Cluster     │
│ manifests│     │ • Sync       │     │              │
│ helm     │     │ • Diff       │     │ • Pods       │
│ kustomize│     │ • Health     │     │ • Services   │
│          │     │ • Rollback   │     │ • ConfigMaps │
└──────────┘     └──────────────┘     └──────────────┘
                       │
                 ┌─────▼─────┐
                 │ Dashboard  │
                 │ (Sync      │
                 │  status,   │
                 │  health)   │
                 └────────────┘

ArgoCD Application

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: order-service
  namespace: argocd
spec:
  project: commerce
  source:
    repoURL: https://github.com/company/k8s-manifests
    targetRevision: main
    path: apps/order-service/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: commerce
  syncPolicy:
    automated:
      prune: true         # Delete resources not in Git
      selfHeal: true       # Fix drift automatically
    syncOptions:
      - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

---

Deployment Strategies

Strategy	Risk	Rollback Speed	Cost
Rolling update	Medium (gradual)	Minutes	No extra resources
Blue-Green	Low (instant switch)	Seconds	2x resources
Canary	Lowest (% traffic)	Seconds	Minimal extra resources
Feature flags	Lowest (code-level)	Instant	No extra resources

---

Repository Structure

k8s-manifests/
├── apps/
│   ├── order-service/
│   │   ├── base/                    # Shared manifests
│   │   │   ├── deployment.yaml
│   │   │   ├── service.yaml
│   │   │   └── kustomization.yaml
│   │   └── overlays/
│   │       ├── development/         # Dev overrides
│   │       ├── staging/             # Staging overrides
│   │       └── production/          # Prod overrides
│   │           ├── kustomization.yaml
│   │           └── patches/
│   │               └── replicas.yaml
│   └── payment-service/
│       └── ...
├── infrastructure/
│   ├── monitoring/
│   ├── ingress/
│   └── cert-manager/
└── argocd/
    ├── projects/
    └── applications/

---

Anti-Patterns

Anti-Pattern	Problem	Fix
Manual kubectl in production	No audit trail, no rollback, drift	All changes through Git PRs
CI pushes to cluster	CI has cluster credentials, no drift detection	GitOps operator pulls from Git
Monorepo for app + config	App changes trigger config deploys	Separate app repo and config repo
No automated sync	GitOps without automation is just Git	Enable automated sync with self-heal
Secrets in Git	Credentials exposed in repository	Sealed Secrets, External Secrets, or SOPS

---

Checklist

• GitOps operator deployed (ArgoCD or Flux)
• All manifests in Git (no manual kubectl)
• Automated sync enabled with self-healing
• Repository structure: base + environment overlays
• Secrets managed externally (Sealed Secrets, External Secrets)
• Deployment strategy: canary or blue-green for critical services
• Drift detection: alerts on manual cluster changes
• PR reviews required for production changes
• Rollback tested: git revert produces clean rollback

---

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For GitOps consulting, visit garnetgrid.com. :::