TL;DR

Ab drei Kubernetes-Clustern brauchst du Fleet Management. ArgoCD ApplicationSets deployen Workloads automatisch auf alle registrierten Cluster. Rancher Fleet synchronisiert Git-Repos clusterübergreifend. Wähle Hub-Spoke für zentrale Kontrolle oder Mesh für autonome Teams. Drift-Erkennung verhindert Konfigurationsabweichungen zwischen Clustern.

Multi-Cluster Management für Kubernetes

Ein Cluster reicht — bis er nicht mehr reicht. Compliance fordert Regionstrennung, Dev und Prod müssen isoliert sein, oder Edge-Standorte brauchen eigene Cluster. Plötzlich verwaltest du fünf Cluster und jede Änderung wird fünfmal manuell ausgerollt.

So listest du alle Cluster in deinem ArgoCD auf:

# Registrierte Cluster anzeigen
argocd cluster list

# Neuen Cluster hinzufügen
argocd cluster add staging-eu-west \
  --kubeconfig ~/.kube/staging-eu-west.yaml

Wann Multi-Cluster Sinn ergibt

Nicht jedes Setup braucht mehrere Cluster. Hier die typischen Treiber:

Faustregel: Wenn du denselben Helm-Chart in mehr als zwei Cluster manuell installierst, ist es Zeit für Fleet Management.

Hub-Spoke vs. Mesh-Topologie

Hub-Spoke setzt auf einen zentralen Management-Cluster. Alle Deployments laufen über diesen Hub. Rancher und ArgoCD arbeiten standardmäßig so. Vorteil: eine zentrale Quelle der Wahrheit. Nachteil: der Hub ist ein Single Point of Failure.

Mesh-Topologie verteilt die Kontrolle. Jeder Cluster synchronisiert sich eigenständig mit einem Git-Repository. Flux eignet sich dafür besonders gut. Vorteil: kein SPOF. Nachteil: schwierigere Gesamtübersicht.

Für die meisten Teams funktioniert Hub-Spoke besser, weil es einfacher zu debuggen ist.

ArgoCD ApplicationSets für Multi-Cluster

ApplicationSets sind der Multiplikator in ArgoCD. Statt pro Cluster eine Application zu definieren, beschreibst du ein Template und ArgoCD generiert die Applications automatisch.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: nginx-fleet
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'nginx-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://git.example.com/platform/apps.git
        targetRevision: main
        path: 'apps/nginx/overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: web
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true

Der clusters-Generator iteriert über alle in ArgoCD registrierten Cluster mit dem Label env: production. Für jeden Cluster wird eine eigene Application erstellt. Das {{metadata.labels.region}}-Feld erlaubt regionale Kustomize-Overlays — EU-Cluster bekommen andere ConfigMaps als US-Cluster.

Cluster-Labels setzen

# Label für Region und Environment setzen
argocd cluster set staging-eu-west \
  --label env=staging \
  --label region=eu-west

argocd cluster set prod-eu-central \
  --label env=production \
  --label region=eu-central

Rancher Fleet: GitOps für Cluster-Flotten

Rancher Fleet geht einen anderen Weg. Statt Applications definierst du GitRepo-Objekte, die auf ein Repository zeigen. Fleet synchronisiert den Inhalt auf ausgewählte Cluster-Gruppen.

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: platform-base
  namespace: fleet-default
spec:
  repo: https://git.example.com/platform/base-config.git
  branch: main
  paths:
    - /monitoring
    - /logging
    - /network-policies
  targets:
    - name: production
      clusterSelector:
        matchLabels:
          env: production
    - name: staging
      clusterSelector:
        matchLabels:
          env: staging
      helm:
        values:
          replicas: 1
          resources:
            requests:
              memory: 256Mi

Fleet erlaubt es, pro Target unterschiedliche Helm-Values zu setzen. Staging bekommt reduzierte Ressourcen, Production die vollen Werte aus dem Repository.

Configuration Drift erkennen

Drift entsteht, wenn jemand kubectl edit auf einem Cluster ausführt, ohne das Git-Repository zu aktualisieren. Bei einem einzelnen Cluster fällt das schnell auf. Bei zehn Clustern nicht.

ArgoCD zeigt Drift direkt im UI als "OutOfSync" an, wenn selfHeal aktiviert ist. Für systematisches Monitoring:

# Alle Applications mit Drift finden
argocd app list -o json | \
  jq -r '.[] | select(.status.sync.status != "Synced") |
  "\(.metadata.name): \(.status.sync.status)"'

# Drift-Details für eine Application
argocd app diff nginx-prod-eu-central

Ohne GitOps-Tool hilft ein CronJob, der kubectl diff gegen die gewünschte Konfiguration laufen lässt und bei Abweichungen alarmiert.

Tool-Vergleich

FAQ

Ab wie vielen Clustern lohnt sich Fleet Management?

Ab drei Clustern wird manuelles Management fehleranfällig. Bei zwei Clustern (Dev/Prod) reicht oft ein einfaches CI/CD-Pipeline-Setup mit getrennten Deployment-Stages.

Kann ich ArgoCD und Rancher Fleet kombinieren?

Technisch ja, aber es erzeugt Konflikte wenn beide dasselbe Deployment verwalten. Besser: ArgoCD für Application Delivery, Fleet nur für Cluster-Basiskonfiguration wie Network Policies und Monitoring.

Was passiert wenn der Hub-Cluster ausfällt?

Die Workloads auf den Spoke-Clustern laufen weiter. Nur neue Deployments und Sync-Operationen stoppen. Deshalb: Hub-Cluster hochverfügbar betreiben und regelmäßig Backups machen.

Wie handle ich Secrets über mehrere Cluster?

Sealed Secrets oder External Secrets Operator pro Cluster installieren. Secrets sollten nie im Git-Repository liegen. External Secrets kann zentrale Vaults (HashiCorp Vault, AWS Secrets Manager) nutzen und in jedem Cluster die Secrets lokal erzeugen.

Nächster Schritt: Starte mit ArgoCD ApplicationSets und zwei Clustern (Staging + Production). Registriere beide Cluster, setze Labels und erstelle dein erstes ApplicationSet. Der Aufwand für das Setup ist gering, der Gewinn bei jeder weiteren Anwendung sofort spürbar.