DevOps 3 Min Lesezeit

GitOps mit ArgoCD – Kubernetes Deployment Guide 2026

1. Was ist GitOps und warum ArgoCD die erste Wahl ist

GitOps ist ein operatives Modell, bei dem der gewünschte Zustand von Infrastruktur und Anwendungen in einem Git-Repository versioniert wird. Ein Agent – im Fall von ArgoCD der argocd-application-controller – gleicht den Live-Zustand im Cluster kontinuierlich mit dem Repository ab und führt bei Abweichungen automatisch oder manuell eine Synchronisation durch.

Der entscheidende Vorteil gegenüber traditionellen CI/CD-Pipelines: Deployments werden reproduzierbar, auditierbar und rollback-fähig. Jede Änderung durchläuft einen Pull-Request, jede Regression lässt sich über git revert rückgängig machen. ArgoCD wurde ursprünglich von Intuit entwickelt und ist heute ein CNCF-Graduated-Projekt mit über 18.000 GitHub-Stars.

Im Vergleich zu klassischen Push-Pipelines (Jenkins, GitLab CI) eliminiert ArgoCD das Problem credentialed CI-Runner, die direkt in produktive Cluster schreiben dürfen. Stattdessen pullt der Controller aus dem Cluster heraus, was das Sicherheitsmodell grundlegend verbessert und den Blast Radius kompromittierter Build-Agents drastisch reduziert.

Für 2026 prognostizieren wir eine noch stärkere Verbreitung von ArgoCD durch ApplicationSets, progressive Sync-Strategien und die native Integration in Service-Mesh-Lösungen wie Istio und Linkerd. Plattformen wie Red Hat OpenShift GitOps setzen vollständig auf ArgoCD als Operator-Schicht.

GitOps-Tools im Überblick (2026)
ToolModellSync-EngineMulti-ClusterLizenz
ArgoCDPull-basiertKubernetes-nativeJa (AppSets + Hub-Spoke)Apache 2.0
FluxCDPull-basiertHelm/Kustomize/OCIJa (Multi-Tenancy)Apache 2.0
Jenkins XPush/Pull hybridTekton-basiertEingeschränktApache 2.0
SpinnakerPush-basiertCloud-agnostischJaApache 2.0

2. ArgoCD Architektur und Kernkomponenten verstehen

Die ArgoCD-Architektur folgt dem klassischen Controller-Pattern von Kubernetes. Drei zentrale Komponenten bilden das Herzstück: der API-Server, der Application Controller und das Repository Server. Jede dieser Komponenten übernimmt klar abgegrenzte Aufgaben und lässt sich unabhängig skalieren.

Der argocd-server stellt die Web-UI, die CLI-Schnittstelle und die gRPC/REST-API bereit. Über ihn laufen Authentifizierung, Autorisierung sowie alle manuellen Sync-Operationen. In Produktion sollte dieser Pod hinter einem Ingress mit TLS-Termination betrieben werden, idealerweise mit OIDC-Integration zu Keycloak, Okta oder Azure AD.

Der argocd-application-controller ist der Workhorse. Er pollt konfigurierbare Git-Repos, vergleicht den Live-Zustand mit dem gewünschten Zustand und triggert bei Drifts eine Reconciliation. Standard-Polling-Intervall sind 3 Minuten; in Hochfrequenz-Szenarien lässt sich dies pro Application auf 30 Sekunden reduzieren – beachte dabei die API-Server-Last des Git-Providers.

Der argocd-repo-server cached Git-Repositories lokal und rendert Helm-, Kustomize- und Plugin-Templates. Er entlastet den Application Controller von CPU-intensiven Templating-Aufgaben und hält Manifeste über einen internen Redis-Cache vor. In großen Setups empfiehlt sich ein dedizierter Repo-Server mit horizontaler Skalierung.

# Beispiel: Komponenten in einem produktiven Namespace
kubectl -n argocd get deploy
NAME                       READY   UP-TO-DATE   AVAILABLE
argocd-applicationset-controller   1/1     1            1
argocd-dex-server                  1/1     1            1
argocd-notifications-controller    1/1     1            1
argocd-redis                       1/1     1            1
argocd-repo-server                 2/2     2            2
argocd-server                      2/2     2            2

3. Voraussetzungen und produktive Installation

Bevor du ArgoCD installierst, benötigst du einen funktionsfähigen Kubernetes-Cluster ab Version 1.27, Helm 3.12+ sowie einen Git-Server (GitHub, GitLab, Gitea oder Bitbucket). Für produktive Setups sind zudem cert-manager für TLS, ein Ingress-Controller (NGINX, Traefik oder Istio) und ein externer OIDC-Provider empfehlenswert.

Die Installation selbst erfolgt wahlweise über das offizielle Manifest, den Helm-Chart oder den ArgoCD-Operator. Der Operator-Ansatz bietet Vorteile bei Lifecycle-Management und automatischen Upgrades, während das klassische Manifest maximale Kontrolle behält. Für die meisten Teams empfehlen wir den Helm-Chart, da er Konfiguration über values.yaml versionssicher abbildet.

# Installation via offizielles Manifest (schnell)
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Installation via Helm (empfohlen für Produktion)
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd \
  --namespace argocd --create-namespace \
  --set server.service.type=ClusterIP \
  --set server.ingress.enabled=true \
  --set server.ingress.hostname=argocd.example.com \
  --set configs.params.server.insecure=false

Nach der Installation rufst du das initiale Admin-Passwort ab. Ab ArgoCD 2.8 wird der argocd-initial-admin-secret mit einem zufälligen Passwort generiert. Ändere dieses sofort oder deaktiviere den lokalen Account zugunsten von SSO.

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

# Login per CLI
argocd login argocd.example.com \
  --username admin \
  --password $(kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d) \
  --insecure

Für den Produktionsbetrieb solltest du argocd-application-controller, argocd-server und argocd-repo-server mit PodDisruptionBudgets, ResourceLimits und NetworkPolicies absichern. Ebenfalls empfehlenswert: das Setzen einer --self-heal-timeout und das Aktivieren von server.enable.proxy für gehärtete Cluster.

4. Dein erstes Application Manifest erstellen

Eine ArgoCD-Application ist eine Custom Resource, die drei Dinge definiert: das Quell-Repository, das Ziel-Cluster mit Namespace und die Synchronisationsstrategie. Das folgende Minimalbeispiel deployt ein Guestbook aus dem offiziellen Beispiel-Repository mit automatischem Sync.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Das Feld targetRevision akzeptiert Branch-Namen, Tags oder Commit-SHAs. Für reproduzierbare Deployments empfehlen wir Git-Tags statt HEAD, da HEAD bei Force-Pushes zu ungewollten Rollbacks führen kann. In regulierten Umgebungen sind zudem GPG-signierte Tags ein wirksames Audit-Instrument.

Der syncPolicy.automated.prune-Schalter löscht Ressourcen, die im Git-Repo nicht mehr definiert sind – ein mächtiges Feature, das in Kombination mit Finalizern jedoch Datenverlust verursachen kann. Aktiviere prune daher nur, wenn deine Manifeste vollständig und idempotent sind.

Mit selfHeal: true revertiert ArgoCD manuelle Cluster-Änderungen automatisch nach dem Polling-Intervall. Dies ist das Herzstück von GitOps: Der Cluster-Zustand konvergiert immer zum Git-Zustand. In Staging-Umgebungen empfehlen wir selfHeal: true mit kurzem Intervall, in Produktion oft einen hybriden Ansatz mit manueller Freigabe.

5. Sync Policies und automatisierte Deployments im Detail

ArgoCD unterscheidet zwischen drei Sync-Modi: manuell, automatisch ohne Self-Heal und automatisch mit Self-Heal. Die Wahl hängt vom Reifegrad deines Teams, der Kritikalität der Workloads und den Compliance-Anforderungen ab. Production-Workloads mit externem Datenbankzugriff sollten oft manuell synchronisiert werden.

Mit Sync Waves orchestrierst du die Reihenfolge von Ressourcen. Das Annotation-argocd.argoproj.io/sync-wave akzeptiert ganzzahlige Werte, wobei kleinere Wellen zuerst ausgerollt werden. Typische Reihenfolge: Namespace → ConfigMap → Secret → Deployment → Service → Ingress → HPA.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  annotations:
    argocd.argoproj.io/sync-wave: "5"
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/api:2.4.1

Sync Options erlauben feingranulare Steuerung. ApplyOutOfSyncOnly=true führt inkrementelle Updates durch, ServerSideApply=true nutzt die Kubernetes-SSA-API und vermeidet Konflikte bei mehreren Writern, PrunePropagationPolicy=foreground wartet auf finale Cleanup-Phasen. In 2026 ist SSA der empfohlene Standard, da es Field-Manager-Konflikte sauber auflöst.

Wichtige Sync-Optionen
OptionWirkungEinsatzempfehlung
CreateNamespace=trueLegt fehlende Namespaces anImmer aktiv
PruneLast=truePruning erst nach erfolgreichem SyncProduktion
ApplyOutOfSyncOnly=trueNur geänderte Ressourcen anwendenGroße Apps
ServerSideApply=trueVerwendet Kubernetes-SSA2026 Standard
FailOnSharedResource=trueBricht ab, wenn Ressource von anderer App verwaltet wirdStrikte Mandantentrennung

Mit Retry Strategy definierst du, wie ArgoCD fehlgeschlagene Syncs behandelt. Standard ist 5 Retries mit exponentiellem Backoff (5s, 10s, 20s, 40s, 80s). In CI-ähnlichen Pipelines kannst du dies auf 0 setzen, um sofortige Fehlerrückmeldungen zu erhalten.

6. ApplicationSets für Multi-Tenant- und Multi-Cluster-Setups

ApplicationSets sind das Multiplikator-Pattern von ArgoCD. Mit einer einzigen Custom-Resource kannst du hunderte Applications über Cluster, Umgebungen oder Tenants hinweg generieren. Die Generator-Syntax unterstützt List, Cluster, Git-Directory, Git-File und Matrix-Generatoren.

Der folgende ApplicationSet rollt eine Microservice-Anwendung über drei Cluster und zwei Umgebungen aus, insgesamt sechs Applications. Der Matrix-Generator kombiniert zwei Listen, während der Cluster-Generator automatisch alle registrierten Cluster anspricht.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: checkout-service
  namespace: argocd
spec:
  generators:
    - matrix:
        generators:
          - list:
              items:
                - cluster: prod-eu
                  url: https://prod-eu.example.com
                - cluster: prod-us
                  url: https://prod-us.example.com
          - list:
              items:
                - env: staging
                - env: production
  template:
    metadata:
      name: 'checkout-{{cluster}}-{{env}}'
    spec:
      project: platform
      source:
        repoURL: https://git.example.com/platform/checkout.git
        targetRevision: '{{env}}'
        path: overlays/{{env}}
      destination:
        server: '{{url}}'
        namespace: checkout
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

In 2026 sind ApplicationSets das zentrale Steuerungsinstrument für Fleet-Management. Kombiniert mit ArgoCD Notifications (Slack, Microsoft Teams, PagerDuty) und Sync Windows (Wartungsfenster) entsteht eine vollständige Plattform-Engine, die Platform-Teams befähigt, Self-Service für Produktteams bereitzustellen.

Ein wichtiges Architekturmuster ist das Hub-and-Spoke-Modell: Ein zentraler Hub-Cluster beherbergt die ApplicationSets und steuert Spoke-Cluster über deren API-Server-Endpunkte. Spoke-Cluster benötigen dabei nur einen lokalen ArgoCD-Controller, der mit dem Hub kommuniziert. Dies entkoppelt Lifecycle und reduziert Cross-Cluster-Latenzen.

7. Secrets Management mit ArgoCD und externen Tools

GitOps und Secrets sind ein klassisches Spannungsfeld: Klartext-Secrets im Git-Repository sind ein No-Go, aber ArgoCD muss trotz

Docker Compose auf dem VPS: Webserver, Datenbank & Reverse Proxy richtig betreiben
DevOps 02. June 2026 10 Min

Docker Compose auf dem VPS: Webserver, Datenbank & Reverse Proxy richtig betreiben

Praxisnaher Guide für Docker Compose auf dem VPS: Webserver, Datenbank, Reverse Proxy, TLS, Backups, Updates und Sicherheit richtig planen und betreiben.

Weiterlesen →

📖 Ähnliche Artikel