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 contrôleurs de Flux, ceux installés par défaut et les optionnels, et le rôle 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.

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 (à chaque spec.interval)	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 contrôleurs de Flux

Quatre contrôleurs sont installés par défaut par flux install et flux bootstrap : source-controller, kustomize-controller, helm-controller et notification-controller. Les deux contrôleurs d'images, image-reflector-controller et image-automation-controller, sont optionnels : ils s'ajoutent avec l'option --components-extra, au même titre que source-watcher. C'est la valeur documentée de ces options, et c'est ce qui explique qu'un cluster fraîchement installé ne connaisse pas encore les objets ImagePolicy.

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: podinfo
  namespace: web
spec:
  interval: 5m
  chart:
    spec:
      chart: podinfo
      version: "6.15.0"
      sourceRef:
        kind: HelmRepository
        name: podinfo
  values:
    replicaCount: 2

La différence avec helm upgrade --install en pipeline : la HelmRelease est réconciliée à chaque intervalle, et une nouvelle version ou de nouvelles values dans Git déclenchent l'upgrade. La correction des modifications manuelles, elle, n'est pas active par défaut : elle s'active avec driftDetection, détaillé dans la leçon Helm.

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 réconciliation immédiate

Glissez pour voir

image-reflector-controller et image-automation-controller

Ces deux contrôleurs optionnels 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 intervalle (spec.interval de la ressource)

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 réconcilie les sources à deux moments :

1. À intervalles réguliers : définis dans spec.interval de chaque ressource. Ce champ est obligatoire, il n'a pas de valeur par défaut : c'est vous qui choisissez la fréquence, ressource par ressource. Cela garantit la réconciliation même sans notification.
2. Sur webhook : un push GitHub/GitLab peut déclencher une réconciliation 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 contrôleurs installés + 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 contrôleurs installés
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'équipe	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

Vous n'avez pas à écrire de Kustomize. Une Kustomization Flux peut pointer vers un répertoire de YAML bruts, sans kustomization.yaml : le kustomize-controller génère alors ce fichier en interne pour tous les manifestes du chemin, puis les applique en server-side apply. La seule exigence est que chaque YAML du chemin soit un manifeste Kubernetes valide. La documentation de Flux recommande tout de même de versionner votre propre kustomization.yaml, pour pouvoir valider les manifestes en CI.

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 se réconcilient indépendamment. Si la Source a un intervalle de 5 minutes et la Kustomization de 1 minute, Flux réconciliera 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.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →