Formation Flux CD — GitOps sur Kubernetes

Flux CD est un opérateur GitOps qui réconcilie en permanence l’état de votre cluster Kubernetes avec ce que décrit votre dépôt Git. Contrairement à un pipeline qui pousse des manifestes (kubectl apply), Flux tire les changements depuis Git et les applique lui-même — votre cluster devient déclaratif, auditable, et auto-réparant.

Cette formation vous guide de la première installation jusqu’à la gestion multi-tenancy en production, en couvrant Kustomize, Helm, l’automatisation des mises à jour d’images et le monitoring.

Ce que vous allez apprendre

Cette formation couvre 7 modules progressifs :

Module	Sujet	Niveau
1	Concepts et architecture Flux CD	Débutant
2	Bootstrap et installation	Débutant
3	Première application avec Kustomize	Débutant
4	Déploiements Helm avec HelmRelease	Intermédiaire
5	Automatisation des mises à jour d’images	Intermédiaire
6	Multi-tenancy et isolation par équipe	Intermédiaire
7	Monitoring, alertes et observabilité	Avancé

Pourquoi Flux CD ?

Avant Flux, déployer sur Kubernetes signifiait souvent exécuter kubectl apply dans un job CI, avec des credentials cluster exposés dans la pipeline, et sans historique fiable de qui a déployé quoi et quand.

Flux renverse ce modèle : c’est le cluster qui tire les changements depuis Git, pas votre CI qui les pousse. Résultat concret : zéro credentials cluster dans vos pipelines, un historique complet d’audit par commit Git, et la capacité de revenir en arrière sur n’importe quel état du cluster.

Flux se distingue également par son architecture modulaire : là où ArgoCD est une application monolithique avec une UI centralisée, Flux est un ensemble de contrôleurs Kubernetes indépendants que vous assemblez selon vos besoins. Pas d’interface graphique native — Flux est pensé pour les équipes qui préfèrent kubectl et le CLI.

Flux CD vs ArgoCD — quand choisir quoi ?

Critère	Flux CD	ArgoCD
Architecture	Contrôleurs modulaires, pas d’UI	Application tout-en-un avec UI
Interface	CLI + kubectl	Dashboard web + CLI
Bootstrap Git	Flux gère ses propres manifestes dans Git	Manifestes gérés manuellement
Helm	HelmRelease CRD natif	Application CRD avec source Helm
Automatisation d’images	Contrôleur dédié natif	Via Argo CD Image Updater (plugin)
Multi-tenancy	Namespace isolation native	AppProject system
Courbe d’apprentissage	Plus raide (CLI-first)	Plus douce (UI d’abord)
Préférer si	Équipe CLI-first, multi-tenancy stricte	Débutants GitOps, UI nécessaire

À qui s’adresse cette formation

Cette formation est conçue pour :

Les développeurs et DevOps qui maîtrisent les bases Kubernetes (Pods, Deployments, Services) et veulent structurer leurs déploiements en GitOps.
Les Platform Engineers qui déploient Flux pour plusieurs équipes et ont besoin d’isolation par namespace et de contrôle d’accès fin.
Les équipes passant de kubectl/Helm en CI à une approche GitOps déclarative, avec bootstrap Git et réconciliation automatique.

Connaître Kustomize et/ou Helm est un plus à partir du module 4.

Ce que vous saurez faire à la fin

À l’issue des 7 modules, vous serez capable de :

Bootstrapper Flux sur un cluster depuis un dépôt GitHub ou GitLab.
Déployer une application depuis un dépôt Git avec Kustomize et comprendre les statuts de réconciliation.
Gérer des releases Helm avec les CRDs HelmRepository et HelmRelease.
Automatiser les mises à jour d’images : Flux détecte une nouvelle image et met à jour Git automatiquement.
Structurer un cluster multi-tenant avec isolation par namespace et politique d’accès par équipe.
Configurer les alertes (Slack, Teams) et lire les métriques Prometheus exposées par Flux.

Les concepts clés de Flux CD

Flux introduit plusieurs Custom Resource Definitions (CRDs) dans votre cluster. Les voici regroupés par contrôleur :

CRD	Contrôleur	Rôle
`GitRepository`	source-controller	Déclare un dépôt Git à surveiller
`OCIRepository`	source-controller	Déclare un artefact OCI (image ou chart)
`HelmRepository`	source-controller	Déclare un dépôt de charts Helm
`HelmChart`	source-controller	Résoud un chart depuis un HelmRepository
`Kustomization`	kustomize-controller	Applique un répertoire de manifestes (Kustomize ou YAML brut)
`HelmRelease`	helm-controller	Déploie et gère une release Helm
`ImageRepository`	image-reflector-controller	Surveille un registre de conteneurs
`ImagePolicy`	image-reflector-controller	Filtre les tags d’image selon une règle semver
`ImageUpdateAutomation`	image-automation-controller	Pousse les mises à jour de tags dans Git
`Alert`	notification-controller	Envoie des notifications sur événements Flux
`Provider`	notification-controller	Définit le canal de notification (Slack, Teams…)
`Receiver`	notification-controller	Reçoit des webhooks entrants

Chaque module de la formation approfondit un sous-ensemble de ces objets.

Pièges courants avec Flux CD

Piège	Impact	Correctif
Bootstrap sans `--private-key-file` sur un repo privé	Flux ne peut pas lire le dépôt	Utiliser le deploy key généré par `flux bootstrap`
`Kustomization` sans `prune: true`	Les ressources supprimées de Git restent dans le cluster	Activer `prune: true` dès le départ
Tout dans le namespace `flux-system`	Confusion entre ressources Flux et ressources applicatives	Créer un namespace par équipe, pointer avec `targetNamespace`
`HelmRelease` sans `remediation.retries`	Un chart défaillant bloque silencieusement	Définir `remediation.retries: 3` + `remediation.strategy: rollback`
Secrets en clair dans le config-repo	Credentials exposés	Utiliser SOPS avec age, ou External Secrets Operator
`ImageUpdateAutomation` sur la branche `main`	Une image non testée va directement en production	Cibler une branche de staging, PR automatio pour main
Pas de `sourceRef` explicite sur les sous-Kustomizations	Dépendance implicite difficile à déboguer	Toujours déclarer le `sourceRef` dans chaque Kustomization

Critères de réussite

Votre déploiement Flux CD est prêt pour la production quand :

Flux surveille son propre dépôt de configuration (bootstrap complet)
Aucun secret n’est en clair dans le config-repo (SOPS ou External Secrets)
Chaque équipe a son namespace dédié avec ServiceAccount et droits RBAC limités
prune: true est activé sur toutes les Kustomization de production
Les alertes de drift sont configurées (Slack, Teams ou webhook)
Un rollback git a été testé (git revert + flux reconcile) au moins une fois
Les HelmRelease ont une stratégie de remediation définie
L’automatisation d’images cible une branche de staging, pas main directement

L’architecture globale : CI + Flux ensemble

Dans un modèle GitOps avec Flux, la CI ne touche jamais le cluster directement. Elle publie des artefacts (images Docker, charts Helm) et met à jour le config-repo (tag d’image, version de chart). Flux détecte le changement dans Git et applique l’état désiré sur le cluster.

Code source → CI (build + test + push image) → Config-repo (mise à jour tag)
                                                      ↓
Cluster Kubernetes ← source-controller (pull from Git)
       ↑                     ↓
kustomize-controller ← artefact (manifestes)
       ↓
kubectl apply (réconciliation)

La différence avec un pipeline classique : le cluster tire, il ne reçoit pas. Le serveur GitLab ou GitHub n’a jamais de credentials Kubernetes.

Modules de la formation

1 — Concepts et architecture 5 contrôleurs, Sources, Kustomizations, réconciliation, modèle pull GitOps

2 — Bootstrap et installation CLI flux, flux check, bootstrap GitHub/GitLab, deploy key, structure du dépôt

3 — Première application GitRepository, Kustomization, flux get, sync manuel, self-healing

4 — Déploiements Helm HelmRepository, HelmChart, HelmRelease, values, remediation automatique

5 — Automatisation d'images ImageRepository, ImagePolicy, ImageUpdateAutomation, push dans Git

6 — Multi-tenancy Isolation namespace, ServiceAccount par équipe, tenant RBAC, path isolation

7 — Monitoring et alertes Métriques Prometheus, Grafana dashboards, AlertManager, notifications Slack

Dépôts de référence pour la formation

Pour suivre les modules pratiques, vous avez besoin d’un dépôt Git accessible depuis votre cluster (GitHub, GitLab ou Gitea autohébergé) :

fleet-infra/                     ← Config-repo (géré par Flux)
  clusters/
    my-cluster/
      flux-system/               ← Composants Flux (auto-générés au bootstrap)
        gotk-components.yaml
        gotk-sync.yaml
        kustomization.yaml
  apps/
    base/                        ← Manifestes de base
    dev/                         ← Overlay dev (Kustomize)
    staging/                     ← Overlay staging
    production/                  ← Overlay production
  infrastructure/
    sources/                     ← GitRepository, HelmRepository
    configs/                     ← ConfigMaps, NetworkPolicies partagés

À retenir

Flux CD est un ensemble de contrôleurs Kubernetes qui synchronise votre cluster depuis Git en mode pull.
Le bootstrap est la première étape : Flux s’enregistre lui-même dans Git et se gère à partir de là.
Flux ne dispose pas d’UI native : il s’utilise avec kubectl et le CLI flux.
Les Sources (GitRepository, HelmRepository…) produisent des artefacts que les contrôleurs consomment (Kustomization, HelmRelease).
La réconciliation est continue et auto-réparante : tout drift est corrigé sans intervention manuelle.
Flux est pensé pour le multi-tenancy strict : chaque équipe a ses propres namespaces, sources et droits RBAC.

Prochaines étapes

Comprendre le GitOps Les principes fondamentaux avant d'installer Flux

Formation ArgoCD L'alternative avec UI — comparez les deux approches