Flux passe à l’échelle sur de nombreux clusters en exécutant un jeu de contrôleurs dans chaque cluster, tous suivant le même dépôt Git à des chemins différents. Il n’y a pas de hub central auprès duquel enregistrer les clusters. Ce guide montre comment organiser un dépôt unique pour le staging et la production, bootstrapper chaque cluster, ordonner l’infrastructure avant les applications, et quand utiliser plutôt une configuration à clusters distants.

Un dépôt, un chemin par cluster

Flux suit une règle simple : chaque cluster est bootstrappé sur son propre dossier sous clusters/. Un dépôt servant deux clusters ressemble à ceci :

fleet-infra/
├── clusters/
│   ├── staging/
│   │   ├── flux-system/        # créé par le bootstrap
│   │   ├── infrastructure.yaml
│   │   └── apps.yaml
│   └── production/
│       ├── flux-system/
│       ├── infrastructure.yaml
│       └── apps.yaml
├── infrastructure/
│   ├── base/                   # partagé : ingress, cert-manager, monitoring
│   ├── staging/
│   └── production/
└── apps/
    ├── base/
    ├── staging/
    └── production/

Les définitions partagées vivent dans les dossiers base/, et chaque dossier d’environnement contient l’overlay Kustomize pour ce qui diffère (voir le guide sur les overlays).

Bootstrapper chaque cluster

Basculez votre contexte kubectl sur chaque cluster tour à tour et lancez le bootstrap sur le même dépôt avec un chemin différent :

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

Chaque cluster a maintenant sa propre installation de Flux et son propre dossier flux-system dans Git. Ajouter un troisième cluster plus tard se résume à une commande de bootstrap supplémentaire avec un nouveau chemin.

Pointer chaque cluster vers ses propres overlays

clusters/production/apps.yaml applique l’overlay de production :

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 est identique, à l’exception de path: ./apps/staging. La Kustomization infrastructure pointe de la même façon vers ./infrastructure/<env>, et a wait: true pour que les applications ne démarrent qu’une fois l’ingress controller, le gestionnaire de certificats et les composants similaires prêts. Le champ dependsOn est ce qui impose cet ordre.

Vérifier sur l’ensemble des clusters

Flux n’a pas de tableau de bord central, vérifiez donc chaque cluster depuis son propre contexte :

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

Les deux devraient afficher Ready. Comparez ce que Git dit être déployé avec ce que chaque cluster rapporte, à l’aide de flux tree et flux get all -A. Pour une visibilité à l’échelle de la flotte, les équipes collectent souvent les métriques Prometheus de Flux dans Grafana.

Promouvoir du staging vers la production

Comme les deux clusters lisent le même dépôt, la promotion est un commit. Un flux courant :

1. Modifier apps/staging et laisser Flux l’appliquer au cluster de staging.
2. Tester et vérifier.
3. Faire la même modification dans apps/production via une pull request relue, ou tagger une release que le GitRepository de production suit (voir le guide sur les overlays).

Alternative : un cluster de contrôle, de nombreux clusters distants

Plutôt que d’exécuter Flux dans chaque cluster, vous pouvez l’exécuter à un seul endroit et faire appliquer ses Kustomizations et HelmReleases à d’autres clusters. Définissez spec.kubeConfig sur la ressource avec un Secret qui contient le kubeconfig du cluster distant :

spec:
  kubeConfig:
    secretRef:
      name: production-kubeconfig

Cela centralise le contrôle, mais place aussi les identifiants de chaque cluster dans le cluster de contrôle. C’est différent du modèle habituel de Flux, où les identifiants ne quittent jamais chaque cluster et où un cluster compromis ne peut pas atteindre les autres. Préférez une installation de Flux par cluster, sauf si vous avez une raison claire de centraliser, comme des clusters edge légers. Si vous choisissez cette voie, utilisez l’identité de workload cloud plutôt que des kubeconfigs de longue durée là où votre plateforme le permet, et regardez le Flux Operator pour gérer des flottes à grande échelle.

Bonnes habitudes

• Gardez le dossier flux-system de chaque cluster hors des overlays partagés. Le bootstrap en est propriétaire.
• Utilisez dependsOn pour que l’infrastructure, les CRD et les contrôleurs s’installent avant les applications qui en ont besoin.
• Donnez à chaque cluster sa propre clé SOPS (voir le guide sur les secrets) pour que le staging ne puisse pas déchiffrer les secrets de production.
• Mettez à niveau Flux un cluster à la fois, en commençant par un cluster hors production, en relançant flux bootstrap avec une CLI plus récente.