Cloudnative Technologien und Werkzeuge haben sich zu einem Eckpfeiler der IT entwickelt. Während Admins traditionelle Software oft noch manuell oder mittels Tools wie Ansible auf Servern installieren, stoßen solche Deployment-Verfahren in Cloudumgebungen schnell an Grenzen. Zum einen arbeiten klassische Werkzeuge in der Regel imperativ – sie führen also explizite Befehle aus, um einen Zustand zu erreichen. Zum anderen sind deren Konfigurationen nicht zwingend in Git hinterlegt und somit nicht immer versionskontrolliert oder nachvollziehbar. Des Weiteren wurden diese Tools nicht für Kubernetes entwickelt, was die Wartbarkeit gerade bei größeren Deployments erschwert.

Die Firma Weaveworks stellte vor einigen Jahren ein neues Betriebsmodell vor, das auf DevOps-Praktiken basiert und Git als zentrale Instanz ("Single Source of Truth") nutzt. Die Kernidee: Admins definieren alle Änderungen deklarativ in Git-Repositorys und setzen diese anschließend mit Werkzeugen wie Argo CD um. Dieser GitOps-Ansatz fußt auf vier Kernprinzipien:

- Deklarative Konfiguration: Die gewünschte Systemkonfiguration ist in Git gespeichert (zum Beispiel YAML-Dateien für Kubernetes).

- Git als Single Source of Truth: Alle Änderungen erfolgen über Pull-Requests, was eine vollständige Nachverfolgbarkeit garantiert. Manuelle Eingriffe im Zielsystem sind zu vermeiden.

- Automatisierung: Werkzeuge wie Argo CD synchronisieren den Zustand im Git-Repository mit der Produktion.

- Kontinuierliche Überwachung: Diese sorgt dafür, dass Admins Abweichungen zwischen Git und Produktion (Drift) erkennen und automatisch korrigieren.

Die Umstellung von traditionellem Deployment auf GitOps kann initial einen erhöhten Aufwand bedeuten. Dies gilt insbesondere dann, wenn wir existierende Skripte mit komplexer prozeduraler Logik in einen deklarativen Ansatz überführen. Dem stehen jedoch signifikante Vorteile gegenüber: Die Transparenz und Nachverfolgbarkeit durch Git, die Sicherheit durch Pull-Requests und Peer-Reviews sowie die Geschwindigkeit automatisierter Deployments. Zudem profitieren Teams von einer besseren Zusammenarbeit und der Konsistenz reproduzierbarer Umgebungen.

Im Bereich GitOps haben sich über die Jahre verschiedene Werkzeuge etabliert. Die beiden bekanntesten Vertreter sind Flux CD und Argo CD [1] – letzteres beschreiben wir in diesem Artikel.

Bevor Sie mit der Installation starten, lohnt sich ein Blick auf die Architektur von Argo CD. Dessen zentrale Komponenten lassen sich wie folgt beschreiben:

- Der API-Server bildet die Schnittstelle für die Benutzerinteraktion. Wie bei vielen Systemen gibt es verschiedene Wege der Kommunikation – über das Web-UI, das Argo-CD-CLI oder das API. Darüber hinaus übernimmt der API-Server die Authentifizierung sowie Autorisierung und liefert Statusinformationen über deployte Anwendungen.

- Der Application-Controller ist als Herzstück von Argo CD für die Überwachung und Synchronisation verantwortlich. Er vergleicht laufend den gewünschten Zustand aus Git mit dem aktuellen Zustand im Cluster. Bei Konfigurationsabweichungen (Drift) kann er eine Synchronisation auslösen. Dann verarbeitet er die deklarativen Manifeste aus Git und wendet sie auf den Cluster an.

- Im Repository-Server kommen die Verwaltung der Git-Repositorys sowie die Interaktion mit diesen zusammen. Der Server liest und parst die Konfigurationsdateien. Dazu gehört auch die Authentifizierung gegenüber den Repositorys sowie ein Caching zur Performancesteigerung.

Mittlerweile liegt Argo CD in Version 3.0 vor und hat über die Jahre eine Vielzahl an Funktionen erhalten. Dazu gehört die Unterstützung für unterschiedliche Konfigurationsmanagement- und Templating-Werkzeuge wie Plain YAML, Kustomize, Helm oder das weniger bekannte Jsonnet. Argo CD ist multi-mandantenfähig, sodass unterschiedliche Teams einen Server gemeinsam nutzen können. Administratoren konfigurieren innerhalb von Argo CD mittels Projekten den Zugriff auf Cluster, Ressourcen und Elemente wie RBAC-Regeln feingranular. Auch eine SSO-Anbindung ist möglich.

Besonderes Augenmerk verdienen das GUI und die Visualisierung von Applikationen. IT-Verantwortliche erkennen darüber schnell den Health-Zustand jeder Anwendung, rufen Logs sowie Audit-Informationen ab, synchronisieren Anwendungen manuell oder führen bei Bedarf ein Rollback durch. Mit einer Argo-CD-Installation lassen sich wahlweise ein oder mehrere Kubernetes-Cluster verwalten.

Die Einrichtung umfasst Argo CD, das CLI sowie die Konfiguration des Ingresses für das GUI. Die Installation gelingt am einfachsten per Kubernetes-Manifest; für fortgeschrittene Szenarien mit individuellen Anpassungen eignet sich eine Helm-Installation besser. Wenn Sie "kubectl" installiert haben und die kubeconfig-Datei für Ihren Cluster konfiguriert ist, führen Sie folgenden Befehl zum Anlegen eines Namespaces aus und starten die Installation:

Im nächsten Schritt empfiehlt es sich, das Argo CD-CLI zu installieren:

Nun testen Sie die Installation per Port-Forwarding auf den lokalen Rechner, da der Argo-CD-Kubernetes-Service standardmäßig noch nicht erreichbar ist:

Sie können das GUI nun unter der Adresse "https://localhost:8080" öffnen. Zu diesem Zeitpunkt besitzen Sie jedoch noch kein Administratorpasswort, um sich gegenüber Argo CD zu authentifizieren. Das initiale Passwort rufen Sie über das Argo-CD-CLI ab:

Wenn Sie sich später per CLI am Server anmelden möchten, nutzen Sie den Befehlargocd login <ARGOCD_SERVER>. Da wir sämtliche Administrationsaufgaben wahlweise über das GUI oder das CLI ausführen können, ist dieser Zugang essenziell.

Um Argo CD in Aktion zu erleben, empfiehlt es sich, eine Beispielapplikation zu installieren.

Der bekannteste Vertreter ist "Guestbook", den Sie einfach über das CLI deployen:

Dabei liest das CLI ein fertiges Applikationsmanifest aus Git (Pfad: "guestbook") und installiert es im Namespace "default" des Kubernetes-Clusters. Anschließend können Sie sich im GUI anmelden und die Installation begutachten; die Guestbook-Anwendung ist dort sofort sichtbar (siehe Bild). Die Guestbook-Anwendung selbst besteht aus einer Reihe von Komponenten. Sobald Sie auf die Anwendung klicken, sehen Sie die Details.

Um die Konfiguration abzuschließen, müssen Sie die Argo-CD-Anwendung noch über eine IP-Adresse exponieren. Für Testzwecke können Sie den Dienst mittels NodePort veröffentlichen. Alternativ lässt sich direkt ein Loadbalancer vorschalten – für die meisten Anwendungsfälle ist jedoch die Konfiguration als Kubernetes-Ingress empfohlen.

Um Argo CD tiefgreifender zu verstehen, ist eine Auseinandersetzung mit den zugrundeliegenden Konzepten erforderlich. Bei der Installation hat das Werkzeug eine Reihe von "Kubernetes Custom Resource Definitions" (CRDs) hinzugefügt. Ein zentrales Element davon ist die "Argo CD Application". Mit deren Hilfe modellieren wir Anwendungen in Git und deployen diese in Kubernetes. Um dies genauer zu untersuchen, dient eine einfache Kubernetes-Anwendung – bestehend aus einem Deployment und einem Service – als Basis (Listing 1).

Wenn Sie nun – ähnlich wie vorhin per CLI – eine Argo-CD-Applikation per Manifest deployen wollen, kann das wie in Listing 2 aussehen. In diesem Manifest finden sich einige interessante Aspekte: Die Sektion "metadata" definiert die Version des Argo-CD-API und weist die Ressource als Argo-CD-Applikation aus. Der Name der Anwendung lautet "demo", die Installation erfolgt in den Namespace" argocd". Die "finalizers" stellen sicher, dass Argo CD alle zugehörigen Ressourcen löscht, bevor die Applikation selbst entfernt wird.

Im spec-Teil wird zunächst das "default-AppProject" referenziert. AppProjects dienen innerhalb von Argo CD der Trennung von Teams. Sie können so Applikationen, Cluster und andere Ressourcen bestimmten Projekten zuweisen und anschließend Teams per RBAC-Regeln Zugriff auf das jeweilige AppProject samt seiner Ressourcen gewähren. In der source-Sektion beschreiben Sie den Fundort der Kubernetes-Manifeste. Im Attribut "repoURL" konfigurieren Sie die URL des Git-Repositorys – in unserem Beispiel ein öffentliches GitHub-Repository. Mit "targetRevision: HEAD" geben Sie an, dass die neueste Version des Repositorys zum Einsatz kommt; alternativ wäre ein spezifischer Branch, Tag oder Commit-Hash möglich. Der "path" legt den Pfad innerhalb des Repositorys fest, während "directory.recurse: false" bestimmt, dass Argo CD nur Dateien im angegebenen Verzeichnis und nicht in Unterverzeichnissen sucht. Den Bestimmungsort des Deployments legen Sie in der destination-Sektion fest, indem Sie den Server sowie den Namespace angeben.

Schließlich konfiguriert der Abschnitt syncPolicy die entsprechenden Richtlinien. Mit "automated" aktivieren wir die automatische Synchronisierung. Dabei löscht "prune: true" Ressourcen aus dem Cluster, die in Git nicht mehr definiert sind und "selfHeal: true" stellt sicher, dass das Werkzeug Abweichungen zwischen Soll- und Ist-Zustand automatisch korrigiert. Die Zeile " allowEmpty: " false legt fest, ob auch ein leerer Zustand ohne Ressourcen synchronisiert werden darf.

Eine Herausforderung bei GitOps besteht darin, dass manche Anwendungen Credentials in Form von Passwörtern oder Tokens benötigen. In Kubernetes werden diese oft als Secrets bereitgestellt oder Pods als Umgebungsvariablen zugänglich gemacht. Sensitive Informationen dürfen Sie jedoch keinesfalls unverschlüsselt in Git speichern, sodass ein sicherer Ansatz für die Bereitstellung notwendig ist.

Um diesen Vorgang mit Argo CD zu automatisieren, ist eine Vault-Integration eine Option. Secrets lassen sich in einem Vault speichern. In der Cloud nutzen wir Dienste wie den Google oder Azure Secret Manager; on-premises sind Hashicorp Vault oder Cyberark Conjur verbreitet. Für die meisten Umgebungen stehen Kubernetes-Operatoren bereit, die die Credentials mittels Manifesten in Kubernetes bereitstellen.

Für einfache Anwendungsfälle eignet sich Bitnami Sealed Secrets [2]. Darüber lassen sich sensible Daten verschlüsselt in einem Git-Repository ablegen. Das Werkzeug besteht aus zwei Komponenten: Der "Sealed Secrets Controller "wird im Kubernetes-Cluster installiert und wandelt verschlüsselte SealedSecret-Ressourcen in reguläre Kubernetes-Secrets um. Die zweite Komponente ist das CLI "kube- seal". Entwickler nutzen es, um Secrets mit einem öffentlichen Schlüssel zu verschlüsseln, bevor sie diese in ein Git-Repository hochladen. Der private Schlüssel verbleibt dabei sicher im Cluster. Die Installation geht schnell vonstatten. Das kubeseal-CLI erhalten Sie auf der GitHub-Seite [3], die Installation des Controllers im Cluster führen wir mit Helm durch:

Nun können Sie anfangen, vertrauliche Daten in SealedSecrets umzuwandeln. Das folgende Beispiel zeigt dies anhand eines Zertifkats:

Häufig besteht die Anforderung, mehrere Anwendungen zu einem Deployment zu bündeln oder die Logik einer Applikation für verschiedene Deployments wiederzuverwenden. Für beide Szenarien bietet Argo CD dedizierte Unterstützung: Bei "App of Apps" nutzen wir eine zentrale "Eltern"-Applikation, die untergeordnete "Kind"-Applikationen bündelt und als Einheit deployt. Dieses Design-Pattern erweist sich beispielsweise beim Bootstrapping eines Kubernetes-Clusters als praktisch, wenn wir eine Vielzahl von Anwendungen gleichzeitig installieren müssen. Hingegen ermöglichen "App- licationSets", mehrere Applikationsressourcen dynamisch auf Basis eines Templates zu erzeugen. Damit eignen sie sich bestens für Szenarien, in denen Admins viele ähnliche Anwendungen über mehrere Cluster, Namespaces oder Umgebungen hinweg verwalten müssen.

Da beide Konzepte für die Arbeit mit Argo CD essenziell sind, beschreiben wir diese im Folgenden genauer. Die Umsetzung einer "App of Apps" ist dabei sehr einfach, wie Listing 3 zeigt. Die Applikation unterscheidet sich auf den ersten Blick nicht wesentlich von den vorigen Beispielen. Die Besonderheit liegt darin, dass das Attribut "path" auf ein Verzeichnis verweist, in dem wir die weiteren CRDs definiert haben.

Das dynamische Deployment mit ApplicationSets ist in der Umsetzung etwas komplexer, ein Beispiel liefert Listing 4. Von besonderer Bedeutung ist darin die "generators"-Sektion, in der wir eine Liste mit zwei Elementen ("prod" und "staging") definieren. Die darauffolgende "template"-Sektion greift diese Werte auf und generiert für jeden Eintrag eine "Application-Resource". Dabei werden die Variablen "{{ namespace }}" und "{{ environment }}" jeweils durch die vom Generator erzeugten Werte ersetzt.

Das Beispiel zeigt einen einfachen List-Generator, der Anwendungen basierend auf statischen Listen erstellt. Darü- ber hinaus stehen der Git-, der Cluster-, der Matrix- sowie der SCM-Generatorzur Verfügung.

Argo CD hat sich als Standard für das Kubernetes-native Deployment etabliert, da es die Lücke zwischen Git-Revisionierung und Cluster-Zustand zuverlässig schließt. Die Stärke des Werkzeugs liegt nicht nur in der visuellen Aufbereitung der Applikations-Health im GUI, sondern vor allem in der Skalierbarkeit durch Application- Sets und der konsequenten Korrektur von Konfigurations-Drifts.

Für IT-Verantwortliche bedeutet der Umstieg zwar einen initialen Aufwand bei der Umstellung prozeduraler Skripte auf deklarative Manifeste, der Gewinn an Nachverfolgbarkeit und Sicherheit wiegt diesen jedoch auf.

(jp)