Helm 4 est sorti comme prévu fin 2025 lors de la KubeCon + CloudNativeCon North America. Nous avions anticipé les principales nouveautés dans cet article — voici ce que la release finale confirme et précise
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 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 utilise désormais le Server Side Apply (SSA) par défaut, mais uniquement pour les nouvelles installations. Pour les upgrades et rollbacks, Helm conserve la méthode utilisée lors de l’installation initiale : toutes vos releases existantes créées avec Helm 3 continueront donc d’utiliser le client-side apply après la migration vers Helm 4. Il faudra passer le flag --server-side explicitement pour forcer le basculement sur une release existante.
En cas de conflit à l’occasion d’une modification apportée sur le même champ par des propriétaires différents, helm 4 va alors générer une erreur plutôt que d’écraser tout avec un patch. Les conflits peuvent donc toujours se produire… mais l’utilisateur en est cette fois explicitement informé !
On relève que Helm 4 prévoit, 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. À noter également : le flag --force est renommé en --force-replace. L’ancien nom reste fonctionnel mais émet désormais un warning de déprécation — pensez à mettre à jour vos scripts d’automatisation.
On note toutefois que Helm 4 ne gère pas deux cas possibles :
- plusieurs propriétaires d’un même manifest : dans un premier temps il ne peut y avoir qu’un unique propriétaire par manifest helm ;
- transfert de propriété d’un champ : contrairement à l’API Kubernetes il n’est 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 est assurée, à moins que vous n’ayez un cluster kubernetes dans une version inférieure à 1.22… mais cela nous semble peu probable !
En cas de doute, la documentation officielle indique les étapes à suivre pour une migration en toute sérénité .
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 est 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 attend que chaque composant soit réellement opérationnel. L’utilisateur peut 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 se base dorénavant sur le hash du contenu du chart et choisit ou non de télécharger le contenu sur cette base là.
La refonte complète du système de plugins avec Wasm : Helm 4 introduit un runtime optionnel basé sur WebAssembly, avec trois types de plugins officiels — CLI, getter et post-renderer. Les plugins existants continuent de fonctionner sans modification. Attention toutefois à un breaking change important : les post-renderers ne peuvent plus être passés comme un exécutable arbitraire via
--post-renderer. Il faut désormais passer un nom de plugin. Si vous utilisez des post-renderers dans vos pipelines CI/CD, une adaptation sera nécessaire.Avertissement en cas de version de chart non-SemVer : helm lint émet désormais un warning si la version du chart dans Chart.yaml n’est pas exprimée en SemVer 2 valide. La commande helm package n’échoue pas pour autant, c’est donc une alerte préventive plutôt qu’un blocage.
Une autre fonctionnalité que nous n’avions pas mentionnée initialement est le support des fichiers de values multi-documents : jusqu’ici, un fichier de values Helm ne pouvait contenir qu’un seul document YAML. Helm 4 autorise désormais l’utilisation du séparateur
---au sein d’un même fichier de values, permettant d’y inclure plusieurs documents YAML distincts. Concrètement, cela facilite la gestion de configurations complexes : il devient possible de structurer logiquement un fichier de values très dense, ou de regrouper dans un seul fichier des valeurs destinées à différents contextes, sans avoir à multiplier les appels -f dans vos commandes Helm.
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 existantes (v2, celles de Helm 3) continuent de fonctionner sans modification. Un nouveau format de charts v3 est prévu, mais il n’est pas encore disponible dans Helm 4.0 - la documentation officielle le mentionne comme “coming soon” pour 2026 (et oui … la numérotation peut prêter à confusion mais on parle bien de charts en version 3 pour Helm 4).
A la date de mise à jour de cet article, la release la plus récente est la version 4.1.3 comportant une première série de fix. Pour une revue plus exhaustive des modifications apportées par Helm 4, n’hesitez pas a revoir le changelog complet de l’equipe Helm.
Ne ratez pas nos prochains articles DevOps et Cloud Native! Suivez Enix sur Linkedin!