Helm : le package manager de K8s

Tu sais déployer des Pods, des Deployments, des Services. Mais quand ton application grossit — 7 manifestes YAML, 3 environnements, des dépendances entre services — gérer tout ça à la main devient un cauchemar. C’est exactement le problème que Helm résout. Helm, c’est le gestionnaire de paquets de Kubernetes : il emballe tes manifestes dans un chart réutilisable, versionné et paramétrable. Pense à apt pour Debian ou brew pour macOS, mais pour ton cluster K8s.

Dans ce cours, tu vas comprendre pourquoi Helm est devenu un standard de facto, maîtriser ses commandes essentielles, et déployer un vrai service d’entreprise avec des values par environnement.

Pourquoi Helm est indispensable

Sans Helm, déployer une application sur Kubernetes implique de maintenir à la main chaque fichier YAML : Deployment, Service, ConfigMap, Secret, Ingress, HPA… Multiplie ça par 3 environnements (dev, staging, prod) et tu te retrouves avec des dizaines de fichiers quasi identiques, sans versioning, sans rollback propre, et sans gestion de dépendances.

Helm résout ces problèmes d’un coup :

• Templating — Un seul jeu de templates, paramétré par des fichiers values.yaml différents selon l’environnement.
• Versioning — Chaque déploiement crée une release avec un numéro de révision. Tu peux revenir en arrière en une commande.
• Dépendances — Ton chart peut déclarer qu’il a besoin de PostgreSQL ou Redis, et Helm les installe automatiquement.
• Écosystème — Des milliers de charts publics (Bitnami, Prometheus, cert-manager…) prêts à l’emploi.

🔥 Cas réel — Une équipe SRE que je connais gérait 45 fichiers YAML à la main pour 3 microservices. Après migration vers Helm, ils sont passés à 3 charts + 9 fichiers values. Le temps de déploiement est passé de 40 minutes (avec vérifications manuelles) à 5 minutes avec helm upgrade.

💡 Tip DevOps — Utilise toujours --atomic sur tes helm upgrade en production. Si le déploiement échoue, Helm fait automatiquement un rollback à la révision précédente. Zéro intervention manuelle.

Comprendre les concepts clés

Avant de taper des commandes, tu dois maîtriser quatre notions fondamentales :

Chart — C’est le paquet. Un dossier contenant des templates YAML, un fichier values.yaml avec les valeurs par défaut, et un Chart.yaml qui décrit le chart (nom, version, dépendances). C’est l’équivalent d’un .deb ou d’un .rpm.

Release — C’est une instance d’un chart déployée dans ton cluster. Tu peux installer le même chart plusieurs fois avec des noms de release différents. Par exemple, redis-cache et redis-sessions à partir du même chart Redis.

Repository — C’est le dépôt qui héberge les charts, comme un registry npm ou un repo apt. Les plus connus : Bitnami, prometheus-community, jetstack.

Values — C’est le mécanisme de paramétrage. Le fichier values.yaml contient les valeurs par défaut. Tu les surcharges avec -f values-prod.yaml ou --set image.tag=v2.0 au moment du déploiement.

L’anatomie d’un chart ressemble à ça :

mychart/
├── Chart.yaml          # Metadata (nom, version, dépendances)
├── values.yaml         # Valeurs par défaut
├── templates/          # Templates Go → manifestes K8s
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── _helpers.tpl    # Fonctions helper réutilisables
└── charts/             # Sous-charts (dépendances)

🧠 À retenir — version dans Chart.yaml est la version du chart (le packaging). appVersion est la version de l’application qu’il déploie. Ce sont deux choses distinctes — ne les confonds pas.

Commandes essentielles

Commençons par installer Helm et ajouter un repository de charts :

# Installation de Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
helm version

# Ajouter le repo Bitnami et mettre à jour le cache
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

Maintenant, les commandes que tu utiliseras au quotidien. Pour inspecter un chart avant de l’installer, puis le déployer :

# Voir les values par défaut d'un chart
helm show values bitnami/postgresql > pg-defaults.yaml

# Installer un chart avec des paramètres personnalisés
helm install my-postgres bitnami/postgresql \
  --namespace databases --create-namespace \
  --set auth.postgresPassword=secret \
  --set primary.persistence.size=20Gi

# Lister toutes les releases du cluster
helm list -A

Pour mettre à jour, revenir en arrière ou désinstaller :

# Upgrade avec conservation des values existantes
helm upgrade my-postgres bitnami/postgresql \
  -n databases --reuse-values \
  --set primary.persistence.size=50Gi

# Voir l'historique des révisions
helm history my-postgres -n databases

# Rollback à la révision 1
helm rollback my-postgres 1 -n databases

# Désinstaller proprement
helm uninstall my-postgres -n databases

Et deux commandes indispensables pour le debug — --dry-run simule l’installation sans rien appliquer, et template génère les manifestes YAML finaux :

# Dry-run : simuler sans appliquer
helm install my-postgres bitnami/postgresql --dry-run --debug

# Générer les manifestes pour inspection
helm template my-postgres bitnami/postgresql -f values.yaml > output.yaml

⚠️ Attention — --reuse-values garde les values de la révision précédente, mais ignore les nouvelles valeurs par défaut du chart si tu as changé de version. Préfère -f values.yaml explicitement en production pour éviter les surprises.

Cas concret : déployer un service multi-environnement

Imagine que tu gères un service de paiement pour une plateforme e-commerce. Tu as besoin de le déployer en staging et en production avec des configurations différentes. Voici la stratégie values par environnement :

# values-staging.yaml
replicaCount: 2
image:
  tag: "staging-latest"
resources:
  requests: { cpu: 250m, memory: 256Mi }
  limits: { cpu: 500m, memory: 512Mi }
ingress:
  enabled: true
  hosts:
    - host: payment.staging.example.com
      paths: [{ path: /, pathType: Prefix }]
config:
  logLevel: debug
  environment: staging
autoscaling:
  enabled: false

# values-production.yaml
replicaCount: 3
image:
  tag: "v3.1.0"
resources:
  requests: { cpu: 500m, memory: 512Mi }
  limits: { cpu: "1", memory: "1Gi" }
ingress:
  enabled: true
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  hosts:
    - host: payment.example.com
      paths: [{ path: /, pathType: Prefix }]
  tls:
    - secretName: payment-tls
      hosts: [payment.example.com]
autoscaling:
  enabled: true
  minReplicas: 3
  maxReplicas: 20
config:
  logLevel: warn
  environment: production

Le déploiement est ensuite trivial — une commande par environnement, le même chart, des values différents :

# Staging
helm upgrade --install payment ./payment-chart \
  -n staging --create-namespace \
  -f values-staging.yaml --atomic

# Production
helm upgrade --install payment ./payment-chart \
  -n production --create-namespace \
  -f values-production.yaml --atomic

🔥 Cas réel — En entreprise, ces commandes sont dans ton pipeline CI/CD (GitLab CI, GitHub Actions, ArgoCD). Le développeur merge sur main, le pipeline lance helm upgrade --atomic en production. Pas de SSH, pas d’intervention manuelle. C’est l’essence du GitOps.

💡 Tip DevOps — Utilise helm upgrade --install (avec le flag --install) plutôt que helm install suivi de helm upgrade. Cette commande est idempotente : elle installe si la release n’existe pas, et upgrade si elle existe déjà. Parfait pour le CI/CD.

Pièges fréquents

1. Oublier --create-namespace — Helm ne crée pas le namespace par défaut. Sans ce flag, ton install échoue si le namespace n’existe pas. Ajoute-le systématiquement.

2. Confondre version et appVersion — Tu bumpes appVersion quand tu déploies une nouvelle version de ton code. Tu bumpes version quand tu changes le chart lui-même (templates, valeurs par défaut). En CI/CD, c’est souvent appVersion qui bouge.

3. Ne pas versionner les values — Tes fichiers values-production.yaml doivent être dans Git. Si tu fais des --set manuels en prod sans les tracer, tu perds la reproductibilité. Un jour tu auras besoin de recréer le cluster — et tu seras content d’avoir tout en code.

4. Ignorer helm diff — Avant chaque upgrade en production, installe le plugin helm-diff et lance helm diff upgrade. Tu verras exactement ce qui va changer avant d’appliquer. C’est ton filet de sécurité.

5. Charts publics sans épingler la version — Ne fais jamais helm install sans --version. Sans ça, Helm prend la dernière version disponible. Un chart Bitnami peut changer de breaking entre deux minor. Épingle toujours.

⚠️ Attention — Les PersistentVolumeClaims ne sont pas supprimés par helm uninstall. C’est voulu (pour protéger tes données), mais ça peut surprendre. Pense à nettoyer manuellement les PVC si tu veux vraiment tout supprimer.

Exercice pratique

Mets en pratique ce que tu viens d’apprendre :

1. Installe Helm et ajoute le repo Bitnami
2. Installe Redis : helm install my-redis bitnami/redis --set auth.password=test123 --version 19.6.0 -n redis --create-namespace
3. Vérifie : helm list -n redis et kubectl get pods -n redis
4. Crée ton propre chart : helm create mon-api
5. Modifie values.yaml pour passer à 3 replicas et changer l’image
6. Déploie : helm install mon-api ./mon-api -n dev --create-namespace
7. Upgrade : change le nombre de replicas à 5 avec helm upgrade mon-api ./mon-api -n dev --set replicaCount=5
8. Rollback : reviens à la version précédente avec helm rollback mon-api 1 -n dev

🧠 À retenir — Helm, c’est trois choses : du templating pour ne pas dupliquer tes YAML, du versioning pour tracer et rollback chaque déploiement, et un écosystème de charts publics pour ne pas réinventer la roue. Maîtrise helm upgrade --install --atomic -f values.yaml — c’est la commande que tu utiliseras 90% du temps en production. Le reste, c’est du bonus.