Helm — Gestion de packages Kubernetes

Helm est le package manager de Kubernetes. Un chart est un ensemble de fichiers qui décrivent un ensemble de ressources Kubernetes. Helm permet de les versionner, les partager et les déployer avec des paramètres configurables.

La version actuelle stable est la v3.x. Le format Chart est compatible entre les deux, mais Tiller (composant côté serveur de Helm v2) est supprimé — les charts s’exécutent uniquement dans le contexte de l’utilisateur.

1. Installation de Helm


# Installation via le script officiel
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
 
# Vérification
helm version
 
# Ajouter un dépôt Helm
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo add grafana    https://grafana.github.io/helm-charts
helm repo update

Après chaque helm repo update, les metadata locales sont synchronisées. Sans mise à jour, helm search peut ne pas trouver les dernières versions d’un chart.

2. Structure d’un Chart

Un chart est un répertoire contenant :


mon-chart/
├── Chart.yaml         # Métadonnées : version, dépendances, description
├── values.yaml        # Valeurs par défaut du déploiement
├── templates/         # Fichiers Go-templates (.yaml, .html, etc.)
│   ├── deployment.yaml
│   ├── service.yaml
│   └── _helpers.tpl   # Fonctions auxiliaires partagées
└── charts/            # Charts dépendants (optionnel)

`Chart.yaml`


apiVersion: v2
name: mon-service
description: Service API avec base PostgreSQL
type: application
version: 1.2.0
appVersion: "2.1.0"
dependencies:
  - name: postgresql
    version: "15.x.x"
    repository: https://charts.bitnami.com/bitnami
    condition: postgresql.enabled
  - name: redis
    version: "18.x.x"
    repository: https://charts.bitnami.com/bitnami
    condition: redis.enabled

Le champ condition relie une dépendance à une clé dans values.yaml. Si la clé est false, la dépendance n’est pas installée.

`values.yaml` — valeurs par défaut


replicaCount: 2
 
image:
  repository: mon-registry/mon-service
  pullPolicy: IfNotPresent
  tag: "latest"
 
service:
  type: ClusterIP
  port: 80
  targetPort: 8080
 
resources:
  limits:
    cpu: 500m
    memory: 256Mi
  requests:
    cpu: 250m
    memory: 128Mi
 
postgresql:
  enabled: true
  auth:
    username: app
    database: appdb
 
redis:
  enabled: true

Les valeurs de values.yaml sont les seules sources de vérité. Le shell ou helm install ne devrait jamais toucher aux templates directement — chaque paramètre passé par --set ou -f redéfinit les valeurs.

Templates — syntaxe Go

Les fichiers dans templates/ utilisent le moteur Go text/template avec les fonctions sprig intégrées.


# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "mon-chart.fullname" . }}
  labels:
    {{- include "mon-chart.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "mon-chart.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "mon-chart.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.service.targetPort }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

L’opérateur - dans {{- ... -}} supprime les blancs (retours à la ligne et espaces) en début et en fin de bloc. Son omission crée des lignes vides dans le YAML résultant.

`_helpers.tpl` — fonctions auxiliaires


{{/*
Nom complet du chart (nom + suffixe de version)
*/}}
{{- define "mon-chart.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
{{- end -}}
 
{{- define "mon-chart.labels" -}}
helm.sh/chart: {{ .Chart.Name }}-{{ .Chart.Version }}
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end -}}
 
{{- define "mon-chart.selectorLabels" -}}
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end -}}

printf | trunc 63 | trimSuffix "-" est un pattern récurrent qui garantit le respect de la limite Kubernetes de 63 caractères pour les noms.

3. Gestion des releases

Déployer un chart


# Installer une release depuis un chart local
helm install ma-release ./mon-chart
 
# Installer depuis un dépôt Helm
helm install redis bitnami/redis
 
# Installer avec des valeurs nommées sur la ligne de commande
helm install my-db bitnami/postgresql \
  --set auth.username=app \
  --set auth.password=secr3t \
  --set persistence.size=5Gi \
  --namespace production \
  --set namespaceOverride=production
 
# Installer avec un fichier de valeurs externe
helm install my-service ./mon-chart -f production-values.yaml
 
# Installer dans un namespace qui n'existe pas (création automatique)
helm install my-service ./mon-chart --create-namespace

--set écrase les valeurs de values.yaml par priorité : d’abord la valeur par défaut, puis -f (si donné), puis --set (en dernier). Pour des valeurs complexes (listes, objets imbriqués), utiliser -f est plus lisible que --set avec la notation pointée.

Liste et inspection


# Liste des releases dans tous les namespaces
helm list -A
 
# Liste des releases dans un namespace
helm list -n production
 
# Détails d'une release
helm status ma-release -n production
 
# Voir les valeurs d'une release installée
helm get values ma-release -n production

Mise à jour et rollback


# Mettre à jour une release avec un nouveau chart
helm upgrade ma-release ./mon-chart
 
# Mettre à jour avec un nouveau fichier de valeurs
helm upgrade ma-release ma-app \
  --values new-values.yaml
 
# Rollback à une révision précédente
helm rollback ma-release 3
 
# Vérifier l'historique des releases
helm history ma-release
 
# Annulation (uninstall)
helm uninstall ma-release

En cas d’échec lors d’un helm upgrade, la release reste dans son état précédent (version n-1). Lancer helm rollback vers la version visible dans helm history restaure l’application.

Versionner un release


# Mettre à jour Chart.yaml et values.yaml en conséquence
helm package ./mon-chart
helm push mon-service-1.3.0.tgz oci://ghcr.io/mon-registry/charts
 
# Dans un autre cluster, déployer depuis OCI
helm install ma-release oci://ghcr.io/mon-registry/charts/mon-service \
  --version 1.3.0

Le support OCI (helm push / helm install oci://...) est la méthode recommandée pour stocker les charts dans un registry container (ghcr.io, Harbor, GCR), sans passer par des registres de charts dédiés.

4. Lint et débogage


# Synthétiser le chart sans le déployer (output YAML)
helm template ma-release ./mon-chart
 
# Lint statique du chart (erreurs de syntaxe, valeurs manquantes)
helm lint ./mon-chart
 
# Lint avec des valeurs personnalisées
helm lint ./mon-chart -f production-values.yaml
 
# Afficher les fichiers rendus du chart avec verbose
helm template ma-release ./mon-chart -f production-values.yaml --show-only templates/deployment.yaml

helm template ne touche pas au cluster — il affiche uniquement le YAML que Helm produirait. Idéal pour vérifier un template avant le déploiement, et pour déboguer une erreur d’hydratation.

5. Bonnes pratiques

Valeurs nommées (first-class values)

Définir les constantes de configuration en haut du fichier values.yaml plutôt que d’éparpiller les valeurs hardcodées dans les templates :


# values.yaml
database:
  host: "{{ include \"mon-chart.fullname\" . }}-postgres"
  port: 5432
  name: appdb
  pool:
    min: 5
    max: 20
 
cache:
  ttl: 300
  evictions: "LRU"

values.yaml est rendu via le moteur Go-templates de Helm, pas seulement les fichiers sous templates/. Les expressions {{ include ... }} y sont donc valides. Séparer host, port et name évite les problèmes de formatage de chaînes et rend le chart plus facile à moduler.

Templates conditionnels


{{- if .Values.rbac.enabled }}
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: {{ include "mon-chart.fullname" . }}-role
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]
{{- end }}

Les fonctions {{ if }} / {{ else }} / {{ end }} gèrent la création conditionnelle de ressources. Combinées avec le champ condition de Chart.yaml, elles permettent de composer des charts modulaires sans duplication.

Charts enfants et `requirements.yaml`

La section dependencies de Chart.yaml installe automatiquement les sous-charts déclarés dans charts/ lors du build. C’est le mécanisme de chart chaining — un chart principal orchestre plusieurs chart enfants sans avoir besoin de les déployer séparément.

6. Pitfalls

Templates modifiés après une release

Helm ne détecte pas les modifications de templates entre deux releases. Si un template a été modifié après un helm install initial mais avant le prochain helm upgrade, ces modifications sont perdues lors de la prochaine mise à jour. Toujours vérifier l’état actuel des templates avec helm template ou helm get manifest avant de modifier.

`values.yaml` et clés de données sensibles

values.yaml est un fichier texte brut : tout mot de passe, clé API ou JWT stocké dedans est visible en clair. En production, utiliser des Secret Kubernetes créés à la main et injectés dans le chart via --set ou -f, ou privilégier un outil externe de gestion de secrets (Vault, Sealed Secrets, SOPS).

Namespace correct

Si un chart ne spécifie pas de namespace, il est installé dans default (sauf si --namespace est donné à la ligne de commande). Vérifier avec helm status que la release est bien dans le namespace souhaité.

Écrasement de templates

Si un template partage un nom (ex. deployment.yaml) avec un autre chart parent, les deux sont appliqués. Utiliser le champ name dans Chart.yaml et des templates nommés uniques (via _helpers.tpl) pour éviter les conflits à l’emballage.

Voir aussi

Kubernetes — Déploiement et services — pods, deployments, services, Ingress