Was ist ArgoCD und wie funktioniert es?
ArgoCD ist ein GitOps-Tool für Kubernetes, das den gewünschten Zustand einer Anwendung aus einem Git-Repository liest und automatisch auf dem Cluster umsetzt. Wenn jemand eine Änderung im Repository macht, sorgt ArgoCD dafür, dass der Cluster diese Änderung übernimmt, ohne manuelles Deployment. Mit Claude Code lassen sich Application-Manifeste, App-of-Apps-Strukturen und ApplicationSets in natürlicher Sprache generieren; spezialisierte Sub-Agents übernehmen Manifest, Policy, Test und Doku parallel.
Auch bekannt als: Argo CD · Argo Continuous Delivery
Ist ArgoCD bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
ArgoCD läuft als Controller im Cluster und holt sich seine Arbeit selbst ab. Eine Application beschreibt, welches Verzeichnis aus welchem Git-Repository in welchen Cluster und Namespace gehört. ArgoCD rendert daraus die Manifeste, auch wenn sie als Helm-Chart oder Kustomize-Overlay vorliegen, und vergleicht sie mit dem, was tatsächlich im Cluster läuft. Stimmen beide überein, steht die Application auf Synced. Hat jemand per kubectl ein Deployment geändert, steht sie auf OutOfSync. Je nach Sync-Policy zeigt ArgoCD diesen Drift nur an oder stellt den Git-Stand selbst wieder her. Diese Option heißt Self-Heal.
Der Unterschied zum klassischen Push-Deployment liegt in der Richtung der Verbindung. Beim Push braucht die CI-Pipeline Zugangsdaten für den Cluster und öffnet von außen eine Verbindung zur Kubernetes-API. Bei ArgoCD bleiben diese Zugangsdaten im Cluster, und ArgoCD baut die Verbindung zum Git-Server von innen nach außen auf. In segmentierten OT-Netzen entfällt damit die eingehende Verbindung vom CI-Server in die Produktionszone. Die Firewall muss nur noch ausgehende Verbindungen zum internen Git-Server und zur Registry erlauben.
Für regulierte Umgebungen zählt vor allem der Audit-Trail. Jede Zustandsänderung ist ein Git-Commit mit Autor, Zeitstempel und, bei geschütztem Branch, einem freigegebenen Merge Request. Fragt der Auditor, wer diese Änderung wann freigegeben hat, liegt die Antwort im Git-Log statt in Aktenordnern und E-Mail-Verläufen. Das deckt Nachweispflichten aus IEC 62443 oder dem internen Change-Prozess ab, ohne dass ein zweites Logging-System gepflegt werden muss.
Drei Stolpersteine begegnen uns in Projekten immer wieder. Der erste betrifft Secrets. Beim ersten Pilot landet das Datenbank-Passwort als Base64-String im Repository, weil die Demo bis Freitag laufen soll. Base64 ist keine Verschlüsselung, und jeder mit Lesezugriff auf das Repository kennt damit das Passwort. Der zweite ist Auto-Sync, denn in produktiven OT-Zonen ist ein manueller Sync nach Freigabe oft die sicherere Wahl. Der dritte ist die Repository-Struktur, die ab einigen Dutzend Applications ohne App-of-Apps oder ApplicationSet schnell unübersichtlich wird.
Gleicher Softwarestand an allen Werksstandorten
Ein Hersteller betreibt Edge-Cluster an mehreren Werksstandorten, bisher wurde jeder Standort von Hand aktualisiert. ArgoCD synchronisiert jetzt dieselbe Anwendungsversion aus einem zentralen Repository auf alle Cluster, lokale Abweichungen liegen als Overlay je Standort daneben. Welcher Stand in welchem Werk läuft, zeigt danach die ArgoCD-Oberfläche statt einer von Hand gepflegten Liste.
Replicas während einer Störung von Hand hochgesetzt
Während einer Störung setzt ein Kollege per kubectl die Replica-Zahl eines Dienstes von zwei auf sechs. Früher blieb so ein Eingriff oft wochenlang unbemerkt, bis ihn das nächste Deployment stillschweigend überschrieb und niemand mehr wusste, warum. ArgoCD markiert die Application sofort als OutOfSync und stellt mit Self-Heal den Git-Stand wieder her. Soll die Änderung bleiben, kommt sie als Commit ins Repository und ist damit auch dokumentiert.
ArgoCD oder Flux — was passt zu Ihrem Team?
ArgoCD und Flux sind beide erstklassig — entscheidend ist, wer im Team damit arbeitet. Sagen Sie uns Rolle und Präferenz, und Sie sehen, welches Tool bei Ihnen die Nase vorn hat.
Wer arbeitet mit dem GitOps-Tool?
- Was ist der Unterschied zwischen ArgoCD und Flux?
- Beide sind GitOps-Operatoren für Kubernetes mit Pull-Prinzip. ArgoCD bringt eine ausgereifte Web-UI mit Visualisierung des Application-Trees mit, Flux ist schlanker und stärker auf reine Automatisierung ausgelegt. Der Flux Operator von ControlPlane liefert seit Ende 2025 zwar ebenfalls eine schlanke Web-UI. Für Teams, die den Sync-Status vieler Anwendungen visuell kontrollieren wollen, ist ArgoCD trotzdem meist die naheliegendere Wahl.
- Kann ArgoCD in air-gapped OT-Umgebungen laufen?
- Ja. ArgoCD benötigt nur Zugriff auf das Git-Repository und die Container-Registry, und beides kann on-premise im segmentierten Netz liegen. Ein interner Git-Server und ein Registry-Mirror genügen, einen Internetzugang braucht ArgoCD nicht.
- Wie verwaltet ArgoCD Secrets sicher?
- Secrets werden nicht im Klartext versioniert. Bitnami Sealed Secrets verschlüsselt sie mit einem Schlüssel, den nur der Controller im Cluster entschlüsseln kann. Der External Secrets Operator legt im Repository nur einen Verweis ab und holt den Wert zur Laufzeit aus einem Vault. SOPS verschlüsselt die Werte direkt in der Datei. So bleibt das Git-Repository auch bei sensiblen Daten die Single Source of Truth.
- Wofür wird ArgoCD eingesetzt?
- ArgoCD wird eingesetzt, um Deployments auf Kubernetes-Cluster vollständig über Git zu steuern. Teams beschreiben den Soll-Zustand deklarativ im Repository, ArgoCD synchronisiert ihn kontinuierlich in den Cluster und macht jede Abweichung sichtbar. Typische Einsatzfelder sind Multi-Cluster-Setups, Edge-Standorte in der Fertigung und regulierte Umgebungen, die einen lückenlosen Audit-Trail brauchen.
- Was bedeutet GitOps?
- GitOps bedeutet, dass ein Git-Repository den gewünschten Zustand einer Umgebung beschreibt und ein Software-Agent diesen Zustand laufend im Zielsystem herstellt. Änderungen am Betrieb laufen damit über Commits und Merge Requests statt über direkte Befehle am Cluster. Das Projekt OpenGitOps fasst das in vier Prinzipien: deklarativ, versioniert und unveränderlich, automatisch gezogen, kontinuierlich abgeglichen. ArgoCD ist eines der Werkzeuge, die dieses Modell für Kubernetes umsetzen.
- Wie überwacht man ArgoCD am besten?
- ArgoCD liefert eigene Prometheus-Metriken, die Sie mit Prometheus und Grafana auswerten. Die wichtigste Metrik ist argocd_app_info, deren Labels sync_status und health_status für jede Application zeigen, ob sie synchron und gesund ist. Ein Grafana-Dashboard als Vorlage liegt im ArgoCD-Projekt bereit. Für Meldungen bei OutOfSync oder einem fehlgeschlagenen Sync gibt es den mitgelieferten Notifications Controller, der etwa an Slack, Microsoft Teams oder per E-Mail meldet.
Wo steht Ihr Team bei ArgoCD?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu ArgoCD: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01Argo ProjectArgo CD Documentation(externe Seite, öffnet in neuem Tab)
Offizielle Dokumentation mit Installation, Application-Ressourcen, Sync-Optionen und RBAC.
- /02Argo ProjectArgo CD Architecture(externe Seite, öffnet in neuem Tab)
Beschreibt die Komponenten API-Server, Repository-Server und Application-Controller im Zusammenspiel.
- /03Cloud Native Computing FoundationArgo bei der CNCF(externe Seite, öffnet in neuem Tab)
Projektstatus als Graduated Project, Governance und Maintainer der Argo-Familie.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance