GitOps in der Praxis: Git als Single Source of Truth für Infrastruktur

Die meisten Teams, die sagen, sie machen GitOps, machen in Wirklichkeit „Git-triggered CI/CD.” Der Unterschied ist fundamental. GitOps ist nicht nur „Manifeste in Git” — es ist ein Architekturmuster mit Pull-basierter Reconciliation Loop, deklarativem Desired State und automatischer Drift-Erkennung. Dieser Artikel erklärt, was GitOps wirklich ist, wie man es mit ArgoCD oder Flux deployt, und wo die meisten Implementierungen still scheitern.

Was GitOps ist — und was nicht¶

Der Begriff GitOps wurde erstmals 2017 von Alexis Richardson von Weaveworks verwendet. Die OpenGitOps-Arbeitsgruppe unter der CNCF definierte vier Prinzipien, ohne die man nicht von GitOps sprechen kann.

Vier OpenGitOps-Prinzipien (v1.0.0)¶

1

Deklarativ¶

Das gesamte System muss deklarativ beschrieben sein. Keine Skripte, die Schritt für Schritt etwas tun, sondern Manifeste, die sagen „so soll das System aussehen.”

2

Versioniert und Unveränderlich¶

Desired State lebt in einem Git-Repository. Jede Änderung ist ein Commit. Jeder Commit hat einen Autor, Zeitstempel und Diff. Rollback bedeutet git revert.

3

Automatisch gezogen¶

Hier scheitern die meisten „GitOps”-Implementierungen. Echtes GitOps verwendet ein Pull-Modell — ein Agent im Cluster (ArgoCD, Flux) überwacht kontinuierlich das Git-Repository und zieht Änderungen.

4

Kontinuierlich Abgeglichen¶

Der Agent vergleicht kontinuierlich den Ist-Zustand mit dem Soll-Zustand. Wenn sie sich unterscheiden, korrigiert der Agent den Zustand automatisch. Das ist die Reconciliation Loop — das Herz von GitOps.

ArgoCD vs Flux: Praktischer Vergleich¶

Kriterium	ArgoCD	Flux
UI	Reichhaltige Web-UI mit Resource-Tree-Visualisierung	Keine native UI
Architektur	Zentralisierter Server + API	Verteilte Controller
Multi-Tenancy	AppProjects mit RBAC, SSO-Integration	Native Kubernetes RBAC
Helm-Support	Rendert Helm Charts als Plain Manifests	Native HelmRelease CRD
Image-Automatisierung	ArgoCD Image Updater (separate Komponente)	Eingebauter Image Reflector
CNCF-Status	Graduated (Dezember 2022)	Graduated (November 2024)

Wann ArgoCD¶

Wenn das Team visuelle Übersicht braucht, mehrere Teams deployen, oder SSO-Integration erforderlich ist.

Wann Flux¶

Für Kubernetes-native Umgebungen, maximale Composability und CLI-fokussierte Workflows.

Repository-Strategie: Mono vs Multi¶

Getrennte Repositories: App-Repo + Config-Repo¶

Anwendungscode in einem Repository, Deployment-Manifeste in einem anderen. Unsere Empfehlung für die meisten Enterprise-Kunden.

# GitOps in der Praxis: Git als Single Source of Truth für Infrastruktur
config-repo/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
├── overlays/
│   ├── staging/
│   │   ├── kustomization.yaml # image: v1.24.0
│   │   └── replicas-patch.yaml
│   └── production/
│       ├── kustomization.yaml # image: v1.23.2
│       └── replicas-patch.yaml
└── README.md

ArgoCD: Produktions-Setup¶

Application CRD¶

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payment-service
  namespace: argocd
spec:
  project: backend-team
  source:
    repoURL: https://github.com/acme/k8s-config.git
    targetRevision: main
    path: apps/payment-service/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: payment
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - PruneLast=true
    retry:
      limit: 3
      backoff:
        duration: 5s
        maxDuration: 3m
        factor: 2

Secrets in GitOps: Der Elefant im Raum¶

Drei Ansätze: Sealed Secrets (Bitnami), SOPS + Age/KMS (Mozilla), und External Secrets Operator — unser bevorzugter Ansatz für Enterprise.

# ExternalSecret — Referenz auf Vault, nicht das Secret selbst
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-credentials
  data:
    - secretKey: username
      remoteRef:
        key: secret/data/production/db
        property: username
    - secretKey: password
      remoteRef:
        key: secret/data/production/db
        property: password

Anti-Patterns von GitOps-Implementierungen¶

• Push-basiertes „GitOps”: CI-Pipeline, die kubectl apply aufruft. Das ist CI/CD mit besserem Branding, nicht GitOps.
• Manuelles kubectl „nur dieses eine Mal”: Wenn selfHeal aktiviert ist, revertiert ArgoCD Ihre Änderung innerhalb von 3 Minuten.
• Secrets im Klartext in Git: Ein einmal committetes Secret im Klartext ist ein kompromittiertes Secret.
• Eine riesige Application für den gesamten Cluster: Granularität: eine Application pro Microservice oder pro Team.

Fazit: GitOps ist kein Tool, es ist eine Betriebsphilosophie¶

GitOps ist nicht ArgoCD. Es ist nicht Flux. Es ist ein Betriebsmodell, bei dem Git die Single Source of Truth über den Infrastrukturzustand ist und Software-Agenten diesen Zustand kontinuierlich durchsetzen.

Wenn Ihr Team heute via kubectl apply deployt — starten Sie mit einem kleinen Piloten. Ein Service, ein Config-Repo, ArgoCD mit Standard-Einstellungen. Sie werden den Unterschied in einer Woche sehen. In einem Monat wollen Sie nicht mehr zurück.