Helm Charts Kubernetes en 2026 : Packaging, Deploiement et Questions d'Entretien

Les Helm Charts Kubernetes simplifient le deploiement d'applications en regroupant toutes les ressources Kubernetes dans un artefact unique et versionne. Helm 3, la version stable actuelle, elimine le besoin de Tiller et introduit le support des registres OCI, rendant la distribution des charts plus securisee et standardisee. Ce tutoriel couvre la creation de charts, le templating, les strategies de deploiement et les questions d'entretien les plus frequentes posees par les equipes de recrutement.

Comprendre la Structure et les Composants d'un Helm Chart

Un Helm chart est un repertoire avec une structure predefinie. Le nom du chart devient le nom du repertoire, et chaque fichier remplit un role specifique dans le processus de packaging et de deploiement.

# Chart.yaml
apiVersion: v2
name: my-application
description: A production-ready web application
type: application
version: 1.0.0
appVersion: "2.1.0"
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

Le champ apiVersion: v2 indique la compatibilite avec Helm 3. Le champ version suit les modifications du chart, tandis que appVersion reflete la version de l'application deployee. Les dependances declarent les autres charts requis par ce chart, avec des conditions optionnelles pour les activer ou desactiver.

# values.yaml
replicaCount: 3

image:
  repository: myregistry.io/app
  tag: "2.1.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

postgresql:
  enabled: true
  auth:
    database: appdb

Les values definissent les configurations par defaut que les utilisateurs peuvent surcharger lors de l'installation. L'imbrication des valeurs sous des cles significatives garde les configurations organisees et auto-documentees.

Creation de Deployments Kubernetes avec les Templates Helm

Les templates Helm utilisent le templating Go avec les fonctions Sprig pour generer dynamiquement des manifestes Kubernetes. L'objet {{ .Values }} donne acces au contenu de values.yaml, tandis que {{ .Release }} contient les metadonnees de deploiement.

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

La fonction nindent ajoute un saut de ligne et une indentation, element critique pour la generation YAML. L'utilisation de include avec des templates nommes (definis dans _helpers.tpl) garde les templates DRY et maintenables.

# templates/_helpers.tpl
{{- define "my-application.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}

{{- define "my-application.labels" -}}
helm.sh/chart: {{ include "my-application.chart" . }}
app.kubernetes.io/name: {{ include "my-application.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

Les templates helper standardisent les conventions de nommage et les labels sur toutes les ressources, assurant la conformite avec les labels recommandes par Kubernetes.

Dependances et Subcharts Helm

Les applications complexes dependent souvent de bases de donnees, de caches ou de files de messages. Les dependances Helm permettent d'embarquer ces elements sous forme de subcharts, geres automatiquement lors de l'installation.

# Mettre a jour les dependances avant le packaging
helm dependency update ./my-application

# Construire les dependances (cree le repertoire charts/)
helm dependency build ./my-application

La commande helm dependency update telecharge les dependances dans le repertoire charts/. Les dependances conditionnelles utilisent les values pour activer ou desactiver leur inclusion :

# values.yaml
postgresql:
  enabled: true

redis:
  enabled: false

# Chart.yaml
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled
  - name: redis
    version: "19.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled

Ce pattern permet des configurations specifiques a l'environnement ou la production utilise des services manages tandis que le developpement utilise des bases de donnees dans le cluster.

Deploiement de Helm Charts avec Gestion des Releases

Helm suit les deploiements sous forme de releases, permettant des rollbacks et mises a jour versionnees. Chaque release maintient un historique pour l'audit et la recuperation.

# Installer un chart avec des valeurs personnalisees
helm install my-release ./my-application \
  --namespace production \
  --create-namespace \
  --values production-values.yaml \
  --set image.tag=2.1.1

# Mettre a jour une release existante
helm upgrade my-release ./my-application \
  --namespace production \
  --values production-values.yaml \
  --set image.tag=2.2.0 \
  --atomic \
  --timeout 5m

Le flag --atomic assure que les mises a jour echouees sont automatiquement annulees. Le flag --timeout definit combien de temps Helm attend que les ressources soient pretes avant de declarer un echec.

# Voir l'historique des releases
helm history my-release -n production

# Rollback vers une revision precedente
helm rollback my-release 2 -n production

# Desinstaller une release
helm uninstall my-release -n production --keep-history

Le flag --keep-history preserve les enregistrements de release meme apres la desinstallation, utile pour la conformite et le debogage.

Strategies de Test et Validation des Helm Charts

Tester les Helm charts avant le deploiement permet de detecter les erreurs de templates et les problemes de configuration en amont. Helm fournit des outils integres pour le linting et les tests en dry-run.

# Verifier le chart pour les erreurs et bonnes pratiques
helm lint ./my-application

# Rendre les templates localement sans deployer
helm template my-release ./my-application \
  --values production-values.yaml \
  > rendered-manifests.yaml

# Dry-run contre l'API du cluster
helm install my-release ./my-application \
  --dry-run \
  --debug \
  --namespace production

La commande helm template rend les manifestes localement, utile pour les pipelines CI qui valident le YAML genere. Le flag --dry-run envoie les manifestes au serveur API Kubernetes pour validation sans creer de ressources.

# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "my-application.fullname" . }}-test"
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: curl
      image: curlimages/curl:8.7.1
      command: ['curl']
      args: ['{{ include "my-application.fullname" . }}:{{ .Values.service.port }}/health']
  restartPolicy: Never

Les hooks Helm avec helm.sh/hook: test s'executent apres helm test my-release, validant que les deploiements fonctionnent correctement apres l'installation.

Techniques Avancees de Templating Helm

Les charts de production necessitent une logique conditionnelle, des boucles et de la transformation de donnees. Les fonctions Sprig etendent les templates Go avec des utilitaires pour la manipulation de chaines, l'encodage et le controle de flux.

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "my-application.fullname" . }}-config
data:
  {{- range $key, $value := .Values.config }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}
  
  {{- if .Values.features.enabled }}
  FEATURE_FLAGS: {{ .Values.features.flags | join "," | quote }}
  {{- end }}

# templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "my-application.fullname" . }}-secrets
type: Opaque
data:
  {{- range $key, $value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc }}
  {{- end }}

La fonction range itere sur les maps et les listes. La fonction b64enc encode les valeurs en base64 pour les secrets Kubernetes. Les operateurs pipe chainent les fonctions pour la transformation des donnees.

Questions et Reponses d'Entretien sur les Helm Charts

Les entretiens techniques testent frequemment les connaissances Helm a travers des questions conceptuelles et pratiques. La section suivante couvre les sujets les plus frequemment abordes.

Quelle est la difference entre helm install et helm upgrade --install ?

helm install cree une nouvelle release et echoue si la release existe deja. helm upgrade --install (avec le flag --install) cree une nouvelle release si elle n'existe pas, ou la met a jour si elle existe. Les pipelines CI/CD utilisent generalement helm upgrade --install pour des deploiements idempotents.

Comment transmettre des donnees sensibles aux Helm charts ?

Trois approches existent : les gestionnaires de secrets externes (Vault, AWS Secrets Manager), les fichiers values chiffres (SOPS, sealed-secrets), ou les secrets Kubernetes crees en dehors de Helm et references dans les templates. Il faut eviter de stocker les secrets dans des fichiers values.yaml en clair commites dans le controle de version.

Que sont les hooks Helm et quand les utiliser ?

Les hooks s'executent a des points specifiques du cycle de vie d'une release : pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback, et test. Les utilisations courantes incluent les migrations de base de donnees avant les mises a jour, l'envoi de notifications apres les deploiements, ou l'execution de tests d'integration.

Comment gerer le versioning des charts ?

Le champ version dans Chart.yaml suit les modifications du chart en utilisant le versioning semantique. Le champ appVersion suit la version de l'application deployee. Le champ version doit etre incremente pour toute modification du chart, meme si la version de l'application reste identique.

Quel est le but de .helmignore ?

Similaire a .gitignore, .helmignore exclut des fichiers du packaging du chart. Les entrees typiques incluent *.tgz (eviter de packager les builds precedents), .git/, la documentation *.md non necessaire a l'execution, et les fichiers de configuration CI.

Pour approfondir la preparation aux entretiens Kubernetes, il est possible d'explorer les modules de questions Kubernetes Basics et Kubernetes Advanced sur SharpSkill.

Conclusion

Points cles a retenir pour travailler avec les Helm charts :

• Structurer les charts avec une separation claire entre les metadonnees Chart.yaml, les valeurs par defaut values.yaml et le repertoire templates contenant les manifestes Kubernetes
• Utiliser les templates helper dans _helpers.tpl pour standardiser le nommage et les labels sur toutes les ressources
• Gerer les dependances via Chart.yaml avec activation conditionnelle pour les configurations specifiques a l'environnement
• Tester les charts avec helm lint, helm template et helm install --dry-run avant de deployer en production
• Suivre les releases avec des noms significatifs et utiliser le flag --atomic pour un rollback automatique en cas d'echec
• Stocker les secrets dans des gestionnaires externes plutot que dans des fichiers values en clair