Argo CD hält Kubernetes-Deployments automatisiert, konsistent und dauerhaft mit Git synchronisiert. Statt sich auf manuelle Korrekturen zu verlassen oder zu hoffen, dass der Cluster-Zustand noch zum Repository passt, gibt GitOps Teams einen wiederholbaren Weg, Anwendungen über versionierte Infrastrukturkonfiguration auszuliefern.

Viele Teams haben Git bereits im Einsatz, aber GitOps noch nicht vollständig umgesetzt. Git hilft ihnen also, Code-Versionen zu verfolgen, aber es gibt noch kein System, das jede Änderung an der Infrastrukturkonfiguration über Commits in einem Repository erzwingt. Zusätzlich braucht es eine CI/CD-Pipeline, die Code automatisch bauen, testen und deployen kann.

Das Hauptziel ist einfach: Eine Anwendung soll in einen Kubernetes-Cluster ausgeliefert werden. Die Implementierungsdetails sind der Teil, in dem die Tradeoffs sichtbar werden. Kubernetes unterstützt mehrere Deployment-Strategien, und jede Option hat eigene Vorteile, Risiken und operative Gewohnheiten.

Git-Repositories und das Push-Modell

In einem Push-Modell erfolgen Build, Test und Deployment einer Anwendung in den Kubernetes-Cluster nach einem git push. Ein Entwickler pusht Code-Änderungen, und diese Aktion startet eine Kette automatisierter Schritte, die mit einer neuen Anwendungsversion für die Nutzer endet.

Die meisten Git-Plattformen bieten genug eingebaute Funktionen, um diesen Workflow zu unterstützen.

Wie das Push-Modell funktioniert

Eine typische Push-basierte Pipeline sieht so aus:

1. Ein Entwickler committet Änderungen in einem Feature-Branch oder merged sie in den Main-Branch.
2. Dieser Commit löst eine Pipeline mit Aufgaben wie Build, Tests und Deployment aus.
3. Der Build-Prozess nutzt meistens Docker oder ein ähnliches Tool, um ein Container-Image zu erzeugen.
4. Tests bestätigen, dass der neue Code wie erwartet funktioniert und weiterhin zu den bestehenden Komponenten passt.
5. Wenn die Tests erfolgreich sind, wird das neue Image in eine Container Registry gepusht.
6. Zum Schluss platziert das Deployment die neue Anwendungsversion in der Zielumgebung, etwa Produktion, Staging oder Entwicklung.

Diese drei Tools werden häufig für Kubernetes-Deployments aus solchen Pipelines verwendet:

• Kubectl
• Kustomize
• Helm

Alle drei können sinnvoll sein, lösen aber leicht unterschiedliche Probleme.

Kubectl

kubectl ist das Standard-Command-Line-Tool für den Betrieb von Anwendungen in einer Kubernetes-Umgebung. Damit lassen sich Services deployen, skalieren, aktualisieren und debuggen.

Für eine saubere Nutzung stellt man in der Regel YAML-Manifeste bereit, die den gewünschten Zustand von Kubernetes-Ressourcen beschreiben:

• Deployment steuert Rollout-Verhalten und Replica-Anzahlen.
• Pod ist eine laufende Instanz einer containerisierten Anwendung.
• Service macht die Anwendung innerhalb oder außerhalb des Clusters erreichbar.
• Ingress routet externen Traffic in den Cluster.
• ConfigMap und Secret speichern Konfigurationsdaten und sensible Zugangsdaten.

Hier ist ein Beispiel für einen Pipeline-Job, der Kubernetes-Manifeste direkt anwendet:

deploy-kubectl:
  stage: deploy
  image: myregistry/tools/kubectl:latest
  before_script:
    - kubectl config use-context $MY_CLUSTER_CONTEXT
  script:
    - kubectl apply -f my-demo-app/
  rules:
    - if: $CI_COMMIT_BRANCH
      when: manual

Der Befehl kubectl apply weist Kubernetes an, den Cluster an die Ressourcendefinitionen in den YAML-Dateien anzugleichen.

Vorteile von Kubectl

kubectl ist vielseitig. Man kann Kubernetes-Ressourcen erstellen, aktualisieren, löschen oder patchen und fortgeschrittene Deployment-Muster wie Blue-Green- oder Canary-Releases skripten.

Es ist außerdem flexibel, weil es das offizielle Kubernetes-CLI ist und sich gut in viele Workflows integrieren lässt.

Nachteile von Kubectl

Der wichtigste Nachteil ist operative Disziplin. Man muss Kommando-Parameter, Ressourcentypen und YAML-Syntax verstehen. Jeder Schritt verlangt, dass Ressourcen manuell angegeben werden, und ein einzelner Fehler kann das Deployment stören.

Wenn ein Team nur von kubectl apply abhängt, kann außerdem leicht Drift zwischen dem Git-Repository und dem tatsächlich laufenden Zustand im Cluster entstehen.

Kustomize

Kustomize verwaltet Kubernetes-Konfiguration ohne Templates. Es verändert Basis-YAML-Manifeste mit Patches und Transformationen und erzeugt daraus finale Manifeste, die mit kubectl angewendet werden können.

Die wichtigsten Konzepte sind:

• Base: ein Verzeichnis mit den zentralen YAML-Manifesten.
• Overlay: ein Verzeichnis mit umgebungsspezifischen Patches und Transformationen.
• kustomization.yaml: die Datei, die Bases, Overlays, Patches und Transformationen beschreibt.
• Patches: YAML-Dateien, die Ressourcen mergen oder ändern.
• Transformations: Massenänderungen, die auf Ressourcen aus der Base angewendet werden.

Man kann zum Beispiel ein Base-Verzeichnis für gemeinsame Konfiguration und Overlays für dev, staging und prod verwenden.

Hier ist ein Pipeline-Job, der vor dem Deployment Kustomize nutzt:

deploy-kustomize:
  stage: deploy
  image: myregistry/tools/kubectl-kustomize:latest
  before_script:
    - kubectl config use-context $MY_CLUSTER_CONTEXT
    - cd deploy/base
    - kustomize edit set namespace $CI_ENV_NAME-demo
    - kustomize edit set image demo-app=$CI_REGISTRY_IMAGE/demo-app:$CI_COMMIT_SHORT_SHA
    - kustomize build ../overlays/$CI_ENV_NAME > $CI_PROJECT_DIR/final.yaml
  script:
    - kubectl create ns $CI_ENV_NAME-demo || true
    - kubectl apply -f $CI_PROJECT_DIR/final.yaml
  rules:
    - if: $CI_COMMIT_BRANCH
      when: manual

In diesem Setup steuert kustomization.yaml, wie Patching und umgebungsspezifische Änderungen verarbeitet werden.

Warum Kustomize wählen

Kustomize ist deklarativ und wiederverwendbar. Es zeigt klar, wie Konfiguration geschichtet wird, und macht es einfacher, dieselbe Base für verschiedene Umgebungen anzupassen.

Außerdem ist die Syntax vergleichsweise direkt, weil keine separate Template-Sprache eingeführt wird.

Mögliche Nachteile

Kustomize hat trotzdem eine Lernkurve. Patching kann subtil werden, besonders wenn mehrere Overlays über längere Zeit wachsen. Wenn die Struktur nicht sauber bleibt, werden Overlays schnell schwer nachvollziehbar.

Helm

Helm ist der Package Manager für Kubernetes. Es bündelt alles, was eine Anwendung benötigt, in einem Chart: Deployments, Services, ConfigMaps, Secrets und weitere Ressourcen.

Helm nutzt Go-basiertes Templating. Werte aus Dateien wie values.yaml werden verwendet, um finale Kubernetes-Manifeste zu erzeugen. Charts können außerdem Subcharts enthalten und werden häufig in Registries gespeichert.

Wenn Befehle wie helm install oder helm upgrade ausgeführt werden, erstellt oder aktualisiert Helm die notwendigen Ressourcen:

deploy-helm:
  stage: deploy
  image: myregistry/tools/helm-kubectl:latest
  before_script:
    - kubectl config use-context $MY_CLUSTER_CONTEXT
  script:
    - helm upgrade --install my-demo-app ./chart \
        -f values.yaml \
        -n demo-namespace --create-namespace
  rules:
    - if: $CI_COMMIT_BRANCH
      when: manual

Dieser Job deployt oder aktualisiert my-demo-app mit dem Chart im Verzeichnis chart und der Konfiguration aus values.yaml.

Vorteile von Helm

Helm vereinfacht Deployments, weil nicht viele einzelne YAML-Dateien manuell verwaltet werden müssen. Es bietet außerdem Versionierung, Rollback-Unterstützung, wiederverwendbare Charts und ein großes Ökosystem offizieller und Community-gepflegter Charts.

Das macht Helm besonders nützlich, wenn eine Anwendung viele zusammenhängende Ressourcen oder Abhängigkeiten besitzt.

Nachteile

Helm führt eine eigene Chart-Struktur und ein eigenes Templating-Modell ein. Go-Templating kann am Anfang herausfordernd sein, und ein falsch konfiguriertes Chart kann Zuverlässigkeits- oder Sicherheitsprobleme verursachen.

Secrets sollten nicht direkt in Charts gespeichert werden. Nutze stattdessen Kubernetes Secrets, externe Secret Manager oder Vault-ähnliche Integrationen.

Pull-Modell, GitOps und Argo CD

Das Push-Modell funktioniert, hat aber eine Schwäche: Kubernetes speichert Ressourcendefinitionen in seiner internen Datenbank etcd. Wenn jemand eine Ressource im Cluster manuell verändert, kann der laufende Zustand vom Git-Zustand abweichen.

Das erzeugt mehrere Probleme:

• Kubernetes versucht, Cluster-Ressourcen anhand seines aktuell gespeicherten Zustands zu reconciliieren.
• Manuelle Änderungen können zu dem Zustand werden, den Kubernetes sich merkt.
• Wenn eine Ressource direkt im Cluster gelöscht wird, kann sie verloren gehen, sofern sie nicht erneut aus Git angewendet wird.

GitOps mit Argo CD hilft, dieses Problem zu lösen, indem der Workflow auf ein Pull-Modell umgestellt wird.

Pull-Modell

Bei GitOps zieht der Cluster Änderungen, statt sie über manuelle Deployment-Kommandos zu erhalten. Die Infrastrukturkonfiguration bleibt weiterhin in Git, aber ein automatisierter Agent läuft im Cluster und beobachtet das Repository.

Wenn der Agent eine Differenz zwischen Git und Cluster erkennt, aktualisiert er den Cluster so, dass er wieder zum Repository passt.

Der zentrale Vorteil ist, dass manuelle Änderungen außerhalb des GitOps-Prozesses vom Controller überschrieben werden. Der Cluster bewegt sich immer wieder in Richtung des Zustands, der in Git beschrieben ist. Dadurch müssen Änderungen durch das Repository laufen, und die Konsistenz steigt.

Argo CD

Argo CD ist ein deklaratives GitOps-Continuous-Delivery-Tool für Kubernetes. Es beobachtet Git-Repositories, vergleicht den gewünschten Zustand mit dem Live-Zustand im Cluster und reconciliiert Unterschiede.

Die Hauptkomponenten sind:

• API Server: übernimmt Authentifizierung und stellt die Argo-CD-API bereit.
• Application Controller: vergleicht Cluster-Zustand mit Git und reconciliiert Abweichungen.
• Repository Server: cached Git-Repositories, speichert Commit-Referenzen und rendert Manifeste mit Tools wie Helm, Kustomize oder plain YAML.

Anders als beim manuellen Anwenden von YAML-Dateien verwaltet Argo CD ein höheres Objekt namens Application. Eine Application definiert, was deployed wird, wohin es deployed wird und welches Source-Repository oder welcher Pfad als gewünschter Zustand gilt.

Hier ist ein Beispiel für ein Application-Manifest:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-sample-app
  namespace: argocd
spec:
  source:
    path: sample-app
    repoURL: https://some-git-service.com/my-org/k8s-config.git
    targetRevision: HEAD
  destination:
    namespace: sample-app
    server: https://kubernetes.default.svc
  project: production

Damit wird Argo CD angewiesen, die Manifeste aus dem Pfad sample-app im GitOps-Repository in den Namespace sample-app zu deployen.

ApplicationSet

Wenn eine Plattform viele Services hat, wird das manuelle Erstellen einer Application pro Service schnell repetitiv. ApplicationSet automatisiert diesen Prozess mit Generatoren, die Repository-Strukturen oder andere Quellen beobachten.

Zum Beispiel:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: all-tenants
  namespace: argocd
spec:
  generators:
  - git:
      repoURL: https://some-git-service.com/my-org/k8s-config.git
      revision: HEAD
      directories:
      - path: tenants/*

Der Git-Generator prüft hier neue Ordner unter tenants/. Wenn ein Ordner erscheint, kann Argo CD automatisch eine Application dafür erstellen.

Argo CD verwendet außerdem Applications und Projects, um Deployments zu organisieren:

• Application: ein logisches Bündel von Kubernetes-Ressourcen, das einen Git-Pfad, ein Helm Chart, ein Kustomize-Verzeichnis oder plain YAML referenziert.
• Project: eine Grenze zur Organisation von Applications und zur Kontrolle, welche Cluster und Repositories erlaubt sind.

Argo CD bringt außerdem eine nützliche UI mit, um Synchronisationsstatus, Versionen, Diffs und Deployment Health zu prüfen.

Einheitliches Deployment

Moderne Entwicklungsteams verwalten oft viele verschiedene Projekte. Einige werden aktiv entwickelt, andere müssen zwischen Clustern migriert werden, und wieder andere sollen nach einer längeren Pause reaktiviert werden.

Es wird schnell unübersichtlich, wenn jedes Projekt seine eigene spezielle Pipeline hat.

GitOps mit Argo CD hilft, den Deployment-Prozess zu standardisieren. Statt für jedes Projekt einmalige Deployment-Logik zu bauen, aktualisiert die Anwendungspipeline den gewünschten Zustand in einem GitOps-Repository. Argo CD wendet diesen gewünschten Zustand anschließend im Cluster an.

Ein typischer Workflow ist:

1. Die Anwendungspipeline baut und pusht ein Container-Image.
2. Die Pipeline aktualisiert den Image-Tag in einem GitOps-Repository.
3. Argo CD erkennt den Commit.
4. Argo CD synchronisiert die Anwendung in den Ziel-Cluster.

Hier ist ein vereinfachter CI-Job, der eine values.yaml-Datei mit dem aktuellen Commit-SHA aktualisiert und die Änderung zurück in das GitOps-Repository pusht:

.deploy_template:
  stage: deploy
  image: myregistry/tools/yq:latest
  script:
    - git clone "https://$GIT_USER:$GIT_TOKEN@$GITOPS_REPO_URL" my-gitops
    - cd my-gitops
    - yq -i ".app.image.tag = strenv(CI_COMMIT_SHORT_SHA)" path/to/myapp/values.yaml
    - git config --global user.email "[email protected]"
    - git config --global user.name "CI Pipeline"
    - git commit -am "Deploy myapp - ${CI_COMMIT_SHORT_SHA}"
    - git push

Sobald der neue Tag committet wurde, bemerkt Argo CD die Änderung und aktualisiert Kubernetes so, dass die Live-Umgebung wieder zu Git passt.

Unser Ansatz

Der Ansatz, den ich bevorzuge, basiert auf klarer Trennung der Verantwortlichkeiten:

• Separate Repositories für Anwendungscode und Umgebungskonfiguration.
• Umbrella Helm Charts für gemeinsame Abhängigkeiten und Deployment-Struktur.
• Updates am GitOps-Repository aus CI-Pipelines statt direkter Cluster-Mutation.
• Argo CD als clusterseitiger Reconciler.

Das Ergebnis ist ein Workflow, in dem CI die gewünschte Version baut und festhält, während Argo CD die Synchronisierung in den Cluster übernimmt.

Vorteile von Argo CD

Argo CD gibt Teams eine praktische Web-UI für Monitoring von Deployments, Synchronisationsstatus, Health und Diffs. Es synchronisiert Anwendungen kontinuierlich, reduziert Drift und hält den Cluster am Repository ausgerichtet.

Außerdem bietet es eine Single Source of Truth für Konfiguration. Das macht Deployments leichter auditierbar, leichter rückgängig zu machen und einfacher über mehrere Cluster hinweg zu replizieren.

Für Teams, die mehrere Services oder Umgebungen verwalten, kann diese Konsistenz viel tägliche Wartung reduzieren.

Nachteile

Argo CD erfordert trotzdem ein durchdachtes Setup. Teams brauchen eine klare Repository-Strategie, wiederverwendbare Helm Charts oder Kustomize-Strukturen, Zugriffskontrollen und Konventionen für Umgebungen.

GitOps verändert außerdem die Denkweise rund um Deployment. Der Cluster sollte nicht beiläufig per Hand verändert werden. Änderungen sollten durch Git laufen, und das verlangt Disziplin in Engineering und Operations.

Fazit

Die Einführung von GitOps-Prinzipien und Argo CD kann Kubernetes Delivery über viele Projekte hinweg vereinheitlichen. Configuration Drift wird deutlich kleiner, weil der Live-Zustand des Clusters kontinuierlich mit dem Git-Repository verglichen wird.

Kubernetes erleichtert bereits Skalierung und Verschiebung von Workloads. Argo CD ergänzt ein Deployment-Modell, mit dem diese Workloads leichter kontrolliert werden können.

Die besten Ergebnisse entstehen, wenn das Team eine solide Kubernetes-Basis und eine klare Strategie für Repositories, Charts, Zugriffe und Umgebungen hat. Die Kombination aus Managed Kubernetes und Argo CD kann einen automatisierten Weg von Code bis Produktion liefern und gleichzeitig den täglichen Aufwand für Infrastrukturmanagement reduzieren.

GitOps ist nicht nur eine Tool-Entscheidung für Deployments. Es ist ein Delivery-Modell, in dem Git der Vertrag ist, Automation der Operator wird und Argo CD den Cluster ehrlich hält.