Sind Sie neugierig auf eine weitere Add-on-Lösung für das Flottenmanagement?
Hinweis: Der Zweck dieses Blogs ist es nicht, die vielen Möglichkeiten von Sveltos vorzustellen, da Gianluca Mardente und Eleni Grosdouli dies bereits in der Dokumentation und in vielen Blogbeiträgen auf Medium erläutert haben. Ich konzentriere mich hier auf die Perspektive eines Plattform-Ingenieurs und die Herausforderungen, denen wir mit Argo CD gegenüberstehen und die Sveltos in Kombination mit Flux CD eleganter gelöst hat.
Wie in Abbildung 1 dargestellt, werden wir nur Argo CD und Sveltos betrachten, nicht aber Flux CD. Der Grund dafür wird in Kürze erklärt. Dieser Blog setzt voraus, dass Sie mit dem GitOps-Konzept sowie mit Cockpit und Fleet vertraut sind.
Einführung
Sveltos basiert auf einem Management-Cluster und mehreren Flotten-Clustern, auf denen Anwendungen (Add-ons) verwaltet werden. Ein Add-on wie eine Anwendung wie der Ingress-Controller. Argo CD kann auch mit diesem Ansatz verwendet werden. Ein Vergleich mit Flux CD wäre nicht fair oder sinnvoll, da Flux CD meiner Meinung nach für die Verwaltung seines eigenen Clusters konzipiert ist.
Die meisten Leute denken sofort an Flux CD und Argo CD, wenn sie über GitOps sprechen, als ob es keine anderen Werkzeuge gäbe. Ich war übrigens einer von diesen Leuten. Auch wenn dies die vorherrschenden Tools auf dem Markt sind, sollten wir unseren Geist für andere Optionen öffnen. Glücklicherweise ist mir das auf der KubeCon2024 in Paris passiert, wo ich Gianluca, einen Maintainer von Sveltos, getroffen habe, und ich finde die Lösung ziemlich elegant
Sveltos gegen Argo CD
Sveltos ist ein Paket von Kubernetes-Controllern, die im Management-Cluster laufen. Vom Management-Cluster aus kann Sveltos Add-ons und Anwendungen in einer Flotte von verwalteten Kubernetes-Clustern verwalten. Sveltos ist ein deklaratives Tool, das sicherstellt, dass der gewünschte Zustand einer Anwendung immer im tatsächlichen Zustand des Kubernetes Management- oder Workload-Clusters wiedergegeben wird.
Argo CD ist ein Open-Source-Continuous-Delivery-Tool (CD) für Kubernetes, das die Bereitstellung, Überwachung und das Rollback von Anwendungen automatisiert. Es ist ein deklaratives Tool, das GitOps-Prinzipien verwendet, um sicherzustellen, dass der gewünschte Zustand einer Anwendung immer im tatsächlichen Zustand des Kubernetes Management- oder Workload-Clusters wiedergegeben wird.
Klingt zunächst einmal ähnlich, nicht wahr? Hier kommt die erste Ähnlichkeit, aber auch der erste große Unterschied.
Obwohl beide Tools verwendet werden können, um die erforderlichen Anwendungen auf den Flottenschiffen (Workload-Clustern) auszurollen, hat Argo CD den GitOps-Ansatz integriert, während Sveltos an diesem Punkt auf Flux CD als Integrationswerkzeug angewiesen ist (wie in Abbildung 3 dargestellt).
Im Folgenden werden wir verschiedene Punkte betrachten, um zu verstehen, welche Ansätze die beiden Werkzeuge verfolgen und wo die Werkzeuge an ihre Grenzen stoßen.
Architektur
Betrachten wir dies nun auf architektonischer Ebene, um zu verstehen, wie der Cockpit-Cluster Verbindungen zu den Flottenschiffen (Workload-Clustern) herstellt, die verwaltet werden. Im folgenden Abschnitt werden wir technisch und praktisch untersuchen, wie sich die Herstellung dieser Verbindungen unterscheidet.
Hier können wir den ersten Unterschied sehen. Wie bereits erwähnt, greift Argo CD auf das Repository zu und verwaltet es über einen Controller (Repo Server). Beim Aufbau der Verbindung erstellt Argo ServiceAccounts, ClusterRole und ClusterRoleBinding und speichert das Bearer-Token im Management-Cluster als Geheimnis im Namespace, in dem die Argo-Instanzen ausgeführt werden. Dann hält Argo die bereitgestellten Anwendungen synchron und überprüft den Status zwischen dem Repository und dem bereitgestellten Zustand in den Clustern standardmäßig alle 3 Minuten. Die Synchronisierung und das Templating, zum Beispiel bei der Verwendung von Helm als Paketmanager, erfolgen serverseitig in Argo.
Hier stoßen wir auf die ersten Herausforderungen, die unser Team bereits bewältigt hat. Zum Beispiel erfordert die Verwaltung von 2000 Anwendungen über Argo erhebliche Ressourcen für die Aktualisierung oder Synchronisierung. Derzeit halten wir die Replikate auf 3 fest und erlauben eine horizontale Skalierung auf bis zu 5.
Da dies viele Ressourcen verbraucht, empfiehlt Akuity beispielsweise, das Rendering über CI zu verwalten und nur die endgültigen Manifeste zu verteilen. Zu diesem Zweck haben sie auch ein Tool namens Kargo entwickelt, um diese Prozesse zu vereinfachen.
Werfen wir nun einen Blick auf die Architektur von Sveltos:
Um den GitOps-Ansatz zu gewährleisten, setzt Sveltos auf die Integration von Flux CD. Flux ruft so genannte Profile oder ClusterProfile als Ressourcen ab, die Sveltos dann zum Ausrollen der Add-ons auf die Flottenschiffe verwendet. Wir werden dies später noch genauer betrachten. Beim Aufbau der Verbindung erstellt Sveltos einen Namespace für das Flottenschiff im Management-Cluster sowie ServiceAccounts, ClusterRole und ClusterRoleBinding im Flottenschiff und speichert sie als Geheimnis im erstellten Namespace des Management-Clusters. Außerdem stellt Sveltos dann den Agenten auf dem Flottenschiff bereit.
Dies wirkt sich auch auf den Synchronisierungsprozess aus. Im Gegensatz zu Argo setzt Sveltos Agenten auf den Flottenclustern ein, die je nach Sync-Modus die Sveltos-Instanz auf dem Management-Cluster benachrichtigen, die dann den Re-Sync durchführt, um den ursprünglichen Zustand (Manifest) wiederherzustellen. Dies spart Ressourcen, da der Sync nur im Falle einer Drift stattfindet und die Überprüfung über die Agenten erfolgt, nicht wie bei Argo über die Cockpit-Instanz. Das spart erheblich Ressourcen und sorgt gleichzeitig für eine stärkere Isolation durch Namespaces. Außerdem ermöglicht es Sveltos, einen konsequenteren Multi-Tenancy-Ansatz zu verfolgen, da es von Anfang an auf diese Idee hin konzipiert wurde. Jeder, der sich mit Multi-Tenancy in Argo beschäftigt hat, weiß, wie herausfordernd es ist, eine echte harte Isolation zu implementieren.
Im nächsten Teil werden wir uns ansehen, wie man beide Lösungen einrichtet.
Einsatz von Argo CD vs. Sveltos
Voraussetzung dafür ist, dass Sie bei allen Kubernetes-Clustern angemeldet sind und diese in der kubeconfig gespeichert haben. Wir verwenden sie, um die Verbindung zwischen dem Cockpit und den Flottenschiffen sowohl für Argo als auch für Sveltos herzustellen.
Argo CD:
Verteilen Sie die Argo-CD im Cockpit mit:
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yamlLaden Sie Argo CD CLI herunter und installieren Sie es:
brew install argocdEs gibt jetzt einen speziellen Arbeitsablauf von Argo, der in Abbildung 6 zu sehen ist.
In Abbildung 6 sehen Sie, dass Sie sowohl bei den Clustern als auch beim Argo-Server angemeldet sein müssen, um die Verbindung herstellen zu können. Natürlich können Sie die Verbindung auch direkt über manuelle Schritte und die Bereitstellung der Manifeste einrichten, was Ihnen Schritt 2 erspart.
argocd cluster add aks-vengeance-development --label env=development --upsert --yesSie können ein Geheimnis im Cockpit sehen und die Verbindung kann auch in der Benutzeroberfläche angezeigt werden, z.B. wie:
Hier gibt es zwei direkte Unterschiede zu Sveltos. Argo hat eine Benutzeroberfläche, Sveltos noch nicht.
Sie müssen das Flag – – label für jedes Label setzen, während Sie bei Sveltos eine Liste angeben können.
Wie ist die Lage bei Sveltos?
Sveltos:
Sveltos bietet zwei Modi für die Verwaltung von Clustern: In Modus 1 läuft in jedem verwalteten Cluster ein Agent, was für Standardkonfigurationen ideal ist. Modus 2 führt einen anderen Ansatz ein, bei dem zwar jeder verwaltete Cluster immer noch seinen eigenen Agenten hat, diese Agenten aber innerhalb des Verwaltungsclusters selbst arbeiten.
Diese Anpassung (Modus 2), die von der Kamaji-Architektur inspiriert ist, bei der die Steuerungsebenen des verwalteten Clusters als Pods innerhalb des Management-Clusters fungieren, stellt sicher, dass die Agenten zwar zentral angesiedelt sind, aber dennoch ausschließlich den API-Server des ihnen zugewiesenen verwalteten Clusters überwachen.
Also werde ich es in meinen eigenen Worten nennen:
Modus-1 (Lokaler Agentenmodus): Für den Modus, in dem ein Agent in jedem verwalteten Cluster läuft.
Modus-2 (Zentralisierter Agentenmodus): Für den Modus, in dem Agenten innerhalb des Management-Clusters arbeiten, aber dennoch jeden verwalteten Cluster überwachen.
Wir werden Modus 1 verwenden.
kubectl apply -f https://raw.githubusercontent.com/projectsveltos/sveltos/main/manifest/manifest.yaml
kubectl apply -f https://raw.githubusercontent.com/projectsveltos/sveltos/main/manifest/default-classifier.yamlLaden Sie sveltosctl CLI herunter und installieren Sie es:
wget https://github.com/projectsveltos/sveltosctl/releases/download/v0.28.0/sveltosctl-darwin-arm64 -O /usr/local/bin/sveltosctl
chmod +x /usr/local/bin/sveltosctlJetzt registrieren wir den Flotten-Schiffs-Cluster oder den Flotten-Schiffs-Cluster.
Zu diesem Zeitpunkt benötigt Sveltos nur noch Zugang zu den Clustern (Abbildung 8) und keine zusätzliche Anmeldung über den Server.
kubectl create ns aks-vengeance-development
sveltosctl register cluster --namespace=aks-vengeance-development --cluster=aks-vengeance-development --fleet-cluster-context=aks-vengeance-development --labels=env=developmentNachdem der Cluster mit dem vorherigen Befehl registriert wurde, können wir ihn anzeigen. Da es keine Benutzeroberfläche gibt, können wir ihn mit dem folgenden Befehl anzeigen:
kubectl get sveltosclusters.lib.projectsveltos.io -A
NAMESPACE NAME READY VERSION
aks-vengeance-development aks-vengeance-development v1.28.3
mgmt mgmt v1.27.1Da sveltoscluster CustomResourceDefinitions sind, können wir sie leicht abrufen. Mit Argo ist es ein Geheimnis und wir können das Token, den Server usw. nur sehen, wenn wir es verschlüsseln.
Beide Tools bieten eine einfache Möglichkeit, die Cluster dem Cockpit hinzuzufügen. Bei Argo ist dafür ein zusätzlicher Schritt erforderlich.
Jetzt haben wir die Grundlage, um die Flottencluster entsprechend auszustatten.
Los geht’s mit dem Deployment!
In diesem Schritt wollen wir den Ingress-Controller über ein Helm-Diagramm mit dem entsprechenden Label env=development auf alle Cluster ausrollen.
In Argo CD erstellen wir zu diesem Zweck ein ApplicationSet wie:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: nginx-ingress
namespace: argocd
spec:
generators:
- clusters:
selector:
matchLabels:
env: development
values:
branch: main
template:
metadata:
name: "{{name}}-nginx-ingress"
annotations:
argocd.argoproj.io/manifest-generate-paths: ".;.."
spec:
project: default
sources:
- repoURL: https://github.com/Hamburg-Port-Authority/kubernetes-service-catalog.git
targetRevision: "{{values.branch}}"
path: "./networking/ingress-nginx"
helm:
releaseName: "ingress-nginx" # Release name override (defaults to application name)
valueFiles:
- "values.yaml"
destination:
name: "{{name}}"
namespace: "nginx-ingress"
syncPolicy:
automated:
prune: false
selfHeal: true
syncOptions:
- CreateNamespace=true
retry:
limit: 5
Hier verwenden wir einen Cluster-Generator, der aus den registrierten Clustern und der Übereinstimmung der Labels eine Anwendung erstellt und diese entsprechend patcht. Dies ermöglicht das clusterspezifische Überschreiben der Werte.
Dieser Ansatz ermöglicht es uns bei Argo CD, eine Anwendung auf allen Clustern auszurollen, die den Bezeichnungen entsprechen. Wir können auch filtern, indem wir zum Beispiel sagen, dass wir die Anwendung nur auf den Clustern ausrollen, die env=development && networking=true && ingress-controller=nginx enthalten.
Das Cockpit sieht wie folgt aus:
Die Nachteile sind zum Beispiel, dass Sie nur maximal zwei Generatoren kombinieren können. Außerdem können Helm und Kustomize an dieser Stelle nicht kombiniert werden. Argo versucht dann, beide Manifeste mit Helm und einmal mit Kustomize zu rendern, weiß aber nicht, welches angewendet werden soll. Es ist auch nicht möglich, die Manifeste nachzupatchen.
Sie müssen dann komplexe Lösungen wie Post-Hooks definieren, um die Ressourcen anschließend zu patchen. Dies war für uns eine besondere Herausforderung, als wir von Pod-Sicherheitsrichtlinien auf Pod-Sicherheitsstandards umstellten. Die meisten Tools von Drittanbietern hatten den erforderlichen Sicherheitskontext noch nicht implementiert.
In Sveltos werden die CustomResourceDefinitions Profile oder ClusterProfiles genannt. Wir erstellen ein ClusterProfile, weil wir als Administratoren die Profile in allen Clustern abgleichen wollen.
Diese sehen dann wie folgt aus:
apiVersion: config.projectsveltos.io/v1alpha1
kind: ClusterProfile
metadata:
name: kyverno
spec:
clusterSelector: env=prod
syncMode: Continuous
helmCharts:
- repositoryURL: https://kyverno.github.io/kyverno/
repositoryName: kyverno
chartName: kyverno/kyverno
chartVersion: v3.1.4
releaseName: kyverno-latest
releaseNamespace: kyverno
helmChartAction: InstallWir haben die Beziehung über die Labels festgelegt und anschließend eine Liste von Helm-Charts angegeben, die von oben nach unten in dieser Reihenfolge verarbeitet wird. Hier verwenden wir Kyverno als Beispiel, da wir den Ingress-NGINX-Controller bereits über Argo CD ausgerollt haben.
Dann können wir das Addon wie folgt sehen:
sveltosctl show addonsMögliche Ausgabe:
+-----------------------------------------------------+---------------+-----------+----------------+---------+--------------------------------+------------------------+
| CLUSTER | RESOURCE TYPE | NAMESPACE | NAME | VERSION | TIME | PROFILES |
+-----------------------------------------------------+---------------+-----------+----------------+---------+--------------------------------+------------------------+
| aks-vengeance-development/aks-vengeance-development | helm chart | kyverno | kyverno-latest | 3.1.4 | 2024-04-19 19:33:47 +0200 CEST | ClusterProfile/kyverno |
+-----------------------------------------------------+---------------+-----------+----------------+---------+--------------------------------+------------------------+Sveltos legt von Grund auf einen starken Fokus auf Multi-Tenancy, was an vielen Stellen erkennbar ist, z. B. in der Verwaltung über namensraumbezogene Profile, wie in Abbildung 10 zu sehen ist.
Mit Argo CD ist es erst seit Version 2.10 möglich, die Anwendung in anderen Namespaces zu erstellen und nicht nur in einem Namespace.
Was noch?
As you can see, a blog series is necessary to make a detailed comparison. But that is not the aim of the blog. I would like to share the experience we have had with Argo CD for around 2 years and the challenges we have faced.
Deshalb habe ich den Rest in Punkte unterteilt und werde unsere Erfahrungen in 2–3 Sätzen teilen.
- Beobachtbarkeit (Benachrichtigungen): Argo CD ist sehr vereinfacht und kann über eine ConfigMap gesteuert werden, sodass die Alarmregeln ziemlich lang sind. Aus diesem Grund verzichten wir an dieser Stelle auf die Alarmregeln und verwenden stattdessen einen Observability-Stack. Sveltos bietet hier deutlich mehr und erweitert den Bereich mit CRDs, die die Handhabung erleichtern. Außerdem stellt Sveltos verschiedene Endpunkte für Benachrichtigungen zur Verfügung, wie Teams, Discord, Slack usw.
- UI: Das UI von Argo CD ist großartig, es erleichtert den Einstieg, besonders für Entwickler, die neu auf diesem Gebiet sind. Es enthält alle notwendigen Informationen, und der Login über einen OIDC-Provider wie Azure funktioniert bei uns ebenfalls einwandfrei. Derzeit fehlt mir dieser Teil bei Sveltos, aber er wird vermutlich irgendwann kommen.
- Templating/Patching-Einschränkungen: Ich hatte bereits früher erklärt, dass wir Herausforderungen beim Patchen der gerenderten Ressourcen hatten. Sveltos scheint hier deutlich mehr zu bieten und stellt Helm-Charts, Kustomize, Jsonnet, YTT usw. zur Verfügung. Sveltos bietet auch Schnittstellen, um Ressourcen zu patchen, z.B. über eine ConfigMap. So können Ressourcen abgerufen werden, um beispielsweise eine Operation im Ziel-Cluster durchzuführen, wenn Anmeldedaten erstellt werden müssen, und diese dann direkt an das Management-Cluster weiterzugeben, damit weitere Operationen durchgeführt werden können. Das bedeutet, dass keine Zwischenschritte oder extra Tools erforderlich sind.
- Multi-Tenancy: Sveltos wurde direkt mit einem Multi-Tenancy-Konzept entwickelt, was sich zum Beispiel in den Profilen und Cluster-Profilen zur Bestimmung und Verwaltung von Tenants zeigt. Jeder, der schon einmal versucht hat, ein Multi-Tenancy-Setup mit Argo CD einzurichten, weiß, wie anstrengend und zeitaufwendig das ist.
- Ereignisse: Beide Tools bieten eine großartige Ereignis-Integration, obwohl Argo CD ein deutlich größeres Portfolio an Triggern bietet. Das liegt wahrscheinlich daran, dass Ereignisse stark in den Argo-Workflow-Ansatz integriert sind. Sveltos-Ereignisse sind auf das Wesentliche zugeschnitten, um Multi-Cluster zu verwalten.
Fazit
Zusammenfassend lässt sich sagen, dass Sveltos seine GitOps-Funktionen vollständig entfaltet, wenn es mit Flux CD kombiniert wird – eine entscheidende Kombination für uns als Platform Engineers, um GitOps in großem Maßstab zu ermöglichen. Zunächst könnte es für Neulinge schwierig sein, sich in Sveltos zurechtzufinden, da es keine Benutzeroberfläche gibt und man beim Integrieren mit GitOps gleichzeitig zwei Tools lernen muss. Doch es erfüllt genau den Zweck, für den es entwickelt wurde, nämlich Add-ons, die über Cluster verteilt sind, sicher und stabil über einen rekonzilierten Loop zu verwalten.
Ich bin optimistisch, dass Sveltos in den kommenden Monaten benutzerfreundlicher wird. Die Nutzung von Sveltos über CI/CD sollte meiner Meinung nach keine Hürden darstellen. Darüber hinaus unterstützt Sveltos von Natur aus Funktionen wie Multi-Tenancy, agentenbasierte Drift-Benachrichtigungen und -Synchronisation, um Ressourcen zu sparen, was aufgrund steigender Cloud- und On-Premise-Kosten immer wichtiger wird. Unser Ziel ist es, weitere Kostensteigerungen durch Engineering-Stunden zu vermeiden.
Es ist wichtig zu bedenken, dass Argo etwa 1.300 Mitwirkende hat und seit etwa 2018 existiert. Sveltos hingegen hat etwa fünf Mitwirkende, ist seit etwa 2022 auf dem Markt und vollständig Open Source. Trotzdem haben die Sveltos-Mitarbeiter bemerkenswerte Arbeit geleistet und ein robustes Tool auf den Markt gebracht.
Ich freue mich auf die zukünftigen Entwicklungen und bin dankbar für die neuen Perspektiven und Erkenntnisse, die durch Sveltos gewonnen wurden. Gianluca ist sehr aufgeschlossen für Feedback und setzt Lösungen schnell um, also zögert nicht, euch einzubringen und eure Ideen zu teilen. Vergesst nicht, einen STAR 🌟 zu hinterlassen!
Kontaktinformationen
Wenn du mehr über GitOps erfahren möchtest dann kontaktiere uns hier oder füge mich einfach in dein LinkedIn-Netzwerk hinzu!
