Wir haben im vorigen Kapitel einen Einstieg mit Argo CD gewagt. Eine der fundamentalsten Entscheidungen in Bezug auf GitOps wird in den meisten Fällen lauten: Nutzen wir Argo CD oder Flux? Die beiden Platzhirsche unter den GitOps-Tools sind beide ausgereift mit vielen Features. Dieses Kapitel gibt Starthilfe, bespricht die wichtigsten Features, Gemeinsamkeiten und die kleinen aber feinen Unterschiede.
Wie bei allen technischen Entscheidungen ist auch bei der Auswahl eines GitOps-Operators die wichtigste Grundlage die Kenntnis der eigenen Anforderungen, am besten in priorisierter Form. Beim Vergleich von Argo CD mit Flux macht es das in vielen Fällen allerdings nicht einfacher. Beide Tools erfüllen den grundlegenden GitOps-Prozess mit Bravour und haben darüber hinaus eine schwer überblickbare Anzahl an Features, bei denen sie sich nur in Nuancen unterscheiden. An dieser Stelle setzt dieses Kapitel an und erörtert verschiedene praxisrelevante Aspekte Schritt für Schritt.
Zum Einstieg gibt uns Tabelle 4–1 eine Übersicht über einige Zahlen der beiden CNCF-Projekte Argo und Flux. Dazu einige Anmerkungen:
Deshalb sind die Metriken nicht 1:1 vergleichbar. Argo ist ein Projekt mit größerem Scope und besteht aus den vier Teilprojekten Workflows, Rollouts, Events und CD. Flux enthält Flux Version 1 und 2 sowie Flagger. Flux 2 ist eine komplette Neuimplementierung, daher ein separates Teilprojekt mit eigenen Metriken.
Tab. 4–1
Schnelle Fakten über die CNCF-Projekte Argo und Flux
|
Argo-Projekt |
Flux-Projekt |
Erster Commit |
02/2018 (Argo CD)4 |
07/2016 (Flux v1)5 |
GitHub Stars |
27.400 |
13.300 |
Anzahl Repos |
127 |
44 |
Anzahl Commits |
38.127 |
42.286 |
Anzahl Issues |
16.808 |
5.726 |
Anzahl PRs |
16.368 |
8.003 |
Contributors (Individuen) |
11.936 |
4.022 |
Contributors (Firmen) |
20006 |
10007 |
Top 3 Committer |
1. Intuit (45 %) 2. Red Hat (6 %) 3. Akuity (3 %) |
1. Weaveworks (71 %) 2. Unabhängige (3 %) 3. Cybercom Group (2 %) |
Anzahl Adopters |
300 (Argo CD)8 |
192 (Flux v1+v2)9 |
Stand: 07/2023
Chronologisch betrachtet ist die erste Handlung das Bootstrapping des Operators.
Flux installieren
Dabei zeigt sich ein erster klarer Unterschied: Flux bietet mit dem Befehl flux bootstrap seiner CLI eine Best Practice sowohl zur Installation als auch zur Strukturierung des Config-Repos an. Darüber hinaus verlinkt die Dokumentation auf offizielle Beispiele, die Lösungen für weitere Herausforderungen bieten, wie Promotion, clusterweite Ressourcen und die Umsetzung des Repo per Team-Patterns. Kapitel 6 auf Seite 133 beleuchtet diese Themen im Detail.
Wer keinen direkten Zugriff auf den Cluster hat, kann sich das notwendige YAML mittels CLI generieren lassen. Da die CLI der offizielle Weg zur Installation ist, bietet das Projekt Flux kein Helm-Chart an. Wer trotzdem eines benötigt, findet eines, das von der Community gewartet10 wird. Immerhin: Unter den Beitragenden finden sich offizielle Maintainer des Flux-Projekts. Zusätzlich steht ein Terraform-Provider bereit.
Argo CD installieren
Auch bei Argo CD gibt es mehrere Möglichkeiten zur Installation, allerdings ohne empfohlene Repo-Struktur. Die Doku verweist auf fertige Kubernetes-Manifeste11 zur Installation. Darüber hinaus gibt es folgende Möglichkeiten im Kontext des Projekts:
Diese Auswahl ist mehr Fluch als Segen, denn keine der Möglichkeiten ist so einfach und ausgereift ist wie bei Flux. Mit Kubernetes-Manifesten oder Helm-Charts ist die Installation zwar einfach, aber zur Repo-Struktur äußert sich Argo CD nicht. Die Tools Autopilot und Argo CD Operator sind offiziell noch nicht stabil, womit sich Kapitel 6 auf Seite 133 im Detail befasst.
Flux aktualisieren
Wichtig ist auch ein Blick auf das Thema Upgrades, denn mit einer einmaligen Installation ist es ja nicht getan. Auch hier ist die Flux-CLI erfreulich klar: Upgrades installiert man wie beim Bootstrapping14 per flux bootstrap. Dabei ist es auch möglich, einfach die Manifeste in das Config-Repo zu pushen, und Flux aktualisiert sich selbst per GitOps. Alternativ bietet Flux eine GitHub Action15 zum Upgrade an.
Argo CD aktualisieren
Die Verwaltung des GitOps-Tools per GitOps ist konsequent und vereinfacht den Betrieb. Für Argo CD wäre dies auch wünschenswert. Jedoch gibt es dafür keinen offiziellen Weg. Auch der Autopilot hat für Upgrades noch keine Lösung. Dass es möglich ist, zeigt beispielhaft der GitOps Playground16 als alternativer Weg zur Installation von Argo CD mit klarer Struktur der Config-Repos. In 6.7.2 auf Seite 175 besprechen wir ihn als ein Beispiel zur Strukturierung von Repos.
Schnelleres Feedback mit Weave GitOps Run
Eine interessante Innovation hinsichtlich des Bootstrapping von GitOps für die lokale Entwicklung bietet die Firma Weaveworks, die Flux ursprünglich an die CNCF spendete. Sie stellt mit »Weave GitOps«17 eine Erweiterung für Flux bereit. Teil davon ist »GitOps Run«18, ein interaktiver CLI-Befehl, der das Bootstrapping durchführt und danach das lokale Dateisystem auf Änderungen überwacht. Ändert man Kubernetes-Ressourcen, deployt Flux diese direkt. Dadurch bekommt man schnelles Feedback bei der lokalen Entwicklung.
GitOps Run ist in der aktuellen Version 0.29.0 von Weave GitOps noch im Beta-Stadium, was wir sowohl bei der Benutzung als auch an der Dokumentation merken.
Sobald der Operator läuft, ist es an der Zeit, Anwendungen zu deployen. Dazu gilt es Repos, Ordner, Environments etc. zu verbinden und zu gruppieren. Beide Operatoren bieten dafür CRDs an.
Linking mit Argo CD
Bei Argo CD kümmert sich die CRD Application um mehrere Belange, beispielsweise Repos, Pfade oder Branches und Helm-Releases (siehe Abschnitt 4.8 auf Seite 80). Der Name Application ist zwar treffend, führt aber hin und wieder zur Verwirrung, ob denn nun von der Anwendung als solcher oder von der CRD die Rede ist.
Linking mit Flux
Bei Flux steigt man mit der CRD Kustomization ein. Sie kümmert sich ausschließlich um die Konfiguration der Ressourcen. Für die Verbindung zu den Repos gibt es eine separate CRD GitRepository. Der Name Kustomization kommt daher, dass Flux unter der Haube Kustomize einsetzt. Als User muss man nicht zwangsweise Erfahrung mit Kustomize haben, um die CRD zu benutzen. Zusätzlich gibt es noch die Möglichkeit, Kustomize nativ mittels einer Datei kustomization.yaml zu verwenden, was zu Verwirrung zwischen dieser Datei und der Kustomization CRD führen kann.
Löschen von Ressourcen
Mittels den CRDs Application oder Kustomization ist auch das Löschen von Ressourcen per GitOps konfigurierbar. Dafür verwenden beide den Begriff »Resource Pruning« oder nur »Pruning«, bei Flux ist zusätzlich »Garbage Collection« synonym. Bei Argo CD ist Pruning standardmäßig deaktiviert. Bei Flux hingegen gibt es keinen Standardwert, und man muss sich bewusst für oder gegen Pruning entscheiden. Alle Codebeispiele in der Dokumentation von Flux haben Pruning aktiviert und geben damit zumindest implizit eine Empfehlung ab.
Grundsätzlich bietet das Löschen eine weitere Automatisierung und sorgt dafür, dass keine »Leichen« im Cluster zurückbleiben. Insofern macht es Sinn, dies möglichst früh zu aktivieren. Sicherheitshalber ist es empfehlenswert, zentrale Applications oder Kustomizations davon auszunehmen. Sensible Ressourcen (beispielsweise PersistentVolumeClaims) kann man sowohl in Argo CD19 als auch in Flux20 per Annotation vom Pruning ausnehmen.
Zur Interaktion mit den GitOps-Tools stehen neben Git jeweils eine CLI und GUIs zur Verfügung. Bei den GUIs lohnt sich ein Blick auf die Details.
GUI von Argo CD
Anders als Flux bringt Argo CD von Haus aus eine webbasierte GUI mit. Diese gibt es schon seit vielen Jahren und sie hat daher viele Features: Sie bietet grundlegende Funktionen wie Anzeige aller Anwendungen, Visualisierung der zugehörigen Ressourcen (siehe Abb. 4–1), Generierung von Application-YAML, Zugriff auf Konfiguration sowie Diffs zwischen Soll- und Istzustand, die bei Upgrades hilfreich sein können. Darüber hinaus kann man auch mit Argo CD und dem Cluster interagieren, beispielsweise Synchronisierung starten, Kubernetes-Events und Logs einsehen und sogar ein Terminal in Pods öffnen, was aber aus Sicherheitsgründen standardmäßig deaktiviert ist.
Abb. 4–1
Visualisierte Ressourcen in der UI von Argo CD
Aufgrund der standardmäßig enthaltenen GUI sind Aussagen wie »Flux hat keine UI« oder »Argo CD ist schwergewichtiger als Flux« gängig. Beide sind relativierbar.
Für Flux stellt Weaveworks zwei GUIs bereit: das beim Bootstrapping bereits erwähnte WeaveGitOps und eine Visual Studio Code Extension21.
GUIs für Flux
Beide sind jünger als die UI von Argo CD und haben einen kleineren Funktionsumfang. Bei WeaveGitOps sind dies primär grundlegende Funktionen wie Anzeige aller Anwendungen, eine einfache Visualisierung der zugehörigen Ressourcen (siehe Abb. 4–2) und Anzeige von YAML. Die einzige Möglichkeit zur Interaktion ist das Starten und Stoppen der Synchronisierung.
Obwohl Weaveworks nach wie vor große Anteile an der Maintenance des Flux-Projekts hat (siehe Tabelle 4–1 auf Seite 70), ist wichtig zu erwähnen, dass deren Produkte nicht Teil des CNCF-Projekts Flux sind. Damit sind sie prinzipiell als Third-Party-Tools anzusehen. Es sind zwar meist ebenfalls Open-Source-Projekte, sie unterliegen aber nicht den gleichen Regularien wie ein CNCF-Projekt, was ihren Einsatz generell riskanter macht: Die Einstellung des Projekts oder eine Lizenzänderung sind hier wahrscheinlicher.
Abb. 4–2
Visualisierte Ressourcen in der UI von WeaveGitOps
Leichtgewichtiger: Argo CD Core
Auf der anderen Seite steht dagegen die leichtgewichtigere Variante Argo CD Core22 bereit. Diese konfiguriert Argo CD mit einem minimalen Set an Controllern, unter anderem ohne UI.
Der vorherige Abschnitt zeigt uns, dass die Frage, ob Argo CD wirklich schwergewichtiger ist, nicht so einfach zu beantworten ist. Tabelle 4–3 auf Seite 77 und Tabelle 4–4 auf Seite 78 zeigen Fakten, die sich zur Laufzeit über die Container und Pods von Argo CD und Flux erheben lassen. Um einen ähnlichen Funktionsumfang zu vergleichen, gehen die zum Zeitpunkt des Tests neueste Version Argo CD (2.7.7) gegen Flux (2.0.1) plus Weave GitOps und GitOpsSet-Controller (mehr dazu in Abschnitt 4.7 auf Seite 79) ins Rennen. Allerdings sind diese Zahlen nicht immer direkt vergleichbar.
Für Caching und Authentifizierung verwendet Argo CD mit Redis und Dex externe Produkte, wodurch mehr Pods laufen. Bei Flux ist dafür Helm in einem dedizierten Controller, was bei Argo CD im Application-Controller integriert ist.
Ob diese Unterschiede groß genug sind, um Einfluss auf die Entscheidung zu haben, ist fraglich. Für die Ressourcenanforderungen wären Benchmarks oder Lasttests aussagekräftiger.
Wir werden in diesem Kapitel noch Punkte sehen, bei denen die Tools sich deutlicher voneinander unterscheiden. Mehr Details zu den Zahlen finden sich in diesem Artikel25.
Abb. 4–3
Containerbezogene Fakten zu Argo CD
Abb. 4–4
Container-bezogene Fakten zu Flux
Authentifizierung und Autorisierung sind beim Zugriff auf CLI und UI relevant.
Authentifizierung
Argo CD setzt sowohl für CLI als auch für UI auf Single Sign-On (SSO) mittels OpenID Connect (OIDC) und setzt dafür das Tool Dex ein. Es gibt eingeschränkte Möglichkeiten, lokale User zu verwenden, von denen die Dokumentation abrät.
Bei der Flux CLI authentifiziert man sich typischerweise Kubernetes-nativ via Kubeconfig. Weave GitOps setzt ebenfalls auf SSO via OIDC.
Autorisierung
Das Thema Autorisierung ist bei Flux einfach, aber eingeschränkter (siehe dazu Abschnitt 4.11 auf Seite 88): Flux realisiert die gesamte Autorisierung Kubernetes-nativ über RBAC (Role Based Access Control), sowohl für die CLI als auch für die UI26.
Anders sieht es bei Argo CD aus. Es hat seine eigene Notation27 zur Berechtigung von Usern oder Gruppen auf Applications, AppProjects, Cluster, Repos etc. Diese ist textbasiert und wird in der Konfiguration von Argo CD spezifiziert.
Zusätzlich gibt es die CRD AppProject. Sie gruppiert Applications und kann Zugriff auf Repos, Cluster und Namespaces geben. Unserer Erfahrung nach trennt man mittels AppProjects typischerweise Environments und/oder Teams voneinander (siehe Abschnitt 6.8 auf Seite 189).
ApplicationSets integriert in Argo CD
Argo CD bot als Erstes eine Funktionalität zum Templating von Application CRs an. Dies bietet viele neue Möglichkeiten, beispielsweise zur Skalierung von GitOps, zum Deployment auf mehrere Cluster oder zur Realisierung von Preview Environments (siehe Abschnitt 6.5.2 auf Seite 157).
Dafür stellt Argo CD eine CRD ApplicationSet mit zugehörigem Controller28 zur Verfügung, das wir bereits aus Abschnitt 3.3 auf Seite 51 kennen. Das ApplicationSet steht zur Application im gleichen Verhältnis wie das Deployment zum Pod: Im ApplicationSet definiert man ein Template, aus dem der Controller mehrere Applications generiert. Dafür stehen verschiedene Generatoren zur Verfügung, beispielsweise für Cluster, Verzeichnisse oder Dateien in Git oder für PRs. Damit generiert der Controller dann Applications pro Cluster, Verzeichnis, Datei oder Pull Request. Darin enthaltene Werte kann man als Variablen im ApplicationSet verwenden, beispielsweise den Namen Pull Requests.
GitOpsSets als Enterprise-Feature von Weave GitOps
Weaveworks hat dieses Potenzial erkannt und für Weave GitOps den bereits erwähnten GitOpsSet-Controller29 entwickelt. Dieser ist allerdings weder Bestandteil des CNCF-Projekts Flux noch Open Source, sondern ein Enterprise-Feature von Weave GitOps. Außerdem ist er noch im Alpha-Stadium30.
Eine wichtiger Teil der täglichen Arbeit mit GitOps ist die Verwendung von Configuration Management (CM) Tools. Sowohl Argo CD als auch Flux unterstützen die prominentesten CM-Tools: Kustomize und Helm.
Kustomize
Kustomize ist bei beiden über eine kustomization.yaml31 einsetzbar. Dies macht Kustomize zu einem Operator-agnostischen Werkzeug. Dadurch ist es besonders empfehlenswert bei der Strukturierung von Config-Repos, wie wir in Kapitel 6 auf Seite 133 genauer betrachten. Beim Einsatz von Kustomize bei Argo CD ist zu beachten, dass in der Application nicht recurse: true gesetzt sein darf. Wie in Abschnitt 4.3 auf Seite 72 erwähnt, verwendet Flux unter der Haube außerdem Kustomize zur Realisierung von Kustomizations.
Helm
Bei Helm ist die Lage sowohl bei Argo CD als auch bei Flux komplizierter: Es sind Operator-spezifische CRDs notwendig. Bei Flux gibt es einen dedizierten Helm-Controller mit eigenen CRDs, beispielsweise HelmRelease. Flux nutzt die native Helm Library und führt damit Helm-Releases genau wie die helm CLI durch. Dadurch stehen alle Features von Helm wie gewohnt zur Verfügung.
Anders geht Argo CD vor. Dort installiert man Helm-Charts mittels einer Application CR. Argo CD nutzt intern dann helm template und wendet die daraus erzeugten Manifeste selbst auf den Cluster an. Dadurch sind beispielsweise helm ls und die Nutzung der lookup-Funktion in Helm-Charts nicht möglich.
Oftmals ist die Pflege der values.yaml außerhalb der Application, zur Vermeidung von geschachteltem YAML und für die lokale Entwicklung gewünscht. Dies war bei Argo CD lange nicht direkt möglich. Daher ist oft das Umbrella Chart-Pattern (siehe Abschnitt 6.5.4 auf Seite 160) im Einsatz. Dieses ist generell aber eingeschränkt, da man beispielsweise nicht mit Authentifizierung auf Helm-Repos zugreifen und keine Charts aus Git laden kann. Um dies zu verbessern, gibt es seit Argo CD 2.6 »Multi-Source Applications«, die allerdings in Version 2.8 noch im Beta-Stadium32 sind.
Aufgrund der feingranulareren CRD ist der Einsatz des Umbrella Chart-Patterns bei Flux selten. Mit der Kombination der CRDs Git-Repo und HelmRelease ist dies aber generell möglich. Abschnitt 7.2.1 auf Seite 205 beschreibt dies im Detail.
Die Pflege der values.yaml außerhalb der HelmRelease-CRs ist etwas umständlich über Kustomize realisierbar33.
JSonnet und Plugin-Mechanismus bei Argo CD
Argo CD hat darüber hinaus Support für JSonnet. Außerdem ist es prinzipiell möglich, weitere CM-Tools über einen Plugin-Mechanismus einzubinden, was allerdings aufwendig und für die Security von Nachteil ist, weil ein externes Binary aufgerufen wird. Im Gegensatz zu Argo CD erlaubt Flux aus diesem Grund keine Kustomize-Plugins34.
JSonnet, Cuelang und Timoni via OCI-Registries bei Flux
Das von Flux-Maintainer Stefan Prodan gestartete Projekt Timoni schickt sich an, eine bessere User Experience (UX) für das Package Management in Kubernetes zu bieten als Helm oder Kustomize. Es ist so entworfen, dass es mit dem Support für OCI-Artifacts von Flux (siehe Abschnitt 4.13 auf Seite 90) zusammenspielt35.
Das Speichern von Kubernetes-Manifesten in OCI-Registries schlägt Flux auch offiziell zur Anbindung weiterer CM-Tools wie JSonnet oder Cuelang vor36. Dieses Vorgehen der Verwendung der CM-Tools auf dem CI-Server statt im GitOps-Operator bezeichnen wir als Rendered Manifest-Pattern (siehe Abschnitt 6.5.4 auf Seite 160). Es erlaubt die Verwendung von beliebigen CM-Tools mit allen GitOpsOperatoren, also auch mit Argo CD.
Die asynchrone Natur des GitOps-Prozesses macht Monitoring und Alerting besonders wichtig. Mit den Themen Asynchronität befassen wir uns in Kapitel 7 auf Seite 197, mit Alerting in Kapitel 8 auf Seite 229 noch genauer. In diesem Abschnitt fokussieren wir uns auf die konkreten Möglichkeiten, die Argo CD und Flux bieten.
Prometheus und Grafana
Sowohl Argo CD als auch Flux exponieren standardmäßig Prometheus-Metriken und bieten fertige Grafana-Dashboards an. Abb. 4–5 und Abb. 4–6 zeigen jeweils das offizielle Dashboard. Auf Basis der Metriken sind Alerts per Grafana oder Prometheus Alertmanager realisierbar, siehe Abb. 4–7.
Abb. 4–5
Grafana-Dashboard für Argo CD
Flux bietet eine einfache Anleitung zur Installation von Prometheus und Grafana, inklusive Dashboard, an37. Dies ist für den Start bequem.
Abb. 4–6
Grafana-Dashboard für Flux
Abb. 4–7
Alerting per Notification-Controller (links) und Metriken (rechts)
Sowohl Flux38 als auch Argo CD39 bieten die Möglichkeit, in Grafana Annotations zu setzen. Dadurch lassen sich Korrelationen zwischen Deployment und Veränderungen an den Metriken schneller erkennen.
Notification-Controllers
Als Alternative zum Alerting über Metriken bringen beide Tools Notification-Controllers mit. Mit diesen kann man auf Basis von Events Notifications versenden. Abb. 4–7 zeigt deren generelle Funktionsweise. Bei Argo CD liegt der Fokus auf den Zuständen der Application CRs, bei Flux sind Events pro Controller spezifizierbar.
Bei Argo CD sind Notifications in der globalen Konfiguration sowie auf Application- und auf AppProject-Ebene (jeweils per Annotation an der CR) konfigurierbar. Bei Flux gibt es dafür eigene CRDs, beispielsweise Alert. Abschnitt 8.2 auf Seite 239 beschreibt dies im Detail.
Bei beiden gibt es wenig Tipps, welche Notifications zum Starten sinnvoll sind. Argo CD bietet immerhin einen »Katalog«40, doch der zeigt eher alle Möglichkeiten als ein Paket zum Starten.
Nachrichten und Empfänger konfiguieren
Bei der Konfiguration der Nachrichten und der Empfänger unterscheiden sich beide Tools in Details. Argo CD41 und Flux42 unterstützen jeweils eine lange Liste von Diensten, über deren APIs oder Protokolle sie Nachrichten versenden können. Darunter sind verschiedene Chat-Dienste. Interessanterweise unterstützt nur Argo CD den Versand von Mails per SMTP.
Wer dies bei Flux benötigt, ist auf Workarounds angewiesen. Unserer Erfahrung nach ist dies beispielsweise über Prometheus Alertmanager möglich.
In der Liste von Diensten finden sich auch einige andere Arten von Notifications, wie die oben erwähnten Grafana Annotations oder das Setzen des Commit Status. Argo CD kann dies nur für GitHub43, Flux für verschiedene SCM-Dienste44.
Falls der gewünschte Dienst nicht unterstützt wird, kann gegebenenfalls, je nach Anwendungsfall, die Verwendung eines ausgehenden generischen Webhooks Abhilfe schaffen. Dies bieten sowohl Argo CD45 als auch Flux46 an.
Abb. 4–8 Eingehende Webhooks bei GitOps-Operatoren
GitOps per Webhook beschleunigen
Nicht zu verwechseln sind diese ausgehenden Webhooks mit den eingehenden. GitOps-Operatoren prüfen regelmäßig das Git-Repo auf Änderungen (Polling). Diesen Prozess kann man durch die Verwendung eingehender Webhooks beschleunigen: Der SCM-Dienst meldet Git-Pushes per Webhook an den Operator, was den normalen Pull-Mechanismus anstößt (siehe Abb. 4–8). Abschnitt 7.2.4 auf Seite 212 beschreibt dies im Detail. Dieses Prinzip findet auch beim Starten von Jobs auf CI-Servern häufig Anwendung.
Das Polling bleibt mit niedrigerer Frequenz dennoch bestehen, um sicherzustellen, dass das System auch beim Scheitern der Auslieferung des Webhooks eventually consistent bleibt. Ein Scheitern ist denkbar durch Downtimes des Operators oder Probleme im Netzwerk.
Im Rahmen seines Supports für OCI-Artifacts (siehe auch Abschnitt 4.13 auf Seite 90) unterstützt Flux zusätzlich die Webhooks verschiedener OCI-Registries. Damit kann man bei Flux auch einen GitOp-Prozess, der mit OCI-Registries statt Git läuft, beschleunigen. Darüber hinaus unterstützt Flux auch einen Receiver für eingehende generischen Webhooks, über den man auch nicht offiziell unterstützte SCM-Dienste und OCI-Registries anbinden kann.
Neben den bisher genannten grundlegenden GitOps-Funktionen gibt es weitere, die im Alltag mit GitOps eine Rolle spielen können. Viele von diesen stehen als zusätzliche Tools in den Ökosystemen von Flux oder Argo CD bereit.
Config Update per Image Update Controller
Eine Herausforderung im GitOps-Prozess ist das Config Update (siehe auch Abschnitt 6.5.5 auf Seite 163), bei dem man neue Image-Tags in die Kubernetes-Manifeste schreibt. Zur Automatisierung dieses Prozesses bietet sich die Verwendung von Image Update Controllers an. Sowohl Argo CD als auch Flux bieten hierfür optionale Controller an.
Bei Argo CD ist das externe Projekt »Image Updater«47 noch nicht stabil und die Weiterentwicklung steht seit Monaten still48, während Diskussionen über die grundsätzliche Eingliederung in Argo CD im Gange sind49. Der Image Updater wird generell per Annotation an Applications konfiguriert. Man kann dem Controller mitteilen,
Bei Flux teilen sich die Aufgaben mehrere »Image Automation Controllers«50 untereinander auf. Diese sind über CRDs (ImageRepository, ImagePolicy, ImageUpdateAutomation) sowie »image policy markers« (Kommentare im YAML, direkt am Image des Kubernetes-Objekts) konfigurierbar. Die Optionen sind vergleichbar mit denen von Argo CD. Allerdings bezeichnet Flux seine Controller als stabil. Darüber hinaus kann Flux nicht nur Images aktualisieren. Dank des bereits erwähnten OCI-Features kann es auch die Version von Helm-Charts aus OCI-Registries aktualisieren.
Bei beiden ist es nicht möglich, Pull Requests zu erstellen, was die Controller gegenüber anderen Methoden zum Config Update einschränkt. Diese Methoden vergleichen wir im Detail in Abschnitt 6.5.5 auf Seite 163.
Secrets Management
Ein Thema, das nicht direkt etwas mit GitOps zu tun haben muss, ist Secrets Management. Da bei GitOps alles in Git gespeichert wird, stellen sich jedoch viele in diesem Kontext die Frage, wie man dies mit Secrets Management vereinbaren kann. Daher wird es oft mit GitOps in Verbindung gebracht. Unabhängig von GitOps gibt es für das Secrets Management eine große Anzahl von Möglichkeiten, auf die wir in Kapitel 5 auf Seite 97 im Detail eingehen. Grundsätzlich bedarf es keiner speziellen Lösung durch den GitOps-Operator. Trotzdem ist es erwähnenswert, dass sowohl Flux als auch Argo CD Lösungen anbieten.
Flux und SOPS
Flux kann nativ mittels des CNCF-Projekts SOPS entschlüsseln51. SOPS bietet viele Möglichkeiten wie GPG, Hashicorp Vault oder die Key-Management-Systeme (KMS) verschiedener Cloud-Anbieter. SOPS konfiguriert man in der Kustomization, beispielsweise über den Zugriff auf ein Kubernetes-Secret, das ein GPG-Key-Pair enthält. Dann entschlüsselt Flux per SOPS verschlüsselte Kubernetes-Secrets direkt im Cluster.
Vault-Plugin bei Argo CD
Argo CD bietet das Vault-Plugin52 an. Anders als der Name vermuten lässt, bietet es nicht nur Anbindung an Hashicorp Vault, sondern an eine große Zahl von »Backends«, darunter alle bei Flux genannten. Das Plugin verwendet den in Abschnitt 4.8 auf Seite 80 erwähnten CM-Plugin-Mechanismus. Das macht die Verwendung umständlich: Man muss es separat installieren, und die Konfiguration hängt dann von der Art der Installation des Plugins, vom verwendeten Backend und von der Kombination mit anderen CM-Tools wie Helm und Kustomize ab53. Beispielsweise mountet man einen Key-Pair mittels Secret in den Repo-Server von Argo CD. Danach aktiviert man das Plugin in der Application. Dann kann Argo CD Secrets, die mit Platzhaltersyntax und spezifischen Kubernetes Annotations versehen sind, im Cluster entschlüsseln. Das Plugin liegt zwar seit Jahren in einer Version 1.x vor, befindet sich aber nach wie vor in der »argoproj-labs«-Organisation bei GitHub statt in »argoproj«. Insofern ist fraglich, ob man es offiziell als stabil ansehen kann. Auch die Mandantenfähigkeit ist durch die Realisierung als Plugin eingeschränkt. Außerdem bietet das Plugin keine automatische Aktualisierung von Secrets, wenn sie sich im KMS ändern54.
Progressive Delivery
Ähnlich wie mit dem Thema Secrets Management verhält es sich mit Progressive Delivery (PD): Es hat nicht zwangsweise mit GitOps zu tun, wird aber oft im gleichen Kontext erwähnt. Der Begriff PD fasst verschiedene Deployment-Strategien (Canary-Releases, A/B-Testing, Blue/Green-Deployment) zusammen. Abschnitt 7.4.3 auf Seite 221 beleuchtet das Thema genauer. Argo CD und Flux haben jeweils ein Schwesterprojekt, das die Möglichkeit bietet, PD deklarativ umzusetzen: »Flagger«55 aus dem Projekt Flux und »argo-rollouts«56 aus dem Projekt Argo. Beide liefern separate Operatoren, die auch ohne GitOps verwendbar sind. Daher spielen sie für diesen Vergleich keine entscheidende Rolle.
Relevanter für die Entscheidung könnten weitere Tools aus dem Ökosystem von Flux sein.
Terraform per GitOps mit Flux
Weaveworks bietet mit dem »tf-controller«57 eine Option zum Deployment von Terraform-Ressourcen per GitOps. Der Operator erlaubt es, neben Anwendungen auch Infrastruktur per GitOps auszurollen. Der Controller ist Open Source und liegt noch in einer Version 0.x vor, bekommt aber im Rahmen von »Weave GitOps Enterprise« schon kommerziellen Support.
Argo CD und Flux kombinieren mit Flamingo
Wer das Beste aus beiden Welten vereinen möchte, beispielsweise Helm-Handling von Flux mit der UI von Argo CD, greift zum »Flux Subsystem for Argo« (FSA, auch bekannt als »Flamingo«58). Flamingo steht als Argo-CD-Image zur Verfügung, das um die Möglichkeit der Verwaltung von Flux-CRs erweitert ist. Flamingo ist ein Open-Source-Projekt, für das Weaveworks kommerziellen Support anbietet. Die Kehrseite der Medaille ist der erhöhte Betriebs- und Ressourcenaufwand, denn man betreibt dann sowohl Flux als auch Argo CD. Außerdem ist auch hier wichtig zu erwähnen, dass Flamingo nicht Teil der CNCF-Projekte Flux und Argo ist (siehe Abschnitt 4.4 auf Seite 73 für Details). In 11.1.5 setzen wir das Flux-Subsystem auf und verwenden dieses in Kombination mit Terraform.
Ein Thema, auf das man beim Design des GitOps-Prozesses stößt, ist die Mandantentrennung. In diesem Abschnitt werden wir dieses Thema hinsichtlich der Features von Argo CD und Flux beleuchten. Eine umfangreichere Betrachtung liefert dann Abschnitt 6.8 auf Seite 189.
Grundsätzlich haben wir die Möglichkeit, die Mandantentrennung durch eine dedizierte Instanz pro Mandant umzusetzen oder die Trennung innerhalb einer Instanz durchzuführen.
Dedizierte Instanz pro Mandant
Eine dedizierte Instanz pro Mandant, die allein in einem eigenen Cluster läuft, ist die stärkste Form der Isolation. Es sind keine weiteren Optionen zur Mandantentrennung seitens des Operators notwendig. Damit ist dies sowohl mit Argo CD als auch mit Flux möglich.
Mehrere Instanzen im selben Cluster
Ein Sonderfall ist der Betrieb dedizierter Operator-Instanzen in unterschiedlichen Namespaces desselben Clusters. Argo CD bietet hierfür den »namespace-scoped mode«59, der allerdings etwas schlecht dokumentiert ist. Dazu ergänzend bietet Argo CD die Option »namespace-install«60 fürs Bootstrapping an. Alternativ steht mit dem in Abschnitt 4.2 auf Seite 71 erwähnten Argo CD Operator ein eigenes Tool bereit, mit dem mehrere Instanzen bequem verwaltbar sind.
Bei Flux finden sich zum Betrieb in Namespaces desselben Clusters keine Informationen in der Dokumentation. Prinzipiell sollte dies aber möglich sein: Man kann mittels Patching der Flux-Installation über eine kustomization.yaml RoleBindings statt ClusterRoleBindings für die ServiceAccounts der einzelnen Controller je Namespace erzeugen.
Geteilte Instanz
Bei einer geteilten Instanz wird die Autorisierung mittels der RBAC-Methoden des jeweiligen Operators wichtig. Argo CD bringt dafür seine eigene Notation mit (siehe Abschnitt 4.6 auf Seite 79). Daneben spielt die Custom Resource AppProject eine wichtige Rolle. Sie autorisiert zugehörige Applications auf Cluster, Namespaces und Repos. Für besseren Self-Service der Mandanten empfiehlt sich bei einer geteilten Instanz zudem das Feature »Applications in any namespace«61: Argo CD liest Application-CRs aus allen Namespaces statt nur aus dem, in dem es installiert ist. Das Feature ist allerdings noch im Beta-Stadium.
In Bezug auf Self-Service schränkt zusätzlich die globale Konfiguration ein: Mandanten können die Konfiguration von Repos und Cluster standardmäßig nicht selbst pflegen. Mittels zusätzlicher RBAC-Regeln kann man Project-scoped Repos und Cluster62 jedoch ermöglichen.
Multi-Tenancy Lockdown
Flux bietet die Möglichkeit eines »Multi-Tenancy Lockdown«63. Dieser erlaubt die Nutzung des RBAC von Kubernetes64 zur Mandantentrennung. Dazu berechtigt man jede Kustomization über einen ServiceAccount. Zur Vereinfachung gibt es den CLI-Befehl flux create tenant, der noch im Beta-Stadium65 ist. 6.7.4 auf Seite 183 zeigt dafür ein Beispiel.
Im Kontext der Mandantentrennung stellt sich oft die Frage nach der Verwaltung mehrerer Cluster. Dies ist sowohl bei Flux als auch bei Argo CD möglich. In Argo CD gibt es in der globalen Konfiguration die explizite Möglichkeit, Cluster anzugeben. Diese finden sich dann in den AppProjects und Applications wieder.
Bei Flux ist die Verwaltung mehrerer Cluster weniger prominent. Man kann eine KubeConfig in einem Secret ablegen und diese in Helm-Release oder Kustomization referenzieren66. Zusätzlich dazu zeigt Abschnitt 6.7 auf Seite 169, dass beide offiziellen Beispiele von Flux zu Repo-Strukturen das Instance per Cluster-Pattern (siehe Abschnitt 6.3 auf Seite 137) verwenden. Daraus kann man schließen, dass die Verwaltung mehrerer Cluster mit einer Flux-Instanz, also das Hub and Spoke-Pattern, bei Flux kein Kern-Feature ist.
Generell bietet Flux mit dem Support für OCI-Artifacts67 ein Feature, das Argo CD nicht hat. Dabei schreibt man die beispielsweise auf dem CI-Server mittels CM-Tools generierten Kubernetes-Manifeste in eine OCI-Registry, statt sie in Git zu speichern, siehe Abb. 4–9. Das Config-Repo verweist dann nur noch per Kustomization auf die OCI-Registry. Je nachdem, wie unveränderlich man es haben möchte (siehe Diskussion zu GitOps-Prinzip 2 in Abschnitt 1.3.2 auf Seite 18), verweist man auf latest/stable beziehungsweise SemVer, wie es die oben genannten Flux-Dokumentation beschreibt, oder auf eine unveränderliche Version.
Abb. 4–9
GitOps-Prozess mit Speicherung der Config in Git (oben) und in OCI-Registry (unten)
Die Nutzung der OCI-Registry für Config bietet einige Vorteile:
GitOps-Cache
Durch die Speicherung der Config in OCI-Registries können allerdings auch neue Herausforderungen entstehen. Beispielsweise ist die Ansicht der fertig gerenderten Manifeste, wie sie in der Registry gespeichert werden, aufgrund fehlenden Toolings deutlich schwieriger als in Git direkt. Je nachdem, wie man seinen GitOps-Prozess gestaltet, ist diese Ansicht allerdings nur fürs Debugging notwendig.
Abhängig von der Repo-Struktur und der Frage, ob man Code und Config in einem Repo speichert (siehe Abschnitt 6.4.3 auf Seite 141), muss man seinen Prozess anpassen. Beispielsweise ist es denkbar, dass die Umsetzung von Reviews/PRs neu gedacht werden muss. Und der CI-Job auf dem Config-Repo (so er denn bereits existiert) muss so angepasst werden, dass er zusätzlich die gerenderten Manifeste in die OCI-Registry pusht. Das bringt mehr Asynchronität und Komplexität ins Gesamtsystem.
Da das Thema GitOps mit OCI-Registry noch recht neu ist, sind dazu noch wenige Erfahrungen zu finden.
Die Themen Hochverfügbarkeit (High Availability, HA) und Lastverteilung (Load Balancing, LB) und horizontale Skalierung sind eng verwandt. Beide Operatoren speichern ihren Zustand in Kubernetes-Objekten, wodurch es kein zusätzliches Risiko von Ausfällen durch externen Storage gibt.
HA bei Argo CD
Argo CD bietet für HA eine spezielle Konfiguration beim Bootstrapping an und empfiehlt diese sogar71. Dazu gibt es viele Optionen zur Verbesserung der Performance und Daumenregeln, wie viele Objekte eine einzelne Instanz verwalten kann, beispielsweise mindestens 1500 Applications72.
LB bei Flux
Bei Flux gibt es keine Konfiguration für HA, allerdings eine für LB mittels Sharding, was ab »zehntausenden« Anwendungen relevant sein kann73. Dafür ordnet man Flux-CRs per Label einem Satz von Flux-Controllern (Shard) zu. Zusätzlich kann die Verwendung von OCI-Registries statt Git die Performance verbessern.
Die Frage ist, ob das Fehlen eines HA-Features bei Flux74 entscheidend ist. Die Controller von Flux starten schnell und haben regelmäßige Synchronisierungsintervalle. Insofern wäre durch einen Ausfall nur die Synchronisation um wenige Sekunden verzögert.
Es existiert noch keine Benchmark, die einen objektiven Vergleich der Skalierbarkeit von Argo CD und Flux ermöglicht.
Beide Tools sind bei der CNCF im Status »Graduated«. Damit erfüllen sie umfassende Kriterien75 in Bezug auf Dokumentation, Community, Verbreitung, Maintainers, Security und Open Source Governance.
Darüber hinaus lohnt sich ein Blick auf die Stabilität der APIs.
Bei Flux sind die grundlegenden CRDs76 wie Kustomization stabil. Andere CRDs wie die Alert sind noch im Beta-Stadium.
Bei Argo CD sind alle CRDs noch im Alpha-Stadium. Allerdings sind Breaking Changes selten. So gab es beispielsweise beim Übergang von Version 1 zu 2 keine Breaking Changes am API.
Enterprise Support und Plattformintegrationen bei Flux
Wie Tabelle 4–1 auf Seite 70 zeigt, hat Weaveworks mit Abstand den größten Anteil am Projekt Flux. Dort ist auch Enterprise Support im Angebot. Darüber hinaus ist Flux in Plattformen integriert77, wird also mit diesen ausgerollt, lässt sich optional installieren oder ist ins Produkt integriert. Beispiele sind AWS EKS Anywhere, Azure AKS sowie Azure Arc, Giant Swarm, Gimlet, VMware Tanzu, D2iQ und GitLab.
Besonders erwähnenswert ist GitLab, das von einem selbst entwickelten GitOps-Operator zu Flux wechselte. Für Flux und gegen Argo CD spricht dabei, dass GitLab schon seine eigene UI hat und Flux komplett auf Kubernetes-APIs basiert78.
Außerdem ist das Fallbeispiel von D2iQ interessant: Diese stellten ebenfalls aufgrund der guten Integration von Flux in Kubernetes ihr Produkt von Argo CD auf Flux um79.
Angebote als managed Service gibt es bei Flux nicht.
Managed Services und Plattformintegrationen bei Argo CD
Genau das sieht bei Argo CD anders aus: Es gibt keinen Enterprise Support, dafür viele Angebote von managed Argo CD oder Plattformen, die Argo CD enthalten oder darauf aufbauen. Beispiele sind Akuity, CodeFresh und Harness. Die prominenteste Plattform für den Betrieb on-Premises, die Argo CD enthält, ist OpenShift von RedHat. Ihr Produkt »OpenShift GitOps« basiert auf Argo CD.
Wie ein Blick auf Tabelle 4–1 auf Seite 70 zeigt, sind die meisten der genannten Firmen auch an der Weiterentwicklung beteiligt. Intuit, die Firma, die das Argo-Projekt an die CNCF spendete, hat selbst keine kommerziellen Angebote, sondern nutzt die Tools intern.
Dieser Abschnitt vergleicht Argo CD und Flux in Bezug auf verschiedene Bereiche und gibt damit eine Übersicht, welche Punkte bei der Entscheidung eine Rolle spielen können. Dabei fällt auf, dass der Teufel im Detail steckt. Wie finden wir nun das richtige Tool für unseren Anwendungsfall?
Für viele Anwendungsfälle sind diese Details nicht relevant. Für sie sind sowohl Argo CD und Flux eine gute Wahl. Die Unterschiede liegen dann eher in der unterschiedlichen UX. Trotzdem ist eine Kenntnis der eigenen Anforderungen essenziell. Es gibt einige Punkte, bei denen eines der Tools die Nase vorn hat: Argo CD hat Vorteile im Bereich UI und Templating, was erfahrungsgemäß oft wichtige Anforderungen sind. Bei Flux könnte die Verfügbarkeit eines Terraform-Operators oder das OCI-Feature entscheidend sein. Auch das Bootstrapping und CM sind unserer Erfahrung nach mit Flux angenehmer, doch hier findet man auch bei Argo CD (umständlichere) Lösungen. Prinzipiell kann man mittels Flamingo auch beide Operatoren gemeinsam nutzen.
Grundsätzlich ist Flux modularer und fühlt sich durch mehr CRDs und RBAC Kubernetes-nativer an. Das ist ein Grund, warum es öfter in andere Produkte integriert wird. Argo CD richtet sich mit seiner UI eher an End-User.
