ArgoCD und GitOps 2026: Kubernetes Continuous Deployment und Interviewfragen

ArgoCD hat sich als führendes GitOps-Tool für Kubernetes Continuous Deployment etabliert. Mit der Veröffentlichung von Version 3.4 im Mai 2026 und über 64 % der Unternehmen, die GitOps als primären Bereitstellungsmechanismus einsetzen, ist das Thema aktueller denn je. Dieses Tutorial behandelt die Kernkonzepte von ArgoCD, praktische Konfigurationsmuster und die häufigsten Interviewfragen für DevOps- und Platform-Engineering-Positionen.

So implementiert ArgoCD das GitOps-Modell

ArgoCD läuft als Sammlung von Microservices innerhalb eines Kubernetes-Clusters: ein API-Server, ein Repo-Server, ein Application Controller und ein Redis-Cache. Der Controller überwacht Git-Repositories und vergleicht den gewünschten Zustand (Manifeste in Git) mit dem Live-Zustand im Cluster. Sobald eine Differenz erkannt wird, löst ArgoCD je nach konfigurierter Richtlinie entweder eine Warnung oder eine automatische Synchronisation aus.

Dieses Pull-basierte Modell bietet einen Sicherheitsvorteil gegenüber traditionellen CI-getriebenen Push-Deployments. Der Cluster zieht Änderungen aus Git, anstatt einen eingehenden Endpunkt für ein CI-Tool bereitzustellen. Die Zugangsdaten für den Cluster verlassen niemals die Cluster-Grenze.

Der erste Schritt besteht in der Installation von ArgoCD und der Definition einer Application-Ressource:

# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/acme/my-web-app-config
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true        # Remove resources deleted from Git
      selfHeal: true     # Revert manual changes in the cluster
    syncOptions:
      - CreateNamespace=true

Der source-Block verweist auf das Git-Repository mit den Kubernetes-Manifesten. Der destination-Block gibt den Ziel-Cluster und den Namespace an. Die Einstellung automated.selfHeal: true stellt sicher, dass manuelle kubectl-Änderungen innerhalb von Sekunden durch den im Git deklarierten Zustand überschrieben werden.

Sync Waves und Hooks für geordnete Deployments

Reale Deployments bestehen selten aus einem einzigen Manifest. Datenbankmigrationen müssen vor dem Start der Anwendungs-Pods ausgeführt werden. ConfigMaps und Secrets müssen existieren, bevor Deployments sie referenzieren. ArgoCD löst dieses Problem mit Sync Waves und Resource Hooks.

Sync Waves weisen Ressourcen eine numerische Reihenfolge zu. Niedrigere Nummern werden zuerst bereitgestellt, und ArgoCD wartet, bis jede Wave als gesund gemeldet wird, bevor es fortfährt:

# migration-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
  annotations:
    argocd.argoproj.io/sync-wave: "-1"   # Runs before wave 0
    argocd.argoproj.io/hook: PreSync      # Executes before main sync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: acme/my-web-app:latest
          command: ["python", "manage.py", "migrate"]
      restartPolicy: Never

Der PreSync-Hook führt den Migrations-Job aus, bevor ArgoCD die Hauptmanifeste der Anwendung anwendet. Die HookSucceeded-Löschrichtlinie bereinigt den Job nach erfolgreichem Abschluss. ArgoCD 3.3 führte zusätzlich PreDelete-Hooks ein und löste damit das langjährige Problem verwaister Ressourcen beim Entfernen von Anwendungen.

Multi-Cluster-Verwaltung mit ApplicationSets

Die Verwaltung Dutzender Cluster von einer einzigen ArgoCD-Instanz aus erfordert mehr als das Kopieren von Application-Manifesten. ApplicationSets generieren Application-Ressourcen dynamisch aus Templates und Generatoren:

# applicationset-clusters.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-web-app-all-clusters
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-web-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/acme/my-web-app-config
        targetRevision: main
        path: 'overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: production
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Der Cluster-Generator iteriert über alle registrierten Cluster mit dem Label env: production und erstellt eine Application pro Cluster. Die Platzhalter {{name}}, {{server}} und {{metadata.labels.region}} werden aus den Cluster-Registrierungsdaten aufgelöst. Das Hinzufügen eines neuen Produktions-Clusters zu ArgoCD löst automatisch die Bereitstellung der Anwendung auf diesem Cluster aus.

ArgoCD vs. Flux: Das richtige GitOps-Tool wählen

Der Vergleich zwischen ArgoCD und Flux gehört zu den häufigsten DevOps-Interviewthemen. Beide sind CNCF-Graduated-Projekte, die das GitOps-Muster implementieren, unterscheiden sich aber in Architektur und Kompromissen:

| Feature | ArgoCD 3.4 | Flux 2.8 | |---------|-----------|----------| | Architektur | Zentralisierter Server mit UI | Verteilte Controller pro Cluster | | Web UI | Integriertes, ausgereiftes Dashboard | Keine integrierte UI (Drittanbieter-Optionen) | | Helm-Support | Rendert Templates serverseitig | Native Helm SDK-Integration | | Multi-Cluster | Hub-and-Spoke von einer Instanz | Unabhängige Installation pro Cluster | | RBAC | Anwendungsebene mit SSO | Nur Kubernetes-natives RBAC | | Image-Automatisierung | Separater Image Updater | Integrierter Image Reflector/Automation | | Progressive Delivery | Argo Rollouts-Integration | Flagger-Integration | | Ressourcenbedarf | Höher (API-Server, Repo-Server, Redis) | Niedriger (nur benötigte Controller) |

ArgoCD eignet sich für Teams, die zentralisierte Übersicht, ein Web-Dashboard und feingranulares RBAC auf Anwendungsebene schätzen. Flux eignet sich für Teams, die Edge- oder ressourcenbeschränkte Umgebungen betreiben oder stark auf native Helm-Lifecycle-Features angewiesen sind. Manche Organisationen setzen beide ein: ArgoCD für Anwendungsdeployments, bei denen die UI Mehrwert bietet, und Flux für Infrastrukturkomponenten, bei denen verteilter Betrieb und Helm-Treue wichtiger sind.

Repository-Struktur für produktives GitOps

Ein häufiger Fehler bei der GitOps-Einführung ist die Speicherung von Kubernetes-Manifesten zusammen mit dem Anwendungs-Quellcode. Die Trennung des Konfigurations-Repositories vom App-Repository bietet eine sauberere Git-Historie, unabhängige Review-Zyklen und einfachere CI-Trigger:

# Empfohlene Repository-Struktur
my-web-app-config/
  base/
    deployment.yaml
    service.yaml
    kustomization.yaml
  overlays/
    staging/
      kustomization.yaml       # Patches for staging
      replica-count.yaml
    production/
      kustomization.yaml       # Patches for production
      replica-count.yaml
      hpa.yaml

Das base-Verzeichnis enthält gemeinsam genutzte Manifeste. Jedes Overlay wendet umgebungsspezifische Patches über Kustomize an. Die CI-Pipeline erstellt und pusht das Container-Image und aktualisiert anschließend das Image-Tag im Konfigurations-Repository. ArgoCD erkennt den Commit und synchronisiert die neue Version in den Cluster.

ArgoCD 3.4 Features, die man kennen sollte

ArgoCD 3.4, veröffentlicht im Mai 2026, zielt auf Day-2-Operations ab und enthält Features, die in Senior-DevOps-Interviews häufig abgefragt werden:

Pause Cluster Reconciliation ermöglicht es Operatoren, die ArgoCD-Synchronisation während Produktions-Incidents einzufrieren. Dies verhindert, dass ArgoCD Notfall-Hotfixes rückgängig macht, die direkt am Cluster vorgenommen wurden, während das Team das Problem behebt:

# Pause reconciliation on a specific cluster
apiVersion: v1
kind: Secret
metadata:
  name: prod-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
  annotations:
    argocd.argoproj.io/pause-reconciliation: "true"
stringData:
  server: https://prod-cluster.example.com
  config: |
    { "tlsClientConfig": { "insecure": false } }

Helm Value Globs ersetzen umfangreiche valueFiles-Arrays durch Muster und reduzieren damit Merge-Konflikte in Teams, die viele umgebungsspezifische Value-Dateien pflegen:

# Before ArgoCD 3.4
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production.yaml
      - values-production-eu.yaml
      - values-production-eu-secrets.yaml

# With ArgoCD 3.4 value globs
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production*.yaml

Häufige ArgoCD-Interviewfragen

Diese Fragen tauchen regelmäßig in DevOps- und Platform-Engineering-Interviews auf. Sie testen das Verständnis von GitOps-Prinzipien, nicht nur die ArgoCD-Syntax. Für eine umfassendere Kubernetes-Vorbereitung deckt das Kubernetes Advanced Modul Scheduling, Security Contexts und Custom Controllers ab.

"Erklären Sie den Unterschied zwischen automatischem und manuellem Sync in ArgoCD."

Automatischer Sync wendet Änderungen auf den Cluster an, sobald ArgoCD eine Differenz zwischen Git und dem Live-Zustand erkennt. Manueller Sync erfordert einen expliziten Auslöser über die UI, CLI oder API. Automatischer Sync mit selfHeal: true korrigiert kontinuierlich Drift und ist der Standard für Produktionsumgebungen, in denen Konfigurationskonsistenz entscheidend ist. Manueller Sync eignet sich für Staging-Umgebungen, in denen Teams Änderungen vor der Anwendung prüfen möchten.

"Was passiert, wenn ArgoCD einen Drift zwischen Git und dem Cluster erkennt?"

ArgoCD vergleicht den gewünschten Zustand (Git-Manifeste, gerendert über Helm, Kustomize oder Plain YAML) mit dem Live-Zustand im Cluster. Wenn automatischer Sync mit selfHeal aktiviert ist, setzt ArgoCD den Cluster sofort auf den Git-Zustand zurück. Ist selfHeal deaktiviert, markiert ArgoCD die Anwendung als OutOfSync und wartet auf manuelles Eingreifen. Der Ressourcen-Diff ist in der UI sichtbar und zeigt exakt, welche Felder abweichen.

"Wie würden Sie Datenbankmigrationen in einem GitOps-Workflow handhaben?"

Datenbankmigrationen laufen als PreSync-Hook-Jobs mit negativer Sync-Wave-Nummer. Der Migrations-Job wird ausgeführt, bevor ArgoCD die neue Anwendungsversion bereitstellt. Schlägt die Migration fehl, bricht die Synchronisation ab und die vorherige Anwendungsversion bleibt aktiv. Die HookSucceeded-Löschrichtlinie bereinigt erfolgreiche Migrations-Jobs. Für Rollback-Szenarien müssen Migrationsskripte als idempotente Operationen konzipiert sein.

"Vergleichen Sie ArgoCD und Flux für ein Multi-Cluster-Produktions-Setup."

ArgoCD verwaltet mehrere Cluster von einer einzigen Steuerungsebene aus und bietet zentralisierte Übersicht durch sein Dashboard sowie einheitliches RBAC über alle Cluster. Flux läuft unabhängig in jedem Cluster und reduziert den Blast Radius, da ein Ausfall der Steuerungsebene nur einen Cluster betrifft. Bei 100+ Clustern erfordert das zentralisierte ArgoCD-Modell einen robusten Management-Cluster, während der verteilte Flux-Ansatz diesen Single Point of Failure eliminiert. Die Wahl hängt davon ab, ob das Team operative Einfachheit (ArgoCD) oder Fehlerisolierung (Flux) priorisiert. Das CI/CD Pipeline Security Modul behandelt verwandte Fragen zur Absicherung von Deployment-Pipelines.

"Was ist ein ApplicationSet und wann würde man es einsetzen?"

Ein ApplicationSet ist ein Controller, der ArgoCD-Application-Ressourcen aus Templates generiert. Er verwendet Generatoren (Cluster, Git Directory, List, Matrix, Merge), um mehrere Applications aus einer einzigen Definition zu erzeugen. Typische Anwendungsfälle sind die Bereitstellung derselben Anwendung über alle Produktions-Cluster hinweg, die Generierung mandantenspezifischer Anwendungen in einer Multi-Tenant-SaaS-Plattform oder die Erstellung von Applications für jedes Verzeichnis in einem Monorepo.

Fazit

• ArgoCD 3.4 (Mai 2026) fügt Pause Reconciliation und Helm Value Globs hinzu und adressiert damit Day-2-Betriebsanforderungen in Kubernetes-Produktionsclustern
• Das Pull-basierte GitOps-Modell eliminiert die Notwendigkeit, Cluster-Zugangsdaten an CI-Tools weiterzugeben, und hält Secrets innerhalb der Cluster-Grenze
• Sync Waves und Hooks lösen die Deployment-Reihenfolge: Migrationen vor App-Pods, ConfigMaps vor Deployments, Aufräumen nach dem Löschen
• ApplicationSets automatisieren Multi-Cluster-Deployments durch Generierung von Application-Ressourcen aus Cluster-Labels, Git-Verzeichnissen oder benutzerdefinierten Listen
• Konfigurations-Repositories sollten von App-Repositories getrennt werden für eine sauberere Git-Historie, unabhängige Review-Zyklen und einfachere CI-Trigger
• ArgoCD eignet sich für zentralisiertes Multi-Cluster-Management mit Dashboard und RBAC; Flux eignet sich für verteilte, ressourcenbeschränkte oder Helm-intensive Umgebungen
• Die Interviewvorbereitung für GitOps-Rollen sollte Drift-Erkennung, Sync-Strategien, Fehlermodi und konkrete Produktionsszenarien abdecken, nicht nur auswendig gelernte Definitionen