Les valeurs par défaut de Flux diffèrent de celles des outils qui attendent une synchronisation manuelle. Une Kustomization Flux s’applique selon un calendrier et corrige la dérive à chaque exécution. Ce que vous contrôlez, c’est la fréquence, ce qui est supprimé, quand attendre la bonne santé des ressources et quand mettre en pause. Ce guide passe en revue chaque réglage en utilisant la Kustomization webapp du guide précédent.

Intervalles : à quelle fréquence Flux regarde et applique

Deux intervalles contrôlent le timing, et ils sont indépendants :

• L’intervalle du GitRepository détermine à quelle fréquence Git est interrogé pour de nouveaux commits.
• L’interval de la Kustomization détermine à quelle fréquence les manifestes sont réappliqués et la dérive corrigée, même si Git n’a pas changé.

spec:
  interval: 10m
  retryInterval: 2m

retryInterval est le délai d’attente avant de réessayer après une réconciliation échouée. Pour réagir immédiatement plutôt qu’attendre, déclenchez une réconciliation à la main pendant vos tests :

flux reconcile kustomization webapp --with-source

--with-source rafraîchit d’abord la source Git puis l’applique. En production, configurez un webhook pour que les push Git déclenchent une réconciliation sans interrogation fréquente (voir le guide sur les notifications).

Ajouter le pruning

Par défaut, Flux crée et met à jour les ressources mais ne supprime rien. Si vous renommez ou retirez un manifeste dans Git, l’ancien objet reste dans le cluster. Activez explicitement la suppression :

spec:
  prune: true

Pour l’essayer, renommez le Deployment dans apps/webapp/deployment.yaml de webapp en webapp-v2, committez et réconciliez. Flux crée le nouveau Deployment et supprime l’ancien. Flux suit les objets qu’il a appliqués via un inventaire, il ne supprime donc jamais que ce qu’il a créé. Le pruning supprime de vrais objets, activez-le donc délibérément et soyez prudent avec les ressources qui conservent un état.

Pour protéger un objet du pruning, annotez-le dans le manifeste :

metadata:
  annotations:
    kustomize.toolkit.fluxcd.io/prune: disabled

Correction de dérive

À chaque réconciliation de la Kustomization, l’état désiré de Git est de nouveau appliqué, donc les modifications manuelles sont annulées. Testez-le :

kubectl scale deployment webapp-v2 -n webapp --replicas=5
flux reconcile kustomization webapp
kubectl get pods -n webapp

Flux ramène le Deployment aux deux réplicas déclarés dans Git. Il n’y a pas de réglage « self-heal » distinct à activer. Ce comportement est celui par défaut, et c’est ce qui fait de Git l’unique source de vérité.

Si vous devez faire un changement temporaire à la main, par exemple pendant un débogage, mettez d’abord Flux en pause (section suivante). Si un objet doit être géré en dehors de Flux, annotez-le dans Git :

metadata:
  annotations:
    kustomize.toolkit.fluxcd.io/reconcile: disabled

Les versions récentes de Flux (2.9) ajoutent aussi des règles d’ignorance de champs pour le server-side apply, qui vous permettent d’indiquer à Flux de laisser certains champs tranquilles, comme un nombre de réplicas géré par un autoscaler. Consultez la référence de Kustomization pour la syntaxe exacte de votre version.

Attendre la bonne santé et ordonner vos déploiements

Par défaut, Flux signale un succès dès que l’API server accepte les manifestes. Définir wait: true lui fait attendre que les ressources soient prêtes, et timeout borne l’attente :

spec:
  wait: true
  timeout: 2m

Utilisez dependsOn pour qu’une Kustomization attende une autre, par exemple pour installer un ingress controller avant les applications qui en ont besoin :

spec:
  dependsOn:
    - name: infrastructure

La dépendance doit être Ready avant que cette Kustomization commence à se réconcilier.

Suspendre et reprendre

Pour mettre en pause la réconciliation sans rien supprimer :

flux suspend kustomization webapp
# faire des modifications manuelles, déboguer, puis :
flux resume kustomization webapp

Pendant la suspension, Flux ignore l’objet et les modifications manuelles restent en place. La reprise déclenche une réconciliation qui remet le cluster en accord avec Git, n’oubliez donc pas de reprendre. Suspendre est l’équivalent Flux de couper l’automatisation pour un environnement.

Revenir en arrière en toute sécurité

Flux n’a pas de commande rollback pour les Kustomizations, car Git est l’historique. Pour annuler un mauvais changement :

git revert <bad-commit>
git push
flux reconcile kustomization webapp --with-source

Flux fait converger le cluster vers l’état rétabli, et Git conserve une trace honnête de ce qui s’est passé. Pour les urgences où le cluster doit d’abord cesser de bouger, suspendez la Kustomization, corrigez, poussez le revert, puis reprenez.

Les releases Helm sont différentes : le helm-controller peut annuler automatiquement une mise à niveau échouée, ce que le guide Helm couvre.

Garder la production délibérée

Comme l’automatisation est activée par défaut, le contrôle de la production se fait dans Git plutôt que par un bouton de « synchronisation manuelle ». Schémas courants :

• Protéger la branche de production et exiger l’approbation des pull requests.
• Pointer le GitRepository de production vers un tag ou une plage semver (ref.tag ou ref.semver) pour que la production ne change que lorsque vous coupez une release.
• Utiliser flux suspend pendant les gels de changements.