▸ saaro:~/blog ▊ Notizen & Artikel
← zurück

📷 "599 - Network connect timeout error" by GirlieMac is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

Multi-Cluster-GitOps mit ArgoCD 2026: ApplicationSets, Architektur und bewährte Praktiken

03. September 2026 · 3 min · Martin Jochum #ArgoCD#GitOps#Kubernetes#Multi-Cluster#DevOps

Die Verwaltung mehrerer Kubernetes-Cluster ist für die meisten Unternehmen längst Realität: Laut aktuellen Umfragen betreiben Enterprise-Organisationen im Jahr 2026 zwischen fünf und fünfzig Kubernetes-Cluster parallel – für unterschiedliche Umgebungen, Regionen oder Compliance-Anforderungen. Mit dieser Vervielfachung der Cluster wächst die Komplexität der Deployment-Prozesse exponentiell. Genau hier setzt GitOps mit ArgoCD an: Was als Tool für einzelne Cluster begann, hat sich zur zentralen Plattform für Multi-Cluster-Deployments entwickelt.

Architektur-Paradigmen: Hub-and-Spoke vs. Federated

Im Multi-Cluster-Kontext stehen zwei grundlegende Architekturmuster zur Wahl:

Hub-and-Spoke (zentralisiert): Eine einzelne ArgoCD-Instanz in einem Management-Cluster verwaltet mehrere Ziel-Cluster. Dieses Modell bietet eine zentrale Sicht auf alle Umgebungen, vereinfacht RBAC und erlaubt globale Policy-Steuerung aus einem Dashboard. Der Nachteil: Der Management-Cluster besitzt hochprivilegierte Credentials für alle verwalteten Cluster – ein Sicherheitsrisiko, das durch VPC-Peering, private Endpunkte und externe Secret-Manager gehärtet werden muss.

Federated (dezentral): Jeder Cluster betreibt seine eigene ArgoCD-Instanz, gesteuert von einer Meta-ArgoCD-Ebene. Dieses Modell eignet sich für Organisationen mit mehr als 20 Clustern, strikten Netzwerk-Isolationen oder Teams, die volle Autonomie benötigen. Der Credential-Blast-Radius bleibt auf den einzelnen Cluster beschränkt.

Die Wahl zwischen beiden hängt maßgeblich von der Cluster-Anzahl, den Sicherheitsanforderungen und der Team-Struktur ab.

ApplicationSets: Der Schlüssel zur Multi-Cluster-Automatisierung

Das Herzstück der Multi-Cluster-Fähigkeiten von ArgoCD sind ApplicationSets. Sie erzeugen aus einer Vorlage und einem Generator dynamisch mehrere Application-Ressourcen – eine pro Cluster, eine pro Git-Verzeichnis oder eine pro Team.

Die wichtigsten Generator-Typen im Überblick:

List-Generator: Explizite Aufzählung von Ziel-Umgebungen. Ideal für kleine, stabile Cluster-Sets.

generators:
  - list:
      elements:
        - cluster: staging
          url: https://k8s-staging.example.com
          values.replicas: "1"
        - cluster: production
          url: https://k8s-prod.example.com
          values.replicas: "3"

Cluster-Generator: Erzeugt automatisch ein Application pro registriertem Cluster. Neue Cluster werden über Labels wie environment=production selektiert. Sobald ein Cluster in ArgoCD registriert und gelabelt wird, deployt das ApplicationSet die definierte Anwendung automatisch – ohne manuelles Eingreifen.

Git-Generator (Directory-Mode): Erzeugt ein Application pro Unterverzeichnis im Git-Repository. Das ermöglicht Self-Service-Onboarding: Ein Team fügt ein neues Verzeichnis apps/neuer-service/ hinzu, und ArgoCD erstellt und synchronisiert die zugehörige Application automatisch.

Matrix-Generator: Bildet das kartesische Produkt aus zwei Generatoren. Damit lassen sich alle Anwendungen auf allen Clustern deployen, ohne jede Kombination einzeln definieren zu müssen. Beispiel: 5 Cluster × 8 Anwendungen = 40 Applications aus einem einzigen ApplicationSet.

Merge-Generator: Überschreibt Basiswerte für bestimmte Cluster. So erhalten etwa High-Traffic-Cluster mehr Replicas oder größere Ressourcenkontingente, während die Basis-Konfiguration für alle anderen Cluster gleich bleibt.

Sicherheit im Multi-Cluster-Betrieb

Die Verwaltung mehrerer Cluster erhöht die Angriffsfläche erheblich. Bewährte Praktiken umfassen:

  • Dedizierte Service-Accounts mit minimalen Berechtigungen pro Cluster
  • Private API-Endpunkte – Kubernetes-APIs niemals öffentlich exponieren
  • Regelmäßige Credential-Rotation für alle Cluster-Zugänge
  • Namespace-Isolation durch ArgoCD-Projekte, die Ziel-Cluster und Namespaces begrenzen

ArgoCD 3.3 hat 2026 zudem wichtige Sicherheitsverbesserungen gebracht, darunter PreDelete-Hooks für kontrollierte Application-Löschungen und einen verbesserten OIDC-Token-Refresh, der Session-Timeouts in langen Monitoring-Sessions verhindert.

GitOps im Produktionseinsatz 2026

GitOps hat sich als Standard für Kubernetes-Deployments etabliert – über 64 % der Unternehmen setzen es laut Umfragen als primäre Delivery-Methode ein. ArgoCD führt den Markt mit seiner visuellen Application-Topologie, den ApplicationSets und dem breiten Ökosystem (Argo Rollouts, Workflows, Events, Image Updater) an. Die Konkurrenz durch FluxCD ist im dezentralen und Edge-Bereich stark, doch für zentral gesteuerte Multi-Cluster-Umgebungen bleibt ArgoCD die erste Wahl.

Die Herausforderung verschiebt sich 2026 zunehmend von der Frage “ArgoCD oder Flux?” hin zu “Wie betreiben wir GitOps im Fleet-Maßstab?” – mit Fokus auf OCI/Helm-Maturität, Progressive Delivery und Multi-Cluster-Konsistenz.

Fazit

Multi-Cluster-GitOps mit ArgoCD ist kein Nice-to-have mehr, sondern eine betriebliche Notwendigkeit für Unternehmen, die Kubernetes im größeren Stil betreiben. ApplicationSets sind das entscheidende Werkzeug, um diese Komplexität zu beherrschen – sie machen Deployment-Prozesse skalierbar, nachvollziehbar und sicher. Die Wahl der richtigen Architektur (Hub-and-Spoke vs. federated) sollte dabei immer anhand der konkreten Sicherheitsanforderungen, Cluster-Anzahl und Teamstruktur getroffen werden.

Quellen

🤖 Dieser Beitrag wurde KI-gestützt erstellt und redaktionell geprüft.