GitOps concept

GitOps is een aanpak waarbij Git de enige bron van waarheid is voor de gewenste staat van je infrastructuur en applicaties. In plaats van direct naar een cluster te deployen via een CI/CD-pipeline, sla je de gewenste staat op in Git en laat je een agent in het cluster die staat afdwingen. Dit artikel legt de kernconcepten, het verschil met traditionele deployments en de architectuur uit.

De vier GitOps-principes

1. Declaratief — de gewenste staat wordt beschreven als code (YAML, HCL), niet als een reeks stappen
2. Versiebeheerd — alles staat in Git, met volledige auditlog en rollback-mogelijkheid
3. Automatisch toegepast — goedgekeurde wijzigingen worden automatisch uitgerold zonder handmatige stappen
4. Continu geverifieerd — een agent vergelijkt voortdurend de gewenste staat (Git) met de werkelijke staat (cluster)

Pull-based vs push-based: het cruciale verschil

Traditioneel (push-based): een CI/CD-pipeline heeft directe schrijftoegang tot het cluster. Na een build voert de pipeline kubectl apply uit. Dit vereist dat je cluster-credentials in je CI-systeem opslaat — een beveiligingsrisico.

GitOps (pull-based): een agent die in het cluster draait bewaakt de Git-repository en trekt wijzigingen op. De CI-pipeline heeft geen clustertoegang nodig — alleen schrijftoegang tot Git. Het cluster opent zelf de verbinding naar buiten, niet andersom.

# Push-based (traditioneel):
# CI/CD pipeline → kubectl apply → cluster
# Vereist: KUBECONFIG in CI-secrets

# Pull-based (GitOps):
# Developer → git push → Git repo
# ArgoCD/Flux in cluster → git pull → kubectl apply
# Vereist: alleen Git-leestoegang in het cluster

Drift en self-healing

Drift is het verschil tussen de gewenste staat in Git en de werkelijke staat in het cluster. Dit kan door handmatige wijzigingen via kubectl, door bugs in applicaties die hun eigen resources aanpassen, of door externe systemen.

Een GitOps-operator detecteert drift en kan die automatisch corrigeren (selfHeal: true). Dit is een van de krachtigste eigenschappen van GitOps: het cluster is altijd consistent met wat in Git staat, ongeacht wat er handmatig is gedaan.

# ArgoCD Application met selfHeal en prune
spec:
  syncPolicy:
    automated:
      prune: true      # Verwijder wat niet in Git staat
      selfHeal: true   # Corrigeer handmatige wijzigingen

ArgoCD architectuur

ArgoCD bestaat uit meerdere componenten die samenwerken:

• API server — de REST/gRPC API voor de UI en CLI
• Repository server — kloont Git-repositories en genereert Kubernetes-manifesten
• Application controller — bewaakt de clusterstatus en vergelijkt die met Git
• Redis — caching van repo-content en clusterstatus
• Dex — OIDC-authenticatie voor de ArgoCD-UI

# ArgoCD-componenten bekijken
kubectl get pods -n openshift-gitops
kubectl get pods -n argocd

# Application aanmaken
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: mijn-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/mijnorg/mijn-app
    targetRevision: main
    path: overlays/productie
  destination:
    server: https://kubernetes.default.svc
    namespace: productie
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

Flux architectuur

Flux is het andere grote GitOps-platform. In tegenstelling tot ArgoCD heeft Flux geen eigen UI — het is puur een set Kubernetes-controllers:

• Source controller — bewaakt Git-repositories, Helm-repositories en OCI-registries
• Kustomize controller — past Kustomize-overlays toe op het cluster
• Helm controller — beheert Helm-releases
• Notification controller — stuurt notificaties bij events
• Image automation controller — detecteert nieuwe container-images en past Git bij

# Flux installeren
flux bootstrap github \
  --owner=mijnorg \
  --repository=mijn-gitops-repo \
  --branch=main \
  --path=clusters/productie

# GitRepository aanmaken
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: mijn-app
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/mijnorg/mijn-app
  ref:
    branch: main

GitOps best practices

• Scheiding van app-code en configuratie — houd de applicatiecode en de Kubernetes-manifesten in aparte repositories. De CI-pipeline bouwt de image en update de tag in de config-repo; ArgoCD/Flux deployt die.
• Omgeving-specifieke overlays — gebruik Kustomize-overlays of Helm values-bestanden per omgeving (dev, staging, productie) in dezelfde repository
• Handmatige wijzigingen verboden — met selfHeal aan worden handmatige kubectl apply wijzigingen automatisch teruggedraaid. Train je team: alles via Git
• Secrets buiten Git — gebruik Sealed Secrets, External Secrets Operator of OpenBao om secrets veilig te beheren — nooit plain text secrets in Git

Relevantie voor certificeringen

• CGOA — GitOps-principes, pull vs push, Kustomize en Helm als bronformaten
• CAPA — ArgoCD Application, AppProject, sync policies, Argo Rollouts
• EX380 — OpenShift GitOps (Argo CD) als enterprise deployment tool