infra / kubernetes

Helm : les bases des charts

Leçon 141 exercice

Explication

Ce que vous allez apprendre

Comprendre le problème de duplication que Helm résout entre environnements
Comprendre l'analogie entre Helm et un gestionnaire de paquets classique (npm, apt)
Distinguer la structure d'un chart (templates/) de ses valeurs (values.yaml)
Installer un chart communautaire existant plutôt que réécrire des manifestes à la main
Vérifier un chart avec helm template et --dry-run avant tout déploiement réel

Dans quel contexte ?

Une équipe gère trois environnements (dev, staging, prod) avec des fichiers YAML quasi identiques, dupliqués manuellement : un deployment-dev.yaml, un deployment-staging.yaml, un deployment-prod.yaml. Un jour, il faut ajouter une variable d'environnement partout : le développeur oublie de la reporter dans le fichier de staging, qui se retrouve donc différent des deux autres sans que personne ne s'en aperçoive avant plusieurs semaines. Helm règle ce problème à la racine en gardant un seul template, dont seules les valeurs changent d'un environnement à l'autre.

Le problème de la duplication de manifestes

D'abord, un constat : déployer une application réelle demande souvent plusieurs fichiers YAML liés entre eux, comme un Deployment, un Service, un Ingress, un ConfigMap.

Ce qui varie selon l'environnement

Ces fichiers changent légèrement selon l'environnement, dev, staging, prod. Copier-coller ces manifestes en changeant deux ou trois valeurs à la main devient vite source d'erreurs et difficile à maintenir.

La solution : un système de paquet pour Kubernetes

Helm répond à ce problème en introduisant un système de "paquet" pour Kubernetes, appelé chart.

Une analogie utile pour comprendre son rôle

Helm joue pour Kubernetes le rôle qu'un gestionnaire de paquets, comme npm pour JavaScript ou apt pour Linux, joue pour un système : installer des logiciels tout prêts, packagés par d'autres, en une commande.

Concept Helm	Équivalent
Chart	Un paquet installable (comme un paquet npm)
`values.yaml`	La configuration surchargeable de ce paquet
`templates/`	Les manifestes YAML génériques, remplis avec les valeurs
`helm install`	L'équivalent de `npm install`, appliqué au cluster

Prérequis

Cette leçon suppose les Deployments, Services et ConfigMaps déjà connus : Helm ne remplace aucun de ces objets, il ne fait qu'automatiser leur génération à partir d'un modèle unique.

Un exemple concret de ce que ça évite

Une entreprise qui a besoin de PostgreSQL sur son cluster n'a pas à écrire un Deployment, un Service, un PVC à la main : un chart communautaire comme Bitnami fait déjà tout cela, testé et maintenu par d'autres.

Ce qu'un chart sépare, et pourquoi

Un chart sépare la structure, les fichiers dans templates/ écrits avec un langage de templating, des valeurs concrètes rassemblées dans values.yaml.

Le bénéfice concret de cette séparation

Le même chart peut ainsi produire des manifestes différents selon les valeurs fournies : 2 replicas en dev, 10 en production, simplement en changeant un fichier de valeurs, sans dupliquer aucun template. C'est le même principe que les ConfigMaps, qui séparaient déjà code et configuration, mais appliqué cette fois à la structure des déploiements.

Piège fréquent

Lancer helm install directement sans avoir vérifié le rendu final est risqué : un chart mal configuré peut produire un YAML invalide ou incohérent, appliqué tel quel au cluster. Toujours passer par helm template ou helm install --dry-run en premier.

Vérifier avant d'appliquer

Un chart mal écrit peut générer un YAML invalide ou incohérent. helm template et helm install --dry-run permettent de voir exactement le YAML final qui serait produit, sans rien appliquer au cluster.

Ce réflexe de prudence est essentiel avant tout déploiement réel. La leçon suivante aborde une question différente mais tout aussi essentielle : qui a le droit de faire quoi sur le cluster, avec RBAC.

Commandes & code

Helm : gestionnaire de paquets Kubernetes

Helm empaquette un ensemble de manifests en un "chart" templatisé et versionné.

# Installer un chart depuis un dépôt public
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm search repo bitnami/postgresql

helm install my-postgres bitnami/postgresql \
  --namespace data --create-namespace \
  --set auth.postgresPassword=changeme

helm list -n data
helm uninstall my-postgres -n data

mychart/
├── Chart.yaml            # métadonnées : nom, version, dépendances
├── values.yaml            # valeurs par défaut, surchargeables
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── _helpers.tpl       # fonctions/templates réutilisables
│   └── NOTES.txt          # affiché après "helm install"
└── charts/                 # dépendances vendorisées

# Chart.yaml
apiVersion: v2
name: mychart
description: Chart de démo pour l'API
version: 0.1.0
appVersion: "1.4.2"

# values.yaml
replicaCount: 3
image:
  repository: myorg/api
  tag: "1.4.2"
  pullPolicy: IfNotPresent
service:
  port: 80
resources:
  requests:
    cpu: 100m
    memory: 128Mi

# templates/deployment.yaml - utilise le moteur de templates Go
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-api
  labels:
    app: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: api
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

# Créer un chart local et l'utiliser
helm create mychart
helm lint mychart                          # valide la structure et les templates
helm template mychart --values custom.yaml # génère le YAML final SANS l'appliquer (debug)
helm install demo ./mychart --dry-run --debug

helm upgrade demo ./mychart --set image.tag=1.5.0
helm rollback demo 1                        # revient à la révision 1
helm history demo

Résumé

Un chart = templates Go + values.yaml : une base réutilisable, paramétrable par environnement.
helm template / --dry-run permettent d'inspecter le YAML final avant de l'appliquer.
helm upgrade / helm rollback gèrent le cycle de vie complet, avec historique de révisions.
values.yaml par environnement (values-prod.yaml) évite de dupliquer les templates.

Exercices pratiques

1 disponible

Mission : éviter un déploiement Helm à l'aveugle en production

Objectif : Vérifier un chart avant de l'appliquer, forcer une valeur de production sans modifier le fichier de valeurs, et comprendre la précédence entre fichiers de valeurs et --set.

Contexte

Un collègue s'apprête à lancer helm upgrade --install api ./mychart -f values-prod.yaml directement sur le cluster de production, sans jamais avoir inspecté le YAML que ce chart va réellement produire. Tu soupçonnes que values-prod.yaml contient encore une valeur de test, replicaCount: 1, oubliée après un debug récent. Il faut vérifier avant d'appliquer, puis forcer la bonne valeur sans toucher au fichier partagé par l'équipe.

Résoudre l’exercice →