Helm 4 : les principales améliorations !

Helm 4 arrive dans quelques jours avec son lot de nouvelles fonctionnalités très attendues par la communauté Kubernetes. Nous nous sommes donc dit qu’un peu de prospection sur les changements à venir pourrait nous être utile à tous !

Nous avons ainsi exploré en détail les principales nouveautés de Helm 4 — du passage au Server Side Apply à la gestion avancée du status des ressources. L’objectif : comprendre plus concrètement ce que ces évolutions changent pour vos déploiements Kubernetes et comment anticiper la migration vers Helm 4.

L’équipe derrière Helm présente déjà une synthèse des nouveautés apportées par la version 4. Nous nous concentrons ici sur les changements qui nous semblent les plus importants et les plus utiles.

Helm 4 : la fin du three way merge

Helm 4 met fin à la méthode du three way merge au profit du server side apply. Voyons ça de plus près…

Le three way merge, petit rappel

Le three way merge c’est le processus par lequel helm 3 gère actuellement les problèmes de concurrence lors de la modification d’un objet. Pour cela, il compare trois états :

• Le nouvel état défini dans le manifeste que l’on souhaite appliquer ;
• L’état actuel de l’objet (ou état “live”) ;
• Et la dernière configuration appliquée avec succès, qu’il conserve dans un secret (ce que vous voyez avec helm history).

Mais cette méthode qui était également celle de l’API kubernetes n’est plus utilisée par cette dernière depuis quelques années déjà, il était donc temps de refléter cette évolution dans Helm. Rattraper la dette technique est d’ailleurs un des objectifs affichés pour Helm 4 dès le début du projet !

La solution : le Server Side Apply (SSA)

Helm 4 implémente une solution avec une approche plus déclarative déjà standard dans kubernetes depuis sa version 1.22, le Server Side Apply.

Chaque modification apportée sur un champ d’un objet se voit attribuer un propriétaire. Vous pouvez voir les différents propriétaires des champs en faisant un kubectl get d’un objet avec le flag --show-managed-fields.

Helm 4 entend avoir recours au Server Side Apply (SSA) par défaut, même si la méthode du three way merge devrait rester utilisable, pendant un temps, au moyen d’un flag si besoin. En cas de conflit à l’occasion d’une modification apportée sur le même champ par des propriétaires différents, helm 4 devrait alors générer une erreur plutôt que d’écraser tout avec un patch. Les conflits pourront donc toujours se produire… mais l’utilisateur en sera cette fois explicitement informé !

On relève que Helm 4 devrait prévoir, comme pour kubectl, un flag --force-conflicts=false|true (défini par défaut à false) pour les commandes install, upgrade et rollback afin de pouvoir outrepasser les conflits si nécessaire. On note toutefois que Helm 4 ne devrait pas gérer deux cas possibles :

• plusieurs propriétaires d’un même manifest : dans un premier temps il ne pourra y avoir qu’un unique propriétaire par manifest helm ;
• transfert de propriété d’un champ : contrairement à l’API Kubernetes il ne sera pas possible de transférer un champ d’un propriétaire à l’autre.

La rétro compatibilité avec les charts déployées en three way merge devrait être assurée, à moins que vous n’ayez un cluster kubernetes dans une version inférieure à 1.22… mais cela nous semble peu probable !

Helm 4 : des déploiements plus fiables

Quand ready ne veut pas exactement dire ready (avec notre bon vieux helm install wait)

Actuellement, avec helm install --wait, Helm attend principalement que les déploiements (Deployments) et quelques autres types de ressources soient dans un état ready. Mais ready ne signifie pas nécessairement que l’application déployée est effectivement prête et en fonctionnement.

Actuellement, Helm ne dispose d’aucun mécanisme natif pour un utilisateur ou un mainteneur de chart d’attendre une condition précise avant de poursuivre le déploiement d’une ressource, à l’exception de solutions de contournement comme les hooks ou les init containers.

C’est d’autant plus problématique par exemple lorsqu’on déploie une application dépendante d’une base de données elle-même déployée par un chart ou un sous chart.

Avec Helm 4, utiliser le status comme source de vérité

La solution: kstatus. C’est une bibliothèque standard de Kubernetes qui sait interpréter l’état de santé (health status) de nombreuses ressources Kubernetes natives (Deployments, StatefulSets, Services, etc.) de manière bien plus fine que le helm --wait actuel.

Il sera dès lors possible de contrôler les déploiements avec beaucoup de granularité. Avec notamment deux nouvelles annotations : helm.sh/readiness-success et helm.sh/readiness-failure helm pourra procéder au déploiement du groupe de ressources / ou sous charts suivants qu’à partir du moment où le status aura la valeur attendue.

Avec cette évolution, fini les déploiements qui échouent à cause de race conditions (par exemple, une application qui démarre avant sa base de données). Helm attendra que chaque composant soit réellement opérationnel. L’utilisateur pourra avoir un contrôle quasi total sur ce que “succès” ou “échec” signifient à chaque étape de leur déploiement.

D’autres fonctionnalités notables de Helm 4

Helm 4 apporte de nombreuses autres améliorations et fonctionnalités, celles-ci nous semblent plus notables :

• Mise en place d’un cache plus intelligent : le cache de Helm est jusqu’ici basé sur le chart name et sa version, de sorte que si vous avez deux charts différentes (l’une avec un deployment et l’autre avec un statefulset par exemple) mais avec le même nom et version il y a collision. Pour cette raison, helm ne se fie pas à ce cache et télécharge toujours le contenu. Helm 4 devrait dorénavant se baser sur le hash du contenu du chart et choisir ou non de télécharger le contenu sur cette base là.

• La refonte complète du système de plugins avec Wasm : une meilleure sécurisation des plugins, et la rétrocompatibilité avec l’ancien système sera assurée.

• Echec en cas de version de chart non-SemVer : La commande helm package échouera si la version du chart dans Chart.yaml n’est pas exprimée dans une version sémantique (SemVer 2) valide (cela semble encore très prospectif).

Helm 4 : sortie officielle et migration

Pas d’inquiétude côté rétrocompatibilité : les équipes de Helm ont visiblement bien anticipé les problématiques de migration vers Helm 4. Les charts Helm 3 resteront compatibles, et Helm 4 supportera les nouveaux formats de charts (v3) tout en maintenant la compatibilité avec les anciens (v2) (et oui … la numérotation peut prêter à confusion mais on parle bien de charts en version 3 pour Helm 4).

Pour les plus impatients, la version beta est déjà disponible. Pour les autres, la date de release officielle de helm 4 est autour du 10-13 novembre prochain lors de la KubeCon + CloudNativeCon North America 2025. Helm 4 devrait également être au cœur des discussions des prochains Cloud Native Days France que nous aidons à organiser comme nous l’avions fait sur KCD France en 2023. Nous espérons d’ailleurs vivement vous y croiser !

Ce blogpost sera mis à jour lorsque la v4 sera publiée et nous y ajouterons nos retours d’expérience concrets sur la migration à Helm 4 pour des applications sur des clusters Kubernetes de production.

Ne ratez pas nos prochains articles DevOps et Cloud Native! Suivez Enix sur Linkedin!