Das meiste, was ein Chart tut, ist, Ressourcen zu deklarieren, die weiterlaufen. Manchmal brauchst du etwas, das zu einem bestimmten Zeitpunkt einmal läuft: eine Datenbankmigration vor einem Upgrade, einen Aufräum-Job nach einer Deinstallation oder eine Prüfung, dass das Release tatsächlich funktioniert, sobald es läuft. Helm deckt beides mit Hooks und Chart-Tests ab.

Was ein Hook ist

Ein Hook ist eine gewöhnliche Kubernetes-Ressource, meist ein Job, annotiert, um Helm zu sagen, wann sie relativ zu einer Installation, einem Upgrade, einem Rollback oder einer Deinstallation laufen soll:

# 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"]

Die Annotation helm.sh/hook macht das zu einem Hook statt zu einer normalen Ressource, die Helm als Teil des Releases verfolgt. Die gängigen Hook-Punkte sind pre-install, post-install, pre-upgrade, post-upgrade, pre-rollback, post-rollback, pre-delete und post-delete; die vollständige Liste, einschließlich einiger testbezogener, steht in der Helm-Hooks-Dokumentation.

Wie Helm einen Hook einordnet

Für einen pre-install-Hook:

1. Helm rendert die Hook-Ressource und erstellt sie im Cluster, vor allem anderen im Chart.
2. Helm wartet, bis sie einen bereiten oder abgeschlossenen Zustand erreicht (ein bis zum Ende laufender Job zählt).
3. Erst dann rendert und wendet Helm die übrigen regulären Ressourcen des Charts an.

post-install kehrt Schritt 1 und 3 um: Die regulären Ressourcen des Charts gehen zuerst hinein, dann läuft der Hook. Ein fehlschlagender pre-upgrade-Hook stoppt das Upgrade, was genau der Sinn ist, eine Migration dort statt danach in der Hoffnung auf Erfolg auszuführen.

Hook-Gewicht und Löschrichtlinie

helm.sh/hook-weight ordnet mehrere Hooks am selben Punkt, niedrigere Zahlen laufen zuerst, als einfache Strings ("0", "5"), und Hooks ohne Gewicht haben standardmäßig 0. helm.sh/hook-delete-policy steuert das Aufräumen, da ein abgeschlossener Job sonst unbegrenzt im Cluster verbleibt:

• before-hook-creation (der Standard): Löscht die vorherige Hook-Ressource, bevor eine neue erstellt wird, sodass Wiederholungen nicht mit einem übrig gebliebenen Job desselben Namens kollidieren.
• hook-succeeded: Löscht die Ressource, sobald sie erfolgreich abgeschlossen ist.
• hook-failed: Löscht sie, wenn sie fehlschlägt, nützlich, wenn du lieber aufräumst, als einen fehlgeschlagenen Job zur Untersuchung liegen zu lassen; lass es weg, wenn du kubectl logs für einen Fehler ansehen willst, bevor er entfernt wird.

Eine Kombination pre-install,hook-succeeded bedeutet zum Beispiel, dass der Hook einmal läuft, erfolgreich ist und sich selbst aufräumt, sodass außer der eigenen Ausgabe deines Jobs keine Spur bleibt; füge auch hook-failed hinzu, wenn du nicht willst, dass ein fehlgeschlagener Versuch ebenfalls herumhängt.

Ausprobieren

kubectl get jobs -w

In einem anderen Terminal:

helm install web ./webapp

Beim Zusehen im ersten Terminal solltest du den Hook-Job erscheinen, laufen, abschließen und (je nach Löschrichtlinie) verschwinden sehen, alles bevor das Deployment des Charts auftaucht. Das ist der einfachste Weg, die Einordnung tatsächlich zu sehen, statt sie auf Treu und Glauben hinzunehmen.

Chart-Tests: ein Release prüfen, nachdem es läuft

Ein Chart-Test ist ein Job, der bei Bedarf läuft, nachdem ein Release existiert, um zu prüfen, ob es tatsächlich funktioniert:

# 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 führt jede mit helm.sh/hook: test annotierte Ressource im Release aus und meldet Erfolg oder Misserfolg anhand des Exit-Status jedes Pods; ein wget, das eine Antwort bekommt, beendet sich mit 0, eines, das sich nicht verbinden kann, nicht. Anders als Install-/Upgrade-Hooks werden Test-Ressourcen standardmäßig nicht automatisch gelöscht; führe helm test --logs aus, um ihre Ausgabe inline zu sehen, oder räume sie zwischen den Läufen selbst auf.

Wann du wozu greifst

• Nutze einen Hook, wenn etwas genau einmal an einem bestimmten Punkt im Lebenszyklus eines Releases passieren muss und das übrige Deployment darauf warten oder reagieren soll: Schema-Migrationen vor einem Upgrade, ein externes System nach der Installation benachrichtigen, externe Ressourcen vor einer Deinstallation aufräumen.
• Nutze einen Chart-Test für alles, was du bei Bedarf gegen ein bereits laufendes Release erneut ausführen willst, meist als Smoke-Test nach helm install oder helm upgrade in einer CI-Pipeline, ohne dass er Teil der Deployment-Abfolge selbst ist.

Beide sind unter den Annotationen gewöhnliche Kubernetes-Ressourcen, alles, was du bereits über das Debuggen eines Jobs oder Pods weißt, kubectl describe, kubectl logs, gilt also direkt.