Le values.yaml d’un chart contient des valeurs par défaut raisonnables, mais dev, staging et production partagent rarement un namespace, un nombre de réplicas ou une valeur de configuration. Ce guide couvre la superposition de fichiers de values supplémentaires par environnement, sans maintenir de copies séparées du chart lui-même. Il s’appuie sur le chart webapp du guide précédent.

Garder values.yaml comme base commune

Laissez dans values.yaml tout ce qui doit être identique partout, le nom de l’application, le dépôt de l’image. Seuls les champs propres à un environnement ont leur place dans un fichier de surcharge :

# values-dev.yaml
namespace: dev
config:
  customHeader: "welcome to dev"

# values-prod.yaml
namespace: prod
replicaCount: 5
config:
  customHeader: "welcome to production"

Un fichier passé avec -f ne remplace pas values.yaml, il est fusionné par-dessus. values-dev.yaml n’a besoin de mentionner que namespace et config.customHeader ; tout le reste, appName, image, est repris tel quel du fichier de base.

Référencer le namespace dans vos templates

Ajoutez la valeur et utilisez-la partout où un manifeste doit déclarer son namespace :

# values.yaml (ajoutez une valeur par défaut)
namespace: default

# templates/deployment.yaml, templates/service.yaml, templates/configmap.yaml
metadata:
  name: {{ .Values.appName }}
  namespace: {{ .Values.namespace }}

Installer avec le fichier de values d’un environnement

kubectl create namespace dev
kubectl create namespace prod

helm install web-dev ./webapp -f values-dev.yaml -n dev
helm install web-prod ./webapp -f values-prod.yaml -n prod

Deux éléments jouent ici des rôles liés mais distincts : -n dev indique à Helm dans quel namespace stocker les métadonnées propres à la release, et metadata.namespace dans les templates indique à Kubernetes dans quel namespace va chaque ressource. Les faire coïncider, la release vit dans le même namespace que ce qu’elle a déployé, est la pratique standard et évite la confusion plus tard, lorsque vous exécutez helm list -n dev en vous attendant à voir tout ce qui tourne réellement là.

helm list -A
kubectl get all -n dev
kubectl get all -n prod
curl <dev-pod-ip>   # ou kubectl port-forward, selon NOTES.txt

Confirmez que chaque environnement affiche son propre customHeader et son propre nombre de réplicas.

L’ordre de priorité complet

Helm fusionne les values de plusieurs sources, chacune remplaçant les précédentes :

1. values.yaml, les valeurs par défaut du chart lui-même.
2. Le values.yaml d’un chart parent, si ce chart est utilisé comme dépendance (non couvert ici).
3. Tout fichier passé avec -f, dans l’ordre donné, les fichiers suivants l’emportant sur les précédents.
4. Les options --set, --set-string ou --set-json, qui l’emportent sur tous les fichiers.

helm upgrade web-dev ./webapp -f values-dev.yaml --set replicaCount=1

--set est pratique pour une surcharge ponctuelle ou un test rapide, mais pour tout ce que vous voulez pouvoir reproduire, mettez-le dans un fichier et versionnez-le. Une option --set tapée dans un terminal ne laisse aucune trace de ce qui a réellement été déployé.

Deux façons de vérifier ce qu’a produit une fusion

Avant de faire confiance à une installation ou à une mise à niveau, regardez le résultat :

helm template ./webapp -f values-prod.yaml
helm get values web-prod

helm template -f génère le chart avec un fichier de values donné exactement comme le ferait install, sans toucher au cluster, ce qui vous permet de comparer directement la sortie de deux environnements. helm get values (après l’installation) affiche les values réellement enregistrées pour une release en cours d’exécution, ce qu’il faut vérifier lorsqu’une release en cours ne correspond pas à ce qu’un fichier devrait produire.

Une remarque sur les secrets

Les fichiers de values sont du texte brut ; ne mettez donc pas de vrais identifiants dans un fichier commité dans Git. Une répartition courante : la configuration non sensible par environnement dans values-<env>.yaml, et les secrets injectés soit via --set depuis le magasin de secrets d’une CI, soit via un outil comme Sealed Secrets ou SOPS, soit en faisant référencer par le chart un Secret Kubernetes créé en dehors de Helm plutôt qu’en intégrant la valeur dans values.yaml.