Helm chart (paquet d'application Kubernetes)

Un chart Helm est un paquet qui décrit une application Kubernetes complète : ses manifests sous forme de templates, les valeurs qui les paramètrent et des métadonnées de version. Helm, l’outil qui les consomme, joue pour Kubernetes le rôle qu’un gestionnaire de paquets joue pour un système d’exploitation — installer, mettre à jour, revenir en arrière.

Structure d’un chart

Un chart est un répertoire avec une convention stricte : Chart.yaml porte le nom, la version du chart et celle de l’application ; values.yaml déclare les valeurs par défaut ; templates/ contient les manifests Kubernetes écrits avec le moteur de templates de Go. À l’installation, Helm fusionne les valeurs fournies avec les défauts, rend les templates et applique le résultat au cluster. Chaque installation est une release, dont Helm conserve l’historique — c’est ce qui permet helm rollback vers une révision antérieure.

Un chart peut déclarer des dépendances vers d’autres charts (une application et sa base de données, par exemple), résolues depuis des dépôts de charts, qui sont de simples serveurs HTTP ou des registres OCI.

Ce que Helm apporte en production

L’intérêt principal n’est pas d’écrire ses propres charts, mais de consommer ceux de l’écosystème : la quasi-totalité des composants d’infrastructure (ingress controllers, Prometheus, cert-manager) sont distribués sous cette forme, avec des valeurs par défaut raisonnables et des options documentées. Pour ses applications internes, un chart bien tenu donne un déploiement paramétrable par environnement — mêmes templates, values différentes pour la préproduction et la production — versionné et rejouable depuis la CI.

Limites et alternatives

Le templating texte de Go est le reproche récurrent : indentation significative de YAML générée par des directives {{ include }} et nindent, difficile à lire et à déboguer au-delà d’une certaine taille. Kustomize, intégré à kubectl, prend l’approche inverse — des manifests complets surchargés par patchs, sans templates — et suffit souvent pour des applications internes simples. Les deux ne s’excluent pas : consommer les charts tiers avec Helm et gérer ses propres manifests en Kustomize est une combinaison courante. Dans une démarche GitOps, c’est l’outil de réconciliation (Argo CD, Flux) qui rend les charts, et l’historique de release de Helm perd de son importance au profit de l’historique Git.

Un chart reste du code : il se revoit, se versionne et se teste (helm template rend les manifests sans cluster, helm lint attrape les erreurs de structure) comme n’importe quel autre livrable.