Einführung in Argo CD

Was unterscheidet GitOps von klassischem CI/CD, und warum setzen immer mehr Teams auf das Pull-Modell? Dieses Modul klärt die Kernprinzipien: Git als Single Source of Truth, deklarative Konfiguration und automatische Reconciliation. Sie vergleichen Argo CD mit Flux CD, ordnen beide Tools in das CNCF-Ökosystem ein und verstehen, wann welcher Ansatz passt.

Sie installieren Argo CD per Helm Chart auf Ihrem eigenen Kubernetes-Cluster und machen sich mit der Architektur vertraut: Application Controller, Repo Server, API Server und Redis als Cache. Danach navigieren Sie durch das Web UI und die argocd CLI, legen erste Projekte an und verbinden Ihr Git-Repository. Am Ende dieses Blocks läuft Ihre Argo-CD-Instanz und ist bereit für das erste Deployment.

Jetzt wird es praktisch: Sie erstellen eine Application-Ressource, verknüpfen sie mit einem Git-Repository und beobachten, wie Argo CD den gewünschten Zustand im Cluster herstellt. Dabei konfigurieren Sie Sync Policies (manuell und automatisch), definieren Health Checks und lernen den Unterschied zwischen OutOfSync und Degraded. Nach diesem Block können Sie eigenständig Anwendungen über Git deployen und deren Status im UI überwachen.

Was passiert, wenn jemand manuell per kubectl eine Ressource ändert? Hier aktivieren Sie Self-Healing und beobachten, wie Argo CD den Drift erkennt und korrigiert. Sie konfigurieren Pruning (automatisches Löschen verwaister Ressourcen), arbeiten mit Sync Waves und Resource Hooks für geordnete Deployments und testen Retry-Strategien für fehlerhafte Syncs. So verstehen Sie, wie Argo CD auch ohne manuellen Eingriff den gewünschten Zustand garantiert.

Ein fehlerhaftes Deployment muss schnell rückgängig gemacht werden. Sie vergleichen drei Wege: Rollback über die Argo CD History, Git Revert mit anschließendem Sync und manuelles Überschreiben. Welcher Ansatz passt in welcher Situation? Zusätzlich sichern Sie den Argo-CD-State (Application-Definitionen, Projekte, Repository-Credentials) und üben die Wiederherstellung einer Argo-CD-Instanz auf einem frischen Cluster.

Helm ist der De-facto-Standard für Kubernetes-Paketmanagement, und Argo CD unterstützt Helm-basierte Applications nativ. Sie erstellen Applications mit Values-Files pro Environment, nutzen Chart-Repositories und den neuen OCI Registry Support (ab v3.1). Am konkreten Beispiel sehen Sie, wie Helm-Parameter in Argo CD überschrieben werden und wann Values-Files im Git-Repo der sauberere Weg sind.

Nicht jedes Projekt braucht Helm Templates. Mit Kustomize arbeiten Sie mit Overlays, die Basis-Manifeste pro Environment anpassen, ohne sie zu duplizieren. Sie erstellen eine Kustomization mit Patches für dev, staging und production, testen den Output mit kustomize build und deployen das Ergebnis über Argo CD. Am Ende vergleichen Sie Helm und Kustomize und können für Ihre Projekte begründet entscheiden, welches Tool besser passt.

Mono-Repo oder Multi-Repo? App-Repo und Config-Repo getrennt oder zusammen? Diese Entscheidung beeinflusst Ihren gesamten Deployment-Workflow. Sie analysieren die Vor- und Nachteile beider Ansätze anhand konkreter Szenarien, gestalten eine Environment-Promotion-Pipeline (dev → staging → production) und setzen einen PR-basierten Workflow auf, bei dem Änderungen erst nach Review in den Cluster gelangen.

Wer mehr als eine Handvoll Applications verwaltet, braucht Automatisierung. Mit ApplicationSets generieren Sie Applications dynamisch aus Templates. Sie arbeiten mit den wichtigsten Generators: List (statische Cluster-Liste), Cluster (automatische Erkennung), Git (Directory- und File-basiert) und PullRequest (Preview-Environments pro PR). Am Ende deployen Sie eine Anwendung auf mehrere Cluster gleichzeitig und steuern den Rollout mit der Progressive Rollout Strategy.

Wie bootstrappen Sie einen kompletten Cluster mit allen Anwendungen aus einem einzigen Git-Commit? Das App of Apps Pattern löst genau dieses Problem: Eine Root Application definiert und verwaltet alle untergeordneten Applications. Sie bauen dieses Pattern hands-on auf, diskutieren die Grenzen (Abhängigkeiten zwischen Apps, Sync-Reihenfolge) und vergleichen es mit ApplicationSets. Nach diesem Block wissen Sie, wann App of Apps und wann ApplicationSets die bessere Wahl sind.

In produktiven Umgebungen brauchen verschiedene Teams unterschiedliche Berechtigungen. Sie konfigurieren AppProjects für Namespace-Isolation, definieren RBAC-Policies mit feingranularen Rechten (wer darf synchen, wer nur lesen?) und richten SSO über OIDC mit Dex ein. Dabei nutzen Sie den neuen OIDC Token Auto-Refresh (v3.3), der unerwartete Logouts während der Arbeit verhindert.

Secrets gehören nicht ins Git-Repo, aber GitOps verlangt, dass alles in Git liegt. Wie lösen Sie diesen Widerspruch? Sie testen drei Ansätze hands-on: Sealed Secrets (Verschlüsselung im Repo mit kubeseal), External Secrets Operator (Anbindung an AWS Secrets Manager, HashiCorp Vault oder Azure Key Vault) und SOPS mit age-Verschlüsselung. Für jeden Ansatz bewerten Sie Komplexität, Sicherheit und Wartbarkeit.

Kubernetes Deployments kennen nur Rolling Updates. Für kontrollierte Releases brauchen Sie Argo Rollouts. Sie installieren den Controller, erstellen Ihre erste Canary-Rollout-Strategie mit prozentualer Traffic-Steuerung und definieren AnalysisTemplates, die den Rollout automatisch pausieren oder abbrechen, wenn Metriken Schwellenwerte überschreiten. Anschließend konfigurieren Sie ein Blue-Green Deployment mit Preview-Service und manuellem Promotion-Schritt.

Wer erfährt es, wenn ein Sync fehlschlägt oder ein Rollout pausiert? Sie konfigurieren Argo CD Notifications für Slack, Microsoft Teams und Webhooks und definieren Trigger für Sync-Fehler, Health-Degradation und erfolgreiche Deployments. Auf der Monitoring-Seite scrapen Sie die Prometheus-Metriken von Argo CD und bauen ein Grafana-Dashboard, das Sync-Dauer, Application-Health und Reconciliation-Zyklen visualisiert.

GitOps ergänzt Ihre CI-Pipeline um automatisiertes Continuous Deployment nach Kubernetes. Sie integrieren Argo CD mit GitLab CI und GitHub Actions: Die CI baut und pusht das Image, aktualisiert das Manifest im Config-Repo, und Argo CD rollt die Änderung im Cluster aus. Zusätzlich konfigurieren Sie den Argo CD Image Updater für automatische Image-Tag-Updates. Zum Abschluss diskutieren Sie Produktions-Best-Practices: Shallow Git Fetches (v3.3) für große Repos, Resource Exclusions, Diff-Customization und Performance-Tuning.