Text size
Auf meinem Radar6 Min. Lesezeit

Argo CD oder Flux?

Beide machen GitOps gut. Die Unterschiede, die zählen, wenn man einen wählt.

Argo CD or Flux?
KI-generierte Illustration

Wenn Sie Kubernetes laufen lassen und mit GitOps bereitstellen, haben Sie diese Frage fast sicher gestellt. Argo CD und Flux sind beide abgestufte CNCF-Projekte, beide reif, beide von Tausenden von Unternehmen genutzt. Beide werden Ihre Apps von Git zuverlässig bereitstellen.

Es geht nicht darum, welcher besser ist. Es geht darum, welcher mit der Arbeit Ihres Teams übereinstimmt.

GitOps in einem Absatz

GitOps bedeutet, dass Git die Quelle der Wahrheit für das ist, was in Ihrem Cluster läuft. Statt einer Pipeline, die Änderungen mit kubectl apply, ein Agent im Cluster zieht den gewünschten Zustand aus Git und macht kontinuierlich den Cluster mit ihm übereinstimmen. Jede Änderung ist ein Kommit. Jeder Rückschlag ist ein Rückschlag. Drift wird automatisch korrigiert. Das OpenGitOps-Projekt fasst es in vier Prinzipien zusammen: deklarativ, versioniert und unveränderlich, automatisch gezogen, kontinuierlich abgestimmt.

Kurz gesagt:

Argo CD ist ein anwendungsorientiertes GitOps-Tool mit einer starken Web-Benutzeroberfläche.

  • Die Benutzeroberfläche ist ein großer Verkaufspunkt. Sie sehen jede Anwendung, ihre Ressourcen, ihre Gesundheit und ihren Synchronisationsstatus als lebenden Baum. Entwickler lieben es, in ihre App klicken zu können und zu sehen, was passiert.
  • Anwendungen und ApplicationSets. Ein Application Punkte an einem Git-Pfad und einem Zielcluster. ApplicationSets Generation von mehreren Anwendungen aus Vorlagen: eine pro Cluster, pro Umgebung, pro Pull-Anfrage.
  • Multi-Cluster von einer zentralen Instanz. Eine Argo-CD kann viele Cluster verwalten.
  • Projekte und RBAC für Multi-Team-Setups mit SSO-Integration.
  • Argo CD 3.x Die Argo-Familie umfasst Argo Rollouts für die progressive Bereitstellung und Argo Workflows.

Kurz gesagt:

Flux ist eine Sammlung von Kubernetes-Controllern, die wie native Kubernetes Komponenten funktionieren.

  • Alles ist ein CRD. GitRepository, OCIRepository, Kustomization, HelmRelease- Ich weiß . Sie verwalten Flux genauso wie alles andere.
  • Keine Benutzeroberfläche. Flux ist CLI und API zuerst. Es gibt Benutzeroberflächen und Integrationen von Drittanbietern, aber die Erfahrung basiert auf kubectl und der flux Ich bin ein CLI.
  • Starke Steuerung über die Steuerung des Rumpfs mit automatischen Upgrades, Tests und Rollbacks.
  • OCI-Artefakte als Quelle: Sie können Manifestationen in ein Containerregister schieben und Flux von dort ziehen lassen.
  • Bildautomation Die Controller können Bildtags in Git automatisch aktualisieren, wenn neue Bilder gedrückt werden.
  • Leichtgewicht, Modell pro Cluster. Normalerweise läuft jeder Cluster seinen eigenen Flux und zieht seine eigene Konfiguration.

Die Argo CD zeigt Ihnen GitOps. Der Fluss verschwindet in Kubernetes. Beide sind gute Wege, sie zu lieben.

Nebeneinander

Argo CD Fluss
Schnittstelle Rich Web UI plus CLI CLI und CRD, UI optional
Typisches Modell Zentrale Instanz, viele Cluster Agentur pro Cluster
Mehrfache Mieterei Projekte, RBAC, SSO im UI Kubernetes RBAC und Namensräume
Steuerung Verwandelt Diagramme in Manifests Native Helm-Releases über den Controller
Lernkurve Einfach zu starten, UI hilft Sehr Kubernetes-nativ, steiler für Anfänger
Am besten passt Teams, die Sichtbarkeit und Selbstbedienung wünschen Plattformteams, die eine komponierbare Automatisierung wünschen

Wie ich die Repos strukturiere

Welches Werkzeug auch immer Sie wählen, die Struktur des Repositoriums ist wichtiger als das Werkzeug. Ein gemeinsames Layout:

platform-gitops/
  clusters/
    prod-eu/
    prod-us/
    staging/
  infrastructure/      # cert-manager, gateway, monitoring, policies
    base/
    overlays/
  apps/
    shop/
      base/
      overlays/
        staging/
        prod/

Einige Grundsätze, die helfen können:

  • Trennen Sie den App-Code von der Bereitstellungskonfiguration. Das App-Repo erstellt Bilder; das GitOps-Repo sagt, welche Version wo läuft.
  • Überlagerungen verwenden (Anpassen) oder Werte Dateien (Helm) pro Umgebung, nicht kopierte Ordner.
  • Geheimnisse aus Git heraushalten, oder verschlüsselt (SOPS) oder über Externe Geheimnisse verwiesen.

Veränderungen durch Umgebungen bewegen

Der knifflige Teil von GitOps ist nicht zu implementieren. Es ist... Förderung: eine Version von der Entwicklung über die Inszenierung in die Produktion auf kontrollierte Weise zu bringen. Eine YAML-Datei an drei Stellen manuell zu aktualisieren, wird schnell veraltet.

Die Auswahlmöglichkeiten:

  • Anfragen pro Umgebung abrufen, die nach jeder erfolgreichen Phase von der IC eröffnet wird.
  • Automation der Bildflüsse oder Argo CD Bild-Updater für automatische Tag-Aktualisierungen in niedrigeren Umgebungen.
  • Waren, ein neueres Projekt des Argo-Ökosystemteams, speziell für die GitOps-Promotion in verschiedenen Phasen mit Verifizierungsschritten dazwischen entwickelt.

Also, welcher?

Wenn Ihre Entwickler direkt mit den Einsätzen interagieren und sehen, was los ist, Argo CD- Ich weiß . Wenn Ihr Plattformteam komponierbare, Kubernetes-native Bausteine will und mit CLIs zufrieden ist, Fluss- Ich weiß . Wenn Sie sich nicht entscheiden können: Versuchen Sie beide in einer Testgruppe für eine Woche. Diejenige, nach der Ihr Team natürlich greift, ist die richtige.

Meine Meinung: Das beste GitOps-Tool ist das, was dein Team wirklich versteht. Wählen Sie eine, strukturieren Sie Ihre Reports gut, und der Rest folgt.

Desly