À quoi sert Helm pour Kubernetes ?

Helm est le gestionnaire de paquets de Kubernetes. Il regroupe l'ensemble des manifests YAML d'une application dans un « chart » paramétrable et versionné, qu'on installe, met à jour ou désinstalle en une commande. Il évite de copier-coller et de maintenir des dizaines de fichiers YAML par environnement.

Faut-il migrer de Helm 3 vers Helm 4 ?

Oui à terme : Helm 3 approche sa fin de vie et Helm 4 est la version recommandée. La migration est douce car les charts existants (apiVersion v2) restent compatibles et les releases gérées par Helm 3 sont généralement reprises par Helm 4 sans réécriture.

Qu'est-ce qui change entre Helm 3 et Helm 4 ?

Helm 4 passe par défaut au server-side apply de Kubernetes lors d'une nouvelle installation, ce qui remplace l'ancien merge à trois voies. Il ajoute un système de plugins basé sur WebAssembly, l'intégration de kstatus pour le suivi du déploiement, et le support des fichiers de values multi-documents.

⎈ Helm 4 : le gestionnaire de paquets qui dompte le YAML Kubernetes

📚 Introduction

À la fin de l’article précédent sur Kubernetes, un irritant restait en suspens : le YAML. Déployer une seule application demande déjà un Deployment, un Service, un Ingress, une ConfigMap, un Secret… Multipliez par trois environnements (dev, staging, prod) qui ne diffèrent que par quelques valeurs, et vous voilà à maintenir des dizaines de fichiers quasi identiques, à coups de copier-coller et d’erreurs.

Helm est la réponse de l’écosystème à ce problème. C’est le gestionnaire de paquets de Kubernetes : il regroupe tous ces manifests dans un chart paramétrable, qu’on installe et met à jour en une commande. Nouveauté de taille en 2026 : Helm 4 est sorti, et Helm 3 approche sa fin de vie. Cet article couvre les fondamentaux et ce que la nouvelle majeure change concrètement.

🔎 Qu’est-ce qu’un chart Helm ?

Un chart, c’est un paquet Kubernetes : un dossier structuré qui contient tout le nécessaire pour déployer une application. On le génère avec :

helm create mon-app

La structure obtenue est standardisée :

mon-app/
├── Chart.yaml        # métadonnées : nom, version, description
├── values.yaml       # valeurs par défaut, paramétrables
├── templates/        # manifests Kubernetes avec des variables
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ingress.yaml
└── charts/           # dépendances (sous-charts)

L’astuce est dans le dossier templates/ : les manifests n’y sont pas figés, ils contiennent des variables. Au lieu d’un nombre de répliques en dur, on écrit :

spec:
  replicas: {{ .Values.replicaCount }}

Et la valeur vient de values.yaml. Un même chart sert alors tous les environnements : on change seulement les valeurs, jamais les templates.

🧰 Le cycle de vie d’une release

Quand on installe un chart, Helm crée une release : une instance nommée et versionnée du chart dans le cluster. Tout le cycle de vie tourne autour de cette notion.

# Installer (ou mettre à jour si déjà présent)
helm upgrade --install mon-app ./mon-app \
  --namespace prod --create-namespace \
  --values values.prod.yaml
 
# Lister les releases
helm list --namespace prod
 
# Revenir à la version précédente
helm rollback mon-app
 
# Désinstaller
helm uninstall mon-app --namespace prod

Le helm upgrade --install est le motif que j’utilise partout, y compris en CI : il installe la première fois, met à jour ensuite, sans avoir à distinguer les deux cas. Et le helm rollback est un filet de sécurité précieux : si un déploiement échoue, on revient en arrière en une commande, sans réécrire quoi que ce soit.

📦 Installer des applications toutes prêtes

Helm ne sert pas qu’à empaqueter ses propres applications : c’est aussi le moyen standard d’installer des briques d’infrastructure. Une base de données, un ingress controller, un système de monitoring — la plupart se distribuent sous forme de charts publics, recensés sur Artifact Hub.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm search repo postgresql
helm install ma-db bitnami/postgresql

En trois commandes, on déploie une base PostgreSQL correctement configurée. C’est cette bibliothèque de charts qui fait de Helm un outil incontournable de l’écosystème Kubernetes.

🆕 Ce que Helm 4 change

Helm 4 est la première majeure depuis Helm 3, et elle a été pensée pour une migration douce. L’essentiel à retenir :

Server-side apply par défaut. Pour une nouvelle installation, Helm 4 délègue la fusion des manifests à Kubernetes lui-même, au lieu de calculer le patch côté client (l’ancien « merge à trois voies »). C’est plus fiable et ça élimine toute une catégorie de conflits. Sur les mises à jour et rollbacks, Helm conserve par défaut la méthode d’apply de la release existante.
Plugins WebAssembly. Un nouveau système de plugins optionnel s’appuie sur WebAssembly, avec des plugins officiels de type CLI, getter et post-renderer. Les plugins existants continuent de fonctionner.
Suivi de déploiement avec kstatus. Helm 4 intègre kstatus pour un suivi plus détaillé de l’état réel d’un déploiement.
Values multi-documents. Un fichier de values peut désormais contenir plusieurs documents YAML, là où Helm 3 en imposait un seul.

Point crucial pour la migration : les charts existants restent compatibles. Un chart déployable avec Helm 3 (apiVersion v2) l’est aussi avec Helm 4, et les releases gérées par Helm 3 sont généralement reprises sans réécriture. On peut donc mettre à jour le binaire sans tout refondre.

Et pour ceux qui viennent de loin : Helm 4 conserve l’architecture sans serveur de Helm 3. Le composant Tiller, ce daemon côté cluster qui posait tant de problèmes de sécurité, a été supprimé dès Helm 3 et ne revient pas.

⚠️ Quelques précautions

Migrez, mais planifiez. Helm 3 approchant sa fin de vie, la migration vers Helm 4 n’est pas optionnelle à long terme. Testez sur un environnement non critique avant la production.
Attention au --post-renderer. En Helm 4, on ne passe plus un exécutable arbitraire : il faut fournir un nom de plugin. Un point à vérifier si votre pipeline s’appuyait dessus.
Versionnez vos charts. Le champ version de Chart.yaml n’est pas décoratif : c’est lui qui rend les déploiements traçables et les rollbacks fiables.
Ne mettez pas de secrets en clair dans values.yaml. Ce fichier finit souvent versionné. Passez par des Secrets Kubernetes ou un outil de chiffrement dédié.

🎉 Conclusion

Helm transforme le YAML Kubernetes de fardeau en atout : un chart paramétrable remplace des dizaines de manifests dupliqués, une release versionnée rend les déploiements traçables et réversibles, et Artifact Hub met à portée de commande des milliers d’applications prêtes à l’emploi. Avec Helm 4, l’outil gagne en fiabilité (server-side apply) sans casser l’existant.

En pratique, Helm s’articule avec les autres briques de la pile : Docker produit l’image, Kubernetes l’orchestre, et Helm en fait un déploiement paramétrable et réversible. Pour enchaîner build d’image et déploiement dans un pipeline, GitHub Actions reste mon réflexe côté CI-CD.