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.

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.

• 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.

• 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.

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

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

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.

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.

• 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 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).

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.

• 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/).

• Les objets qu'un chart déploie : Les Deployments, Les Services, Les ConfigMaps et Secrets, Les Ingress.
• La boîte à outils en ligne de commande : kubectl.
• Le catalogue public de charts : Artifact Hub.