KubernetesHelmDevOps

Helm Charts en production : structurer ses releases Kubernetes

11 juillet 2026 · Sphinx-Digital

Helm simplifie le déploiement Kubernetes, mais un chart mal structuré crée autant de problèmes qu’il en résout. Voici les pratiques qui font la différence entre un chart fragile et un chart production-ready.

Structurer les valeurs par environnement

La séparation des valeurs par environnement est fondamentale :

myapp/
├── Chart.yaml
├── values.yaml           # valeurs par défaut (dev)
├── values-staging.yaml   # surcharges staging
└── values-prod.yaml      # surcharges production
# values.yaml
replicaCount: 1
image:
  repository: registry.example.com/myapp
  tag: latest
resources:
  requests:
    cpu: 100m
    memory: 128Mi

# values-prod.yaml
replicaCount: 3
image:
  tag: ""   # toujours overridé au déploiement
resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    cpu: 1
    memory: 1Gi
# Déploiement production
helm upgrade --install myapp ./myapp \
  -f values-prod.yaml \
  --set image.tag=$BUILD_NUMBER \
  --namespace production

Hooks : orchestrer le cycle de déploiement

Les hooks Helm permettent d’exécuter des actions à des moments précis du cycle de release :

# templates/job-migrate.yaml
apiVersion: batch/v1
kind: Job
metadata:
  annotations:
    "helm.sh/hook": pre-upgrade
    "helm.sh/hook-weight": "-5"
    "helm.sh/hook-delete-policy": before-hook-creation
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
          command: ["python", "manage.py", "migrate"]
      restartPolicy: Never

Les migrations de base de données s’exécutent automatiquement avant chaque upgrade — sans les oublier.

Rollback : le filet de sécurité

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

# Rollback à la revision précédente
helm rollback myapp -n production

# Rollback à une revision spécifique
helm rollback myapp 3 -n production

Helm conserve l’historique des releases sous forme de secrets Kubernetes. Le rollback est instantané et traçable.

Helm Secrets : versionner les secrets chiffrés

# Chiffrer un fichier de secrets avec SOPS + Age
helm secrets enc secrets-prod.yaml

# Déployer avec secrets déchiffrés à la volée
helm secrets upgrade --install myapp ./myapp \
  -f values-prod.yaml \
  -f secrets-prod.yaml

Les secrets restent chiffrés dans Git, déchiffrés seulement au moment du déploiement.

Notre formation Kubernetes couvre Helm en profondeur avec des ateliers sur des clusters réels.