Skip to content

Helm

Jump to bottom
ii02735 edited this page Oct 12, 2026 · 1 revision

Helm

Qu'est-ce que Helm ?

Helm est le gestionnaire de paquets de Kubernetes. Il permet d'installer, mettre à jour et désinstaller une application complète — et non un seul manifeste — dans un cluster.

Sans Helm, déployer une application revient à appliquer des dizaines de fichiers YAML à la main (kubectl apply -f …), souvent en recopiant la même configuration d'un environnement à l'autre. Avec Helm, on décrit l'application une seule fois dans un chart, on la paramètre via des values, puis on l'installe en une commande.

Helm : du dépôt au chart, du chart à la release

Note

Un chart ressemble à un paquet (apt, npm…) : c'est une unité réutilisable que l'on peut versionner, publier et partager. Une release est une instance de ce paquet installée dans un cluster.

Un peu d'histoire : Helm 2, Helm 3 et Tiller

Dans Helm 2, un composant serveur appelé Tiller s'exécutait dans le cluster avec de très larges permissions. Toutes les opérations passaient par lui : une compromission de Tiller compromettait le cluster.

Helm 3 a supprimé Tiller. Le client Helm parle directement à l'API Kubernetes, avec vos droits (ceux de votre kubeconfig). Résultat : plus simple et bien plus sûr. Les releases sont stockées dans des Secrets du namespace, et non plus dans des ConfigMaps.

Important

Aujourd'hui, on parle de Helm 3. Si un tutoriel mentionne Tiller ou helm init, il est obsolète.

Le vocabulaire de Helm

  • Chart : un paquet Helm = un ensemble de templates, de valeurs par défaut et de métadonnées décrivant une application.
  • Template : un fichier YAML Kubernetes enrichi de variables (Go template). Il est rendu avec les values pour produire un manifeste final.
  • Values : les paramètres du chart (image, nombre de replicas, ports…). Les valeurs par défaut vivent dans values.yaml.
  • Release : une instance d'un chart installée dans un cluster, sous un nom donné. Le même chart peut donner autant de releases que l'on veut.
  • Repository : un dépôt à partir duquel on télécharge des charts (Artifact Hub, Bitnami, dépôts d'entreprise…).
  • Revision : à chaque helm upgrade, Helm crée une nouvelle révision de la release — ce qui permet de revenir en arrière.

Les trois commandes essentielles

  • helm install <nom> <chart> : installer une release. Helm rend les templates, envoie les objets à l'API et enregistre la release.
  • helm upgrade <nom> <chart> : mettre à jour une release existante (nouvelle image, valeurs modifiées…). Helm calcule la différence et n'applique que ce qui change.
  • helm uninstall <nom> : désinstaller la release et supprimer les objets qu'elle a créés.

On combine souvent les deux premiers : helm upgrade --install installe si la release n'existe pas, sinon la met à jour — très pratique dans une chaîne CI/CD.

Anatomie d'un chart

Un chart typique ressemble à ceci :

mychart/
├── Chart.yaml          # métadonnées : nom, version, appVersion
├── values.yaml         # valeurs par défaut
├── charts/             # sous-charts (dépendances)
├── templates/          # manifests paramétrés
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── _helpers.tpl    # fragments réutilisables (noms, labels…)
│   └── NOTES.txt       # message affiché après l'installation
└── .helmignore

Le fichier Chart.yaml décrit le paquet :

apiVersion: v2
name: mychart
description: Une application d'exemple
type: application
version: 1.2.0        # version du chart
appVersion: "1.27"    # version de l'application empaquetée

Les templates et les values

Un template est un manifeste Kubernetes où certaines valeurs sont remplacées au rendu. Les valeurs proviennent de l'objet .Values, alimenté par les fichiers de values.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "mychart.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

Et les valeurs correspondantes :

# values.yaml
replicaCount: 2
image:
  repository: nginx
  tag: "1.27"
service:
  port: 80

On surcharge les valeurs par défaut au moment de l'installation :

# avec un fichier de valeurs
helm install myapp ./mychart -f values-prod.yaml

# ou directement sur la ligne de commande
helm install myapp ./mychart --set replicaCount=3,image.tag=1.28

La priorité des values

En cas de conflit, la dernière source l'emporte, dans cet ordre :

  1. values.yaml du chart — les valeurs par défaut.
  2. Un fichier passé par -f mon-fichier.yaml (le dernier fichier fourni gagne).
  3. Les surcharges --set clé=valeur — toujours prioritaires.

Tip

helm show values <chart> affiche les valeurs par défaut d'un chart : précieux pour savoir quoi personnaliser.

Les révisions et le rollback

Chaque helm upgrade crée une révision. On peut consulter l'historique et revenir à une version antérieure :

helm history myapp            # toutes les révisions de la release
helm rollback myapp 2         # revenir à la révision 2

C'est l'un des grands avantages de Helm : un « déploiement » devient une opération réversible.

Les commandes principales

  • Chercher et ajouter un dépôt : helm repo add bitnami https://charts.bitnami.com/bitnami
  • Rafraîchir les dépôts : helm repo update
  • Chercher un chart : helm search repo nginx
  • Installer : helm install myapp bitnami/nginx
  • Mettre à jour : helm upgrade myapp bitnami/nginx
  • Installer ou mettre à jour : helm upgrade --install myapp ./mychart
  • Lister les releases : helm list (et helm list -A pour tous les namespaces)
  • Voir l'état d'une release : helm status myapp
  • Vérifier avant d'appliquer : helm install myapp ./mychart --dry-run
  • Afficher le YAML rendu (sans l'appliquer) : helm template myapp ./mychart
  • Voir les values utilisées : helm get values myapp
  • Désinstaller : helm uninstall myapp

Quand utiliser Helm ?

  • Quand on déploie la même application dans plusieurs environnements (dev, staging, prod) avec des valeurs différentes.
  • Quand on veut packager et partager une application — ou la réutiliser d'un projet à l'autre.
  • Quand on installe un logiciel tiers déjà empaqueté (Ingress Controller, Prometheus, base de données…).
  • Quand on veut un cycle de vie réversible (install / upgrade / rollback / uninstall).

Helm ou Kustomize ?

Les deux personnalisent des manifestes Kubernetes, mais différemment :

  • Helm : templating (un vrai langage de gabarits), packaging, gestion des releases et des révisions. Idéal pour distribuer une application.
  • Kustomize : surcouches (overlays) qui partent de YAML valide, sans templates ; intégré à kubectl (kubectl apply -k). Idéal pour adapter ses propres manifestes par environnement.

Ils ne s'opposent pas : un chart Helm peut embarquer du Kustomize, et l'on choisit souvent Kustomize pour ses propres manifests et Helm pour consommer ceux des autres.

Les bonnes pratiques

  • Versionner les charts et leurs valeurs (version, appVersion).
  • Un fichier de values par environnement (values-dev.yaml, values-prod.yaml) plutôt que des --set à rallonge.
  • Tester le rendu avant d'appliquer : helm template et helm install --dry-run.
  • Valider un chart en cours d'écriture : helm lint ./mychart.
  • Ne jamais mettre de secrets en clair dans values.yaml : utiliser des Secrets, sealed-secrets ou external-secrets.
  • Épingler les versions (--version) pour des installations reproductibles.
  • Découper les gros charts en sous-charts (dossier charts/).

Pour aller plus loin

Kubernetes (k8s)

Clone this wiki locally