Helm en 15 minutes : installer et déployer votre premier chart

En 15 minutes, vous allez installer Helm et déployer votre première application sur Kubernetes. À la fin de ce guide, vous saurez installer un chart public, vérifier le déploiement et désinstaller proprement, les 3 opérations de base que vous utiliserez au quotidien.

Ce que vous allez apprendre :

• Installer Helm sur Linux, macOS ou Windows
• Comprendre les 4 termes essentiels : chart, release, repo, values
• Déployer nginx en une commande avec helm install
• Vérifier que tout fonctionne avec helm list et kubectl

Prérequis : un cluster Kubernetes fonctionnel, kind pour cette formation, avec kubectl configuré. Si ce n'est pas le cas, consultez d'abord le guide Kubernetes.

Pourquoi Helm ?

Imaginez que vous devez déployer une application sur Kubernetes. Sans Helm, vous écrivez manuellement plusieurs fichiers YAML (Deployment, Service, ConfigMap, Secret...), puis vous les appliquez un par un avec kubectl apply. Si vous avez 10 environnements, vous dupliquez ces fichiers dix fois. Et quand il faut mettre à jour ? Vous modifiez chaque fichier à la main, en espérant ne rien oublier.

Helm résout ce problème en regroupant tous ces fichiers dans un package appelé "chart". Un chart, c'est comme une recette de cuisine : il contient tous les ingrédients (les fichiers YAML) et les instructions (les templates). Vous ajustez les quantités via un fichier de configuration (values.yaml), et Helm génère automatiquement tous les manifests Kubernetes.

Avant / Après Helm

Sans Helm	Avec Helm
10 fichiers YAML à maintenir	1 chart versionné
"Quelle version est en prod ?" → grep dans les logs	helm list → version, date, statut
Rollback = retrouver les anciens fichiers	helm rollback myapp 2
Config dev/prod = dupliquer tous les YAML	1 chart + values-dev.yaml / values-prod.yaml
Mise à jour = modifier chaque fichier	helm upgrade avec les nouveaux values

Glissez pour voir

Le concept à retenir tient en une équation : release égale chart, plus values, plus version. Quand vous installez un chart avec des values données, Helm crée une release nommée et lui attribue une révision. Cette release est versionnée : vous pouvez consulter son historique et revenir en arrière à tout moment, ce qu'un kubectl apply ne permet pas puisqu'il ne garde aucune trace de l'état précédent.

Vocabulaire minimal

Avant d'installer quoi que ce soit, comprenons les 4 termes que vous verrez partout :

Chart

Un chart est un package Helm. Il contient :

• Des templates YAML (Deployment, Service, etc.) avec des variables
• Un fichier values.yaml avec les valeurs par défaut
• Un fichier Chart.yaml avec les métadonnées (nom, version, description)

Concrètement, un chart est un dossier avec cette structure :

• Répertoiremychart/

  • Chart.yaml Nom, version, description
  • values.yaml Valeurs par défaut
  • Répertoiretemplates/ Fichiers YAML avec variables

    • deployment.yaml
    • service.yaml
    • _helpers.tpl

Release

Une release est une instance d'un chart installée sur votre cluster. Quand vous exécutez helm install my-metrics prometheus-community/kube-state-metrics, vous créez une release nommée my-metrics.

Vous pouvez installer le même chart plusieurs fois avec des noms différents, chaque installation est une release distincte :

helm install metrics-prod prometheus-community/kube-state-metrics -f values-prod.yaml
helm install metrics-dev prometheus-community/kube-state-metrics -f values-dev.yaml

Repository (repo)

Un repository est un serveur qui héberge des charts. C'est comme un "app store" pour Helm. Les plus connus :

Repo	URL	Contenu
prometheus-community	https://prometheus-community.github.io/helm-charts	Charts monitoring (Prometheus, Grafana, exporters)
ingress-nginx	https://kubernetes.github.io/ingress-nginx	Ingress controller officiel Kubernetes SIG

Glissez pour voir

Values

Les values sont les paramètres que vous passez au chart pour le personnaliser. Chaque chart définit des valeurs par défaut dans values.yaml, que vous pouvez surcharger :

# Utiliser les values par défaut
helm install my-metrics prometheus-community/kube-state-metrics

# Surcharger une valeur
helm install my-metrics prometheus-community/kube-state-metrics --set replicas=3

# Surcharger via un fichier
helm install my-metrics prometheus-community/kube-state-metrics -f my-values.yaml

Installer Helm

Helm est un binaire unique sans dépendances. L'installation prend moins d'une minute.

Linux

Depuis le dépôt de paquets signé (recommandé)

# Debian/Ubuntu
curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update && sudo apt-get install helm

# Fedora/RHEL
sudo dnf install helm

macOS

# Via Homebrew
brew install helm

Windows

# Via Chocolatey
choco install kubernetes-helm

# Via Scoop
scoop install helm

# Via winget
winget install Helm.Helm

Vérifier l'installation

helm version

Résultat attendu :

v4.3.0+gbec5b06

Ou en version longue :

version.BuildInfo{Version:"v4.3.0", GitCommit:"bec5b06ed841fe5269972d864d5177944fd5970f", GitTreeState:"clean", GoVersion:"go1.27.1", KubeClientVersion:"v1.37"}

Le champ KubeClientVersion est apparu avec Helm v4, et c'est celui à lire en premier : il annonce la version de la bibliothèque cliente Kubernetes compilée dans votre binaire, donc les versions de cluster que cette build sait piloter. La règle officielle de compatibilité est n-3 : Helm 4.3 couvre Kubernetes 1.37 à 1.34, Helm 4.1 s'arrête à 1.35. Un Helm trop ancien pour votre cluster ne refuse pas de démarrer, il se comporte simplement de façon imprévisible sur les API récentes.

Si la commande affiche un v3.x, ce n'est pas une erreur : c'est une branche différente, encore installée sur beaucoup de postes et parfaitement fonctionnelle. Elle a simplement reçu sa dernière version de fonctionnalités le 9 septembre 2026, et ses correctifs de sécurité s'arrêtent le 10 février 2027.

Les guides de cette formation sont rejoués sur Helm v4.3.0. Les suivre avec une v3 reste possible pour l'essentiel, mais vous rencontrerez des écarts sur trois points précis, --atomic, --dry-run et les post-renderers, que la leçon Migrer vers Helm v4 détaille.

Déployer un chart en 2 minutes

Maintenant que Helm est installé, déployons un outil de monitoring Kubernetes en 4 étapes.

1. Ajouter le repository prometheus-community

   Les charts ne sont pas inclus avec Helm, il faut d'abord ajouter un repo :

   helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

   Résultat attendu :

   "prometheus-community" has been added to your repositories

2. Mettre à jour l'index des charts

   Télécharge la liste des charts disponibles (comme apt update) :

   helm repo update

   Résultat attendu :

   Hang tight while we grab the latest from your chart repositories...
   ...Successfully got an update from the "prometheus-community" chart repository
   Update Complete. ⎈Happy Helming!⎈

3. Installer kube-state-metrics

   Créez une release nommée my-metrics dans le namespace helm-demo :

   helm install my-metrics prometheus-community/kube-state-metrics \
     --namespace helm-demo \
     --create-namespace

   Résultat attendu :

   NAME: my-metrics
   LAST DEPLOYED: Sat Feb  1 17:38:28 2026
   NAMESPACE: helm-demo
   STATUS: deployed
   REVISION: 1
   TEST SUITE: None
   NOTES:
   kube-state-metrics is a simple service that listens to the Kubernetes API
   server and generates metrics about the state of the objects.

   Décryptage de la sortie :

   Ligne	Signification
   NAME: my-metrics	Le nom de votre release, utilisez-le pour toutes les commandes futures (helm upgrade my-metrics, helm uninstall my-metrics)
   LAST DEPLOYED	Date et heure du déploiement, utile pour savoir "quand a été déployée cette version ?"
   NAMESPACE: helm-demo	Le namespace Kubernetes où les ressources ont été créées
   STATUS: deployed	L'installation a réussi. Autres valeurs possibles : failed, pending-install
   REVISION: 1	Numéro de version de la release. S'incrémente à chaque helm upgrade. Permet les rollbacks
   NOTES:	Instructions post-installation, lisez toujours cette section ! Elle indique comment accéder à l'application

   Glissez pour voir

   Les NOTES sont précieuses

   La section NOTES: est générée par le chart et contient des informations spécifiques à lui : URL d'accès, identifiants par défaut, commandes de vérification. Ici, elle explique que kube-state-metrics expose des métriques sur l'état des objets Kubernetes.

4. Attendre que les pods soient prêts

   kubectl get pods -n helm-demo --watch

   Attendez que le statut passe à Running (30-60 secondes), puis appuyez sur Ctrl+C.

Ce chart a été choisi pour apprendre, pas pour son utilité immédiate. kube-state-metrics est léger, réclame environ 50 Mo de mémoire, et expose des métriques sur l'état des objets du cluster. Il est entièrement open source sous licence Apache 2.0, maintenu par la communauté Prometheus, donc ni abandonné ni piloté par un fournisseur. Il s'installe et se désinstalle en quelques secondes sans rien perturber sur un cluster de test.

Vérifier le déploiement

Helm a créé plusieurs ressources Kubernetes. Vérifions que tout est en place.

Lister les releases Helm

helm list est la commande que vous taperez le plus souvent : elle répond à « qu'est-ce qui tourne ici, et dans quel état ». Deux précisions comptent dès le premier jour : elle est limitée à un namespace, celui du contexte courant ou celui passé avec -n, et elle lit les Secrets de ce namespace, pas un serveur Helm.

helm list -n helm-demo

Résultat attendu :

NAME        NAMESPACE   REVISION  UPDATED                                 STATUS    CHART                     APP VERSION
my-metrics  helm-demo   1         2026-02-01 17:48:21.957437663 +0100 CET deployed  kube-state-metrics-7.1.0  2.18.0

Cette commande montre :

• NAME : le nom de votre release
• REVISION : le numéro de version (incrémenté à chaque upgrade)
• STATUS : deployed, failed, pending-install...
• CHART : le chart et sa version
• APP VERSION : la version de l'application (ici kube-state-metrics 2.18.0)

Voir les ressources Kubernetes créées

kubectl get all -n helm-demo

Résultat attendu :

NAME                                                 READY   STATUS    RESTARTS   AGE
pod/my-metrics-kube-state-metrics-76cf999fdf-c5dnl   1/1     Running   0          30s

NAME                                    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/my-metrics-kube-state-metrics   ClusterIP   10.110.86.56   <none>        8080/TCP   30s

NAME                                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/my-metrics-kube-state-metrics   1/1     1            1           30s

Helm a créé un Deployment, un Service et un Pod, le tout à partir d'un seul helm install.

Tester l'accès aux métriques

# Port-forward pour accéder localement
kubectl port-forward svc/my-metrics-kube-state-metrics 8080:8080 -n helm-demo &

# Attendre 2 secondes que le port-forward soit établi
sleep 2

# Tester (affiche les métriques Prometheus)
curl -s http://localhost:8080/metrics | head -10

Résultat attendu :

# HELP kube_configmap_annotations Kubernetes annotations converted to Prometheus labels.
# TYPE kube_configmap_annotations gauge
# HELP kube_configmap_labels [STABLE] Kubernetes labels converted to Prometheus labels.
# TYPE kube_configmap_labels gauge
# HELP kube_configmap_info [STABLE] Information about configmap.
# TYPE kube_configmap_info gauge
kube_configmap_info{namespace="kube-system",configmap="kubeadm-config"} 1
kube_configmap_info{namespace="kube-system",configmap="coredns"} 1

Cette sortie est la seule preuve que le déploiement fonctionne vraiment. Des lignes commençant par # HELP et # TYPE, suivies de métriques au format kube_*, signifient que l'application expose réellement ses métriques Prometheus, et pas seulement qu'elle écoute sur un port. La différence compte : un pod en Running avec un port ouvert peut très bien servir des erreurs, et kubectl get pods n'en dira jamais rien.

# Arrêter le port-forward en arrière-plan
pkill -f "port-forward.*8080"

Désinstaller proprement

Quand vous n'avez plus besoin de la release :

helm uninstall my-metrics -n helm-demo

Résultat attendu :

release "my-metrics" uninstalled

Vérifier le nettoyage

kubectl get all -n helm-demo

Résultat attendu :

No resources found in helm-demo namespace.

Helm a supprimé toutes les ressources qu'il avait créées (Deployment, Service, Pod). Le namespace reste, vous pouvez le supprimer manuellement :

kubectl delete namespace helm-demo

Ressources persistantes

Un PVC rendu depuis templates/ est bien supprimé par helm uninstall, vérification faite. Ce qui survit est ailleurs : les CRD livrés dans crds/, le namespace créé par --create-namespace, et les PVC générés par un StatefulSet via volumeClaimTemplates, que Kubernetes conserve délibérément pour éviter une perte de données. Le contrôle utile après une désinstallation porte donc sur ces trois familles, pas sur les ressources ordinaires.

Erreurs fréquentes

Ces erreurs concentrent la quasi-totalité des blocages d'un premier déploiement, et aucune ne vient du chart : un nom déjà pris, un namespace absent, un dépôt jamais mis à jour. Les reconnaître au message évite de chercher là où il n'y a rien à trouver.

Symptôme	Cause	Solution
Error: INSTALLATION FAILED: cannot reuse a name that is still in use	Une release avec ce nom existe déjà	Choisir un autre nom ou helm uninstall d'abord
Error: chart "kube-state-metrics" not found	Repo non ajouté ou nom incorrect	helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
Error: Kubernetes cluster unreachable	kubectl non configuré	Vérifier kubectl cluster-info
Pods en Pending	Pas assez de ressources sur le cluster	Vérifier kubectl describe pod pour les détails
Pods en ImagePullBackOff	Image introuvable ou registry privé	Vérifier le nom de l'image et les credentials

Glissez pour voir

Lab A1, Déployer Alertmanager

Mettez en pratique ce que vous venez d'apprendre avec un autre chart de la communauté Prometheus.

1. Créer un namespace dédié

   kubectl create namespace helm-lab

2. Ajouter le repo prometheus-community (si pas déjà fait)

   helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
   helm repo update

3. Installer Alertmanager dans le namespace

   helm install my-alertmanager prometheus-community/alertmanager \
     --namespace helm-lab \
     --set persistence.enabled=false

   Résultat attendu :

   NAME: my-alertmanager
   LAST DEPLOYED: Sun Feb  1 17:47:46 2026
   NAMESPACE: helm-lab
   STATUS: deployed
   REVISION: 1

4. Vérifier que le pod est Running

   # Attendre que le pod soit prêt (timeout 2 minutes)
   kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=alertmanager \
     -n helm-lab --timeout=120s
   
   # Vérifier les ressources créées
   kubectl get all -n helm-lab

   Résultat attendu :

   NAME                    READY   STATUS    RESTARTS   AGE
   pod/my-alertmanager-0   1/1     Running   0          30s
   
   NAME                               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
   service/my-alertmanager            ClusterIP   10.106.232.92   <none>        9093/TCP   30s
   service/my-alertmanager-headless   ClusterIP   None            <none>        9093/TCP   30s
   
   NAME                               READY   AGE
   statefulset.apps/my-alertmanager   1/1     30s

5. Validation fonctionnelle, tester l'endpoint de santé

   # Port-forward vers Alertmanager
   kubectl port-forward svc/my-alertmanager 9093:9093 -n helm-lab &
   sleep 2
   
   # Tester l'endpoint de santé
   curl -s http://localhost:9093/-/healthy

   Résultat attendu :

   OK

   Si vous voyez OK, Alertmanager est opérationnel !

6. Désinstaller et nettoyer

   # Arrêter le port-forward
   pkill -f "port-forward.*9093"
   
   # Désinstaller la release
   helm uninstall my-alertmanager -n helm-lab
   
   # Supprimer le namespace
   kubectl delete namespace helm-lab

Critères de réussite :

• Le namespace helm-lab contient un pod Alertmanager en Running
• helm list -n helm-lab affiche la release my-alertmanager avec status deployed
• curl http://localhost:9093/-/healthy retourne OK (validation fonctionnelle)
• Après helm uninstall, plus aucune ressource applicative ne reste
• Vous avez compris la différence entre helm install et kubectl apply

À retenir

• Helm est un gestionnaire de packages pour Kubernetes : un chart = un package réutilisable
• Chart + Values = Release : une release est une instance nommée d'un chart avec sa configuration
• Workflow de base : helm repo add → helm repo update → helm install → helm list → helm uninstall
• Helm 3 est client-only : pas de composant à installer côté cluster
• Les repos open source recommandés : prometheus-community, ingress-nginx et Artifact Hub pour la recherche

Contrôle de connaissances

Cinq questions pour vérifier les points qui comptent vraiment dans cette leçon : ce que helm version vous apprend sur la compatibilité, la section de la sortie qui explique comment accéder à l'application, et le message exact que rend Helm v4 quand un nom de release est déjà pris.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

5 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Trouver et inspecter des charts : Chercher un chart, lire ce qu'il contient avant de l'installer.
• Personnaliser avec les values : Le mécanisme qui rend un chart réutilisable d'un environnement à l'autre.
• Upgrade, rollback et cycle de vie : Ce qui se passe quand une release évolue, et comment revenir en arrière.
• Déboguer et valider un chart : Voir le YAML réellement produit avant de l'envoyer au cluster.

×

📖 Voir la documentation →