Helm Charts : Maîtriser le Package Manager de Kubernetes en 2025

Déployer des applications sur Kubernetes sans Helm, c'est comme construire une maison sans plan : faisable, mais chaotique. Helm est le package manager de Kubernetes qui transforme des dizaines de fichiers YAML en déploiements reproductibles, versionnés, et faciles à configurer.

Pourquoi Helm est Indispensable

Le Problème : Kubernetes YAML Hell

Application simple : Backend + Frontend + PostgreSQL + Redis

Sans Helm : 15-20 fichiers YAML à gérer manuellement

k8s/
├── backend-deployment.yaml
├── backend-service.yaml
├── backend-configmap.yaml
├── backend-secret.yaml
├── backend-hpa.yaml
├── backend-ingress.yaml
├── frontend-deployment.yaml
├── frontend-service.yaml
├── frontend-configmap.yaml
├── postgres-statefulset.yaml
├── postgres-service.yaml
├── postgres-pvc.yaml
├── redis-deployment.yaml
├── redis-service.yaml
└── ...

Problèmes :

• Duplication massive (copier/coller)
• Gestion d'environnements (dev/staging/prod) = 3× fichiers
• Mises à jour laborieuses
• Rollback complexe
• Versioning difficile

La Solution : Helm Charts

Avec Helm : 1 chart paramétrable

helm install my-app ./app-chart \
  --set backend.image.tag=v2.1.0 \
  --set environment=production \
  --set replicas=5

Avantages :

• ✅ Templating : Réutiliser avec différentes valeurs
• ✅ Versioning : helm upgrade / helm rollback
• ✅ Dépendances : Composer charts (PostgreSQL chart inclus)
• ✅ Hooks : Exécuter jobs avant/après déploiement
• ✅ Écosystème : 10,000+ charts publics (Artifact Hub)

Anatomie d'un Helm Chart

Structure de Base

my-chart/
├── Chart.yaml              # Métadonnées du chart
├── values.yaml             # Valeurs par défaut
├── charts/                 # Dépendances (sub-charts)
├── templates/              # Templates Kubernetes
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── configmap.yaml
│   ├── _helpers.tpl        # Templates partagés
│   └── NOTES.txt           # Instructions post-install
└── .helmignore             # Fichiers à ignorer

Chart.yaml

# Chart.yaml
apiVersion: v2
name: my-app
description: Application web full-stack
type: application  # ou 'library' pour charts réutilisables
version: 1.2.3  # Version du chart
appVersion: "2.1.0"  # Version de l'application

keywords:
  - web
  - nodejs
  - postgres

maintainers:
  - name: Flavien Henriot
    email: flavien@example.com

dependencies:
  - name: postgresql
    version: "12.x.x"
    repository: https://charts.bitnami.com/bitnami
    condition: postgresql.enabled  # Optionnel
  - name: redis
    version: "17.x.x"
    repository: https://charts.bitnami.com/bitnami

values.yaml

# values.yaml - Valeurs par défaut
replicaCount: 2

image:
  repository: mycompany/myapp
  tag: "1.0.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80
  targetPort: 3000

ingress:
  enabled: true
  className: nginx
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  hosts:
    - host: myapp.example.com
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: myapp-tls
      hosts:
        - myapp.example.com

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 250m
    memory: 256Mi

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

env:
  - name: NODE_ENV
    value: production
  - name: PORT
    value: "3000"

# Dépendances
postgresql:
  enabled: true
  auth:
    username: myapp
    password: changeme  # À override en prod !
    database: myapp_db
  primary:
    persistence:
      size: 10Gi

redis:
  enabled: true
  auth:
    enabled: false

Templating : Rendre les Charts Dynamiques

Accès aux Valeurs

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-chart.fullname" . }}
  labels:
    {{- include "my-chart.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "my-chart.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-chart.selectorLabels" . | nindent 8 }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        ports:
        - name: http
          containerPort: {{ .Values.service.targetPort }}
        env:
        {{- range .Values.env }}
        - name: {{ .name }}
          value: {{ .value | quote }}
        {{- end }}
        resources:
          {{- toYaml .Values.resources | nindent 10 }}

Variables disponibles :

• .Values : Valeurs depuis values.yaml
• .Chart : Métadonnées Chart.yaml
• .Release : Infos release (nom, namespace)
• .Template : Infos template en cours

Gestion Multi-Environnements

values-prod.yaml

# values-prod.yaml
replicaCount: 5

image:
  tag: "v2.1.0"
  pullPolicy: IfNotPresent

ingress:
  enabled: true
  annotations:
    nginx.ingress.kubernetes.io/rate-limit: "100"

resources:
  limits:
    cpu: 1000m
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 512Mi

autoscaling:
  enabled: true
  minReplicas: 5
  maxReplicas: 50
  targetCPUUtilizationPercentage: 60

postgresql:
  enabled: true
  primary:
    persistence:
      size: 100Gi
    resources:
      limits:
        cpu: 2000m
        memory: 4Gi

Déploiement :

# Production
helm install my-app ./my-chart -f values-prod.yaml

Articles connexes

Pour approfondir le sujet, consultez également ces articles :

• Kubernetes 1.30 : Sécurité renforcée et gestion des coûts optimisée en octobre 2025
• Kubernetes 1.32 : Nouvelles fonctionnalités et améliorations de sécurité (Octobre 2025)
• Kubernetes 1.34 "Of Wind & Will" : Nouvelles fonctionnalités et amélioration trafic réseau

Conclusion : Helm en 2025

Helm est incontournable pour gérer applications Kubernetes en production :

• ✅ Templating puissant (DRY)
• ✅ Gestion versions (upgrade/rollback)
• ✅ Écosystème riche (10k+ charts)
• ✅ Multi-environnements (dev/staging/prod)
• ✅ GitOps ready (ArgoCD, FluxCD)

Checklist Démarrage :

• Créer chart structure
• Définir values.yaml (dev/prod)
• Implémenter templates (deployment, service, ingress)
• Ajouter hooks (migrations)
• Configurer dépendances (PostgreSQL, Redis)
• Tests (lint, unittest)
• CI/CD (GitHub Actions)
• GitOps (ArgoCD)

Helm transforme le chaos YAML en déploiements élégants !

Aller plus loin

• Observabilité : couplez vos releases Helm avec des dashboards Grafana versionnés dans le chart afin que chaque déploiement embarque sa supervision.
• Sécurité : signez vos charts (Helm provenance) et stockez-les dans un registre privé (OCI) avec des politiques de rétention.
• Formation : organisez des game days où les équipes doivent mettre à jour un chart sous contrainte de temps pour ancrer les bonnes pratiques.

En combinant ces leviers, Helm devient bien plus qu’un outil de templating : un socle industriel pour vos plateformes Kubernetes.