Helm 4 : Les nouveautés qui changent la gestion Kubernetes
Six ans. C'est le temps écoulé depuis la dernière version majeure de Helm. Le 12 novembre 2025, à l'occasion de KubeCon North America et du dixième anniversaire du projet, la CNCF a officiellement annoncé Helm 4. Cette release ne se contente pas d'ajouter quelques fonctionnalités : elle redéfinit les fondations du gestionnaire de packages le plus utilisé de l'écosystème Kubernetes.
Pourquoi une version majeure maintenant ?
Helm 3 a remarquablement bien servi la communauté Kubernetes depuis 2019. Mais l'écosystème a évolué. Kubernetes lui-même a introduit des fonctionnalités majeures comme Server Side Apply (SSA) en version 1.22. Les pratiques de distribution de packages ont migré vers les registres OCI. Les exigences de sécurité se sont renforcées.
Plutôt que d'accumuler des patchs sur une architecture vieillissante, l'équipe Helm a choisi de prendre le temps de repenser certains fondamentaux. Le résultat est une version qui pose les bases des cinq prochaines années de gestion de packages Kubernetes.
Server Side Apply : la fin du three-way merge
Le changement le plus structurant de Helm 4 est l'adoption de Server Side Apply (SSA) comme méthode par défaut pour les installations et mises à jour.
Le problème du three-way merge
Jusqu'à Helm 3, la mise à jour d'une release utilisait un algorithme appelé three-way merge. Helm comparait trois états : le manifest précédent, le manifest actuel, et l'état réel du cluster. À partir de ces trois sources, il calculait un patch à appliquer.
Cette approche présentait des limites frustrantes. Helm ne pouvait pas toujours déterminer quelles ressources avaient été modifiées manuellement dans le cluster. Pire, si un champ était supprimé d'un chart entre deux versions, le three-way merge pouvait échouer à le retirer de la ressource déployée.
Les conflits entre modifications manuelles et déploiements Helm généraient des comportements imprévisibles. Un opérateur modifiait un ConfigMap en urgence, puis le prochain helm upgrade écrasait silencieusement la modification.
Comment SSA résout ces problèmes
Server Side Apply transfère la logique de merge vers l'API server Kubernetes. Au lieu de calculer un patch côté client, Helm envoie le manifest complet au serveur. Kubernetes lui-même détermine les modifications à appliquer en se basant sur les field managers.
Chaque champ d'une ressource Kubernetes est associé à un propriétaire. Quand Helm déploie via SSA, il devient le field manager des champs qu'il définit. Si un autre acteur (un opérateur humain, un autre contrôleur) modifie un champ géré par Helm, un conflit explicite est signalé.
Ce comportement est fondamentalement différent : plutôt que d'écraser silencieusement, Helm 4 génère une erreur claire. L'utilisateur doit explicitement choisir de forcer le conflit avec le flag --force-conflicts=true.
Impact pratique
Pour les équipes DevOps, SSA apporte une prévisibilité accrue. Les déploiements deviennent déterministes : le même chart produit toujours le même résultat, indépendamment de l'état précédent du cluster.
Les ressources custom (CRs) bénéficient particulièrement de ce changement. Helm 3 ne fusionnait pas correctement les custom resources, un problème désormais résolu.
Plugins WebAssembly : extensibilité et sécurité
Le système de plugins a été entièrement reconstruit autour de WebAssembly (WASM).
Architecture modernisée
Les plugins Helm 3 étaient des exécutables natifs lancés dans des sous-processus. Cette approche posait des problèmes de portabilité (un plugin compilé pour Linux ne fonctionnait pas sur macOS) et de sécurité (les plugins avaient accès complet au système de fichiers et au réseau).
Helm 4 introduit un runtime WebAssembly sandboxé. Les plugins WASM s'exécutent dans un environnement isolé avec des permissions explicites. Un plugin de post-rendering n'a pas besoin d'accéder au réseau : le sandbox l'en empêche par défaut.
Trois types de plugins
Helm 4 distingue désormais trois catégories de plugins :
Les CLI plugins étendent les commandes Helm disponibles. Ils ajoutent de nouvelles sous-commandes comme helm diff ou helm secrets.
Les getter plugins permettent de récupérer des charts depuis des sources non standard. Un plugin peut implémenter le téléchargement depuis S3, GCS, ou tout autre système de stockage.
Les post-renderer plugins transforment les manifests générés avant leur application au cluster. C'est le mécanisme utilisé pour injecter des sidecars, modifier des labels, ou appliquer des politiques de sécurité.
Migration des plugins existants
Les plugins Helm 3 continuent de fonctionner. Helm 4 maintient la compatibilité avec les exécutables traditionnels. Cependant, les post-renderers doivent être migrés : il n'est plus possible de passer directement un exécutable à --post-renderer. Un plugin doit être déclaré.
Pour les mainteneurs de plugins, l'effort de portage vers WASM varie selon la complexité. Un plugin simple en Go peut être recompilé avec TinyGo pour produire un module WASM compatible.
Distribution OCI native
Helm 4 renforce significativement le support des registres OCI pour la distribution de charts.
Charts par digest
Une nouveauté attendue : l'installation de charts par digest SHA256. Au lieu de :
helm install myapp oci://registry.example.com/charts/app:1.2.3
Vous pouvez désormais spécifier :
helm install myapp oci://registry.example.com/charts/app@sha256:abc123...
Cette fonctionnalité garantit que le chart déployé est exactement celui attendu, indépendamment des tags mutables. Pour les environnements réglementés exigeant une traçabilité complète de la supply chain, c'est un ajout crucial.
Cache basé sur le contenu
Le cache local de Helm 4 utilise désormais un hash du contenu pour identifier les charts. Helm 3 utilisait le nom et la version, ce qui causait des collisions quand un chart était republié avec le même numéro de version mais un contenu différent.
Le nouveau système élimine cette ambiguïté. Si le contenu change, le hash change, et Helm télécharge la nouvelle version.
Intégration registry améliorée
La commande helm registry login nécessite désormais uniquement le nom de domaine :
# Helm 3
helm registry login registry.example.com/charts
Ce changement aligne le comportement sur les conventions des outils container standards comme docker et podman.
Breaking changes et migration
Helm 4 introduit plusieurs changements incompatibles qu'il faut anticiper.
Renommage de flags CLI
Certains flags ont été renommés pour clarifier leur comportement :
| Helm 3 | Helm 4 | Description |
|--------|--------|-------------|
| --atomic | --rollback-on-failure | Rollback automatique en cas d'échec |
| --force | --force-replace | Force le remplacement des ressources |
Les anciens noms restent fonctionnels mais émettent un avertissement de dépréciation. Planifiez la mise à jour de vos scripts CI/CD.
Post-renderers comme plugins
Le changement le plus impactant pour les workflows existants : les post-renderers doivent être déclarés comme plugins. Si votre pipeline utilise :
helm template myapp ./chart --post-renderer ./my-script.sh
Vous devrez créer un plugin wrapper ou migrer vers le format WASM.
Compatibilité des charts
Bonne nouvelle : les charts v2 (format Helm 3) restent pleinement supportés. Helm 4 introduit le format v3 pour les futurs charts avec de nouvelles fonctionnalités, mais la migration n'est pas obligatoire.
Stratégie de migration recommandée
L'équipe Helm recommande une approche progressive en plusieurs phases.
Phase 1 : Validation en staging
Déployez Helm 4 dans un environnement de test. Exécutez vos pipelines CI/CD existants et identifiez les erreurs liées aux flags renommés ou aux post-renderers.
Testez particulièrement :
- Les scripts utilisant des flags dépréciés
- Les workflows de post-rendering
- L'authentification aux registres OCI
- Les installations par digest si vous prévoyez de les utiliser
Phase 2 : Applications à faible risque
Migrez d'abord les applications non critiques. Observez le comportement de SSA en conditions réelles. Notez les conflits générés et ajustez vos processus.
Phase 3 : Applications critiques
Une fois la confiance établie, migrez progressivement les workloads de production. Gardez Helm 3 disponible pour un rollback si nécessaire.
Coexistence Helm 3 et 4
Helm 3 continuera d'être maintenu pendant la période de transition. Vous pouvez faire coexister les deux versions sur vos systèmes :
# Installation de Helm 4 en parallèle
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4 | bash
Ce qui n'a pas changé
Malgré l'ampleur de la release, Helm 4 préserve l'essentiel de l'expérience utilisateur.
La syntaxe des charts reste identique. Vos templates Go, values.yaml, et Chart.yaml fonctionnent sans modification. Les commandes courantes (install, upgrade, rollback, uninstall) conservent leur interface.
Le modèle de release avec stockage dans des Secrets Kubernetes persiste. Les releases Helm 3 existantes sont compatibles avec Helm 4.
Les limites persistantes
Helm 4 n'adresse pas tous les points de friction historiques.
La gestion des CRDs (Custom Resource Definitions) reste problématique. Helm ne peut toujours pas gérer en toute sécurité le cycle de vie des CRDs lors des mises à jour. La communauté continue de débattre des solutions, mais Helm 4 n'apporte pas d'amélioration majeure sur ce front.
Les dépendances entre charts restent gérées de manière basique. Les scénarios complexes avec des dépendances circulaires ou conditionnelles nécessitent toujours des workarounds.
Conclusion
Helm 4 représente une évolution mûrement réfléchie plutôt qu'une révolution. L'adoption de Server Side Apply modernise les fondations. Les plugins WebAssembly ouvrent de nouvelles possibilités d'extensibilité sécurisée. Le support OCI natif aligne Helm sur les pratiques actuelles de distribution.
Pour les équipes utilisant Helm en production, la migration mérite d'être planifiée dès maintenant. Les breaking changes sont gérables, et les bénéfices de SSA justifient l'effort. Commencez par tester en staging, identifiez les ajustements nécessaires, et migrez progressivement.
Helm 4 pose les fondations des cinq prochaines années de gestion de packages Kubernetes. C'est le moment de monter à bord.