GitOps mit ArgoCD für kleine Teams: Schlankes Setup statt Overkill

GitOps verspricht reproduzierbare Deployments, nachvollziehbare Änderungshistorie und klare Trennung zwischen Infrastruktur und Anwendungslogik. ArgoCD ist dabei eines der meistgenutzten Werkzeuge. Das Problem: Viele Einführungsartikel gehen davon aus, dass ein dediziertes Plattform-Team existiert, das sich um Cluster-Management, SSO-Integration und Multi-Tenancy kümmert. Kleine Teams mit zwei bis fünf Entwicklern brauchen das nicht – sie brauchen ein Setup, das funktioniert, ohne zur Vollzeitbeschäftigung zu werden.

Was GitOps für kleine Teams wirklich bedeutet

GitOps bedeutet im Kern: Der gewünschte Zustand eines Systems liegt in Git, ein Operator gleicht diesen Zustand kontinuierlich mit der Realität ab. Für ein kleines Team ist das vor allem eine Frage der Disziplin: Kein manuelles kubectl apply mehr in Produktion, keine undokumentierten Hotfixes direkt am Cluster. Jede Änderung geht durch einen Pull Request.

Was es nicht bedeutet: ein eigenes GitOps-Repository-Framework mit dutzenden Helm-Abstraktionsebenen, Vault-Integration für jeden Secret-Typ und Kustomize-Overlays für sechs Umgebungen. Wer drei Microservices in zwei Umgebungen betreibt, sollte nicht dieselbe Komplexität einführen wie ein Konzern mit fünfzig Diensten.

ArgoCD installieren: Die schlanke Variante

ArgoCD lässt sich in wenigen Minuten in einen bestehenden Kubernetes-Cluster installieren. Für kleine Teams reicht das offizielle Non-HA-Manifest vollständig aus. Hochverfügbarkeit auf der ArgoCD-Ebene ist erst dann relevant, wenn Deployments rund um die Uhr stattfinden und kein Wartungsfenster akzeptabel ist.

kubectl create namespace argocd

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

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

# Port-Forward für lokalen Zugriff
kubectl port-forward svc/argocd-server -n argocd 8080:443

Das war es. Kein Helm-Chart, keine Operator-Abstraktionen, keine externe Datenbank. Der ArgoCD-Server ist jetzt unter https://localhost:8080 erreichbar. Wer einen Ingress bevorzugt, ergänzt einen einfachen Ingress-Eintrag – aber auch das ist optional für den Anfang.

Repository-Struktur: Pragmatisch, nicht dogmatisch

Es gibt zwei verbreitete Muster: Ein dediziertes GitOps-Repository, das ausschließlich Kubernetes-Manifeste enthält, oder ein Monorepo, in dem Anwendungscode und Deployment-Konfiguration nebeneinander liegen. Für kleine Teams ist das Monorepo oft der sinnvollere Einstieg, weil der Overhead eines weiteren Repositories fehlt und Änderungen an Code und Deployment-Konfiguration atomar in einem einzigen Commit landen.

Eine bewährte Struktur für ein kleines Projekt sieht so aus:

# deploy/staging/app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: meine-app-staging
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/meinteam/mein-repo
    targetRevision: main
    path: k8s/staging
  destination:
    server: https://kubernetes.default.svc
    namespace: staging
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Das path-Feld zeigt auf das Verzeichnis im selben Repository, in dem die Kubernetes-Manifeste für die Staging-Umgebung liegen. ArgoCD überwacht diesen Pfad und synct Änderungen automatisch. selfHeal: true sorgt dafür, dass manuelle Eingriffe am Cluster automatisch zurückgesetzt werden – genau das ist der Kern von GitOps.

Zwei Umgebungen verwalten ohne Komplexität

Staging und Produktion unterscheiden sich meist in einigen wenigen Werten: Image-Tag, Replica-Anzahl, Ressourcenlimits, möglicherweise die Datenbankverbindung. Viele Teams greifen hier sofort zu Helm oder Kustomize. Beides ist legitim, aber Kustomize reicht für zwei Umgebungen fast immer aus, ohne eine eigene Lernkurve zu erzwingen.

Eine base/-Konfiguration enthält die gemeinsamen Manifeste, overlays/staging/ und overlays/production/ überschreiben nur das, was sich unterscheidet. Das Ergebnis ist nachvollziehbar und ohne Kustomize-Kenntnisse lesbar. Wer lieber bei Plain-YAML bleibt und nur zwei Dateien manuell synchron hält, trifft für drei Services ebenfalls keine schlechte Entscheidung.

Secrets: Die unbequeme Wahrheit

Secrets in Git zu versionieren ist keine Option. Gleichzeitig ist eine vollständige Vault-Integration oder External Secrets Operator für ein kleines Team oft Overkill. Der pragmatische Mittelweg: Secrets werden außerhalb von ArgoCD verwaltet und manuell oder per CI-Pipeline in den Cluster eingespielt. ArgoCD ignoriert diese Secrets, weil sie nicht im Repository liegen.

Wer einen Schritt weiter gehen möchte, ohne tief in Secret-Management-Infrastruktur zu investieren, kann Sealed Secrets in Betracht ziehen. Das Kubeseal-Tool verschlüsselt Secrets mit dem öffentlichen Schlüssel des Clusters, sodass nur der Cluster selbst sie entschlüsseln kann. Das verschlüsselte Secret kann gefahrlos in Git eingecheckt werden. Der Einstiegsaufwand beträgt etwa eine Stunde.

Automatische Image-Updates: Wann es sich lohnt

ArgoCD Image Updater ist eine Erweiterung, die Container-Registries auf neue Image-Tags überwacht und das GitOps-Repository automatisch aktualisiert. Das klingt praktisch, bringt aber eigene Komplexität mit: Der Updater braucht Schreibzugriff auf das Repository, und die Konfiguration der Update-Strategie (neuestes Tag, SemVer, Regex) muss sorgfältig erfolgen.

Für viele kleine Teams ist es einfacher, den Image-Tag als Teil der CI/CD-Pipeline zu aktualisieren. Nach einem erfolgreichen Build ändert ein Skript den Image-Tag in der Deployment-Konfiguration und erstellt einen Commit. ArgoCD erkennt die Änderung und deployt automatisch. Keine zusätzliche Komponente, keine zusätzlichen Credentials, volle Nachvollziehbarkeit in der Git-Historie.

RBAC und Zugriffskontrolle: So viel wie nötig

ArgoCD bringt ein eigenes RBAC-Modell mit. Für ein Team von zwei bis fünf Personen, die alle Admin-Zugriff auf den Cluster haben, ist es ausreichend, alle Teammitglieder als ArgoCD-Admins einzutragen. Die feingranulare Rechteverwaltung nach Projekten und Applikationen ist sinnvoll, wenn Entwickler Applikationen deployen sollen, ohne Cluster-Zugriff zu haben – also bei externen Mitarbeitern oder strikter Trennung zwischen Entwicklung und Operations.

OIDC-Integration über GitHub oder GitLab ist in zehn Minuten eingerichtet und empfehlenswert, sobald mehr als drei Personen Zugriff benötigen. Das vermeidet das Teilen des Admin-Passworts und liefert eine nachvollziehbare Audit-Historie, wer wann welche Aktion ausgelöst hat.

Monitoring: Was wirklich wichtig ist

ArgoCD stellt Prometheus-Metriken bereit, und die ArgoCD-Notifications-Engine kann Slack, E-Mail oder andere Kanäle informieren, wenn eine Applikation in einen degradierten Zustand gerät oder ein Sync fehlschlägt. Für kleine Teams ist eine einzige Benachrichtigung bei Sync-Fehlern in den Team-Slack-Kanal vollkommen ausreichend.

Wichtiger als umfangreiches Monitoring ist eine klare Antwort auf die Frage: Was passiert, wenn ArgoCD selbst ausfällt? Die Antwort ist: nichts Dramatisches. Laufende Workloads bleiben unberührt. Nur neue Deployments können nicht automatisch ausgerollt werden. Das ist akzeptabel und ein weiteres Argument dafür, kein Hochverfügbarkeits-Setup zu betreiben, solange es nicht wirklich gebraucht wird.

Häufige Fehler beim Einstieg

Der verbreitetste Fehler ist es, zu viel auf einmal einzuführen. GitOps, ArgoCD, Helm, Kustomize, External Secrets, Image Updater und OIDC gleichzeitig einzurichten überfordert jedes kleine Team und führt dazu, dass niemand mehr versteht, was wo konfiguriert ist. Besser ist ein schrittweises Vorgehen: erst ArgoCD mit Plain-YAML zum Laufen bringen, dann optional Kustomize einführen, dann Secret-Management angehen.

Ein weiterer Fehler ist das Beibehalten von manuellen Deployments parallel zu ArgoCD. Sobald jemand direkt mit kubectl in Produktion eingreift, ohne den Commit in Git zu landen, divergieren Repository und Cluster-Zustand. Wenn ArgoCD dann synct, werden diese manuellen Änderungen überschrieben. selfHeal: true macht dieses Verhalten explizit – und ist der beste Grund, von Anfang an konsequent zu sein.

Fazit: Pragmatismus vor Vollständigkeit

ArgoCD ist auch für kleine Teams eine hervorragende Wahl, wenn das Setup der Teamgröße entspricht. Ein einziger ArgoCD-Server, ein überschaubares Repository-Layout und konsequente Nutzung von Auto-Sync liefern den Großteil des GitOps-Nutzens ohne administrativen Overhead. Komplexere Funktionen wie Multi-Cluster-Management, ApplicationSets oder vollständige Secret-Rotation-Automatisierung lassen sich bei Bedarf nachrüsten – sie sind kein Pflichtbestandteil eines funktionierenden Setups.

Der entscheidende Schritt ist der erste: GitOps einführen bedeutet, manuelle Deployments durch versionierte Konfiguration zu ersetzen. Alles andere ist Optimierung.