GitOps-Plattform planen oder übernehmen? WZ-IT baut GitOps mit Argo CD oder Flux: Repository-Struktur, Promotion, Drift-Erkennung, Secrets und Wiederherstellung. Platform Engineering ansehen
Stand Oktober 2026: Argo CD und Flux sind beide CNCF-Projekte im Status Graduated (Argo seit 06.12.2022 laut CNCF, Flux seit 30.11.2022 laut CNCF) und stehen unter Apache-2.0 (Argo CD, Flux). Aktuell sind Argo CD v3.5.6 (20.10.2026) und Flux v2.10.0 (26.10.2026). Reife und Lizenz entscheiden die Wahl also nicht. Es entscheidet die Architektur und was sie für Bedienung, Mandantentrennung, Secrets und Wiederanlauf bedeutet.
Inhaltsverzeichnis
- Entscheidungsregel in Kürze
- Architektur: Server mit Oberfläche oder Controller-Toolkit
- GitOps-Tool-Vergleich nach Kriterien
- Helm: zwei verschiedene Modelle
- Secrets: wo entschlüsselt wird
- Sicherung und Wiederanlauf von GitOps selbst
- Ressourcenbedarf: was die Dokumentation sagt
- Wann welches Werkzeug
- Unsere Praxis bei WZ-IT
- Weiterführende Guides
- Stand und Methodik
Entscheidungsregel in Kürze
- Mehrere Teams, die Status, Diffs und Syncs in einer Oberfläche sehen sollen, und ein zentraler Blick auf viele Cluster: Argo CD.
- Ein Plattformteam, das ausschließlich Kubernetes-RBAC und Git oder OCI als Schnittstelle will, mit verschlüsselten Secrets im Repository und Image-Updates im selben Toolkit: Flux.
- Einzelner Cluster, ein Team, Helm oder Kustomize: beide genügen. Dann entscheidet das vorhandene Wissen im Team, und ein Wechsel braucht einen konkreten Grund.
Die Begründungen stehen in den Abschnitten unten, die Tabelle "Wann welches Werkzeug" ordnet sie nach Situation.
Architektur: Server mit Oberfläche oder Controller-Toolkit
Argo CD hat drei Kernkomponenten (Architektur): einen API-Server für Web-UI, CLI und CI-Systeme (mit Authentifizierung, RBAC und Git-Webhooks), einen Repository-Server, der Manifeste aus Git rendert, und einen Application Controller, der Live- und Soll-Zustand vergleicht. Die Konfiguration läuft über die Custom Resources Application und AppProject. Die Variante Argo CD Core läuft headless ohne Argo-API, Argo-RBAC, OIDC-Login und Notifications und verlässt sich auf Kubernetes-RBAC.
Flux besteht aus dem GitOps Toolkit (Komponenten). Standardmäßig installiert flux bootstrap den source-controller (GitRepository, OCIRepository, HelmRepository, Bucket), den kustomize-controller (Kustomization), den helm-controller (HelmRelease) und den notification-controller; die Image-Controller sind optional (bootstrap). Einen zentralen Server gibt es nicht.
GitOps-Tool-Vergleich nach Kriterien
| Kriterium | Argo CD | Flux |
|---|---|---|
| Komponenten | API-Server, Repository-Server, Application Controller, Redis (Cache); ApplicationSet- und Notifications-Controller | source-, kustomize-, helm- und notification-controller; optional Image-Reflector und Image-Automation |
| Oberfläche | integrierte Web-UI, CLI, API | keine eigene UI, Werkzeuge aus dem Ökosystem (FAQ) |
| Zugriff und RBAC | eigenes RBAC, SSO (OIDC, OAuth2, LDAP, SAML 2.0); AppProjects begrenzen Repos, Ziele und Ressourcentypen, Projektrollen an OIDC-Gruppen (Projects) | Kubernetes-RBAC: Controller nehmen die Identität eines Service Accounts je Kustomization oder HelmRelease an (Multi-Tenancy) |
| Multi-Cluster | eine Instanz verwaltet viele Cluster, Zugangsdaten als Cluster-Secrets (Setup); ApplicationSets | Controller laufen üblicherweise je Cluster; Remote-Apply per spec.kubeConfig (Kustomization) |
| Sync-Verhalten | Auto-Sync, Prune und Self-Heal sind Opt-in; Git-Abfrage alle drei Minuten, Webhooks verkürzen das (Auto-Sync, Webhooks) | Abgleich im Intervall spec.interval (Pflichtfeld), spec.prune ist ein Pflichtfeld der Kustomization |
| Helm | helm template, Lebenszyklus bei Argo CD |
HelmRelease führt Helm-Aktionen aus; Drift-Erkennung und -Korrektur sind optional (spec.driftDetection) |
| Kustomize und weitere Formate | Kustomize, Jsonnet, YAML, Config Management Plugins | Kustomize; Quellen Git, OCI, Helm-Repositories, Buckets |
| Image-Automation | separates Projekt Argo CD Image Updater, laut Doku in aktiver Entwicklung, Test in unkritischen Umgebungen empfohlen | Controller im Toolkit, schreiben neue Tags zurück ins Git (Guide) |
| Notifications | Argo CD Notifications mit Triggern und Templates (Doku) | notification-controller in der Standardinstallation (Guide) |
| Secrets | Secrets auf dem Ziel-Cluster empfohlen, Rendern mit Secrets abgeraten | SOPS-Entschlüsselung im kustomize-controller |
| Upgrade des Werkzeugs | Hinweise je Minor-Schritt, vor Major-Releases Backup (Upgrading) | von jedem v2.x auf jedes andere v2.x, Custom Resources ggf. anpassen (Releases) |
| Release und Support | Minor alle drei Monate, Patches für die drei jüngsten Minor (Release-Prozess) | mindestens drei Minor pro Jahr, die letzten drei unterstützt, Backports durch die Community nach bestem Bemühen (Releases) |
| Kubernetes-Versionen | Argo CD 3.5 getestet mit 1.33 bis 1.36 (Installation) | Kubernetes 1.35 und neuer (Installation) |
Beide Matrizen gehören vor einem Cluster-Upgrade in die Prüfung der Zielversion; Support-Termine, Versions-Skew und Ablauf stehen in Kubernetes Upgrade: Fahrplan, Support-Ende und Notfallleitfaden.
Helm: zwei verschiedene Modelle
Argo CD nutzt Helm nur zum Rendern mit helm template; den Lebenszyklus der Anwendung steuert Argo CD (Helm in Argo CD). Helm-Hooks werden auf Argo-CD-Hooks abgebildet; die Dokumentation hält fest, dass das Annotationskompatibilität ist und keine Garantie identischer Semantik. Der HelmRelease von Flux führt dagegen Helm-Aktionen aus (install, upgrade, test, uninstall, rollback) und kann Abweichungen vom Soll-Zustand erkennen und korrigieren, sobald spec.driftDetection aktiviert ist.
Wer Helm-Tests und Helm-Rollback als Release-Mechanismus nutzt, bekommt das mit Flux. Wer einen einheitlichen Sync-Lebenszyklus über Helm, Kustomize und reines YAML will, bekommt ihn mit Argo CD. Argo CD bündelt Helm und Kustomize und hebt sie zu Beginn jedes Minor-Releases an (Release-Prozess). Die Migration von Helm 3 auf Helm 4 beschreibt Helm 3 auf Helm 4 migrieren.
Secrets: wo entschlüsselt wird
Argo CD empfiehlt, Secrets auf dem Ziel-Cluster zu befüllen (Sealed Secrets, External Secrets Operator, Secrets Store CSI Driver). Von Plugins, die Secrets beim Rendern einsetzen, rät die Dokumentation ab, weil Argo CD generierte Manifeste im Klartext im Redis-Cache ablegt. Eine Entschlüsselung im Render-Schritt, etwa SOPS über ein Config Management Plugin, entspricht diesem abgeratenen Muster.
Flux entschlüsselt SOPS-verschlüsselte Secrets direkt im kustomize-controller über spec.decryption, mit OpenPGP, age oder Cloud-KMS (SOPS-Guide). Das hält verschlüsselte Werte im Repository. Bei External Secrets Operator oder Secrets Store CSI Driver liegen im Repository nur Verweise und die Werte im Secret-Store, Sealed Secrets legt verschlüsselte Werte im Repository ab. Operatoren im Zielcluster arbeiten mit beiden GitOps-Werkzeugen.
Sicherung und Wiederanlauf von GitOps selbst
Argo CD ist weitgehend zustandslos: Die Daten liegen als Kubernetes-Objekte im etcd, Redis ist ein verwerfbarer Cache (High Availability). argocd admin export und argocd admin import sichern und stellen sie wieder her (Disaster Recovery). Bei Flux liegt der Soll-Zustand in Git oder einer OCI-Registry; flux bootstrap legt die Flux-Manifeste im Repository ab und lässt Flux sich daraus aktualisieren (Bootstrap). Daraus folgt: Ein neuer Cluster wird durch erneutes Bootstrap gegen dasselbe Repository wieder an den Soll-Zustand gebunden.
Repository-Zugangsdaten und Entschlüsselungsschlüssel liegen üblicherweise als Secrets im Cluster, nicht im Repository. Sie gehören in ein getrenntes Backup, zusätzlich zur Sicherung der Anwendungsdaten nach Kubernetes-Backup: die vier Ebenen.
Ressourcenbedarf: was die Dokumentation sagt
Die Installations- und Skalierungsseiten beider Dokumentationen nennen keine Mindestwerte für CPU und Speicher. Die Voreinstellungen zeigen die Release-Manifeste, die wir am 28.10.2026 ausgewertet haben:
| Voreinstellung | Argo CD v3.5.6 | Flux v2.10.0 |
|---|---|---|
| Workloads der Standardinstallation | 7 (6 Deployments, 1 StatefulSet); Core-Variante: 4 | 4 Controller bei flux bootstrap; das komplette install.yaml enthält 7 Deployments mit Image-Controllern und source-watcher |
| Requests und Limits | in install.yaml, ha/install.yaml und core-install.yaml nicht gesetzt |
je Controller Request 50 bis 100 m CPU und 64 MiB, Limit 1 CPU und 1 GiB |
| Summe der Requests | keine | 350 m CPU und 256 MiB für die vier Standardcontroller |
Für Skalierung nennt Argo CD die Aufteilung des Application Controllers auf mehrere Replikas und für 1000 Anwendungen 50 Status- und 25 Operation-Prozessoren; die HA-Manifeste brauchen wegen der Anti-Affinity mindestens drei Nodes (High Availability). Flux zeigt für hunderte Anwendungen zehn parallele Reconciliations bei Limits von 2 CPU und 2 GiB je Controller und unterstützt Sharding (Vertical Scaling). Das sind Voreinstellungen und Tuning-Beispiele, kein gemessener Verbrauch; der tatsächliche Bedarf hängt von Anwendungszahl und Repository-Größe ab und wird im eigenen Cluster gemessen. Wer Argo CD produktiv betreibt, setzt Requests und Limits selbst.
Wann welches Werkzeug
| Situation | Empfehlung | Beleg |
|---|---|---|
| Mehrere Entwicklungsteams brauchen Status, Diff und Sync in einer Oberfläche | Argo CD | integrierte Web-UI, Projektrollen an OIDC-Gruppen |
| Zentrale Sicht auf viele Cluster aus einer Instanz | Argo CD | Cluster-Secrets, ApplicationSets |
| Nur Kubernetes-RBAC, keine zusätzliche Anmeldefläche | Flux oder Argo CD Core | Service-Account-Impersonation, headless Core-Variante |
| Verschlüsselte Secrets im Repository ohne zusätzlichen Operator | Flux | SOPS im kustomize-controller |
| Secrets über External Secrets Operator oder Vault, getrennt vom Sync | beide | von Argo CD ausdrücklich empfohlen |
| Helm-Releases mit Helm-Tests und Helm-Rollback | Flux | HelmRelease führt Helm-Aktionen aus |
| Ein einheitlicher Sync-Lebenszyklus für Helm, Kustomize und YAML | Argo CD | Helm nur als Renderer |
| Neue Image-Tags automatisch ins Repository schreiben | Flux | Image-Controller im Toolkit; bei Argo CD ein separates Projekt |
| Ein Cluster, ein Team, Helm oder Kustomize | das Werkzeug, das das Team kennt | beide erfüllen den Fall |
Unsere Praxis bei WZ-IT
Die Platform-Engineering-Leistung umfasst GitOps-Beratung und -Umsetzung mit Argo CD oder Flux: Repository-Struktur, Promotion, Drift-Erkennung, Secrets-Konzept und Wiederherstellung. Die Wahl folgt der Entscheidungsregel oben und dem vorhandenen Wissen im Team. Bestehende CI-Pipelines bleiben in der Regel für Build und Test bestehen, GitOps übernimmt das Deployment. Jeder Plattformbaustein erhält einen Owner, einen Upgrade-Pfad und eine Wiederherstellung.
Argo CD betreiben wir zusätzlich als gehostete Anwendung; Angebot und Leistungsumfang stehen auf der Seite Argo CD Hosting und Betrieb. Die Aussagen in diesem Ratgeber stützen sich auf die verlinkten Dokumentationen und Manifeste, nicht auf eigene Benchmarks.
Weiterführende Guides
- Helm 3 auf Helm 4 migrieren: Fristen und Breaking Changes beim Paketmanager
- Kubernetes-Backup: die vier Ebenen: was zusätzlich zu GitOps gesichert wird
- Kubernetes Upgrade: Fahrplan, Support-Ende und Notfallleitfaden: Add-on-Matrix und Versions-Skew vor einem Cluster-Upgrade
- k3s vs. RKE2 vs. Talos: die Distribution unter dem GitOps-Werkzeug
- Kubernetes-Cluster übernehmen: Audit-Checkliste: GitOps-Stand eines fremden Clusters prüfen
Stand und Methodik
- Erhebung: 28.10.2026, aus den Dokumentationen und Repositories beider Projekte und den CNCF-Projektseiten.
- Versionen: Argo CD v3.5.6 und Flux v2.10.0 laut GitHub-Releases am Erhebungstag; die Dokumentation zu "stable" beschreibt Argo CD 3.5.
- Lizenzen: Prüfung der LICENSE-Dateien und der GitHub-Lizenzangabe von argo-cd, flux2 und den Flux-Controllern (jeweils Apache-2.0); der Flux Operator laut seiner README AGPL-3.0.
- Manifest-Auswertung: Zählung der Workloads und Auslesen der Requests und Limits aus argo-cd v3.5.6
install.yaml,ha/install.yaml,core-install.yamlund flux2 v2.10.0install.yaml. Geprüft wurden alle Container einschließlich Init-Container (Argo CD: 0 von 10, HA 0 von 15, Core 0 von 6 mit Requests oder Limits; Flux: 7 von 7). Summe der Flux-Requests der vier Standardcontroller: source 50 m plus kustomize, helm und notification je 100 m CPU = 350 m; 4 mal 64 MiB = 256 MiB. - Folgerungen: Aussagen zu Wiederanlauf per Bootstrap und zur Secret-Entschlüsselung im Render-Schritt sind Schlüsse aus der Dokumentation, keine wörtlichen Zusagen der Projekte.
- Nicht enthalten: Verbrauchsmessungen, kommerzielle Distributionen und Progressive-Delivery-Werkzeuge (Argo Rollouts, Flagger).
Die Tabellen dürfen mit Quellenangabe und Link auf diesen Ratgeber weiterverwendet werden.
Argo CD oder Flux für Ihre Plattform? Die Wahl, die Repository-Struktur und das Secrets-Konzept klären wir gemeinsam: Platform Engineering und GitOps.
Angebot zum Thema: GitOps mit Argo CD und Flux
