FluxCD

Fiche express
Type	Ensemble d'outils GitOps pour Kubernetes
Éditeur	Weaveworks (origine), projet CNCF
Statut CNCF	Graduated (à vérifier selon la date de consultation)
Modèle	Pull, réconciliation continue depuis Git
Alternative	ArgoCD
Voir aussi	Frontière IaC — Terraform, Ansible, GitOps

FluxCD (ou simplement Flux) est, comme ArgoCD, un outil GitOps de déploiement continu pour Kubernetes : il compare en continu l'état déclaré dans un dépôt Git à l'état réel du cluster et réconcilie l'écart. Les deux projets partagent la même philosophie GitOps et sont tous deux hébergés par la CNCF ; ils diffèrent surtout dans leur architecture et leur positionnement vis-à-vis de l'interface graphique.

Architecture modulaire ("Unix philosophy")

Là où ArgoCD se présente comme une plateforme intégrée avec une UI web centrale, Flux (depuis sa version 2, réécrite sous le nom de GitOps Toolkit) assume une architecture éclatée en plusieurs contrôleurs Kubernetes indépendants, chacun responsable d'une seule chose et communiquant via des CRD :

• source-controller — surveille les sources (dépôt Git, dépôt Helm, bucket S3/OCI) et produit un artefact interne consommable par les autres contrôleurs.
• kustomize-controller — applique des manifests Kustomize depuis une source.
• helm-controller — installe/met à jour des releases Helm à partir d'une HelmRepository et d'une HelmRelease.
• notification-controller — émet des événements (Slack, webhooks...) et reçoit des notifications externes (déclenchement par webhook Git).
• image-reflector-controller / image-automation-controller — scrutent un registre de conteneurs et poussent automatiquement une mise à jour de tag dans le dépôt Git (fonctionnalité sans équivalent direct côté ArgoCD).

<mermaid> flowchart LR

   Git[Dépôt Git] --> SC[source-controller]
   Helm[Dépôt Helm] --> SC
   SC --> KC[kustomize-controller]
   SC --> HC[helm-controller]
   KC --> W[(Workloads)]
   HC --> W
   W -.tags d'image.-> IRC[image-reflector-controller]
   IRC --> IAC[image-automation-controller]
   IAC -->|commit auto| Git

</mermaid>

Cette approche modulaire — chaque contrôleur ne fait qu'une chose, s'installe et s'upgrade indépendamment — rappelle la philosophie Unix (« do one thing well ») plus que l'approche « plateforme » d'ArgoCD. En contrepartie, Flux n'impose pas d'interface graphique : le pilotage se fait principalement en CLI (flux) et par lecture directe des ressources Kubernetes ; une UI existe (Weave GitOps, ou des tableaux de bord tiers) mais reste optionnelle, alors que l'UI d'ArgoCD est un élément central de son usage courant.

Ressources principales

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: mon-app
  namespace: flux-system
spec:
  interval: 1m
  url: https://git.example.org/infra/mon-app.git
  ref:
    branch: main
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: mon-app
  namespace: flux-system
spec:
  interval: 5m
  path: ./manifests/overlays/production
  prune: true
  sourceRef:
    kind: GitRepository
    name: mon-app
  targetNamespace: mon-app

• GitRepository — équivalent, côté source, du champ source d'une Application ArgoCD.
• Kustomization (CRD Flux, à ne pas confondre avec le fichier kustomization.yaml natif de Kustomize) — déclenche l'application et la réconciliation périodique (interval) des manifests, avec suppression des ressources retirées (prune).

ArgoCD vs Flux : comparatif

Dimension	ArgoCD	FluxCD
Interface	UI web intégrée, centrale à l'usage	CLI-first, UI optionnelle (Weave GitOps)
Architecture	Plateforme intégrée (un ensemble de composants couplés)	Contrôleurs indépendants (GitOps Toolkit)
Objet central	CRD Application unique	Plusieurs CRD spécialisées (GitRepository, Kustomization, HelmRelease...)
Multi-cluster	Depuis une instance centrale pilotant plusieurs clusters	Une instance Flux par cluster (modèle plus décentralisé), fédération possible
Mise à jour d'image automatique	Non nativement (outils tiers type Argo Image Updater)	Native (image-reflector/automation-controller)
Courbe d'adoption	Prise en main visuelle rapide	Plus proche des primitives Kubernetes, préféré en contexte très automatisé/scripté

Les deux outils sont interopérables avec le même socle GitOps documenté dans Frontière IaC — Terraform, Ansible, GitOps : dépôt Git comme source de vérité, réconciliation continue, gestion du drift. Le choix entre les deux relève davantage de préférences d'équipe (goût pour une UI centralisée vs composition d'outils spécialisés) que d'une différence fonctionnelle radicale.

Voir aussi

• ArgoCD — alternative avec UI intégrée
• Frontière IaC — Terraform, Ansible, GitOps — répartition provisionnement/configuration/déploiement
• Terraform — Concepts fondamentaux — provisionnement du cluster en amont
• Réseau cloud-native — modèle réseau et primitives Kubernetes