L’essentiel de ce que fait un chart consiste à déclarer des ressources qui restent en cours d’exécution. Parfois, il faut quelque chose qui s’exécute une seule fois à un moment précis : une migration de base de données avant une mise à niveau, un job de nettoyage après une désinstallation, ou une vérification que la release fonctionne bien une fois démarrée. Helm couvre les deux avec les hooks et les tests de chart.

Ce qu’est un hook

Un hook est une ressource Kubernetes ordinaire, le plus souvent un Job, annotée pour indiquer à Helm quand l’exécuter par rapport à une installation, une mise à niveau, un rollback ou une désinstallation :

# templates/hooks/pre-install-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: {{ .Values.appName }}-pre-install
  annotations:
    "helm.sh/hook": pre-install
    "helm.sh/hook-weight": "0"
    "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: migrate
          image: myorg/webapp-migrate:1.0
          command: ["./run-migrations.sh"]

L’annotation helm.sh/hook est ce qui fait de cette ressource un hook plutôt qu’une ressource normale suivie par Helm comme partie de la release. Les points d’accroche courants sont pre-install, post-install, pre-upgrade, post-upgrade, pre-rollback, post-rollback, pre-delete et post-delete ; la liste complète, y compris quelques points liés aux tests, figure dans la documentation des hooks de Helm.

Comment Helm séquence un hook

Pour un hook pre-install :

1. Helm génère la ressource du hook et la crée dans le cluster, avant tout le reste du chart.
2. Helm attend qu’elle atteigne un état prêt ou terminé (un Job allant jusqu’à son terme compte).
3. Seulement alors, Helm génère et applique le reste des ressources du chart.

post-install inverse les étapes 1 et 3 : les ressources habituelles du chart sont créées d’abord, puis le hook s’exécute. Un hook pre-upgrade qui échoue arrête la mise à niveau, ce qui est précisément l’intérêt d’y exécuter une migration plutôt que d’espérer qu’elle réussisse après coup.

Poids et politique de suppression d’un hook

helm.sh/hook-weight ordonne plusieurs hooks au même point : les nombres les plus bas s’exécutent en premier, sous forme de chaînes ("0", "5"), et les hooks sans poids valent 0 par défaut. helm.sh/hook-delete-policy contrôle le nettoyage, puisqu’un Job terminé reste sinon indéfiniment dans le cluster :

• before-hook-creation (par défaut) : supprime la ressource de hook précédente avant d’en créer une nouvelle, afin que les nouvelles tentatives n’entrent pas en collision avec un Job résiduel du même nom.
• hook-succeeded : supprime la ressource dès qu’elle se termine avec succès.
• hook-failed : la supprime si elle échoue, utile quand vous préférez nettoyer plutôt que de laisser un Job en échec pour inspection ; omettez-la si vous voulez faire un kubectl logs sur un échec avant sa suppression.

Une combinaison pre-install,hook-succeeded, par exemple, signifie que le hook s’exécute une fois, réussit et se nettoie lui-même, sans laisser de trace au-delà de la sortie de votre propre Job ; ajoutez aussi hook-failed si vous ne voulez pas non plus qu’une tentative échouée traîne.

Essayez-le

kubectl get jobs -w

Dans un autre terminal :

helm install web ./webapp

En regardant le premier terminal, vous devriez voir le Job du hook apparaître, s’exécuter, se terminer et (selon sa politique de suppression) disparaître, le tout avant que le Deployment du chart n’apparaisse. C’est le moyen le plus simple de voir réellement le séquencement plutôt que de le croire sur parole.

Tests de chart : vérifier une release une fois démarrée

Un test de chart est un Job qui s’exécute à la demande, une fois la release existante, pour vérifier qu’elle fonctionne réellement :

# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "{{ .Values.appName }}-test-connection"
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: wget
      image: busybox:1.36
      command: ["wget", "-qO-", "{{ .Values.appName }}"]
  restartPolicy: Never

helm install web ./webapp
helm test web

helm test exécute chaque ressource annotée helm.sh/hook: test dans la release et indique la réussite ou l’échec d’après le code de sortie de chaque Pod ; un wget qui obtient une réponse se termine avec 0, celui qui ne peut pas se connecter non. Contrairement aux hooks d’installation et de mise à niveau, les ressources de test ne sont pas supprimées automatiquement par défaut ; exécutez helm test --logs pour voir leur sortie directement, ou nettoyez-les vous-même entre deux exécutions.

Quand recourir à chacun

• Utilisez un hook quand quelque chose doit se produire exactement une fois, à un moment précis du cycle de vie d’une release, et que le reste du déploiement doit l’attendre ou y réagir : migrations de schéma avant une mise à niveau, notification d’un système externe après l’installation, nettoyage de ressources externes avant une désinstallation.
• Utilisez un test de chart pour tout ce que vous voulez relancer à la demande sur une release déjà en cours d’exécution, le plus souvent comme test de fumée après helm install ou helm upgrade dans un pipeline de CI, sans que cela fasse partie de la séquence de déploiement elle-même.

Les deux sont des ressources Kubernetes ordinaires sous les annotations ; tout ce que vous savez déjà sur le débogage d’un Job ou d’un Pod, kubectl describe, kubectl logs, s’applique donc directement.