Helm empaquette une application Kubernetes dans un chart : un répertoire de manifestes templatisés accompagné d’un ensemble de valeurs par défaut. Ce guide couvre la structure de dossiers commune à tous les charts et les trois concepts, chart, values et release, sur lesquels repose tout le reste de Helm.

Pourquoi ne pas simplement écrire des manifestes bruts

Une application non triviale est rarement un seul Deployment. C’est un Deployment, un Service, une ConfigMap, peut-être un Secret et un Ingress, et vous voulez déployer le même ensemble en dev, staging et production, avec seulement une poignée de valeurs différentes d’un environnement à l’autre : un tag d’image, un nombre de réplicas, un namespace. Copier-coller les manifestes par environnement signifie que chaque champ commun peut se désynchroniser. Un chart conserve les manifestes une seule fois, sous forme de templates, et laisse chaque installation fournir ses propres valeurs.

La structure de dossiers

helm create webapp

Cela génère l’arborescence suivante :

webapp/
├── Chart.yaml           # métadonnées du chart : nom, version, description
├── values.yaml          # valeurs de configuration par défaut
├── charts/              # les charts dont celui-ci dépend
├── .helmignore
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    ├── _helpers.tpl      # extraits de template réutilisables
    ├── NOTES.txt         # affiché après install/upgrade
    └── tests/
        └── test-connection.yaml

Chart.yaml contient les métadonnées du chart lui-même, principalement son nom, sa version et son apiVersion (v2 pour Helm 3 et le Helm 4 actuel). values.yaml contient la configuration par défaut. templates/ contient les manifestes Kubernetes mêlés à la syntaxe de templating de Helm. charts/ contient les charts dont celui-ci dépend, ce qui n’intervient que lorsque vous commencez à composer des charts entre eux. L’exemple généré est un chart nginx fonctionnel qui en contient plus que ce dont on a généralement besoin ; la plupart des équipes suppriment le squelette et écrivent leurs trois ou quatre templates, ou élaguent ce qui ne s’applique pas.

Les values alimentent les templates

Un template ressemble à un manifeste normal avec des espaces réservés :

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.appName }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: {{ .Values.appName }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

# values.yaml
appName: webapp
replicaCount: 2
image:
  repository: nginx
  tag: "1.25"

.Values est un objet construit à partir de values.yaml, fusionné avec tout ce qui est fourni en ligne de commande. Exécuter helm install ou helm template génère chaque fichier de templates/ avec cet objet, produisant du YAML Kubernetes brut. La syntaxe {{ }} est celle des templates Go, le même langage de templating utilisé ailleurs dans l’écosystème Kubernetes ; il n’y a donc rien de propriétaire à apprendre au-delà. Les valeurs peuvent être surchargées de trois façons, par ordre de priorité croissante : les valeurs par défaut de values.yaml, un fichier supplémentaire passé avec -f, et des options individuelles --set key=value en ligne de commande.

Une release est un déploiement spécifique d’un chart

Générer un chart et appliquer le résultat à un cluster crée une release : une installation nommée et suivie, dotée de son propre historique.

helm install web-dev ./webapp
helm list

web-dev est le nom de la release. Vous pouvez installer le même chart plusieurs fois sous des noms de release différents, dans le même namespace ou dans des namespaces différents, par exemple web-dev et web-staging. Chaque helm upgrade sur une release ajoute une nouvelle révision à son historique, ce qui rend précisément helm rollback possible plus tard : Helm ne se contente pas d’appliquer du YAML, il suit ce qui a été appliqué et quand. Le guide de gestion des releases de cette série couvre ce workflow en détail.

À quoi sert NOTES.txt

templates/NOTES.txt est du texte brut, lui-même templatisé de la même façon, que Helm affiche après install ou upgrade. Utilisez-le pour indiquer à la personne qui a installé le chart ce qu’elle doit faire ensuite : une commande kubectl port-forward, l’URL à laquelle un Service sera accessible, ou une étape de premier lancement. Il n’a aucun effet sur le cluster ; c’est uniquement un message destiné à la personne qui exécute la commande.

D’où viennent les charts

Vous n’avez pas à écrire chaque chart vous-même. Des charts publics pour des logiciels courants, bases de données, stacks de monitoring, contrôleurs d’ingress, sont publiés sur Artifact Hub et s’installent en une commande. Le reste de cette série couvre d’abord l’écriture de votre propre chart, puis la recherche et l’installation de charts publiés.