Cet article est le premier d’une série de deux sur la migration de Flux v1 à Flux v2:
- Migration Flux v1 vers flux v2 : la méthode officielle
- Migration Flux v1 vers flux v2 : retour d’expérience à grande échelle (à suivre)
Dans un précédent article sur le Gitops, nous vous avions rapidement évoqué Flux, aux côtés d’ArgoCD. Aujourd’hui, nous allons nous concentrer sur Flux, de manière concrète et bien plus détaillée.
Nous avons dû le mettre à jour en v2 sur des dizaines de clusters Kubernetes à la fois chez nous et chez nos clients. Et je me suis dit que c’était l’occasion de vous faire un retour d’expérience sur le passage à cette nouvelle version majeure.
Petit rappel, Flux c’est quoi ?
Flux c’est un outil de GitOps. Pour faire simple, il permet de configurer Kubernetes et il fonctionne en mode pull.
On a d’un côté Flux qui tourne sur le cluster Kubernetes et de l’autre un dépôt git avec l’ensemble des ressources à déployer sur le cluster. Flux va régulièrement vérifier le dépôt git et s’assurer que les ressources déclarées dans celui-ci sont correctement appliquées sur le cluster. De cette manière, pour les personnes en charge de la configuration et de l’opération du cluster Kubernetes, il suffit de pousser les changements dans git pour qu’ils se retrouvent déployés sur le cluster Kubernetes grâce à Flux.
Depuis octobre 2020, Flux v1 est considéré en maintenance, avec des nouvelles releases qui visent seulement à fixer les bugs critiques. Flux v2 a été annoncé comme viable et comme la version à privilégier par rapport à la v1 depuis le 30 juin 2021. Le calendrier de migration et de support est disponible sur la documentation de Flux v2.
Passer de Flux v1 à v2
Architecture Flux repensée
Sur Flux v2, on passe d’un opérateur monolithique (souvent accompagné du Helm operator) à une architecture avec un contrôleur dédié par fonctionnalité, une meilleure intégration à Kubernetes (avec de nombreuses custom resources) et une CLI pour piloter tout ça.
Dans les contrôleurs par défaut de Flux v2, on a :
- source-controller, qui s’occupe de garder à jour les GitRepository ou HelmRepository pour détecter une modification
- kustomize-controller, qui va appliquer le reconcile d’après les Kustomization
- helm-controller, qui va gérer les HelmRelease et leur réconciliation
- notification-controller, qui permet d’envoyer les notifications
Et quand on utilise l'image automation update, il faut aussi ajouter :
- image-reflector-controller, qui va utiliser les ImageRepository et ImagePolicy pour faire la liste des tags disponibles et à mettre à jour
- image-automation-controller, qui va appliquer la mise à jour des images
Fin du support de certains composants historiques
Le support de Helm v2 a été supprimé. Cette version de Helm était dépréciée depuis novembre 2020, ça ne devrait donc pas être un problème pour la plupart des utilisateurs qui ont probablement déjà migré sur Helm v3.
La version minimum de Kubernetes initialement exigée pour utiliser Flux v2 est la 1.16. Il faut aujourd’hui privilégier une 1.20.6 minimum !
Un paquet de nouvelles custom resources Flux
Flux v2 vient avec de nouvelles custom resources, que ce soit le HelmRelease du helm-operator qui se retrouve éclaté en plusieurs ressources (avec le repository à part par exemple) ou encore pour l’automatisation des mises à jour d’images. Ces dernières reposaient en v1 sur beaucoup d’implicite, on peut désormais contrôler bien plus finement ce qu’on fait.
Plusieurs éléments qui se trouvaient précédement sur la ligne de commande/config de flux v1 se retrouvent également dans des custom ressources. Ceci permet de gérer l’ensemble plus facilement (surtout les dépôts helm privés) et également d’utiliser si besoin plusieurs dépôts git comme source.
D’un point de vue opérationnel, l’un des gros intérêts d’avoir des ressources séparées, c’est que chacune d’entre-elle remonte son état indépendamment : on peut donc suspendre finement chaque ressource du cluster. Pour investiguer un problème, c’est vraiment plus confortable que la grosse boite noire qu’était Flux v1 par moments.
Plus de détails sont disponibles sur la FAQ de migration qui liste les principales différences et les différents ajouts entre la v1 et la v2 de Flux.
Migration Flux v2 : pas si trivial
La méthode recommandée par le guide de migration à Flux v2 est d’utiliser flux bootstrap pour générer toute la configuration de base et la mettre dans un nouveau dépôt git qui contiendra toutes les ressources migrées sur Flux v2.
L’idée est de migrer les manifests au fur à mesure, avec les changements de Flux v2. On les enlève du dépôt git géré par Flux v1 et on ajoute la version à jour dans celui de Flux v2 et tout devrait bien se passer. Il faut bien entendu désactiver le garbage collection de Flux v1 avant, sinon les ressources vont se voir supprimer puis recréées au lieu d’être rattachées à la nouvelle version de Flux. De cette façon, les deux versions de Flux cohabitent, et on peut tranquillement migrer à notre rythme.
Avec des HelmRelease, il y a quelques étapes de migration en plus. Il faut stopper le helm-operator (Flux v1) pour éviter les conflits avec le helm-controller (Flux v2) sur la prise en charge des HelmRelease. Et ensuite migrer les HelmRelease au nouveau format.
La méthode officielle a le mérite d’être simple et de pouvoir migrer progressivement.
Malheureusement, j’ai fait face à un paquet de problématiques complexes sur nos plateformes client qui m’ont incitées à sortir du chemin balisé explicité dans l’article Migration de Flux v1 à flux v2 : retour d’expérience à grande échelle!
Ne ratez pas nos prochains articles DevOps et Cloud Native! Suivez Enix sur Twitter!