GitOps mit Argo CD: Pull-basierte Deployments auf Kubernetes richtig umsetzen

TL;DR

• GitOps dreht das Deployment-Modell um: Nicht die CI-Pipeline pusht in den Cluster, sondern ein Agent im Cluster pullt den gewuenschten Zustand aus Git.
• Argo CD ueberwacht ein Git-Repository und gleicht den Cluster-Zustand automatisch ab (Reconciliation Loop).
• Das App-of-Apps-Pattern macht Multi-Environment-Setups (Dev, Staging, Prod) handhabbar.
• Rollbacks werden trivial: git revert genuegt, um den vorherigen Zustand wiederherzustellen.
• Der groesste Vorteil ist nicht Geschwindigkeit, sondern Auditierbarkeit -- jede Aenderung hat einen Commit-Hash.

Was GitOps eigentlich bedeutet (und was nicht)

GitOps ist kein Tool, sondern ein Betriebsmodell. Der Kerngedanke: Der gewuenschte Zustand der gesamten Infrastruktur liegt deklarativ in einem Git-Repository. Ein Controller im Cluster vergleicht diesen Soll-Zustand laufend mit dem Ist-Zustand und korrigiert Abweichungen automatisch.

Das unterscheidet sich fundamental vom klassischen CI/CD-Ansatz, bei dem eine Pipeline nach dem Build Befehle wie kubectl apply ausfuehrt. Beim Push-Modell braucht die Pipeline Cluster-Credentials. Beim Pull-Modell hat nur der Agent im Cluster Zugriff -- die Angriffslaeche wird deutlich kleiner.

Wichtig: GitOps ersetzt nicht CI. Die CI-Pipeline baut weiterhin Images und fuehrt Tests durch. GitOps uebernimmt ausschliesslich den CD-Teil.

Argo CD vs. Flux CD: Welches Tool passt besser?

Beide Projekte sind CNCF-graduated und produktionsreif. Die Unterschiede liegen im Detail.

Fuer Teams, die gerade erst mit GitOps starten, ist Argo CD oft der pragmatischere Einstieg. Das Web-UI macht den Sync-Status sichtbar und erleichtert das Debugging. Flux ist staerker auf den "alles in Git, nichts per Hand"-Ansatz ausgerichtet.

Argo CD installieren und konfigurieren

Die Installation erfolgt entweder per Helm-Chart oder direkt ueber die offiziellen Manifeste. Fuer produktive Setups empfehle ich Helm, weil sich Werte wie Resource Limits und HA-Konfiguration sauber parametrisieren lassen.

# Namespace erstellen
kubectl create namespace argocd

# Argo CD via Helm installieren (HA-Modus)
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

helm install argocd argo/argo-cd \
  --namespace argocd \
  --set server.replicas=2 \
  --set controller.replicas=1 \
  --set repoServer.replicas=2 \
  --set redis-ha.enabled=true \
  --set server.ingress.enabled=true \
  --set server.ingress.hostname=argocd.internal.example.com

# Admin-Passwort auslesen
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

Nach der Installation laeuft Argo CD als Set aus mehreren Komponenten: Der Application Controller fuehrt die Reconciliation durch, der Repo Server klont und rendert die Git-Repos, und der API Server stellt UI und CLI bereit.

Repository-Struktur fuer Multi-Environment-Setups

Die Trennung von Applikations-Code und Deployment-Konfiguration ist zentral. In der Praxis hat sich folgende Struktur bewaehrt:

gitops-config/
  apps/
    my-api/
      base/
        deployment.yaml
        service.yaml
        kustomization.yaml
      overlays/
        dev/
          kustomization.yaml
          replicas-patch.yaml
        staging/
          kustomization.yaml
        prod/
          kustomization.yaml
          replicas-patch.yaml
          hpa.yaml
  argocd/
    app-of-apps.yaml
    projects/
      team-backend.yaml
      team-frontend.yaml

Die base/-Verzeichnisse enthalten die gemeinsamen Manifeste. Die overlays/-Verzeichnisse ueberschreiben oder ergaenzen per Kustomize. So bleibt die Konfiguration DRY, und Aenderungen an der Basis wirken sich auf alle Umgebungen aus.

Das App-of-Apps-Pattern

Statt jede Application einzeln in Argo CD anzulegen, definiert eine uebergeordnete Application alle anderen. Das skaliert deutlich besser als manuelle Konfiguration.

# argocd/app-of-apps.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-of-apps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.example.com/infra/gitops-config.git
    targetRevision: main
    path: argocd/applications
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Im Verzeichnis argocd/applications/ liegt dann fuer jeden Service eine eigene Application-YAML. Wird ein neuer Service angelegt, genuegt ein Commit mit der neuen Application-Definition, und Argo CD deployed ihn automatisch.

Sync-Strategien und Rollbacks

Argo CD kennt drei Sync-Modi:

Auto-Sync mit Self-Heal: Der Controller gleicht Abweichungen automatisch aus. Aendert jemand manuell etwas im Cluster per kubectl edit, wird die Aenderung zurueckgesetzt. Das ist der sicherste Modus fuer Produktionsumgebungen.

Auto-Sync ohne Self-Heal: Neue Commits werden automatisch angewendet, aber manuelle Aenderungen im Cluster bleiben bestehen. Selten sinnvoll, weil es den Drift nicht verhindert.

Manual Sync: Aenderungen in Git werden erkannt und angezeigt, aber erst nach expliziter Freigabe angewendet. Nuetzlich fuer Staging-Umgebungen, in denen ein Team-Lead den Rollout bestaetigten soll.

Fuer Rollbacks gibt es zwei Wege: Entweder per git revert auf den vorherigen Commit (bevorzugt, weil es in der Git-Historie nachvollziehbar bleibt), oder ueber die Argo CD UI/CLI, die den Cluster auf einen aelteren Sync-Zustand zuruecksetzt.

Secret Management in GitOps

Secrets gehoeren nicht im Klartext in Git. Es gibt mehrere Loesungen:

Sealed Secrets: Verschluesselt Secrets mit einem Cluster-spezifischen Key. Nur der Controller im Cluster kann sie entschluesseln. Einfach, aber der Key muss gesichert werden.

External Secrets Operator: Synchronisiert Secrets aus externen Stores (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) in Kubernetes Secrets. Der bevorzugte Ansatz fuer groessere Setups. Mehr dazu unter /blog/kubernetes-secrets-management-vault.

SOPS (Mozilla): Verschluesselt YAML-Dateien direkt im Repository mit Age- oder PGP-Keys. Funktioniert gut mit Flux, bei Argo CD ist ein Plugin noetig.

Monitoring des GitOps-Workflows

Argo CD exponiert Prometheus-Metriken auf Port 8082. Die wichtigsten Metriken:

• argocd_app_info: Status aller Applications (Synced, OutOfSync, Degraded)
• argocd_app_sync_total: Anzahl der Sync-Operationen
• argocd_app_reconcile_count: Wie oft der Controller den Zustand abgeglichen hat
• argocd_git_request_total: Git-Operationen (hilfreich, um Rate-Limiting zu erkennen)

Richten Sie Alerts fuer den Status OutOfSync und Degraded ein. Wenn eine Application laenger als 10 Minuten OutOfSync bleibt, stimmt entweder etwas mit dem Manifest oder mit dem Cluster. Fuer eine tiefergehende Monitoring-Strategie empfehle ich den Artikel zu /blog/opentelemetry-kubernetes-deutschland.

Typische Stolperfallen

Zu grosse Repositories: Wenn das GitOps-Repo Tausende von Manifesten enthaelt, wird der Repo-Server zum Bottleneck. Teilen Sie auf: ein Repo pro Team oder Domaene.

Helm-Charts mit externen Dependencies: Argo CD rendert Helm-Charts serverseitig. Wenn ein Chart von einer externen Registry abhaengt, die nicht erreichbar ist, schlaegt der Sync fehl. Pinnen Sie Chart-Versionen und pruefen Sie die Erreichbarkeit.

Fehlende Health Checks: Argo CD erkennt den Sync-Status anhand von Kubernetes-Health-Checks. Wenn Ihre Custom Resources keine Health-Informationen liefern, zeigt Argo CD dauerhaft "Progressing" an. Definieren Sie Custom Health Checks in der Argo CD ConfigMap.

Namespace-Konflikte: Wenn mehrere Applications denselben Namespace verwalten wollen, kommt es zu Konflikten. Definieren Sie klare Ownership-Regeln ueber Argo CD Projects.

Multi-Cluster GitOps

Wenn Sie mehrere Cluster betreiben, kann Argo CD alle aus einer einzigen Instanz verwalten. Dazu registrieren Sie zusaetzliche Cluster:

# Cluster zur Argo CD-Instanz hinzufuegen
argocd cluster add staging-cluster \
  --kubeconfig ~/.kube/staging.yaml \
  --name staging

# Alle registrierten Cluster anzeigen
argocd cluster list

Jede Application in Argo CD hat ein destination-Feld, das den Zielcluster definiert. So koennen Sie dasselbe GitOps-Repo fuer Dev, Staging und Prod verwenden -- mit unterschiedlichen Kustomize-Overlays pro Umgebung.

Achten Sie darauf, dass der Argo CD Service Account in jedem Zielcluster nur die minimal noetigen RBAC-Rechte hat. Ein Wildcard cluster-admin fuer alle Cluster ist ein Sicherheitsrisiko.

Sync Waves und Hooks

Bei komplexeren Deployments (z.B. Datenbank-Migration vor App-Update) brauchen Sie eine definierte Reihenfolge. Argo CD bietet dafuer Sync Waves und Resource Hooks.

Sync Waves nummerieren Ressourcen. Niedrigere Nummern werden zuerst synchronisiert:

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "-1"  # wird vor Wave 0 synchronisiert

Resource Hooks fuehren Jobs zu bestimmten Zeitpunkten aus (PreSync, Sync, PostSync). Ein typischer Use Case: Ein PreSync-Hook fuehrt flyway migrate aus, bevor das neue Deployment ausgerollt wird.

Migration von CI/CD zu GitOps

Der Umstieg muss nicht auf einen Schlag passieren. Ein bewaehrter Migrationsplan:

1. Bestehendes Setup dokumentieren: Welche Pipelines deployen wohin? Welche Secrets werden genutzt?
2. GitOps-Repo aufsetzen mit der aktuellen Konfiguration der Zielumgebung.
3. Argo CD installieren und eine nicht-kritische Anwendung im Manual-Sync-Modus onboarden.
4. CI-Pipeline anpassen: Statt kubectl apply aktualisiert die Pipeline das Image-Tag im GitOps-Repo.
5. Nach erfolgreichem Test auf Auto-Sync mit Self-Heal umstellen.
6. Weitere Anwendungen iterativ migrieren.

Fuer die CI/CD-Seite finden Sie weitere Details unter /blog/kubernetes-cicd-enterprise-scale.

Sicherheitsaspekte

Das Pull-Modell hat einen entscheidenden Sicherheitsvorteil: Die CI-Pipeline braucht keinen cluster-admin-Zugriff mehr. Stattdessen benoetigt nur Argo CD im Cluster die noetigen RBAC-Rechte.

Weitere Best Practices:

• Aktivieren Sie SSO fuer die Argo CD UI (OIDC/SAML).
• Nutzen Sie Argo CD Projects, um Teams auf bestimmte Namespaces und Repositories einzuschraenken.
• Signieren Sie Commits im GitOps-Repo mit GPG-Keys und aktivieren Sie die Commit-Signatur-Verifikation in Argo CD.
• Scannen Sie Manifeste im Git-Repo automatisch auf Security-Probleme (z.B. mit kubesec oder kube-linter).

Mehr zum Thema Security Hardening unter /blog/kubernetes-security-hardening-checkliste.

Notifications und Alerting

Argo CD hat eine integrierte Notification Engine, die Events an Slack, Teams, E-Mail oder Webhooks senden kann. Konfigurieren Sie Notifications fuer diese Events:

• Sync erfolgreich: Informiert das Team, dass ein Deployment durchgelaufen ist.
• Sync fehlgeschlagen: Kritisch -- erfordert sofortige Aufmerksamkeit.
• Health Degraded: Eine Application ist nicht mehr gesund (z.B. Pod CrashLoopBackOff).
• Out of Sync: Jemand hat manuell etwas im Cluster geaendert, das nicht mit Git uebereinstimmt.

Vermeiden Sie Notification Fatigue: Senden Sie nur Fehler und Warnungen in den Team-Channel. Erfolgreiche Syncs koennen in einen separaten, optionalen Channel gehen.

Fazit

GitOps mit Argo CD ist kein Hype, sondern ein Betriebsmodell, das die Zuverlaessigkeit und Nachvollziehbarkeit von Deployments grundlegend verbessert. Die initiale Einrichtung braucht Zeit -- vor allem die Repository-Struktur und das Secret Management muessen durchdacht sein. Aber sobald der Workflow steht, wird jedes Deployment zu einem git commit, jeder Rollback zu einem git revert, und jede Frage "Wer hat wann was geaendert?" laesst sich mit git log beantworten.

Der pragmatischste Einstieg: Eine nicht-kritische Anwendung mit Manual Sync in Argo CD onboarden und das Team zwei Wochen damit arbeiten lassen. Danach ist die Entscheidung fuer oder gegen GitOps meistens eindeutig.

Wenn Sie Unterstuetzung bei der Planung oder Umsetzung brauchen, melden Sie sich gerne unter /kontakt.