Ce que fait Helm

Pourquoi

À la fin du cours Kubernetes, Signalements tient dans une dizaine de fichiers YAML : un Deployment, un Service, un PodDisruptionBudget, une Gateway, une HTTPRoute, un Job de migration. Cela fonctionne, et une kustomization les applique d'un coup. Mais ces fichiers contiennent des choix qui ne sont valables qu'une fois : le nom d'hôte signalements.formation.test, le nombre de répliques, l'étiquette de l'image, le nom du Secret de la base.

Voici trois situations où cela se grippe.

• Un deuxième client. Un autre client de Lyneko veut sa propre instance de Signalements, avec son nom de domaine, sa base, trois répliques au lieu de deux. Copier le répertoire et le modifier à la main donne deux copies qui divergent à la première correction.
• Plusieurs environnements. La recette et la production diffèrent par quelques valeurs (adresse, ressources, répliques). Il faut un moyen d'écrire la structure une fois et de ne faire varier que ces valeurs.
• Les logiciels des autres. Traefik, cert-manager ou Argo CD se déploient avec des dizaines d'objets (Deployment, RBAC, définitions de ressources, webhooks) qu'un éditeur maintient et fait évoluer à chaque version. Personne ne veut recopier ces manifestes dans son dépôt et les resynchroniser à la main.

Helm répond à ces trois besoins par un même mécanisme : un paquet de manifestes paramétrables, versionné, que l'on installe en donnant les valeurs qui diffèrent. Sans lui, on écrit des scripts sed, on copie des répertoires, ou l'on s'interdit d'utiliser des logiciels dont l'installation est trop longue à écrire. Avec lui, installer Traefik tient en une commande, et décliner Signalements pour un nouveau client tient en un fichier de valeurs.

Cette leçon pose le vocabulaire, l'architecture, et les limites de l'outil. Les suivantes l'utilisent.

Les concepts

Les cinq mots à connaître

Le vocabulaire de Helm est court, et tout le reste du cours s'y rattache.

Un chart (« carte », au sens de plan) est le paquet : un répertoire, ou une archive .tgz, qui contient des modèles de manifestes Kubernetes, des valeurs par défaut pour les paramétrer, et des métadonnées (nom, version). Un chart décrit une application, pas une installation particulière : le chart traefik est le même pour tout le monde.

Les valeurs (values) sont les paramètres d'une installation : un arbre de clés et de valeurs au format YAML. Le chart fournit des valeurs par défaut (values.yaml) ; l'utilisateur en surcharge certaines à l'installation, par un fichier ou en ligne de commande. Les modèles du chart lisent ces valeurs pour produire les manifestes.

Une release est une installation d'un chart dans un cluster, sous un nom. Si vous installez deux fois le chart signalements, sous les noms signalements-client-a et signalements-client-b, vous obtenez deux releases, indépendantes, avec leurs propres valeurs et leur propre historique. Une release a des révisions : chaque mise à jour en crée une, ce qui permet de revenir en arrière.

Un dépôt (repository) est un serveur HTTP qui publie une liste de charts (un fichier index.yaml) et leurs archives. Un registre OCI est un registre de conteneurs (le même genre de serveur que celui qui stocke vos images) utilisé pour stocker des charts, comme des artefacts. Les deux servent à distribuer des charts ; le second tend à devenir la norme, et la leçon 9 lui est consacrée.

Enfin, le client : la commande helm. C'est un programme que vous lancez, qui lit un chart, calcule les manifestes, et les envoie à l'API de Kubernetes.

    flowchart LR
  C["Chart<br/>(modèles + valeurs par défaut)"] --> H["helm<br/>(rendu des modèles)"]
  V["Vos valeurs<br/>(-f, --set)"] --> H
  H --> M["Manifestes YAML"]
  M --> API["API Kubernetes"]
  H --> R["Secret de release<br/>(historique)"]
  R --> API
  

Ce qu'une release garde en mémoire

Helm ne se contente pas d'appliquer des manifestes : il retient ce qu'il a installé. À chaque installation ou mise à jour, il écrit dans le cluster un objet qui contient le chart utilisé, les valeurs fournies et les manifestes produits. Par défaut, d'après la documentation, « release information is stored in Secrets in the namespace of the release ». C'est ce qui permet à helm list de lister les releases, à helm rollback de revenir en arrière, et à helm upgrade de savoir ce qui a changé. La leçon 3 montre ce mécanisme en détail.

Il n'y a donc pas de base de données de Helm quelque part : l'état est dans le cluster, à côté de l'application, dans le namespace de la release.

Un client, sans serveur

La première version de Helm (Helm 2) avait un composant serveur, Tiller, installé dans le cluster avec des droits très étendus : tout utilisateur qui pouvait lui parler pouvait installer n'importe quoi. Helm 3 l'a supprimé, comme le rappelle la page des changements depuis Helm 2. Aujourd'hui, la commande helm agit avec vos propres droits : elle lit votre fichier kubeconfig, comme kubectl, et ses requêtes sont soumises à votre RBAC. Si vous ne pouvez pas créer de Deployment dans un namespace avec kubectl, vous ne pourrez pas non plus le faire avec helm.

C'est un point de sécurité important, et c'est aussi une limite : sans composant dans le cluster, rien ne surveille les releases entre deux commandes. Nous y revenons à la fin de cette section.

Helm 4

Helm 4 a été publié le 12 novembre 2025. La version 4.3.0 date du 9 septembre 2026 ; la branche 3 continue de recevoir des versions. Les notes de version décrivent Helm 4 comme une version majeure, avec des changements incompatibles dans les options et les sorties de la ligne de commande et dans le SDK, mais moins étendus que ceux de Helm 2 vers Helm 3. Les charts d'apiVersion: v2, c'est-à-dire la grande majorité des charts actuels, restent pris en charge.

Ce qu'il faut retenir, d'après les notes de version et la page de présentation :

• L'application côté serveur (server-side apply) est prise en charge. Pour une nouvelle installation, Helm 4 l'utilise par défaut ; pour une mise à jour, il suit la méthode d'application de la release précédente, et une release créée par Helm 3 reste donc en application côté client après le passage à Helm 4. L'option --server-side permet de choisir. La leçon 3 explique la différence.
• L'attente des ressources repose sur kstatus, la bibliothèque qui interprète l'état des ressources Kubernetes, ce qui rend --wait plus fiable.
• Deux options sont renommées : --atomic devient --rollback-on-failure, et --force devient --force-replace. Les anciens noms continuent de fonctionner et affichent un avertissement de dépréciation.
• Le système d'extensions est refondu, avec un environnement d'exécution WebAssembly optionnel. Les post-renderers (programmes qui retouchent les manifestes produits) deviennent des extensions : on les désigne par le nom d'une extension, plus par un exécutable.
• Les charts peuvent être installés par empreinte : helm install monapp oci://registre.example.com/charts/app@sha256:....
• Les archives de charts sont reproductibles : construire deux fois le même chart donne la même archive, ce qui facilite la vérification.
• Une nouvelle version d'API de chart (v3) est annoncée comme expérimentale ; elle n'est pas utilisée dans ce cours.

Helm et Kustomize

Kustomize, intégré à kubectl (leçon 11 du cours Kubernetes), répond à une partie du même besoin par une méthode opposée.

Aucun n'est « meilleur ». Helm excelle pour distribuer : un éditeur écrit un chart une fois, des milliers d'équipes l'installent avec leurs valeurs. Kustomize excelle pour adapter ses propres manifestes à quelques environnements, sans écrire de gabarits. Les deux se combinent : Argo CD peut rendre un chart Helm puis y appliquer des correctifs, et l'on peut déployer un chart tiers avec ses valeurs tout en gardant ses propres manifestes en Kustomize. Le cours Kustomize détaille cet autre outil ; l'essentiel pour choisir est ci-dessous, dans « En production ».

Ce que Helm ne fait pas

Un point surprend souvent : Helm n'est pas un outil de réconciliation continue. Quand vous lancez helm upgrade, il compare, applique, puis rend la main. Entre deux commandes, personne ne regarde si quelqu'un a modifié un objet à la main (kubectl edit, kubectl scale), si un objet a été supprimé, ou si le dépôt contenant vos valeurs a changé. La dérive n'est détectée, et corrigée, qu'au prochain helm upgrade.

Helm ne sait pas non plus :

• décider quand déployer : il n'a ni déclencheur sur un dépôt Git, ni planification ;
• faire un déploiement progressif intelligent : il crée les objets, et c'est le Deployment qui remplace les pods ; il n'y a ni canari ni analyse de métriques ;
• garder des secrets : il écrit dans les manifestes ce que vous lui donnez, et les valeurs sensibles de la release se retrouvent dans le Secret de release (la leçon 6 y revient) ;
• gérer l'ordre de création de tout : il installe les objets dans un ordre fixe par type, sans dépendances explicites entre eux, sauf par les hooks (leçon 8).

Ce vide est celui que comble le GitOps. Chez Lyneko, Helm sert à produire les manifestes (le chart de Signalements, les charts de Traefik et de cert-manager), et Argo CD décide quand les appliquer, compare en continu le cluster et Git, et corrige les écarts (cours GitOps avec Argo CD). Argo CD n'installe d'ailleurs pas les charts avec helm install : il rend les manifestes comme helm template le fait, puis les applique lui-même. Il n'y a donc pas de release Helm dans le cluster pour ces applications. La leçon 10 revient sur cette différence, qui a des conséquences concrètes.

En pratique

Cette section n'a besoin d'aucun cluster : helm create et helm template ne parlent qu'à votre disque.

Créer un chart d'exemple

$ helm create demo
Creating demo

La commande génère un chart complet, qui déploie un serveur nginx. Il est conçu pour servir de point de départ, et il montre toutes les parties d'un chart. Regardons l'arborescence :

$ find demo | sort
demo
demo/.helmignore
demo/Chart.yaml
demo/charts
demo/templates
demo/templates/NOTES.txt
demo/templates/_helpers.tpl
demo/templates/deployment.yaml
demo/templates/hpa.yaml
demo/templates/ingress.yaml
demo/templates/service.yaml
demo/templates/serviceaccount.yaml
demo/templates/tests
demo/templates/tests/test-connection.yaml
demo/values.yaml

Chaque élément a un rôle précis.

• Chart.yaml : l'identité du chart. Le nom, la version du chart, la version de l'application, une description. Aucun chart n'existe sans lui.
• values.yaml : les valeurs par défaut. C'est l'interface publique du chart : tout ce qu'un utilisateur peut régler y figure.
• templates/ : les modèles de manifestes. Les fichiers qui produisent des objets (deployment.yaml, service.yaml) sont rendus puis envoyés à Kubernetes. Les fichiers dont le nom commence par un tiret bas (_helpers.tpl) ne produisent aucun objet : ils contiennent des fragments réutilisables. NOTES.txt est le message affiché à l'utilisateur après l'installation. Le sous-répertoire tests/ contient des pods exécutés à la demande (leçon 8).
• charts/ : les charts dont celui-ci dépend (leçon 7). Il est vide ici.
• .helmignore : les fichiers à exclure quand on fabrique l'archive, comme .gitignore.

Lisons Chart.yaml, sans ses commentaires :

$ grep -v '^#' demo/Chart.yaml | grep -v '^$'
apiVersion: v2
name: demo
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: "1.16.0"

apiVersion: v2 est le format de chart de Helm 3 et 4. version est la version du chart (le paquet), appVersion celle de l'application qu'il installe : ce sont deux choses différentes, et la leçon 4 y revient.

Et les valeurs par défaut, abrégées :

$ helm show values demo | grep -v '^\s*#' | grep -v '^$' | head -8
replicaCount: 1
image:
  repository: nginx
  pullPolicy: IfNotPresent
  tag: ""
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""

Produire les manifestes

helm template rend les modèles avec les valeurs, et affiche le résultat, sans rien envoyer au cluster. Il prend un nom de release (ici web) puis le chart :

$ helm template web demo | grep '^# Source'
# Source: demo/templates/serviceaccount.yaml
# Source: demo/templates/service.yaml
# Source: demo/templates/deployment.yaml
# Source: demo/templates/tests/test-connection.yaml

Quatre objets, chacun précédé d'un commentaire qui dit de quel fichier du chart il vient : c'est la meilleure aide quand un manifeste produit surprend. hpa.yaml et ingress.yaml n'apparaissent pas : leurs modèles sont conditionnés par des valeurs (autoscaling.enabled, ingress.enabled) qui valent false par défaut. Regardons le Service :

$ helm template web demo --show-only templates/service.yaml
---
# Source: demo/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: web-demo
  labels:
    helm.sh/chart: demo-0.1.0
    app.kubernetes.io/name: demo
    app.kubernetes.io/instance: web
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: demo
    app.kubernetes.io/instance: web

Plusieurs choses se lisent ici. Le nom web-demo est construit : nom de la release, tiret, nom du chart. Deux releases du même chart ont donc des objets de noms différents et peuvent cohabiter dans un namespace. Les étiquettes app.kubernetes.io/* sont celles que recommande Kubernetes (leçon 5 du cours Kubernetes) ; le chart les pose pour vous, y compris managed-by: Helm. Le sélecteur du Service reprend name et instance, qui identifient cette release et pas une autre.

Changeons une valeur, en ligne de commande, pour voir le rendu changer :

$ helm template web demo --set replicaCount=3 --show-only templates/deployment.yaml | sed -n 12,16p
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: demo

L'option --set replicaCount=3 a remplacé la valeur par défaut 1. Aucune modification du chart : c'est tout le principe. La leçon 2 détaille les façons de fournir des valeurs.

Ce que l'on ferait sur un cluster

Sans rien exécuter ici, voici ce que feraient les commandes suivantes sur le cluster kind formation :

$ helm install web demo --namespace formation --create-namespace
$ helm list --namespace formation
$ kubectl get secret --namespace formation

La première rend les modèles, applique les quatre objets et enregistre la release. La deuxième affiche une ligne par release : nom, namespace, révision, état, chart, version de l'application. La troisième montre, en plus des objets du chart, un Secret de type helm.sh/release.v1 nommé sh.helm.release.v1.web.v1, qui est la mémoire de la release. Le nom suit le motif sh.helm.release.v1.<release>.v<révision>. Vous le retrouverez à la leçon 3.

Sous le capot

Un chart est une archive. Un répertoire de chart peut être empaqueté par helm package en une archive .tgz nommée <nom>-<version>.tgz. C'est cette archive qui est publiée dans un dépôt ou un registre. Un chart installé depuis un dépôt est téléchargé, décompressé en mémoire, puis traité exactement comme un répertoire local.

Le rendu. helm charge le chart, fusionne les valeurs (celles du chart, puis les vôtres, avec les règles de priorité de la leçon 2), puis exécute chaque fichier de templates/ avec le moteur de gabarits du langage Go (le package text/template), enrichi des fonctions de la bibliothèque Sprig et de quelques fonctions de Helm. Le résultat est du texte ; Helm le lit comme du YAML, vérifie qu'il est valide, le range en objets Kubernetes, puis les trie par type pour l'installation. Les modèles produisent donc du texte, pas des objets : c'est la source de la plupart des erreurs d'indentation (leçon 5).

L'envoi à l'API. Pour une installation, Helm crée les objets un par un par l'API Kubernetes. Pour une mise à jour, il compare l'ancien manifeste enregistré dans la release, l'état actuel dans le cluster, et le nouveau manifeste, puis envoie un correctif (patch) : c'est la fusion à trois voies, détaillée à la leçon 3. Avec --wait, il attend ensuite que les ressources soient prêtes.

L'enregistrement de la release. Une fois les objets appliqués, Helm écrit (ou met à jour) le Secret de release. Son contenu est l'enregistrement de la release, sérialisé, compressé puis encodé. Le dossier de stockage est choisi par la variable d'environnement HELM_DRIVER, qui accepte secret (le défaut), configmap ou sql. La documentation signale une limite : si l'enregistrement dépasse 1 Mio, il ne tient pas dans un Secret ou un ConfigMap à cause de la limite d'etcd, et le backend SQL est alors la solution.

Pas de réconciliation, pas de surveillance. Rien de ce qui précède n'est un processus qui continue de tourner. Chaque commande helm est un programme qui démarre, agit, et s'arrête. C'est ce qui fait la simplicité de Helm, et sa limite.

Pièges courants

Confondre version et appVersion. Changer appVersion dans Chart.yaml ne change rien tout seul : c'est une information. Ce qui déploie la nouvelle image, c'est une valeur (image.tag) ou un modèle qui lit .Chart.AppVersion. Et changer la version du chart sans changer ses modèles produit une nouvelle révision de release sans aucun effet.

Croire que helm template valide contre le cluster. Il produit du texte YAML. Une apiVersion inexistante, un champ mal orthographié ou un quota dépassé n'apparaissent pas : seule une application réelle, ou --dry-run=server, les attrape. Par ailleurs, helm template suppose par défaut une version de Kubernetes fixe (sur Helm 3.16, v1.31.0) et n'a pas de cluster pour savoir quelles API existent : pour tester un modèle qui dépend de .Capabilities, passez --kube-version et --api-versions.

Modifier à la main un objet d'une release. Le prochain helm upgrade peut écraser la modification ou la conserver selon le champ (leçon 3), et aucun avertissement n'est donné. La bonne méthode est de changer les valeurs, pas l'objet.

Prendre le nom de release pour un détail. Le nom d'une release est unique par namespace et entre dans les noms des objets. Le renommer revient à tout recréer. Choisissez-le avec soin, et de façon prévisible (par exemple le nom de l'application).

Penser que Helm « garde le cluster conforme ». Une release marquée deployed dit seulement que la dernière commande a réussi. Elle ne dit rien de l'état actuel des objets.

Installer un chart sans le lire. Un chart peut créer des rôles RBAC à l'échelle du cluster, des webhooks d'admission, des définitions de ressources. helm template ou helm show permettent de le vérifier avant d'installer (voir « Sécurité »).

Sécurité

• Helm agit avec vos droits. Il n'y a pas de composant privilégié dans le cluster, mais votre kubeconfig est utilisé pour tout. Un utilisateur de CI qui lance helm upgrade doit avoir exactement les droits nécessaires dans le namespace de la release, y compris le droit de lire et d'écrire les Secrets de release.
• Un chart est du code exécuté avec vos droits. Il ne lance pas de programme, mais il produit des manifestes qui peuvent créer des ClusterRole, des ClusterRoleBinding, des webhooks, des pods privilégiés. Installer un chart d'une source inconnue sans le relire équivaut à appliquer un manifeste inconnu en administrateur. La leçon 9 couvre la signature et la vérification de l'origine.
• Le Secret de release contient vos valeurs. Si vous passez un mot de passe en --set, il est enregistré, avec les manifestes rendus, dans le Secret de release. Quiconque peut lire les Secrets du namespace peut le lire, et il est conservé dans l'historique. Les valeurs sensibles ne doivent pas passer par les valeurs d'un chart : le chart référence un Secret qui existe déjà (créé par External Secrets, par exemple), comme databaseSecretName dans le chart de Signalements.
• Les charts tiers évoluent. Épingler la version d'un chart (--version) évite qu'une mise à jour imprévue change vos manifestes (leçon 2).

En production

• Helm pour distribuer, Kustomize pour adapter. Règle simple chez Lyneko : on utilise un chart quand l'application est publiée sous forme de chart (Traefik, cert-manager, Argo CD), ou quand on veut offrir des réglages explicites à d'autres équipes (le chart de Signalements). On préfère des manifestes bruts et Kustomize quand l'application est simple et que l'on n'a que deux ou trois environnements : un gabarit est du code en plus à maintenir.
• Un chart par application, une release par environnement. Le même chart, avec un fichier de valeurs par environnement, déployé sous le même nom de release dans des namespaces ou des clusters distincts.
• Helm n'est pas le déployeur. En production, personne ne tape helm upgrade sur un cluster : c'est Argo CD qui rend le chart et applique. Helm reste l'outil du poste de travail et de la CI, pour développer, tester et publier les charts (lint, template, package).
• Helm 3 ou Helm 4. Les deux cohabitent. Un chart d'apiVersion: v2 fonctionne avec les deux. Pour une équipe qui démarre, Helm 4 est la version à retenir ; pour un parc existant, testez la mise à jour sur un cluster de recette, car l'application côté serveur et le rendu des options peuvent changer le comportement des mises à jour.
• Les charts, comme du code. Un chart a une version, une revue, un dépôt, des tests. La leçon 9 les publie, la leçon 10 les déploie.

Exercices

1. Lire un chart (niveau 100). Dans le chart demo, quel fichier contrôle le nombre de répliques, quel fichier contient le nom de l'image, et lequel est affiché à la fin d'une installation ?

2. Deux releases (niveau 200). Vous rendez deux fois le chart demo, sous les noms a et b, avec helm template a demo et helm template b demo. Quels éléments des manifestes changent, et pourquoi les deux releases pourraient-elles coexister dans le même namespace ?

3. Surcharger une valeur (niveau 200). Faites afficher, sans modifier le chart, le Deployment avec l'image nginx:1.27 et deux répliques. Quelle commande, et quelles lignes du rendu vérifiez-vous ?

4. Helm ou Kustomize (niveau 300). Lyneko doit (a) installer cert-manager sur trois clusters, (b) déployer Signalements en recette et en production avec deux ou trois différences, (c) proposer Signalements à dix clients, chacun avec son nom d'hôte, sa base et son dimensionnement. Quel outil proposez-vous pour chaque cas, et pourquoi ?

Récapitulatif

• Helm est un gestionnaire de paquets pour Kubernetes : un chart (modèles + valeurs par défaut + métadonnées) installé en release avec des valeurs, distribué par un dépôt HTTP ou un registre OCI.
• Helm est un client seul : pas de Tiller depuis Helm 3, tout se fait avec vos droits ; l'état d'une release est dans des Secrets du namespace (sh.helm.release.v1.<release>.v<révision>).
• helm template rend les manifestes sans cluster : c'est l'outil de relecture, qui ne valide pas contre l'API.
• Un chart est un répertoire (Chart.yaml, values.yaml, templates/, charts/, .helmignore) ou une archive .tgz.
• Helm 4 (12 novembre 2025) apporte l'application côté serveur, l'attente par kstatus, --rollback-on-failure et --force-replace, les extensions WebAssembly, l'installation par empreinte ; les charts v2 restent pris en charge.
• Helm distribue, Kustomize adapte ; les deux se combinent.
• Helm ne réconcilie pas : entre deux commandes, personne ne surveille le cluster. C'est le rôle du GitOps, donc d'Argo CD chez Lyneko.

Pour aller plus loin

• La page Using Helm de la documentation, pour le vocabulaire officiel, et la page Charts pour la structure complète d'un chart.
• La page Changes since Helm 2, pour comprendre pourquoi Tiller a disparu et ce que la fusion à trois voies apporte.
• Les notes de version de Helm 4.0.0 sur le dépôt helm/helm, et la page de présentation de Helm 4 sur helm.sh, pour la liste à jour des changements.
• La leçon suivante, Installer et configurer un chart, qui installe Traefik avec ses valeurs.