Ein zentrales Cluster hält die Kubeconfigs der übrigen und schiebt den Desired State in sie hinein. Das funktioniert, solange es drei Cluster im selben Netzwerk sind. Auf der Größenordnung einer Bank, einer Versicherung oder einer Edge-Flotte bricht das Muster gleichzeitig an drei Stellen.
Wo Hub-and-Spoke bricht
Blast Radius. Der Hub hält eine Admin-Kubeconfig für jeden Spoke. Eine Kompromittierung irgendeiner Komponente des Steuer-Clusters ist eine Kompromittierung der gesamten Flotte, kein „Vorfall in einer Umgebung". Token-Rotation hilft kaum: Solange das Token gültig ist, hat der Hub vollen Zugriff auf Prod.
Netzwerkmodell. Der Hub braucht direkten Inbound-Zugriff auf den API-Server jedes Spokes. Auf AWS heißt das regionsübergreifende Security Groups und Peerings; auf Edge-Infrastruktur, wo der Spoke hinter NAT sitzt, funktioniert das ohne VPN oder Tunnel überhaupt nicht.
Compliance. Regulierte Branchen verbieten Inbound-Traffic in Produktions-Cluster aus jedem externen Netzwerk — und der Hub ist in diesem Bild extern. Eine Auditor-Anforderung, keine architektonische Einschränkung; Hub-and-Spoke umgeht diese Hürde nicht.
Dazu kommt eine operative Obergrenze: ein einzelner Application-Controller-Pod stößt bei 5000+ Applications an CPU- und Speichergrenzen. ArgoCD v3 (Anfang 2026) bringt Horizontal Scaling für den Controller; vorher shardet man über ARGOCD_CONTROLLER_REPLICAS mit Round-Robin nach Cluster-ID. Bei fünfzig Spokes mit jeweils Hunderten von Applications wird die Control Plane ohne Sharding zum Bottleneck.
Per-Cluster local
Jeder Cluster betreibt sein eigenes ArgoCD, das nur seinen Subset des GitOps-Repositorys beobachtet. Der Blast Radius einer Kompromittierung ist ein einzelnes Cluster. Das Netzwerkmodell ist trivial: ArgoCD ↔ K8s-API ist immer lokal, über https://kubernetes.default.svc. Sharding ist nicht nötig, weil 5000 Applications nie auf demselben Controller landen — sie sind physisch über Cluster verteilt.
Der Preis: keine zentrale Konsole und N Instanzen, die synchron aktualisiert werden müssen. Die ArgoCD-UI zeigt nur das lokale Cluster; der On-Call mit drei Prods hält drei Tabs offen. Der ApplicationSet-Matrix-Generator funktioniert lokal, aber nur mit genau zwei Child-Generatoren — mehr wird nicht mehr unterstützt. Das lokale Cluster muss zudem über ein explizites cluster-Secret mit eindeutigem Namen neu registriert werden, weil der Default-Eintrag in-cluster das Matching auf {{name}} kaputt macht.
Per-Cluster local gewinnt dort, wo Compliance Zentralisierung verbietet, das Netzwerk des Spokes nicht vertrauenswürdig ist und die Flotte ohnehin keine zentrale Audit-Konsole braucht.
Pull-Mode: die dritte Option
Sveltos Addon Controller im Pull-Mode (seit v1.0.0, gehärtet in v1.4.0) dreht die Richtung um: der Spoke initiiert eine Outbound-Verbindung zum Hub und zieht seinen Desired State. Der Hub hält keine Admin-Tokens der Spokes mehr — er hält SA-Tokens, mit denen der Spoke seine eigene Konfiguration vom Hub read-only abruft. Eine Hub-Kompromittierung wird zu einer Read-only-API-Kompromittierung, nicht zu Admin-Zugriff auf die Flotte.
Use Cases — regulierte Branchen (Banken, Healthcare), Edge und IoT (POS-Systeme, Factory Floors, Schiffe mit intermittierender Konnektivität), Air-Gapped-Umgebungen (nur Outbound), Multi-Cloud mit einem einheitlichen GitOps-Modell über AWS/GCP/Azure/On-Prem. ArgoCD Core bewegt sich in dieselbe Richtung über argocd-agent (KubeCon EU 2025) und die Akuity Platform, doch Anfang 2026 ist Sveltos Pull-Mode die reifste Produktionsimplementierung.
Wann welches Muster
Per-Cluster local — Air-Gapped, Edge, compliance-eingeschränkte Spokes, keine Netzwerkverbindung zwischen Clustern. Ein guter Default für ein Team, das kein zentrales Dashboard braucht.
Hub-and-Spoke — zentralisierte Governance, eine Flotte von bis zu einem Dutzend Clustern im selben Netzwerk, ein Team, das vom gemeinsamen UI profitiert. Planen Sie Controller-Sharding frühzeitig, wenn Sie auf 1000+ Applications zusteuern.
Pull-Mode — überall dort, wo Hub-and-Spoke an Compliance oder dem Netzwerkmodell bricht und Per-Cluster local wegen der Anforderung an eine zentrale Control Plane nicht passt.
Ein Hybrid ist tragfähig: ArgoCD Hub-and-Spoke für App-Delivery im vertrauten Segment, Sveltos Pull-Mode für das compliance-eingeschränkte Segment. Keine Startarchitektur, sondern ein Ergebnis der Evolution, wenn ein Teil der Flotte an den Edge oder in einen regulierten Perimeter wandert.
Ein gesonderter Fall ist Managed ArgoCD auf EKS Capabilities. AWS übernimmt Installation, Upgrades und HA; der Preis ist, dass Argo außerhalb des Clusters lebt, https://kubernetes.default.svc als Destination nicht funktioniert und EKS als Remote Target registriert werden muss. Identity Center ist Pflicht. Hub-and-Spoke mit Zero Ops am Hub selbst, aber mit denselben Compliance-Grenzen wie ein self-hosted Hub.