TP15 : Packager une application Kubernetes avec Helm et Kustomize

Dès qu’une application doit être déployée dans plusieurs environnements, copier-coller des fichiers YAML devient ingérable. Deux outils dominent : Helm, gestionnaire de paquets qui génère les manifests à partir de templates et de values, et gère des releases versionnées (upgrade, rollback) ; et Kustomize, intégré à kubectl, qui applique des patches à une base commune, sans template. Ce TP fait construire les deux à partir de la même application et les compare.

Fichiers de départ : chart-starter.zip, kustomize-starter.zip

1. Objectifs pédagogiques

À l’issue du TP, vous serez capable de :

• utiliser un chart public et inspecter ses valeurs ;
• écrire un chart : Chart.yaml, values.yaml, templates, helpers, NOTES.txt ;
• valider et prévisualiser un chart (helm lint, helm template, --dry-run) ;
• gérer le cycle de vie d’une release (install, upgrade, history, rollback, uninstall) ;
• structurer Kustomize en base + overlays (dev / staging / prod) avec configMapGenerator, images, replicas et des patches ;
• choisir entre Helm et Kustomize selon le contexte.

Les images de cette page sont des schémas explicatifs, pas des captures d’écran.

2. Environnement du TP

• Le cluster K3s du TP14 et kubectl.

• Installer Helm (il servira aussi d’installeur de logiciels dans tous les TP suivants) :

  curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
  helm version

• Une entrée /etc/hosts : <IP-du-nœud> whoami.lab.local.

3. Partie 1 : Consommer un chart public

• Rechercher et inspecter un chart avant de l’installer :

  helm repo add podinfo https://stefanprodan.github.io/podinfo && helm repo update
  helm search repo podinfo
  helm show chart podinfo/podinfo
  helm show values podinfo/podinfo | less

• L’installer avec une surcharge, puis lister les releases et lire les manifests réellement appliqués :

  helm install demo podinfo/podinfo -n helm-demo --create-namespace --set replicaCount=2
  helm list -A
  helm get values demo -n helm-demo
  helm get manifest demo -n helm-demo | head -40
  helm uninstall demo -n helm-demo

• Où Helm stocke-t-il l’historique d’une release ? (kubectl -n helm-demo get secrets pendant que la release existe.)

4. Partie 2 : Écrire son propre chart

• Étudier le chart chart-starter/whoami/ : Chart.yaml (différence entre version et appVersion), values.yaml, _helpers.tpl, deployment.yaml.

• Compléter les TODO :

  • deployment.yaml : boucle range sur .Values.env, probes sur /health ;
  • service.yaml : Service entièrement paramétré ;
  • ingress.yaml : généré seulement si ingress.enabled.

• Valider et prévisualiser :

  helm lint chart-starter/whoami
  helm template test chart-starter/whoami --set ingress.enabled=true | less
  helm install test chart-starter/whoami --dry-run=server -n tp15 --create-namespace

5. Partie 3 : Cycle de vie d’une release

• Créer values-dev.yaml (1 replica, Ingress activé, env.WHOAMI_NAME: dev) et values-prod.yaml (3 replicas, limits plus élevées).

• Installer, mettre à jour, consulter l’historique puis revenir en arrière :

  helm install whoami chart-starter/whoami -n tp15 --create-namespace -f values-dev.yaml
  curl http://whoami.lab.local
  helm upgrade whoami chart-starter/whoami -n tp15 -f values-dev.yaml --set replicaCount=3
  helm upgrade whoami chart-starter/whoami -n tp15 -f values-dev.yaml --set image.tag=v9.9.9
  kubectl -n tp15 get pods                    # ImagePullBackOff
  helm history whoami -n tp15
  helm rollback whoami 2 -n tp15
  helm history whoami -n tp15                 # le rollback crée une NOUVELLE révision

• Recommencer la mise à jour défaillante avec --atomic --timeout 60s : que fait Helm cette fois-ci ?

• Empaqueter le chart (helm package), incrémenter version et observer le nom de l’archive produite.

6. Partie 4 : Kustomize, base et overlays

• Prévisualiser la base puis l’overlay dev fourni :

  kubectl kustomize kustomize-starter/base
  kubectl kustomize kustomize-starter/overlays/dev

  Repérer : namespace, ConfigMap avec suffixe de hash, labels ajoutés.

• Créer les overlays staging (2 replicas, WHOAMI_NAME=staging) et prod (3 replicas, tag v1.10.1 via le champ images, patch qui augmente limits.memory à 128Mi).

• Ajouter dans prod un patch stratégique (patches: + fichier) qui ajoute une readinessProbe.

• Déployer et comparer les trois environnements :

  kubectl apply -k kustomize-starter/overlays/dev
  kubectl apply -k kustomize-starter/overlays/staging
  kubectl apply -k kustomize-starter/overlays/prod
  kubectl get deploy -A -l app.kubernetes.io/part-of=tp15
  diff <(kubectl kustomize kustomize-starter/overlays/staging) <(kubectl kustomize kustomize-starter/overlays/prod)

• Modifier LOG_LEVEL dans l’overlay dev et réappliquer : pourquoi les Pods sont-ils automatiquement recréés (contrairement au TP14) ?

7. Partie 5 : Comparaison

• Compléter le tableau :

• Quand utiliser les deux ensemble ? (Indice : helmCharts: dans une kustomization.yaml, ou un chart tiers personnalisé par des patches.)

Défi

1. Publier le chart dans un registre OCI : helm push whoami-0.1.0.tgz oci://harbor.lab.local/devsecops (Harbor du TP12) puis l’installer depuis cette adresse.
2. Ajouter un fichier values.schema.json au chart pour que helm lint refuse replicaCount: "trois".

8. Livrables

Captures à déposer dans captures/ :

Ainsi que le chart complété, les fichiers values-*.yaml, les overlays et le tableau comparatif.