Flux CD — Concepts et architecture

Flux CD fonctionne comme un gardien permanent de votre cluster Kubernetes : il compare en continu l’état souhaité (décrit dans Git) avec l’état réel (ce qui tourne dans le cluster) et corrige automatiquement les écarts. Ce guide explique comment ce mécanisme fonctionne, pourquoi l’architecture modulaire de Flux est différente d’ArgoCD, et quels objets Flux introduit dans votre cluster.

Guide précédent recommandé

Ce guide suppose que vous connaissez les principes GitOps (modèle pull, séparation CI/CD, réconciliation). Si ce n’est pas encore le cas, lisez d’abord Comprendre le GitOps.

Ce que vous allez apprendre

• Le modèle Sources-Artefacts-Consumers : comment Flux découpe les responsabilités entre contrôleurs
• Les 5 contrôleurs de Flux et le rôle précis de chacun
• La boucle de réconciliation : desired state, live state, drift et auto-healing
• Les objets clés : GitRepository, Kustomization, HelmRelease, ImagePolicy
• Comment Flux bootstrap se gère lui-même depuis Git

Qu’est-ce que Flux CD ?

Flux CD est un toolkit GitOps open source — un ensemble d’opérateurs Kubernetes qui maintiennent votre cluster synchronisé avec des sources Git ou OCI. Il fait partie de la CNCF (Cloud Native Computing Foundation) et a atteint le statut Graduated en novembre 2022.

L’analogie : Imaginez un chef d’orchestre qui lit en permanence la partition (votre dépôt Git) et s’assure que chaque musicien (composant Kubernetes) joue exactement ce qui est écrit. Si un musicien improvise (drift dans le cluster), le chef le ramène à la partition.

Ce qui distingue Flux d’un helm upgrade ou d’un kubectl apply en pipeline :

Approche	Fréquence	Supervision	Drift
kubectl apply en CI	À chaque push	Aucune	Invisible
helm upgrade en CI	À chaque push	Aucune	Invisible
Flux	En continu (toutes les minutes)	Permanente	Détecté + corrigé

Glissez pour voir

L’architecture modulaire de Flux

Flux n’est pas une application monolithique. C’est un ensemble de contrôleurs indépendants qui communiquent via des ressources Kubernetes (les CRDs). Chaque contrôleur a une responsabilité unique.

Cette modularité a plusieurs avantages :

• Vous n’installez que les contrôleurs dont vous avez besoin.
• Chaque contrôleur peut être mis à jour indépendamment.
• Les pannes sont isolées : un contrôleur défaillant n’affecte pas les autres.

Le modèle Sources-Artefacts-Consumers

Le flux de données dans Flux suit toujours le même schéma :

Source (Git, OCI, Helm) → Artefact (archive locale) → Consumer (Kustomize, Helm)

1. Un Source Controller surveille une source externe (dépôt Git, registre OCI, dépôt Helm) et télécharge son contenu dans une archive locale.
2. Cette archive est mise à disposition des contrôleurs consommateurs (kustomize-controller, helm-controller).
3. Les contrôleurs consommateurs appliquent le contenu de l’archive sur le cluster.

Ce découplage est essentiel : si le dépôt Git est temporairement inaccessible, les contrôleurs consommateurs continuent de travailler depuis la dernière archive téléchargée.

Les 5 contrôleurs de Flux

source-controller

Rôle : surveille des sources externes et produit des artefacts locaux.

Il gère les CRDs suivants :

CRD	Source surveillée
GitRepository	Dépôt Git (GitHub, GitLab, Gitea…)
OCIRepository	Artefact OCI (image ou archive)
HelmRepository	Index de charts Helm (index.yaml)
HelmChart	Un chart spécifique dans un HelmRepository
Bucket	Objet S3 ou GCS

Glissez pour voir

Quand une source change (nouveau commit, nouveau tag), source-controller télécharge l’archive et notifie les contrôleurs consommateurs.

kustomize-controller

Rôle : applique des répertoires de manifestes Kubernetes sur le cluster, avec ou sans overlays Kustomize.

Son CRD principal est Kustomization (noter la majuscule — c’est le CRD Flux, différent du kustomization.yaml de l’outil Kustomize). Une Kustomization Flux déclare :

• Quelle source utiliser (sourceRef)
• Quel chemin dans la source (path)
• Dans quel namespace déployer (targetNamespace)
• Si les ressources supprimées de Git doivent être supprimées du cluster (prune)

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: my-app
  namespace: flux-system
spec:
  interval: 5m
  path: ./apps/my-app
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet-infra
  targetNamespace: my-app

prune: true est important

Sans prune: true, les ressources supprimées de votre dépôt Git restent dans le cluster indéfiniment. Activez-le dès le départ pour éviter l’accumulation de ressources orphelines.

helm-controller

Rôle : gère le cycle de vie complet des releases Helm (install, upgrade, rollback) de façon déclarative.

Son CRD principal est HelmRelease. Il déclare quelle version d’un chart installer, avec quelles valeurs, et quelle stratégie appliquer en cas d’échec (retry, rollback, uninstall).

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: nginx
  namespace: web
spec:
  interval: 5m
  chart:
    spec:
      chart: nginx
      version: ">=1.0.0"
      sourceRef:
        kind: HelmRepository
        name: bitnami
  values:
    replicaCount: 2

La différence avec helm upgrade --install en pipeline : HelmRelease surveille en permanence l’état de la release et la reconcile si elle dérive.

notification-controller

Rôle : envoie des notifications sur les événements Flux (sync réussi, erreur, drift détecté) et reçoit des webhooks entrants.

Il gère trois CRDs :

CRD	Rôle
Provider	Canal de notification : Slack, Teams, PagerDuty, webhook générique…
Alert	Règle : quels événements de quels objets envoyer à quel Provider
Receiver	Endpoint webhook entrant : reçoit un push GitHub/GitLab pour déclencher une reconcile immédiate

Glissez pour voir

image-reflector-controller et image-automation-controller

Ces deux contrôleurs travaillent ensemble pour automatiser les mises à jour d’images dans votre config-repo.

image-reflector-controller surveille un registre de conteneurs et stocke la liste des tags disponibles dans le cluster (objets ImageRepository et ImagePolicy).

image-automation-controller lit les politiques d’image et met à jour le dépôt Git avec le tag sélectionné — sans intervention humaine.

Ce flux permet à Flux de détecter qu’une nouvelle image v1.2.3 est disponible, la valider contre une politique semver, et pousser la mise à jour dans Git. Flux se réconcilie ensuite automatiquement.

La boucle de réconciliation

Le cœur de Flux est une boucle de contrôle (control loop), décrite par les principes GitOps OpenGitOps. Elle effectue ces étapes en permanence :

1. OBSERVE  → Le source-controller pull la source (Git, OCI, Helm)
2. DIFF     → Comparer le desired state (Git) avec le live state (cluster)
3. ACT      → Si différents, appliquer les manifestes sur le cluster
4. REPEAT   → Reprendre au prochain interval (default: 1m)

Desired state vs Live state

Terme	Définition	Où ça vit
Desired state	Ce que vous voulez (décrit dans Git)	Dépôt Git
Live state	Ce qui tourne réellement	Cluster Kubernetes
Drift	Écart entre les deux states	Détecté par Flux

Glissez pour voir

Le drift peut survenir pour plusieurs raisons : modification manuelle d’une ressource avec kubectl edit, rollback par une autre solution, ou mise à jour automatique par un autre outil. Flux détecte et corrige le drift selon la politique définie (prune: true, force: true…).

Intervalles et webhooks

Flux reconcile les sources à deux moments :

1. À intervalles réguliers : définis dans spec.interval de chaque ressource (défaut 1 minute pour les Kustomizations, 5 minutes pour les sources). Cela garantit la réconciliation même sans notification.
2. Sur webhook : un push GitHub/GitLab peut déclencher une reconcile immédiate via le Receiver. Cela réduit la latence de déploiement à quelques secondes.

Le bootstrap : Flux se gère lui-même

Le bootstrap est la commande initiale qui :

1. Génère les manifestes des composants Flux (les 5 contrôleurs + RBAC).
2. Les pousse dans votre dépôt Git (dans clusters/<nom>/flux-system/).
3. Les applique sur votre cluster.

Après le bootstrap, Flux surveille son propre namespace : si vous modifiez les manifestes Flux dans Git, Flux se met à jour lui-même. C’est ce qu’on appelle la self-management ou GitOps pour Flux lui-même.

# Ce que Flux crée dans clusters/my-cluster/flux-system/
gotk-components.yaml   # CRDs + Deployments des 5 contrôleurs
gotk-sync.yaml         # GitRepository + Kustomization qui surveillent le repo
kustomization.yaml     # kustomization.yaml Kustomize (assemblage des deux)

Un seul dépôt ou deux ?

Un seul dépôt Git peut contenir à la fois le code source et les manifestes Kubernetes. En pratique, la séparation en deux dépôts (app-repo + config-repo) est fortement recommandée en production : cela permet d’avoir des droits différents sur chacun, et d’éviter que la CI touche les manifestes de production.

Comparaison des objets Flux vs ArgoCD

Concept	Flux CD	ArgoCD
Unité de déploiement	Kustomization + HelmRelease	Application
Périmètre d’equipe	Namespace + RBAC natif	AppProject
Générer plusieurs apps	Kustomization multi-path	ApplicationSet
Source de manifestes	GitRepository, OCIRepository	Source dans Application
Source de charts Helm	HelmRepository + HelmChart	Source dans Application
Mise à jour d’images	ImagePolicy + ImageUpdateAutomation	Argo CD Image Updater (plugin)
Notifications	Alert + Provider	Notifications intégrées dans l’UI

Glissez pour voir

Pièges courants sur les concepts

Confondre Kustomization (Flux) et kustomization.yaml (Kustomize)

Le CRD Flux Kustomization est différent du fichier kustomization.yaml de l’outil Kustomize. Le premier est une ressource Kubernetes qui déclare quoi réconcilier. Le second est un fichier de configuration de l’outil CLI kustomize. Les deux peuvent coexister dans votre dépôt sans conflit.

Croire que Flux nécessite Kustomize

Non. Une Kustomization Flux peut pointer vers un répertoire de YAML bruts (sans kustomization.yaml). Flux applique alors les manifestes directement avec kubectl apply. Kustomize n’est utilisé que si un kustomization.yaml est présent dans le chemin cible.

Confondre l’intervalle de la Source et l’intervalle de la Kustomization

Les deux objets ont chacun leur spec.interval. La Source et la Kustomization reconcilent indépendamment. Si la Source a un interval de 5 minutes et la Kustomization de 1 minute, Flux reconcilera la Kustomization toutes les minutes mais ne téléchargera une nouvelle archive Git que toutes les 5 minutes.

À retenir

• Flux CD est un ensemble de contrôleurs modulaires, pas une application monolithique.
• Le modèle Sources → Artefacts → Consumers découple la récupération des changements de leur application.
• La boucle de réconciliation garantit que le cluster converge en permanence vers l’état décrit dans Git.
• Kustomization (CRD Flux) et kustomization.yaml (outil Kustomize) sont deux choses différentes.
• Le bootstrap configure Flux pour qu’il se gère lui-même depuis Git.
• prune: true est essentiel : sans lui, les ressources supprimées de Git restent dans le cluster.

Prochaines étapes

Bootstrap et installation Installer le CLI flux, bootstrapper votre premier cluster

Première application avec Kustomize Déployer une application depuis Git avec GitRepository et Kustomization

Vue d'ensemble Flux CD Retour à la page de formation

×

📖 Voir la documentation →