Claude Code & ArgoCD: GitOps-Deployments für Kubernetes automatisieren

Kubernetes-Deployments manuell zu verwalten funktioniert — bis zur dritten Umgebung, dem fünften Microservice oder dem ersten Produktionsausfall durch einen vergessenen Rollback. GitOps löst genau dieses Problem: der gewünschte Zustand eines Clusters liegt im Git-Repository, und ein Tool sorgt dafür, dass der tatsächliche Zustand damit übereinstimmt. ArgoCD ist das führende GitOps-Tool für Kubernetes — und Claude Code beschleunigt erheblich, wie schnell man es produktionstauglich aufgesetzt bekommt.

Dieser Artikel zeigt den vollständigen Weg: von der ArgoCD-Installation über Application-Manifeste und Sync-Strategien bis hin zu RBAC, SSO und Health Checks. Alle Manifeste entstehen mit Claude Code — nicht durch Copy-Paste aus der Dokumentation, sondern angepasst an die eigene Infrastruktur.

1. Was ist GitOps?

GitOps ist ein Betriebsmodell, bei dem Git als Single Source of Truth für den Infrastrukturzustand dient. Statt Deployments manuell per kubectl apply oder CI-Pipeline auszuführen, beschreibt man den Sollzustand deklarativ in Manifesten — und ein Operator im Cluster sorgt dafür, dass der Istzustand dem Sollzustand entspricht.

Die Konsequenzen sind erheblich: Jede Änderung am Cluster ist ein Git-Commit mit Autor, Zeitstempel und Diff. Rollbacks sind git revert. Drift zwischen Umgebungen wird automatisch erkannt und — je nach Konfiguration — automatisch korrigiert. Und neue Cluster-Mitglieder müssen kein komplexes Deployment-System verstehen, sondern nur Pull Requests schreiben.

2. ArgoCD installieren

ArgoCD läuft als Operator im Kubernetes-Cluster. Die schnellste Installation geht über den offiziellen Manifest-Bundle:

kubectl create namespace argocd
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Danach ist die ArgoCD-API für lokalen Zugriff über Port-Forwarding erreichbar:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Das Initialpasswort für den Admin-Account liegt als Secret im Cluster:

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

Hier kann Claude Code den ersten Zeitgewinn bringen. Statt die Dokumentation zu durchsuchen, welche Ports, welche Namespaces und welche Secret-Namen ArgoCD verwendet:

claude "Ich habe ArgoCD gerade per install.yaml installiert. Welche
Services laufen im argocd-Namespace und wie erreiche ich die UI lokal?"

Claude Code liest den aktuellen Cluster-Zustand via kubectl, listet die laufenden Services und gibt konkrete Befehle zurück — angepasst an das, was tatsächlich im Cluster läuft, nicht an eine generische Dokumentationsannahme.

3. Application-Manifest erstellen

Eine ArgoCD Application ist ein Kubernetes-Objekt, das beschreibt, woher die Manifeste kommen (Git-Repository, Pfad, Branch) und wohin sie deployed werden sollen (Cluster, Namespace). Claude Code generiert dieses Manifest aus einer kurzen Beschreibung:

claude "Erstell ein ArgoCD Application-Manifest für mein Backend-Service.
Git-Repo: github.com/meinorg/backend-infra, Pfad: k8s/production,
Branch: main, Ziel-Namespace: backend-prod"

Das Ergebnis ist ein vollständiges, valides Manifest:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: backend-production
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/meinorg/backend-infra
    targetRevision: main
    path: k8s/production
  destination:
    server: https://kubernetes.default.svc
    namespace: backend-prod
  syncPolicy:
    syncOptions:
      - CreateNamespace=true

Was Claude Code dabei leistet: es ergänzt CreateNamespace=true automatisch, wenn der Namespace nicht existiert, setzt kubernetes.default.svc für den lokalen Cluster korrekt ein und weist auf fehlende Felder hin, die später Sync-Fehler verursachen würden.

4. Git-Repository verbinden

Private Repositories benötigen Credentials. ArgoCD speichert diese als Kubernetes Secrets. Claude Code generiert das korrekte Secret-Format:

claude "Ich brauche ein ArgoCD Repository-Secret für ein privates
GitHub-Repo mit SSH-Key-Authentifizierung. Was genau muss ich anlegen?"

apiVersion: v1
kind: Secret
metadata:
  name: backend-infra-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
type: Opaque
stringData:
  type: git
  url: git@github.com:meinorg/backend-infra.git
  sshPrivateKey: |
    -----BEGIN OPENSSH PRIVATE KEY-----
    # SSH-Key hier einfügen
    -----END OPENSSH PRIVATE KEY-----

5. Sync-Strategien: Auto-Sync vs. Manual

ArgoCD unterstützt zwei grundlegende Sync-Modi. Manual Sync zeigt Abweichungen zwischen Git und Cluster an, führt aber keine Änderungen ohne expliziten Benutzerbefehl durch. Auto-Sync bringt den Cluster automatisch in den im Git definierten Zustand.

Auto-Sync ist mächtiger — und risikoreicher, wenn nicht richtig konfiguriert. Claude Code hilft bei der Entscheidung:

claude "Ich überlege Auto-Sync für meine Production-Umgebung zu aktivieren.
Was sind die Risiken, und welche Schutzmaßnahmen sollte ich einbauen?"

Die typische Empfehlung: Auto-Sync mit selfHeal: true und prune: false für Production-Umgebungen. selfHeal korrigiert manuellen Drift automatisch; prune: false verhindert, dass ArgoCD Ressourcen löscht, die im Git-Repo entfernt wurden — eine zusätzliche Sicherheitsebene.

syncPolicy:
  automated:
    selfHeal: true
    prune: false
  syncOptions:
    - CreateNamespace=true
    - PruneLast=true

6. Helm-Chart-Deployments

ArgoCD unterstützt Helm nativ. Statt Helm-Charts manuell zu rendern und die generierten Manifeste zu committen, zeigt ArgoCD direkt auf das Chart — entweder aus einem Helm-Repository oder aus dem eigenen Git-Repo.

claude "Erstell eine ArgoCD Application für das cert-manager Helm-Chart
aus dem offiziellen Helm-Repo, Version 1.14.0, mit diesen Values:
installCRDs: true, replicaCount: 2"

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cert-manager
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://charts.jetstack.io
    chart: cert-manager
    targetRevision: v1.14.0
    helm:
      values: |
        installCRDs: true
        replicaCount: 2
  destination:
    server: https://kubernetes.default.svc
    namespace: cert-manager
  syncPolicy:
    automated:
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Besonders nützlich: Claude Code erkennt, wenn Values-Felder zwischen Helm-Chart-Versionen umbenannt wurden, und weist darauf hin — bevor ein Sync mit veralteten Values scheitert.

7. Multi-Cluster-Setup

ArgoCD kann mehrere Kubernetes-Cluster von einer zentralen Instanz aus verwalten. Die Cluster werden als Secrets registriert und erhalten dann Applications zugewiesen.

argocd cluster add mein-production-cluster \
  --kubeconfig ~/.kube/production.yaml \
  --name production

Claude Code hilft beim Entwurf einer Multi-Cluster-Strategie:

claude "Ich habe drei Cluster: dev, staging, production. Wie strukturiere
ich mein Git-Repo und die ArgoCD Applications, um Umgebungs-Unterschiede
sauber zu verwalten ohne Code-Duplizierung?"

Die empfohlene Antwort folgt meistens dem App-of-Apps-Pattern: eine übergeordnete Application, die selbst ArgoCD Applications als Kind-Objekte verwaltet. Jede Umgebung erhält einen eigenen Ordner im Repository, gemeinsame Konfiguration liegt in Helm-Chart-Defaults oder Kustomize-Bases.

8. RBAC und SSO

In Produktionsumgebungen braucht ArgoCD Zugriffskontrolle. RBAC definiert, wer welche Applications sehen und bearbeiten darf. SSO verbindet ArgoCD mit dem bestehenden Identity-Provider — Okta, Azure AD, GitHub oder Keycloak.

claude "Konfiguriere ArgoCD RBAC so, dass das Team 'frontend' nur Applications
im Project 'frontend-apps' sync-en darf, aber nicht löschen kann.
Admins dürfen alles."

Claude Code generiert die argocd-rbac-cm ConfigMap mit den entsprechenden Policies:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.default: role:readonly
  policy.csv: |
    p, role:frontend-dev, applications, sync, frontend-apps/*, allow
    p, role:frontend-dev, applications, get, frontend-apps/*, allow
    g, frontend-team, role:frontend-dev
    g, admins, role:admin

9. Health Checks und Rollbacks

ArgoCD kennt den Health-Status jeder Kubernetes-Ressource. Für Standard-Ressourcen wie Deployments, Services und StatefulSets funktioniert das automatisch. Für Custom Resources kann man eigene Health-Check-Lua-Skripte definieren.

Rollbacks sind in ArgoCD bewusst als Git-Operation gestaltet: man reverted den Commit, ArgoCD synct den alten Zustand. Es gibt aber auch einen direkten Rollback auf eine frühere Sync-Revision über die UI oder CLI:

argocd app rollback backend-production 5

Claude Code kann helfen, den Rollback-Prozess in einen Runbook-Workflow einzubauen:

claude "Schreib ein Shell-Skript das bei einem fehlgeschlagenen Deployment
in ArgoCD automatisch auf die letzte erfolgreiche Sync-Revision zurückrollt
und das Team per Slack benachrichtigt"

Das Skript verwendet argocd app history um die letzte erfolgreiche Revision zu finden, führt den Rollback aus und sendet die Benachrichtigung über den Slack Webhook — alles ohne manuelle Intervention.

Fazit: GitOps mit Claude Code und ArgoCD

ArgoCD gibt Kubernetes-Deployments die Reproduzierbarkeit, die kubectl-Kommandos nie hatten. Jede Änderung ist ein Commit, jeder Rollback ist ein Revert, jede Abweichung wird sichtbar — und bei Auto-Sync automatisch korrigiert.

Claude Code beschleunigt diesen Weg erheblich. Manifeste die man sonst aus Dokumentations-Snippets zusammensetzt und dreimal korrigiert, entstehen im ersten Entwurf direkt passend zur eigenen Infrastruktur. Die Zeit spart man nicht beim Verstehen von ArgoCD — die konzeptionelle Arbeit bleibt — sondern beim Aufwand von der Idee zur validen YAML-Datei.

• Application-Manifeste aus einer kurzen Beschreibung generieren lassen statt aus Docs zusammenbauen
• Sync-Strategien über Claude Code auf die eigene Risikotoleranz abstimmen
• RBAC-Policies in Prosa beschreiben und als valides ConfigMap-Format ausgeben lassen
• Rollback-Skripte und Runbooks direkt mit Cluster-Kontext generieren