Kubernetes (12/12) — Helm : empaqueter l'application

L’idée reçue

« Déployer une appli Kubernetes = appliquer une pile de fichiers YAML à la main. »

Ça marche pour un service, mais une vraie appli, c’est Deployment + Service + Ingress + ConfigMap + Secret… des dizaines de manifestes à gérer, versionner, dupliquer par environnement. Helm les empaquette en un chart : templates + valeurs + version, installable et réversible en une commande.

Helm n’est pas une nouvelle fonctionnalité de Kubernetes : c’est un outil de packaging de déploiement. On l’aborde « sans magie » — on voit le YAML généré avant d’installer quoi que ce soit.

À la fin de ce module, tu sauras…

Expliquer ce qu’est un chart (templates, values, metadata)
Créer un chart et rendre son YAML localement avant d’installer
Installer une release en surchargeant des valeurs (ton image Harbor)
Distinguer rollback Helm et rollback Kubernetes

01Vérifier Helm, créer un chart

Expérience 1

Le squelette d’un chart

Manipule

helm version
helm create demo-chart
ls -1 demo-chart

Observe

version.BuildInfo{Version:"v3.19.0", ...}
Creating demo-chart

charts
Chart.yaml
templates
values.yaml

Helm a généré un chart de départ avec une structure standard. Ce n’est pas encore « ton appli » : c’est une base de templates.

Comprends chart, values, templates, metadata

Un chart est un paquet d’application Kubernetes. Chart.yaml = la carte d’identité (nom, version). values.yaml = la configuration par défaut. templates/ = les YAML paramétrés (Deployment, Service…). charts/ = les dépendances. En production, ça donne des installs reproductibles, des upgrades, des rollbacks, et un versioning du packaging.

02Voir le YAML AVANT d’installer

Expérience 2

La règle « pas d’aveuglement »

Manipule

helm template demo-release ./demo-chart | head -n 40

Observe

helm template rend les manifestes localement, sans toucher au cluster. Tu vois exactement les objets (Deployment, Service…) que Helm appliquerait, avec les valeurs injectées.

Comprends template vs install

helm template = génère le YAML localement (aperçu, aucun changement). helm install = crée réellement les objets. Toujours regarder le rendu avant d’installer, surtout en apprentissage : on comprend ce qu’on déploie, on ne fait pas confiance aveuglément à l’abstraction.

03Installer avec tes valeurs (image Harbor)

Expérience 3

Une release, avec ton image privée

Manipule

helm install demo-release ./demo-chart -n lab-soria \
--set image.repository=harbor.mondomaine.fr/soria/soria-web \
--set image.tag=2.0

Observe

NAME: demo-release
NAMESPACE: lab-soria
STATUS: deployed
REVISION: 1

Helm a créé une release nommée demo-release, qu’il suit dans le temps. Le –set a surchargé l’image par défaut avec la tienne, tirée de Harbor.

Comprends release et –set

Une release est une installation suivie par Helm (avec un nom et un historique de révisions). –set clé=valeur surcharge une valeur de values.yaml à l’install — pratique pour pointer la même chart vers des images ou environnements différents, sans dupliquer les fichiers.

04Vérifier, puis upgrade & rollback

Expérience 4

Le cycle de vie d’une release

Manipule

kubectl get pods -l app.kubernetes.io/instance=demo-release
helm upgrade demo-release ./demo-chart -n lab-soria --set replicaCount=2
helm history demo-release -n lab-soria
helm rollback demo-release 1 -n lab-soria

Observe

Rollback was a success! Happy Helming!
# les Pods reviennent de 2 → 1 (état de la révision 1)

upgrade crée une nouvelle révision (replicaCount=2) ; rollback restaure une révision antérieure — et modifie réellement l’état du cluster. Helm garde tout l’historique.

Comprends rollback Helm vs rollback Kubernetes

kubectl rollout undo agit sur un Deployment (révision de PodTemplate). helm rollback agit sur toute une release : il peut restaurer d’un coup Deployment + Service + ConfigMap + Ingress. Kubernetes = rollback d’un workload ; Helm = rollback d’un paquet applicatif entier. Le rollback lui-même devient une nouvelle révision tracée.

→Ce que Helm ajoute (récapitulatif)

Sans Helm	Avec Helm
appliquer des YAML bruts un par un	un chart empaqueté
dupliquer les fichiers par environnement	une chart + des `values` différentes
rollback manuel, objet par objet	`helm rollback` de toute l’appli
pas de versioning du déploiement	révisions suivies

✓Ce que tu retiens

Helm empaquette une application Kubernetes en un chart (templates + values + metadata). On voit le YAML avec helm template, on installe une release en surchargeant des valeurs (–set), et on gère son cycle de vie avec upgrade/rollback. Le rollback Helm porte sur tout le paquet applicatif, là où le rollback Kubernetes ne concerne qu’un workload.

Mini-projet — clôture de la Phase 5

Empaquette SORIA Web

À faire

Crée un chart, et rends son YAML avec helm template (lis-le avant d’installer).
Installe une release en pointant vers ton image Harbor via –set.
Vérifie les Pods créés par la release.
Fais un upgrade (change replicaCount), consulte helm history, puis rollback.
Désinstalle proprement (helm uninstall) pour ne pas entrer en conflit avec demo-deploy.
Documente dans BookStack : chart, release, values, et rollback Helm vs Kubernetes.

Fil rouge — Tu maîtrises Kubernetes de bout en bout, à la main. Mais tout cela reste manuel : build, push, deploy, tu les lances toi-même. À la Phase 6, on automatise toute la chaîne avec Jenkins : un git push déclenchera build → scan → push Harbor → déploiement sur le cluster. C’est là que Jenkins se connectera au cluster et à Harbor.

?Auto-évaluation

1. Qu’est-ce qu’un chart Helm ?

Un paquet d’application Kubernetes : des templates YAML paramétrés, un fichier de valeurs, et des métadonnées (nom, version).

2. Pourquoi utiliser helm template avant helm install ?

Pour voir localement le YAML que Helm appliquerait, sans toucher au cluster — comprendre ce qu’on déploie.

3. En quoi helm rollback diffère-t-il de kubectl rollout undo ?

Helm rollback restaure toute une release (plusieurs ressources ensemble) ; kubectl rollout undo ne revient que sur un Deployment.