Concepts clés : Charts, Releases, Repositories

Comprendre le vocabulaire de Helm pour mieux l'utiliser

Pour utiliser Helm efficacement, il est indispensable de bien comprendre son vocabulaire et ses concepts fondamentaux. Ces concepts structurent la manière dont les applications sont packagées, déployées et partagées. Au coeur de Helm se trouvent trois éléments indissociables : les Charts, les Releases et les Repositories.

Saisir la signification et le rôle de chacun de ces éléments est la clé pour débloquer la puissance de Helm et transformer la façon dont vous gérez les déploiements sur Kubernetes. Cette section détaille chacun de ces trois piliers, en expliquant leur fonction et comment ils interagissent.

Charts : Le format de packaging des applications Kubernetes

Un Chart Helm est l'unité fondamentale de packaging dans Helm. C'est essentiellement un ensemble de fichiers organisés dans une structure de répertoires spécifique, décrivant un ensemble connexe de ressources Kubernetes. Pensez à un Chart comme à l'équivalent d'un paquet .deb ou .rpm, mais contenant des modèles de manifestes Kubernetes et des métadonnées associées.

La structure typique d'un Chart ressemble à ceci :

mon-chart/
├── Chart.yaml        # Métadonnées sur le Chart (nom, version, description, etc.)
├── values.yaml       # Valeurs de configuration par défaut pour les modèles
├── templates/        # Répertoire contenant les fichiers modèles de manifestes K8s
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ... (autres modèles: ingress.yaml, configmap.yaml, etc.)
├── charts/           # Répertoire pour les dépendances (sous-charts)
└── README.md         # Documentation lisible par l'humain

• Chart.yaml : Contient des informations essentielles sur le Chart, comme son nom (name), sa version (version), la version de l'application qu'il déploie (appVersion), une description, etc. C'est le fichier d'identité du Chart.
• values.yaml : Ce fichier définit les valeurs de configuration par défaut qui peuvent être utilisées dans les modèles. C'est ici que vous exposez les paramètres que les utilisateurs pourront personnaliser lors de l'installation (nombre de réplicas, image à utiliser, ressources, etc.).
• templates/ : Le coeur du Chart. Ce répertoire contient les fichiers manifestes Kubernetes, mais écrits sous forme de modèles. Helm utilise un moteur de templating (basé sur le langage de template Go et étendu avec les fonctions de Sprig et des fonctions spécifiques à Helm) pour générer les manifestes Kubernetes finaux. Ces modèles peuvent utiliser les valeurs définies dans values.yaml (ou surchargées par l'utilisateur) pour rendre les manifestes dynamiques et configurables. Par exemple, un modèle de Deployment pourrait utiliser {{ .Values.replicaCount }} pour définir le nombre de réplicas.
• charts/ : Ce répertoire contient d'autres Charts dont ce Chart dépend (sous-charts). Helm peut gérer automatiquement le téléchargement et l'installation de ces dépendances.

Les Charts sont conçus pour être versionnés et réutilisables. Vous pouvez créer un Chart pour votre propre application ou utiliser des Charts existants créés par la communauté pour des logiciels populaires (bases de données, outils de monitoring, etc.). L'objectif est de fournir un paquet standardisé et configurable pour déployer une application sur Kubernetes.

Releases : Une instance d'un Chart déployée sur le cluster

Un Chart est un paquet, une définition. Mais lorsque vous installez un Chart sur votre cluster Kubernetes, vous créez une Release. Une Release est une instance spécifique d'un Chart en cours d'exécution dans un cluster Kubernetes. Vous pouvez installer le même Chart plusieurs fois dans le même cluster (par exemple, dans des namespaces différents ou avec des noms de release différents), chaque installation créant une Release distincte.

Chaque Release est identifiée par un nom unique au sein d'un namespace. Lorsque vous installez un Chart avec la commande helm install , Helm effectue les actions suivantes :

1. Il prend le Chart spécifié.
2. Il combine les valeurs par défaut du Chart (values.yaml) avec les valeurs que vous avez éventuellement fournies (via --set ou -f mon-fichier-valeurs.yaml).
3. Il utilise le moteur de templating pour générer les manifestes Kubernetes finaux à partir des modèles du répertoire templates/ et des valeurs combinées.
4. Il envoie ces manifestes générés à l'API Server de Kubernetes pour créer les ressources correspondantes (Deployments, Services, etc.).
5. Il enregistre les informations sur cette Release (le Chart utilisé, les valeurs appliquées, la révision) dans le cluster (généralement sous forme d'objet Secret dans le namespace de la Release).

Helm gère le cycle de vie complet des Releases :

• Installation (helm install) : Crée une nouvelle Release.
• Mise à niveau (helm upgrade) : Met à jour une Release existante vers une nouvelle version du Chart ou avec de nouvelles valeurs de configuration. Helm calcule les différences et applique les changements nécessaires aux ressources Kubernetes. Chaque mise à niveau crée une nouvelle révision de la Release.
• Retour en arrière (helm rollback) : Permet de revenir à une révision précédente d'une Release en cas de problème avec une mise à niveau.
• Suppression (helm uninstall) : Supprime toutes les ressources Kubernetes associées à une Release.

La Release est donc l'entité dynamique que Helm gère activement sur le cluster, représentant une application déployée et configurée via un Chart.

Repositories : Partager et découvrir des Charts

Maintenant que nous savons comment packager des applications (Charts) et les déployer (Releases), comment trouver et partager ces Charts ? C'est le rôle des Repositories Helm (dépôts).

Un Repository Helm est simplement un serveur HTTP qui héberge un fichier spécial nommé index.yaml et, éventuellement, les fichiers de Chart packagés (archives .tgz). Le fichier index.yaml contient une liste de tous les Charts disponibles dans le dépôt, avec leurs métadonnées (nom, version, description, etc.) et des liens vers les archives .tgz correspondantes.

Le client Helm interagit avec les repositories via quelques commandes simples :

• helm repo add : Ajoute un nouveau repository à la configuration locale de Helm, lui donnant un nom court pour référence future.
• helm repo update : Récupère les dernières versions des fichiers index.yaml de tous les repositories configurés localement. C'est important de le faire régulièrement pour voir les nouveaux Charts ou les nouvelles versions.
• helm search repo : Recherche des Charts contenant le mot-clé dans les index locaux de tous les repositories ajoutés.
• helm install / : Installe un Chart provenant d'un repository spécifique (par exemple, helm install my-redis stable/redis). Helm utilise l'index local pour trouver l'URL de l'archive du Chart, la télécharge, puis l'installe.

Il existe de nombreux repositories publics où la communauté partage des Charts pour des logiciels populaires. Artifact Hub (artifacthub.io) est un projet CNCF qui sert d'index centralisé pour découvrir des Charts (et d'autres types de paquets Cloud Native) provenant de divers repositories. Les organisations peuvent également mettre en place leurs propres repositories privés pour partager des Charts internes, en utilisant des solutions comme ChartMuseum ou des fonctionnalités intégrées dans des plateformes comme GitLab, GitHub Packages, ou des registres OCI (Helm supporte désormais nativement le stockage de Charts dans des registres d'images conteneurs OCI).

Ensemble, Charts, Releases et Repositories forment un écosystème cohérent qui simplifie considérablement le cycle de vie des applications sur Kubernetes, favorisant la standardisation, la réutilisation et l'automatisation.