Helm : gestion de packages sur Kubernetes

Dans les environnements Kubernetes modernes, le déploiement d'applications peut rapidement devenir un casse-tête. Entre les Deployments, Services, ConfigMaps, Secrets et autres ressources à orchestrer, la gestion manuelle de fichiers YAML se transforme vite en un exercice fastidieux et source d'erreurs. Comment versionner proprement une application composée de dizaines de manifestes ? Comment réutiliser une configuration entre plusieurs environnements ? Ces défis ont conduit à l'émergence d'un outil devenu incontournable : Helm.

Véritable gestionnaire de packages pour Kubernetes, Helm permet de définir, installer et mettre à jour des applications complexes sous forme de "charts", des packages réutilisables et paramétrables. Projet gradué de la Cloud Native Computing Foundation (CNCF), Helm est aujourd'hui utilisé par la grande majorité des organisations qui opèrent Kubernetes en production. Des entreprises comme Microsoft, Google ou encore Bitnami maintiennent des catalogues entiers de charts, facilitant le déploiement d'applications aussi diverses que PostgreSQL, Prometheus ou WordPress en quelques commandes.

Qu'est-ce que Helm ?

Helm est un gestionnaire de packages pour Kubernetes qui simplifie le déploiement et la gestion d'applications conteneurisées. Souvent comparé à apt pour Debian ou yum pour Red Hat, Helm apporte au monde Kubernetes ce que ces outils apportent aux systèmes Linux : une manière standardisée d'empaqueter, distribuer et installer des logiciels.

Le concept central de Helm repose sur les charts, des packages qui contiennent l'ensemble des ressources Kubernetes nécessaires au déploiement d'une application. Un chart peut inclure des Deployments, Services, Ingress, ConfigMaps, et toute autre ressource requise, le tout organisé de manière cohérente et versionnable. Cette approche offre plusieurs avantages majeurs :

• Réutilisabilité : un même chart peut être déployé dans différents environnements (développement, staging, production) avec des configurations adaptées.
• Versioning : chaque version d'une application correspond à une version de chart, facilitant les mises à jour et les rollbacks.
• Paramétrage : les valeurs peuvent être personnalisées sans modifier les templates, permettant d'adapter le déploiement au contexte.
• Partage : les charts peuvent être publiés dans des repositories et partagés au sein de l'organisation ou avec la communauté.

Lorsqu'un chart est installé sur un cluster, Helm crée ce qu'on appelle une release, une instance spécifique de ce chart avec sa propre configuration. Cette distinction permet de déployer plusieurs fois la même application (par exemple, plusieurs instances de Redis) avec des paramètres différents, chacune étant gérée indépendamment.

L'architecture de Helm a considérablement évolué depuis ses débuts. La version 3, sortie en 2019, a supprimé le composant serveur Tiller qui posait des problèmes de sécurité, pour adopter une architecture entièrement client-side. Désormais, Helm interagit directement avec l'API Kubernetes en utilisant les credentials de l'utilisateur, simplifiant l'installation et renforçant la sécurité.

Fonctionnement et structure d'un chart

Comprendre la structure d'un chart Helm est essentiel pour l'utiliser efficacement, que ce soit pour consommer des charts existants ou en créer de nouveaux.

Un chart Helm suit une organisation de fichiers standardisée qui sépare clairement les templates, les valeurs par défaut et les métadonnées :

mon-application/
├── Chart.yaml          # Métadonnées du chart (nom, version, description)
├── values.yaml         # Valeurs par défaut configurables
├── templates/          # Templates des ressources Kubernetes
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── _helpers.tpl    # Fonctions de template réutilisables
├── charts/             # Dépendances (sous-charts)
└── README.md           # Documentation

Le fichier Chart.yaml définit l'identité du chart : son nom, sa version, une description, ainsi que d'éventuelles dépendances vers d'autres charts. Le fichier values.yaml contient toutes les valeurs configurables avec leurs valeurs par défaut. Ces valeurs peuvent ensuite être surchargées lors de l'installation pour adapter le déploiement.

Les templates constituent le cœur du chart. Ce sont des fichiers YAML enrichis avec le langage de templating Go, permettant d'injecter dynamiquement des valeurs et d'appliquer une logique conditionnelle :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-{{ .Chart.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Chart.Name }}
  template:
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.service.port }}

Cette approche permet de créer des templates génériques qui s'adaptent au contexte de déploiement. Les variables comme .Values.replicaCount sont remplacées par les valeurs définies dans values.yaml ou fournies lors de l'installation. Les objets .Release et .Chart donnent accès aux métadonnées de la release et du chart.

À lire : découvrez notre formation DevOps Engineer

Utilisation pratique de Helm

L'utilisation quotidienne de Helm s'articule autour de quelques commandes essentielles qui couvrent l'ensemble du cycle de vie des applications.

Installation et gestion des releases

L'installation d'un chart depuis un repository se fait simplement avec la commande helm install. Par exemple, pour déployer une instance Redis depuis le repository Bitnami :

# Ajout du repository Bitnami
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Installation de Redis
helm install mon-redis bitnami/redis

# Installation avec des valeurs personnalisées
helm install mon-redis bitnami/redis \
  --set auth.password=monsecret \
  --set replica.replicaCount=3

# Ou en utilisant un fichier de valeurs
helm install mon-redis bitnami/redis -f mes-valeurs.yaml

La gestion des releases installées s'effectue avec des commandes intuitives :

• helm list : affiche toutes les releases installées sur le cluster.
• helm upgrade mon-redis bitnami/redis : met à jour une release avec une nouvelle version ou de nouvelles valeurs.
• helm rollback mon-redis 1 : revient à une révision précédente en cas de problème.
• helm uninstall mon-redis : supprime complètement la release et ses ressources.

Création de charts personnalisés

Pour les applications internes, Helm permet de créer facilement ses propres charts :

# Création d'un squelette de chart
helm create mon-application

# Vérification de la syntaxe
helm lint mon-application

# Test du rendu des templates sans installation
helm template mon-application ./mon-application -f values-prod.yaml

# Empaquetage pour distribution
helm package mon-application

La commande helm template est particulièrement utile en phase de développement : elle génère les manifestes Kubernetes finaux sans les appliquer, permettant de vérifier le résultat avant déploiement. Cette approche s'intègre parfaitement dans les pipelines CI/CD pour valider les charts avant leur publication.

Helm dans l'écosystème DevOps

Helm s'intègre naturellement dans les pratiques DevOps modernes et constitue souvent une pièce maîtresse des pipelines de déploiement sur Kubernetes.

Dans une approche GitOps, les charts Helm sont versionnés dans Git aux côtés des fichiers de valeurs spécifiques à chaque environnement. Des outils comme ArgoCD ou Flux supportent nativement Helm, permettant de synchroniser automatiquement les releases avec l'état défini dans le repository. Cette combinaison offre le meilleur des deux mondes : la puissance de templating de Helm et la réconciliation continue du GitOps.

L'écosystème Helm est particulièrement riche. Artifact Hub (anciennement Helm Hub) référence des milliers de charts maintenus par la communauté et les éditeurs logiciels. Des solutions comme Harbor peuvent servir de repository privé pour héberger les charts internes de l'organisation, offrant ainsi un contrôle total sur la distribution des packages.

Les charts Helm sont également au cœur de nombreuses solutions d'infrastructure. L'installation d'outils comme Prometheus, Istio ou encore des operators se fait généralement via Helm, témoignant de son adoption massive dans l'écosystème Cloud native.

À découvrir : notre formation DevOps Engineer

Conclusion

Helm s'est imposé comme l'outil de référence pour la gestion des applications sur Kubernetes, apportant structure, réutilisabilité et simplicité là où régnait la complexité des manifestes YAML. En encapsulant les bonnes pratiques de déploiement dans des packages versionnés et paramétrables, il permet aux équipes de se concentrer sur la valeur métier plutôt que sur la plomberie Kubernetes.

Que ce soit pour déployer rapidement des solutions tierces depuis des repositories publics ou pour industrialiser le déploiement d'applications internes, Helm offre une approche standardisée qui s'intègre parfaitement dans les workflows DevOps et GitOps modernes. Son adoption massive par l'écosystème Cloud native, des éditeurs logiciels aux grandes entreprises, garantit sa pérennité et en fait un investissement incontournable pour toute organisation opérant Kubernetes en production.