Les applications réelles tournent dans plusieurs environnements qui diffèrent légèrement : nombre de réplicas, noms d’hôte, valeurs de configuration. Flux applique du YAML brut ou des overlays Kustomize, et détecte lequel un dossier utilise. Ce guide montre comment structurer un dépôt pour plusieurs environnements avec Kustomize, comment informer Flux de chacun, et traite un piège qui piège les gens avec les changements de configuration. Il s’appuie sur l’exemple webapp des guides précédents.

Choisir une organisation : des dossiers, pas des branches

Vous pouvez modéliser les environnements comme des branches de longue durée (dev, staging, main), mais cela fait de la promotion un exercice de fusion et laisse les environnements dériver les uns des autres. Une seule branche avec un dossier par environnement est plus facile à raisonner : chaque environnement est visible côte à côte, et un changement dans l’un est un diff normal.

La documentation de Flux décrit trois stratégies de dépôt courantes :

• Monorepo. Tous les clusters, applications et l’infrastructure dans un seul dépôt. Le plus simple pour commencer, et celui utilisé ici.
• Un dépôt par environnement. Par exemple, un pour le staging et un pour la production, avec des règles d’accès distinctes.
• Un dépôt par équipe ou par application. Isolation forte, avec un dépôt plateforme qui enregistre le dépôt de chaque équipe.

Un monorepo typique ressemble à ceci :

fleet-infra/
├── clusters/
│   ├── dev/                 # Kustomizations Flux pour le cluster dev
│   └── production/          # Kustomizations Flux pour le cluster de production
├── infrastructure/          # ingress controller, cert-manager, monitoring
└── apps/
    ├── base/webapp/         # manifestes partagés
    ├── dev/                 # overlay pour le dev
    └── production/          # overlay pour la production

Construire une base et des overlays Kustomize

apps/base/webapp/kustomization.yaml liste les ressources partagées :

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml

Dans apps/base/webapp/deployment.yaml, faites lire à un conteneur ses paramètres depuis une ConfigMap que chaque overlay générera (laissez de côté le champ namespace dans la base, car les overlays le définissent) :

          envFrom:
            - configMapRef:
                name: webapp-config

apps/dev/kustomization.yaml :

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: webapp-dev
resources:
  - namespace.yaml
  - ../base/webapp
replicas:
  - name: webapp
    count: 2
configMapGenerator:
  - name: webapp-config
    literals:
      - HEADER=Hello from dev

avec un namespace.yaml qui crée webapp-dev. apps/production/kustomization.yaml est identique, avec namespace: webapp-prod, count: 4, son propre manifeste de namespace et sa propre valeur HEADER. Vous pouvez vérifier ce qu’un overlay génère avant de committer :

kustomize build apps/dev
# ou, sans installer kustomize séparément :
kubectl kustomize apps/dev

Pointer une Kustomization Flux vers chaque overlay

Flux détecte le kustomization.yaml dans le chemin et le construit pour vous. Dans le dossier de chaque cluster, ajoutez une Kustomization Flux par environnement. clusters/dev/apps.yaml :

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

Pour le cluster de production, clusters/production/apps.yaml utilise path: ./apps/production. Comme chaque cluster a été bootstrappé avec son propre --path, chaque cluster ne voit que son propre dossier.

Rendre la production délibérée

Contrairement aux outils dotés d’un bouton de synchronisation manuelle, Flux applique automatiquement, donc vous contrôlez la production via Git. Un schéma efficace consiste à laisser le dev suivre une branche et la production suivre des tags de release. Dans la source du cluster de production :

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: fleet-releases
  namespace: flux-system
spec:
  interval: 5m
  url: https://github.com/your-org/fleet-infra
  ref:
    semver: ">=1.0.0"

La production ne change alors que lorsque vous taguez une release. L’approbation de pull request sur la branche principale est l’autre contrôle courant.

Gérer volontairement les changements de configuration

Changez la valeur de HEADER dans un environnement et regardez ce qui se passe. Kustomize ajoute un hash du contenu aux noms de ConfigMap générées. Une nouvelle valeur produit une nouvelle ConfigMap (webapp-config-<hash>) et met à jour la référence du Deployment, ce qui déclenche un déploiement des Pods. L’ancienne ConfigMap est désormais orpheline, et avec prune: true Flux la supprime pour vous. Ce comportement est exactement ce que l’on veut : les changements de configuration font redémarrer les Pods.

Les ConfigMaps simples, écrites à la main, sont différentes. Si vous modifiez une ConfigMap qu’un Deployment lit via envFrom, la spec du Deployment ne change pas, et les Pods en cours d’exécution gardent donc les anciennes valeurs. Utilisez configMapGenerator pour tout ce qui doit redémarrer les workloads lorsqu’il change. Les charts Helm ont une technique équivalente, traitée dans le guide Helm.

Substituer des valeurs par cluster

Parfois une valeur diffère selon le cluster mais vous ne voulez pas d’un overlay entier pour elle, par exemple un nom de domaine. Les Kustomizations Flux peuvent substituer des variables après la construction :

spec:
  postBuild:
    substitute:
      cluster_domain: dev.example.com
    substituteFrom:
      - kind: ConfigMap
        name: cluster-vars

Tout ${cluster_domain} dans vos manifestes est remplacé au moment de l’application. Utilisez-le avec parcimonie, car les overlays sont plus faciles à relire.

Promouvoir les changements à travers les environnements

Avec cette organisation, la promotion est une suite de commits ordinaires. Modifiez d’abord l’overlay de dev (par exemple une montée de version d’image avec kustomize edit set image nginx=nginx:1.26 exécuté dans apps/dev), laissez Flux l’appliquer et vérifiez. Faites ensuite le même changement dans apps/production, via une pull request qui exige une approbation. Un pipeline CI peut automatiser le commit de dev, et un relecteur contrôle celui de production. L’image automation de Flux peut aussi faire l’étape de dev pour vous, ce que le guide sur l’automatisation d’images couvre.