Repos Helm : ajouter, chercher et inspecter des charts

Ce guide vous apprend à trouver, évaluer et choisir les bons charts Helm pour vos déploiements. Vous allez configurer vos dépôts, rechercher des charts en local comme sur Artifact Hub, et inspecter leurs métadonnées et leurs values avant d'installer quoi que ce soit. En 15 minutes, vous saurez écarter les charts abandonnés ou mal maintenus.

Prérequis

• Helm installé (voir module H1-01)
• Accès réseau vers Internet (pour télécharger les index de repos)
• Aucun cluster Kubernetes requis pour ce module (on inspecte sans installer)

Comprendre les repositories Helm

Un repository Helm, ou « repo », est un simple serveur HTTP qui héberge un fichier index.yaml listant les charts disponibles et leurs versions. Ce fichier porte les métadonnées de chacun : nom, version, description et dépendances.

Quand vous exécutez helm repo add, Helm télécharge cet index et le range localement dans ~/.cache/helm/repository/. Ensuite, helm search repo interroge cette copie locale : c'est pour cela qu'un helm repo update est nécessaire avant de voir les nouvelles versions.

Helm sait lire deux types de sources, et elles ne se manipulent pas pareil. Un repository classique est un simple serveur HTTP qui publie un fichier index.yaml listant ses charts, comme https://prometheus-community.github.io/helm-charts : il s'ajoute avec helm repo add, se met à jour avec helm repo update, et se cherche avec helm search repo. Un registre OCI stocke les charts au même endroit que les images de conteneurs, sous la forme oci://ghcr.io/stefanprodan/charts/podinfo : il ne s'ajoute pas, il se référence directement, et il n'est pas indexable par helm search.

Cette leçon traite les repositories classiques, encore les plus répandus pour les charts publics. La distribution OCI, qui est la recommandation actuelle pour publier vos charts, a sa propre leçon plus loin dans le parcours.

Gérer les repositories

Un repository Helm est un simple serveur HTTP exposant un fichier index.yaml et des archives de charts. Helm en garde une copie locale : c'est pourquoi une recherche peut rendre des versions périmées tant que cet index n'a pas été rafraîchi.

Ajouter un repository

La commande helm repo add enregistre un repository sous un nom local de votre choix :

# Syntaxe : helm repo add <nom-local> <url>
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

Résultat attendu :

"prometheus-community" has been added to your repositories

Le nom local, ici prometheus-community, est arbitraire : rien n'interdit prom ou monitoring. Il sert de préfixe dans toutes les commandes de recherche et d'installation, ce qui plaide pour un nom court mais reconnaissable.

Cinq dépôts qui couvrent la plupart des besoins

Ces cinq dépôts sont maintenus par les projets eux-mêmes, et c'est le seul critère qui compte pour un dépôt qu'on ajoute une fois et qu'on garde : un chart publié par l'équipe qui écrit le logiciel suit ses versions, un chart publié par un tiers suit la disponibilité de ce tiers.

Repository	URL	Contenu
prometheus-community	https://prometheus-community.github.io/helm-charts	Monitoring (Prometheus, Alertmanager, exporters)
grafana	https://grafana.github.io/helm-charts	Visualisation (Grafana, Loki, Tempo)
ingress-nginx	https://kubernetes.github.io/ingress-nginx	Ingress Controller officiel Kubernetes
jetstack	https://charts.jetstack.io	cert-manager pour les certificats TLS
podinfo	https://stefanprodan.github.io/podinfo	Application de test CNCF

Glissez pour voir

Le dernier n'a pas sa place en production : podinfo est une application de démonstration, volontairement minuscule, faite pour éprouver un cluster ou un chart sans rien déployer d'utile. Elle revient souvent dans cette formation pour cette raison.

Lister les repositories configurés

La liste est locale à votre poste : elle vit dans un fichier de configuration, pas dans le cluster. Deux machines qui déploient le même chart peuvent donc avoir des dépôts différents, ce qui explique qu'une commande fonctionne chez vous et échoue en intégration continue.

helm repo list

Résultat attendu :

NAME                    URL
prometheus-community    https://prometheus-community.github.io/helm-charts
ingress-nginx           https://kubernetes.github.io/ingress-nginx
grafana                 https://grafana.github.io/helm-charts
podinfo                 https://stefanprodan.github.io/podinfo

Lecture du tableau :

Colonne	Signification
NAME	Nom local que vous avez choisi lors du helm repo add
URL	Adresse du serveur hébergeant l'index des charts

Glissez pour voir

Mettre à jour les index locaux

Les repositories évoluent : nouvelles versions, nouveaux charts. Helm ne vérifie pas automatiquement les mises à jour. Vous devez explicitement demander la synchronisation :

# Mettre à jour tous les repos
helm repo update

# Mettre à jour un seul repo (plus rapide)
helm repo update podinfo

Résultat attendu :

Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "podinfo" chart repository
...Successfully got an update from the "grafana" chart repository
...Successfully got an update from the "prometheus-community" chart repository
...Successfully got an update from the "ingress-nginx" chart repository
Update Complete. ⎈Happy Helming!⎈

Piège classique

Si helm search repo ne montre pas une version que vous savez publiée, la cause est presque toujours un index local obsolète. Lancez helm repo update avant de conclure qu'un chart n'existe pas.

Supprimer un repository

helm repo remove podinfo

Résultat attendu :

"podinfo" has been removed from your repositories

Cela supprime uniquement la référence locale. Aucun chart installé n'est affecté.

Rechercher des charts

Helm propose deux commandes de recherche qui interrogent des sources différentes.

Recherche locale : helm search repo

Cette commande interroge l'index local de vos repositories configurés :

# Rechercher un mot-clé dans tous les repos locaux
helm search repo prometheus

Résultat (extrait) :

NAME                                              CHART VERSION   APP VERSION   DESCRIPTION
prometheus-community/prometheus                   28.7.0          v3.9.1        Prometheus is a monitoring system and time seri...
prometheus-community/kube-prometheus-stack        81.4.2          v0.88.1       kube-prometheus-stack collects Kubernetes manif...
prometheus-community/prometheus-node-exporter     4.51.0          1.10.2        A Helm chart for prometheus node-exporter
prometheus-community/prometheus-redis-exporter    6.20.2          v1.80.2       Prometheus exporter for Redis metrics

Lecture du tableau :

Colonne	Signification	Exemple
NAME	<nom-repo>/<nom-chart>, identifiant complet du chart	prometheus-community/prometheus
CHART VERSION	Version du chart Helm (packaging)	28.7.0
APP VERSION	Version de l'application déployée	v3.9.1
DESCRIPTION	Brève description du chart	Tronquée à 50 caractères

Glissez pour voir

Les deux colonnes de version que renvoie cette commande ne parlent pas de la même chose, et les confondre fausse toute décision de mise à jour. La CHART VERSION est la version de l'emballage Helm : templates, values, helpers. Elle change dès que le packaging évolue, même si l'application ne bouge pas. L'APP VERSION est la version du logiciel réellement déployé, celle de Prometheus ou de Grafana.

Les deux numéros sont indépendants. Un même chart peut donc porter plusieurs versions qui déploient la même APP VERSION, quand seuls ses templates ont été corrigés, ou au contraire une seule version qui embarque une nouvelle version applicative. C'est pourquoi une montée de CHART VERSION ne signifie pas que vous mettez à jour votre application, et réciproquement.

Une chose que ce tableau ne montre pas vous évitera une fausse piste : les pré-versions en sont absentes. Un chart publié en 0.3.0-alpha.1 ne remontera pas dans la liste tant que 0.2.0 existe, parce que Helm considère tout suffixe SemVer de pré-version (-alpha, -beta, -rc) comme une version de développement et la masque par défaut. Le drapeau --devel lève ce filtre :

helm search repo mon-chart            # 0.2.0 seulement
helm search repo mon-chart --devel    # 0.3.0-alpha.1 apparaît aussi

Le comportement par défaut est une protection : sans lui, une alpha poussée par erreur deviendrait instantanément la version proposée à tous ceux qui installent le chart. Réservez donc --devel au moment où vous cherchez volontairement une pré-version, jamais dans un script d'installation.

Rechercher dans un repo spécifique

Préfixer la recherche du nom local du repository évite les homonymes : plusieurs éditeurs publient un chart nommé nginx.

# Tous les charts du repo prometheus-community
helm search repo prometheus-community

# Recherche d'un terme précis
helm search repo exporter

Voir toutes les versions disponibles

Par défaut, seule la dernière version apparaît. Pour voir l'historique :

helm search repo podinfo/podinfo --versions

Résultat :

NAME              CHART VERSION   APP VERSION   DESCRIPTION
podinfo/podinfo   6.10.0          6.10.0        Podinfo Helm chart for Kubernetes
podinfo/podinfo   6.9.4           6.9.4         Podinfo Helm chart for Kubernetes
podinfo/podinfo   6.9.3           6.9.3         Podinfo Helm chart for Kubernetes
podinfo/podinfo   6.9.2           6.9.2         Podinfo Helm chart for Kubernetes
podinfo/podinfo   6.9.1           6.9.1         Podinfo Helm chart for Kubernetes
podinfo/podinfo   6.9.0           6.9.0         Podinfo Helm chart for Kubernetes
...

C'est utile pour épingler une version ou revenir à une version antérieure en cas de régression.

Recherche globale : helm search hub

Cette commande interroge Artifact Hub, le catalogue centralisé de la CNCF qui indexe des milliers de charts de multiples éditeurs :

helm search hub prometheus

Résultat (extrait) :

URL                                                                         CHART VERSION   APP VERSION   DESCRIPTION
https://artifacthub.io/packages/helm/prometheus-community/prometheus        28.7.0          v3.9.1        Prometheus is a monitoring...
https://artifacthub.io/packages/helm/wenerme/prometheus                     28.7.0          v3.9.1        Prometheus is a monitoring...

Différence avec helm search repo :

Aspect	helm search repo	helm search hub
Source	Index locaux (vos repos configurés)	Artifact Hub (Internet)
Vitesse	Instantané	Requête HTTP
Couverture	Limitée à vos repos	Tous les charts publics
Offline	Fonctionne	Nécessite Internet

Glissez pour voir

Ces deux commandes se complètent dans un ordre qui a du sens, et qu'il vaut mieux suivre plutôt que de chercher au hasard. On découvre avec helm search hub <mot-clé>, qui interroge Artifact Hub et donne un panorama. On évalue en ouvrant l'URL rendue : documentation, fréquence de mise à jour, identité du mainteneur. On configure ensuite le dépôt retenu avec helm repo add, une fois pour toutes. Et on cherche au quotidien avec helm search repo, qui lit l'index local et répond instantanément, sans réseau.

Formats de sortie alternatifs

La sortie en tableau est faite pour l'œil humain, pas pour un script : ses colonnes bougent avec la longueur des noms. Dès qu'une commande doit être lue par du code, demandez du JSON ou du YAML et extrayez le champ voulu, plutôt que de découper du texte à coups de awk.

Pour le scripting ou l'intégration CI/CD :

# Format YAML
helm search repo -o yaml podinfo/podinfo

- app_version: 6.10.0
  description: Podinfo Helm chart for Kubernetes
  name: podinfo/podinfo
  version: 6.10.0

# Format JSON
helm search repo -o json podinfo/podinfo

[{"name":"podinfo/podinfo","version":"6.10.0","app_version":"6.10.0","description":"Podinfo Helm chart for Kubernetes"}]

Inspecter un chart avant installation

Règle d'or

Ne jamais installer un chart sans l'avoir inspecté. Vous allez déployer du code dans votre cluster, autant savoir ce qu'il contient.

La commande helm show (ou son alias helm inspect) affiche les informations d'un chart sans l'installer.

Métadonnées du chart (Chart.yaml)

C'est la première chose à regarder sur un chart qu'on ne connaît pas : la version, l'application embarquée, et surtout le mainteneur et la source. Un chart sans dépôt source déclaré est un chart dont vous ne pourrez pas lire les templates avant installation.

helm show chart podinfo/podinfo

Résultat :

apiVersion: v1
appVersion: 6.10.0
description: Podinfo Helm chart for Kubernetes
home: https://github.com/stefanprodan/podinfo
kubeVersion: '>=1.23.0-0'
maintainers:
- email: stefanprodan@users.noreply.github.com
  name: stefanprodan
name: podinfo
sources:
- https://github.com/stefanprodan/podinfo
version: 6.10.0

Lecture des champs :

Champ	Signification	Pourquoi c'est important
apiVersion	Version de la spec Chart.yaml (v1 ou v2)	v2 = Helm 3, v1 = Helm 2 (legacy)
appVersion	Version de l'application déployée	Correspond-elle à vos besoins ?
kubeVersion	Versions Kubernetes supportées	Votre cluster est-il compatible ?
maintainers	Qui maintient ce chart	Projet actif ou abandonné ?
home / sources	Liens vers le projet	Documentation disponible ?

Glissez pour voir

Valeurs par défaut (values.yaml)

C'est la partie la plus importante, elle définit toute la configuration possible :

helm show values podinfo/podinfo

Résultat (extrait) :

# Default values for podinfo.

replicaCount: 1
logLevel: info

image:
  repository: ghcr.io/stefanprodan/podinfo
  tag: 6.10.0
  pullPolicy: IfNotPresent

ui:
  color: "#34577c"
  message: ""

service:
  enabled: true
  type: ClusterIP
  httpPort: 9898

resources: {}
  # limits:
  #   cpu: 100m
  #   memory: 128Mi

Ce que vous devez repérer :

Élément	Question à se poser
image.repository	L'image vient-elle d'un registre de confiance ?
resources	Les limites par défaut sont-elles adaptées à votre cluster ?
service.type	ClusterIP, LoadBalancer, NodePort, lequel pour votre cas ?
Valeurs commentées	Options désactivées par défaut mais disponibles

Glissez pour voir

Documentation (README)

Le README d'un chart est souvent le seul endroit où ses auteurs documentent les values, leurs valeurs par défaut et les combinaisons qui ne fonctionnent pas. Le lire avant l'installation coûte cinq minutes ; le découvrir après un incident en coûte bien davantage.

helm show readme podinfo/podinfo | head -50

Résultat (extrait) :

# Podinfo

Podinfo is a tiny web application made with Go
that showcases best practices of running microservices in Kubernetes.

## Installing the Chart

To install the chart with the release name `podinfo`:

$ helm upgrade -i podinfo oci://ghcr.io/stefanprodan/charts/podinfo

Le README contient généralement :

• Les instructions d'installation
• La liste des paramètres configurables
• Des exemples de configuration
• Les prérequis spécifiques

Tout en une seule commande

helm show all podinfo/podinfo | wc -l
# Résultat : 387 lignes

helm show all combine chart + values + readme. Utile pour sauvegarder dans un fichier :

helm show all podinfo/podinfo > podinfo-chart-doc.txt

Inspecter une version spécifique

Inspecter la dernière version d'un chart ne dit rien de celle que vous exécutez réellement. Dès qu'une release est en place depuis quelque temps, la comparaison qui compte est celle entre la version déployée et la version visée, et elle demande d'interroger explicitement les deux.

Toutes les commandes helm show acceptent --version :

# Voir les values d'une ancienne version
helm show values podinfo/podinfo --version 6.7.0

Épingler une version (reproductibilité)

En production, vous ne voulez jamais que Helm installe "la dernière version", cela peut casser votre déploiement lors d'une mise à jour inattendue.

1. Identifiez la version exacte avec helm search repo --versions

   helm search repo podinfo/podinfo --versions | head -5

2. Testez en environnement de dev avec cette version précise

   helm install podinfo podinfo/podinfo --version 6.9.0 --dry-run

3. Documentez la version dans votre pipeline CI/CD ou fichier de configuration

   # Dans votre Helmfile, ArgoCD Application, ou script CI
   chart: podinfo/podinfo
   version: 6.9.0  # Épinglé

Installer sans préciser la version est l'anti-pattern le plus coûteux de cette leçon. Sans --version, Helm prend la plus récente au moment de la commande : deux exécutions à quinze jours d'intervalle, avec le même script et le même dépôt, installent deux charts différents. C'est exactement ce qui rend un environnement non reproductible, et le genre d'écart qu'on ne découvre qu'en incident.

# ❌ DANGEREUX : version non spécifiée
helm install podinfo podinfo/podinfo

Toujours spécifier la version :

# ✅ SÉCURISÉ : version explicite
helm install podinfo podinfo/podinfo --version 6.9.0

Critères de sélection d'un chart

Avant d'adopter un chart pour la production, vérifiez ces critères :

Critère	Comment vérifier	Seuil acceptable
Maintenance active	Dernière release sur Artifact Hub	< 6 mois
Popularité	Étoiles GitHub, téléchargements	Subjectif, mais > 100 étoiles
Documentation	README, examples, CHANGELOG	Présence de toutes les sections
Sécurité	Pas de privileged: true par défaut, images signées	Vérifier dans values.yaml
Licence	Champ license dans Chart.yaml ou repo GitHub	Apache 2.0, MIT, BSD

Glissez pour voir

Attention aux forks

Artifact Hub indexe de nombreux forks de charts populaires. Vérifiez toujours que vous utilisez le chart officiel, maintenu par le projet d'origine : prometheus-community pour Prometheus, jamais un fork tiers au nom voisin.

Que va vraiment obtenir ce chart dans mon cluster ?

Les critères ci-dessus jugent le projet ; celui-ci juge le code. Un chart n'est pas un fichier de configuration, c'est un programme qui crée des objets Kubernetes avec les droits du compte qui lance helm install. La question à se poser avant d'installer n'est pas « ce projet est-il sérieux » mais « que va-t-il obtenir ». helm template y répond sans rien créer, puisqu'il rend le YAML final sur la sortie standard.

Commencez par l'inventaire, qui tient en une ligne et surprend souvent :

helm template audit prometheus-community/kube-state-metrics | grep '^kind:' | sort | uniq -c

   1 kind: ClusterRole
   1 kind: ClusterRoleBinding
   1 kind: Deployment
   1 kind: Service
   1 kind: ServiceAccount

Deux objets sur cinq sont à l'échelle du cluster. Un ClusterRole sort du namespace où vous installez : ses droits valent partout. C'est justifié ici, un collecteur de métriques devant lire l'état du cluster entier, mais cela mérite d'être su plutôt que découvert.

Lisez donc ce que le rôle demande, verbe par verbe :

helm template audit prometheus-community/kube-state-metrics \
  | awk '/^kind: ClusterRole$/,/^---$/' | grep -A3 'resources:'

Sur ce chart, tous les verbes valent ["list", "watch"] : de la lecture seule. Un create, un delete, ou pire un * sur les secrets, appellerait une autre conversation avec l'équipe qui exploite le cluster.

Trois vérifications complètent le tableau, et chacune répond à une question précise :

# Quelles images vont réellement être tirées, et depuis quel registre ?
helm template audit <chart> | grep -E '^\s+image:' | sort -u

# Le chart demande-t-il des privilèges sur les nœuds ?
helm template audit <chart> | grep -E 'privileged: true|hostNetwork: true|hostPID: true'

# Exécute-t-il du code au moment de l'installation ?
helm template audit <chart> | grep 'helm.sh/hook'

La dernière est la moins connue et la plus importante. Un hook est un Pod que Helm lance pendant l'installation, souvent avec les droits du ServiceAccount du chart. Un chart qui en déclare exécute du code chez vous, avant même que vous ayez vu tourner l'application. Ce n'est pas suspect en soi, une migration de schéma en est l'usage normal, mais cela se lit avant, pas après.

Ce que vous cherchez	Ce qui doit alerter
Objets créés	ClusterRole, ClusterRoleBinding, CRD, MutatingWebhookConfiguration
Verbes RBAC	create, delete, *, surtout sur secrets
Images	registre inconnu, tag mutable, absence de digest
Pods	privileged, hostNetwork, hostPID, montage de /var/run/docker.sock
Hooks	tout hook non expliqué par le README

Glissez pour voir

Lab A2 : Explorer et comparer des charts

Objectif : Pratiquer les commandes de recherche et d'inspection en comparant deux charts de monitoring.

1. Ajoutez les repos nécessaires

   helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
   helm repo add grafana https://grafana.github.io/helm-charts
   helm repo update

2. Recherchez les charts Prometheus disponibles

   helm search repo prometheus

   Notez la différence entre prometheus-community/prometheus (Prometheus seul) et prometheus-community/kube-prometheus-stack (Prometheus + Grafana + Alertmanager).

3. Comparez les versions Kubernetes requises

   helm show chart prometheus-community/prometheus | grep kubeVersion
   helm show chart prometheus-community/kube-prometheus-stack | grep kubeVersion

4. Inspectez les ressources par défaut du chart Prometheus

   helm show values prometheus-community/prometheus | grep -A 10 "resources:"

5. Listez les 3 dernières versions du kube-prometheus-stack

   helm search repo kube-prometheus-stack --versions | head -4

Résultat attendu : Vous savez maintenant identifier quel chart correspond à votre besoin et quelles versions sont disponibles.

Dépannage

Ces symptômes ont un point commun : ils viennent presque tous de l'index local, pas du dépôt distant. Helm ne redemande jamais l'index de lui-même, et un helm repo update oublié explique à lui seul la majorité des « cette version n'existe pas » alors qu'elle est bien publiée.

Symptôme	Cause probable	Solution
Error: repo not found	Nom de repo mal orthographié	Vérifier avec helm repo list
no repositories configured	Aucun repo ajouté	helm repo add <nom> <url>
Version non trouvée malgré existence	Index local obsolète	helm repo update
context deadline exceeded	Problème réseau	Vérifier la connectivité, proxy
Résultats de recherche vides	Mot-clé trop spécifique	Essayer des termes plus génériques
401 Unauthorized	Repo privé sans authentification	helm repo add --username --password

Glissez pour voir

À retenir

• Repository = source de charts. Ajoutez avec helm repo add, mettez à jour avec helm repo update.
• helm search repo interroge vos repos locaux (rapide, offline), helm search hub interroge Artifact Hub (exhaustif, online).
• Deux versions à distinguer : CHART VERSION (packaging) et APP VERSION (application déployée).
• Inspectez avant d'installer : helm show chart (métadonnées), helm show values (configuration), helm show readme (documentation).
• Épinglez toujours la version en production avec --version pour garantir la reproductibilité.
• Évaluez la qualité : maintenance active, documentation, popularité, licence, sécurité par défaut.

Contrôle de connaissances

Six questions sur ce qui distingue un chart digne de confiance d'un chart qu'on installe sans regarder : ce qu'un ClusterRole implique, comment repérer un hook qui exécute du code chez vous, et ce que search repo interroge vraiment.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

5 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Personnaliser avec les values : Adapter un chart trouvé sur un dépôt sans le modifier.
• Anatomie d'un chart : Ce que vous inspectez avec helm show, vu de l'intérieur.
• Distribuer ses charts via OCI : Les registres OCI, qui remplacent progressivement les dépôts classiques.

×

📖 Voir la documentation →