Qu'est-ce que Helm ?

À quoi sert Helm

Helm est l'outil de packaging standard de l'écosystème Kubernetes, équivalent à apt pour Debian ou npm pour Node.js. Il résout un problème simple : une application Kubernetes typique se compose de plusieurs ressources (Deployment, Service, Ingress, ConfigMap, Secret, PVC, ServiceAccount, NetworkPolicy), réparties dans 5 à 15 fichiers YAML. Gérer ces fichiers à la main est viable pour une application, ingérable pour cinquante.

Helm résout ce problème en encapsulant un ensemble cohérent de manifests dans un chart : un répertoire structuré contenant les fichiers de template, des valeurs par défaut, des dépendances et une métadonnée de version. Le chart devient l'unité de déploiement.

Le concept de chart

Un chart Helm comprend trois éléments centraux :

• Templates : les manifests Kubernetes paramétrés avec la syntaxe Go template, par exemple {{ .Values.image.tag }} au lieu de 1.2.3 codé en dur.
• values.yaml : les valeurs par défaut du chart (image, ressources CPU/RAM, réplicas, annotations).
• Chart.yaml : métadonnée (nom, version, dépendances, mainteneurs).

À l'installation, l'opérateur passe un fichier values-prod.yaml ou values-staging.yaml qui surcharge les valeurs par défaut. Le même chart peut donc déployer un service en dev avec 1 réplica et 100 Mi de mémoire, ou en production avec 10 répliques et 2 Gi.

Pourquoi Helm est devenu un standard

Réutilisation industrielle. Le hub Artifact Hub recense plus de 12 000 charts publics (Prometheus, Grafana, PostgreSQL, ArgoCD, cert-manager, ingress-nginx, etc.). Installer une stack d'observabilité complète sur Kubernetes prend une commande helm install, pas une journée de YAML.

Versionning et rollback. Chaque helm upgrade est versionné comme une release. helm rollback my-app 3 ramène l'application à l'état de sa 3e release. Le timing typique pour annuler une mise en production cassée tombe de minutes à secondes.

Standard pour la distribution logicielle. Les éditeurs Open Source publient quasi-systématiquement leurs charts officiels. Pour un produit propriétaire, distribuer un chart privé est devenu la norme pour les installations on-premise chez les clients.

Helm 2 vs Helm 3

Une nuance historique importante : Helm 2 (déprécié en 2020) incluait un composant serveur (Tiller) qui posait des problèmes de sécurité majeurs (privilèges cluster-wide, gestion d'identité absente). Helm 3 a supprimé Tiller : l'outil est désormais purement client-side, sans démon ni RBAC dédié. Tous les nouveaux déploiements doivent utiliser Helm 3.

Quand Helm n'est pas optimal

Pour des configurations très spécifiques à un environnement (un seul cluster, peu de variations), Kustomize offre une syntaxe plus déclarative et moins template-heavy. Beaucoup d'équipes combinent les deux : Helm pour les composants tiers, Kustomize pour les overlays internes.

Pour des applications très dynamiques où la configuration change en runtime (feature flags, A/B testing), Helm reste un outil de déploiement, pas de configuration runtime. Des solutions comme ConfigMaps + opérateurs custom prennent le relais.

En pratique chez Hidora

Sur les missions Kubernetes, nous déployons systématiquement nos clients sur Helm 3 avec une structure standardisée :

• Charts internes pour les applications client (versionnés dans Git)
• Charts publics pour les composants tiers (Prometheus, ingress-nginx, cert-manager)
• ArgoCD configuré pour réconcilier les Application qui pointent vers les charts

Services Hidora associés

• Consulting : conception des charts internes, formation de l'équipe développement à la production de charts maintenables.
• Managed Services : exploitation et mise à jour des charts en production avec validation pré-déploiement.
• Kubernetes, GitOps, ArgoCD : briques associées dans la chaîne de déploiement.