Une fois qu’un chart existe, le travail quotidien avec Helm consiste presque entièrement à gérer des releases : les installer, les mettre à niveau quand le chart ou ses values changent, et occasionnellement en annuler une. Ce guide couvre ce cycle de vie de bout en bout.

Les commandes essentielles

Commande	Ce qu’elle fait
helm install NAME CHART	Crée une nouvelle release à partir d’un chart.
helm upgrade NAME CHART	Applique des changements à une release existante.
helm upgrade --install NAME CHART	Installe si la release n’existe pas encore, met à niveau si elle existe.
helm list	Liste les releases du namespace courant (-A pour tous les namespaces).
helm status NAME	Affiche l’état courant d’une release et de nouveau son NOTES.txt.
helm rollback NAME REVISION	Ramène une release à une révision précédente.
helm uninstall NAME	Supprime une release et ses ressources.

helm upgrade --install mérite une mention à part : c’est le modèle qu’utilise réellement presque tout pipeline CI/CD, car il signifie « assure-toi que cette release existe avec cette configuration » sans que le script ait besoin de savoir ou de vérifier s’il s’agit d’un premier déploiement ou du centième.

Chaque changement est une révision numérotée

helm install web ./webapp
helm list

Une installation neuve est la révision 1. Chaque upgrade suivant ajoute le numéro suivant, et rollback en ajoute un aussi, car un rollback n’est pas une machine à remonter le temps : c’est une nouvelle révision dont le contenu correspond à celui d’une ancienne :

Opération	Révision résultante
helm install	1
helm upgrade	2
helm upgrade	3
helm rollback web 1	4 (le contenu correspond à la révision 1, mais le numéro continue de monter)

helm history web

liste chaque révision avec son statut, la version du chart et la version de l’application, ce que lisent rollback et les commandes d’inspection ci-dessous.

Annuler quand une mise à niveau tourne mal

helm rollback web 2
kubectl rollout status deployment/web

Revenir à un numéro de révision précis est le cas habituel. helm rollback web sans numéro revient à la révision immédiatement précédente. Comme un rollback crée une nouvelle révision, annuler puis annuler de nouveau vous ramène là où vous aviez commencé, cela n’annule pas le rollback lui-même ; vérifiez helm history pour être certain de la révision à laquelle vous revenez réellement.

Inspecter une release sans la modifier

helm status web
helm get values web
helm get manifest web
helm diff upgrade web ./webapp -f values-prod.yaml   # nécessite le plugin helm-diff

get values affiche ce qui a réellement été fourni pour cette release, utile quand une release en cours ne correspond pas à ce que suggère un fichier de values sur disque. get manifest affiche le YAML Kubernetes exact que Helm a appliqué, après templating, ce qui fait foi lorsque vous déboguez un écart entre la source du chart et ce qui est en production. helm diff n’est pas intégré, c’est un plugin communautaire très utilisé (helm plugin install https://github.com/databus23/helm-diff), et il vaut la peine de l’avoir avant d’exécuter une mise à niveau dont vous n’êtes pas sûr, puisqu’il montre exactement ce qui changerait sans rien appliquer.

Désinstaller, en conservant ou non l’historique

helm uninstall web
helm uninstall web --keep-history

Par défaut, la désinstallation supprime à la fois les ressources de la release et son historique. --keep-history supprime les ressources mais conserve l’enregistrement de la release, de sorte que helm history web et helm rollback fonctionnent toujours ensuite, au cas où vous devriez la rétablir ou voudriez simplement une piste d’audit de ce qui tournait auparavant. helm list n’affichera pas une release désinstallée, même avec --keep-history, sauf si vous ajoutez -a/--all.

Ce qui a changé dans Helm 4

Si vous utilisez Helm 4, notez une différence de comportement : les nouvelles installations utilisent par défaut le server-side apply de Kubernetes plutôt que le client-side apply qu’utilisait Helm 3, ce qui gère de façon plus prévisible la propriété des champs et les conflits entre outils. Les mises à niveau et les rollbacks d’une release créée sous Helm 3 continuent d’utiliser le client-side apply, sauf si vous passez explicitement --server-side, de sorte que les workflows mêlant plusieurs versions ne changeront pas soudainement de comportement sous vos pieds. Cela ne modifie aucune des commandes ci-dessus, seulement la façon dont le manifeste résultant est appliqué.