Helm : Gestionnaire de package Kubernetes indispensable

Helm : L'Outil Que Je Ne Peux Plus Ignorer

Helm est le gestionnaire de paquets de Kubernetes, et c'est probablement l'outil que j'utilise le plus au quotidien après kubectl. Sur chaque projet, sans exception, Helm est présent. Et j'ai une histoire avec Helm qui illustre pourquoi c'est indispensable.

La Migration Helm v2 vers v3 : Un Passage Obligé

Chez un client dans le secteur de la santé (hébergement HDS sur AWS), j'ai vécu la migration Helm v2 vers v3 en production. Helm v2 utilisait Tiller, un composant serveur déployé dans le cluster avec des droits admin. C'était un trou de sécurité béant. La migration vers v3 a supprimé Tiller et simplifié considérablement l'architecture.

Mais cette migration n'était pas anodine : il fallait convertir toutes les releases existantes, mettre à jour les charts, et s'assurer que les déploiements ArgoCD continuaient de fonctionner. Nous l'avons fait sans downtime, chart par chart, sur un cluster de production avec une trentaine de services.

Pourquoi Helm et Pas du YAML Brut ?

La tentation est grande de déployer du YAML directement avec kubectl apply. Je l'ai fait en début de carrière, et c'est un cauchemar de maintenance dès que vous avez plus de 3 environnements. Helm apporte la templatisation : un seul chart, des values différentes par environnement. Le même chart déploie votre application en dev, staging et prod avec des configurations adaptées.

Sur le projet WizOps lui-même, notre Helm chart déploie le frontend Nuxt et le backend Django avec des values spécifiques par environnement : replicas, limites de ressources, domaines, secrets...

Écrire de Bons Charts Helm

Après avoir écrit des dizaines de charts Helm, voici mes règles :

• Toujours définir des resource requests et limits dans les templates. Un pod sans limits peut consommer toutes les ressources du noeud.
• Utiliser les helpers _helpers.tpl pour les labels et les noms. La cohérence des labels est essentielle pour le monitoring et le debugging.
• Versionner sémantiquement les charts : le chart version et l'app version sont deux choses distinctes.
• Tester avec helm template avant de déployer : ça évite les surprises.

Helm et les Dépendances

Sur une mission dans le secteur e-Santé, j'ai créé un Helm chart avec 4 sous-charts interdépendants (serveur FHIR, base de données, service d'authentification, API gateway). La gestion des dépendances Helm avec Chart.yaml et les conditions d'activation permet de déployer l'ensemble ou une partie de la stack selon le besoin.

L'Écosystème des Charts Publics

L'un des grands avantages de Helm est son écosystème de charts publics. Pour la stack d'observabilité, j'utilise les charts officiels Grafana (kube-prometheus-stack, loki-stack, tempo). Pour le GitOps, le chart officiel ArgoCD. Pour les certificats TLS, cert-manager. Chaque chart est maintenu par la communauté, testé, et documenté.

Mon conseil : ne réinventez pas la roue. Utilisez les charts publics pour les composants d'infrastructure, et écrivez vos propres charts uniquement pour vos applications métier.