La plupart des équipes commencent à déployer sur Kubernetes de la même façon : le système de CI construit une image, puis exécute kubectl apply ou helm upgrade sur le cluster. Cela fonctionne, jusqu’à ce que le nombre d’applications et de clusters augmente. Ce guide explique ce qui change quand un agent à l’intérieur du cluster, comme Flux, tire à la place l’état désiré depuis Git, et quels compromis cela implique.

Le modèle push et là où il montre ses limites

Dans un pipeline push, le job de CI est la seule chose qui touche le cluster :

1. Un commit déclenche les tests et la construction d’une image.
2. Le job met à jour un manifeste avec le nouveau tag d’image.
3. Le job exécute kubectl apply (ou helm upgrade) sur le cluster.

Trois problèmes apparaissent à mesure que vous grandissez :

• Les identifiants vivent en dehors du cluster. Chaque pipeline a besoin d’un kubeconfig ou d’identifiants cloud, et cela se multiplie avec chaque application et chaque cluster.
• Cela ne se produit qu’une fois. Une fois le job terminé, plus rien ne surveille le cluster. Le kubectl edit de quelqu’un il y a deux semaines reste invisible jusqu’à ce qu’il provoque un incident.
• Il n’y a pas de réponse simple à « qu’est-ce qui est déployé ? » Il faut inspecter le cluster lui-même, car la dernière exécution du pipeline n’est pas un enregistrement fiable.

Inverser le sens : le pull

Avec un modèle pull, un agent s’exécute à l’intérieur du cluster, surveille un dépôt Git, compare ce qui y est déclaré avec ce qui tourne, et applique la différence. Flux est cet agent. Il est composé de plusieurs petits contrôleurs, chacun faisant un seul travail :

Contrôleur	Ce qu’il fait
source-controller	Récupère les dépôts Git, les dépôts Helm, les artefacts OCI et les buckets, et les met à disposition des autres
kustomize-controller	Construit et applique des manifestes Kubernetes (YAML brut ou overlays Kustomize) depuis une source
helm-controller	Installe, met à niveau, teste et annule des releases Helm
notification-controller	Envoie des alertes (Slack, Teams et autres) et reçoit des webhooks
contrôleurs image-reflector / image-automation	Optionnels. Analysent les registres de conteneurs et committent les nouveaux tags d’images dans Git

Développeur ─▶ Dépôt applicatif ─▶ CI (test, build) ─▶ Registre d'images
                            │
                            └─ committe le nouveau tag d'image ─▶ Dépôt de config
                                                            ▲
                                          Flux (dans le cluster) ┘ tire, compare, applique
                                                │
                                                ▼
                                            Kubernetes

Les identifiants du cluster ne quittent jamais le cluster, car la seule chose qui applique les changements est l’agent qui s’y exécute. Les ingénieurs et les systèmes de CI n’ont besoin que d’un accès en écriture à Git.

Les quatre principes GitOps

Le groupe de travail OpenGitOps définit GitOps par quatre principes. Flux les met tous en œuvre :

1. Déclaratif. Le système est décrit en YAML, pas en scripts.
2. Versionné et immuable. Git est l’unique source de vérité. Chaque changement est un commit qui peut être audité et annulé.
3. Tiré automatiquement. Les changements approuvés sont récupérés par le cluster, pas poussés vers lui.
4. Réconcilié en continu. Les agents comparent l’état désiré et l’état réel et corrigent la dérive.

Flux se gère lui-même

Une caractéristique distinctive de Flux est le bootstrap. La commande flux bootstrap installe Flux dans le cluster et committe les propres manifestes de Flux dans votre dépôt Git, puis configure Flux pour qu’il se synchronise depuis ce même dépôt. Dès le premier jour, même l’outillage GitOps est géré via Git. Le guide suivant l’explique pas à pas.

Séparer le code applicatif et la configuration dans des dépôts distincts

La recommandation habituelle est d’avoir deux dépôts : un pour le code source de l’application, un pour la configuration Kubernetes (Deployments, Services, HelmReleases, etc.).

La configuration change selon son propre calendrier. Modifier un Service ou une ConfigMap ne devrait pas déclencher un pipeline complet de build et de test pour un code qui n’a pas changé. Avec deux dépôts, la dernière étape du pipeline de CI devient « committer le nouveau tag d’image dans le dépôt de config », et Flux prend le relais. Cela sépare aussi proprement les responsabilités : les développeurs possèdent la CI, les équipes plateforme ou opérations possèdent la livraison.

Flux offre deux moyens de faire arriver le nouveau tag d’image dans le dépôt de config :

• La CI le committe. Un script du pipeline met à jour le tag dans le YAML et pousse. Cela fonctionne avec n’importe quel système de CI.
• Flux le committe. Les contrôleurs optionnels d’image automation surveillent le registre et poussent eux-mêmes le changement de tag dans Git. Voir le guide sur l’automatisation d’images dans cette série.

Faire de Git la seule porte d’entrée : la correction de dérive

Flux réconcilie selon un intervalle. Quand le cluster en cours d’exécution diffère de Git, Flux réapplique la version de Git, de sorte qu’une modification manuelle est annulée. Cela a des conséquences pratiques :

• Chaque changement a un commit, un auteur et généralement une pull request relue, ce qui vous donne une piste d’audit.
• Les permissions passent dans Git. Beaucoup de gens peuvent ouvrir des pull requests ; seuls quelques-uns peuvent fusionner.
• Un kubectl edit manuel rapide en production cesse d’être un changement silencieux et durable.

Rollback et restauration deviennent des opérations Git

Comme l’état désiré est versionné, revenir à un état connu comme bon est un git revert, et Flux fait converger le cluster vers lui. La même idée couvre la restauration. Si un cluster est perdu, vous en créez un nouveau, lancez flux bootstrap sur le même dépôt et le même chemin, et les workloads sont recréés depuis Git. Tout ce qui n’est pas dans Git, comme les données persistantes ou les secrets que vous gérez ailleurs, nécessite toujours sa propre stratégie de sauvegarde.

Ce que Flux ne remplace pas

Flux est une boîte à outils de livraison, pas un outil de build. Vous avez toujours besoin d’une CI pour tester le code, construire les images et les pousser dans un registre. Il est spécifique à Kubernetes, d’autres cibles de déploiement nécessitent donc d’autres outils. Et ce n’est pas le seul contrôleur GitOps : Argo CD met en œuvre les mêmes principes avec une conception différente, que le guide de comparaison de cette série présente. Le reste de cette série suppose Flux et commence par son installation. Pour la référence complète, consultez la documentation officielle de Flux.