Flux skaliert auf viele Cluster, indem in jedem Cluster ein Satz Controller läuft, die alle demselben Git-Repository an unterschiedlichen Pfaden folgen. Es gibt keinen zentralen Hub, bei dem man Cluster registrieren müsste. Diese Anleitung zeigt, wie du ein einzelnes Repository für Staging und Produktion aufbaust, jeden Cluster bootstrapst, Infrastruktur vor Anwendungen ordnest und wann du stattdessen ein Remote-Cluster-Setup nutzt.

Ein Repository, ein Pfad pro Cluster

Flux folgt einer einfachen Regel: Jeder Cluster wird gegen seinen eigenen Ordner unter clusters/ gebootstrapt. Ein Repository für zwei Cluster sieht so aus:

fleet-infra/
├── clusters/
│   ├── staging/
│   │   ├── flux-system/        # von Bootstrap erzeugt
│   │   ├── infrastructure.yaml
│   │   └── apps.yaml
│   └── production/
│       ├── flux-system/
│       ├── infrastructure.yaml
│       └── apps.yaml
├── infrastructure/
│   ├── base/                   # gemeinsam: Ingress, cert-manager, Monitoring
│   ├── staging/
│   └── production/
└── apps/
    ├── base/
    ├── staging/
    └── production/

Gemeinsame Definitionen liegen in base/-Ordnern, und jeder Umgebungsordner enthält das Kustomize-Overlay für das, was sich unterscheidet (siehe die Anleitung zu Overlays).

Jeden Cluster bootstrappen

Wechsle nacheinander den kubectl-Kontext auf jeden Cluster und bootstrappe gegen dasselbe Repository mit einem anderen Pfad:

kubectl config use-context staging
flux bootstrap github --owner=<user> --repository=fleet-infra \
  --branch=main --path=clusters/staging --personal

kubectl config use-context production
flux bootstrap github --owner=<user> --repository=fleet-infra \
  --branch=main --path=clusters/production --personal

Jeder Cluster hat nun seine eigene Flux-Installation und seinen eigenen flux-system-Ordner in Git. Einen dritten Cluster später hinzuzufügen ist ein weiterer Bootstrap-Befehl mit neuem Pfad.

Jeden Cluster auf seine eigenen Overlays ausrichten

clusters/production/apps.yaml wendet das Produktions-Overlay an:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 10m
  dependsOn:
    - name: infrastructure
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./apps/production
  prune: true
  wait: true

clusters/staging/apps.yaml ist identisch bis auf path: ./apps/staging. Die Kustomization infrastructure zeigt ebenso auf ./infrastructure/<env> und hat wait: true, sodass Anwendungen erst starten, wenn der Ingress-Controller, der Zertifikatsmanager und ähnliche Komponenten bereit sind. Das Feld dependsOn erzwingt diese Reihenfolge.

Über Cluster hinweg prüfen

Flux hat kein zentrales Dashboard, prüfe also jeden Cluster aus seinem eigenen Kontext:

flux get kustomizations --context staging
flux get kustomizations --context production

Beide sollten Ready zeigen. Vergleiche mit flux tree und flux get all -A, was laut Git deployt ist, mit dem, was jeder Cluster meldet. Für flottenweite Sichtbarkeit sammeln Teams oft Fluxs Prometheus-Metriken in Grafana.

Von Staging in die Produktion befördern

Weil beide Cluster dasselbe Repository lesen, ist Promotion ein Commit. Ein üblicher Ablauf ist:

1. Ändere apps/staging und lass Flux es auf den Staging-Cluster anwenden.
2. Teste und prüfe.
3. Mache dieselbe Änderung in apps/production in einem geprüften Pull Request, oder tagge ein Release, dem die GitRepository der Produktion folgt (siehe die Anleitung zu Overlays).

Alternative: ein Steuer-Cluster, viele Remote-Cluster

Statt Flux in jedem Cluster zu betreiben, kannst du es an einer Stelle betreiben und seine Kustomizations und HelmReleases auf andere Cluster anwenden lassen. Setze spec.kubeConfig der Ressource auf ein Secret, das die kubeconfig des Remote-Clusters enthält:

spec:
  kubeConfig:
    secretRef:
      name: production-kubeconfig

Das zentralisiert die Kontrolle, legt aber auch die Zugangsdaten jedes Clusters im Steuer-Cluster ab. Das unterscheidet sich vom üblichen Flux-Modell, bei dem Zugangsdaten nie einen Cluster verlassen und ein kompromittierter Cluster die anderen nicht erreichen kann. Bevorzuge eine Flux-Installation pro Cluster, sofern du keinen klaren Grund zur Zentralisierung hast, etwa leichtgewichtige Edge-Cluster. Gehst du diesen Weg, nutze statt langlebiger kubeconfigs Cloud Workload Identity, wo deine Plattform das unterstützt, und sieh dir den Flux Operator an, um Flotten im großen Maßstab zu verwalten.

Gute Gewohnheiten

• Halte den flux-system-Ordner jedes Clusters aus gemeinsamen Overlays heraus. Bootstrap besitzt ihn.
• Nutze dependsOn, damit Infrastruktur, CRDs und Controller vor den Anwendungen installiert werden, die sie brauchen.
• Gib jedem Cluster einen eigenen SOPS-Schlüssel (siehe die Anleitung zu Secrets), damit Staging die Secrets der Produktion nicht entschlüsseln kann.
• Upgrade Flux einen Cluster nach dem anderen, beginnend mit einem Nicht-Produktions-Cluster, indem du flux bootstrap mit einer neueren CLI erneut ausführst.