helm-Testfälle schreiben

Lint und template prüfen Dateien, aber helm test prüft ein Release, das bereits in Ihrem Cluster läuft. So wird nachgewiesen, dass die Anwendung tatsächlich funktioniert. ✅

Ein Helm-Test ist ein Pod, der im templates-Verzeichnis Ihres Charts definiert ist. Helm führt ihn bei Bedarf aus und beurteilt den Erfolg anhand seines Exit-Codes.

Sie kennzeichnen einen Pod als Test, indem Sie die Annotation helm.sh/hook: test hinzufügen. Helm überspringt ihn dann bei install und führt ihn nur auf Aufforderung aus.

Ein häufig verwendeter Test führt ein kleines Image wie busybox aus, das mit wget überprüft, ob Ihr Service an seinem Port antwortet.

Wenn der Test-Pod mit 0 beendet wird, ist der Test erfolgreich. Jeder Exit-Code ungleich null markiert ihn als fehlgeschlagen, genau wie bei einem Shell-Befehl.

Führen Sie nach der Installation helm test mit dem Namen des Releases aus. Helm erstellt die Test-Pods, wartet und meldet jedes Ergebnis.

Fügen Sie --logs hinzu, um die Ausgabe jedes Test-Pods zu streamen. So erfahren Sie bei einem Fehler, was schiefgelaufen ist, statt nur zu sehen, dass er fehlgeschlagen ist.

Tests werden während der Installation nicht automatisch ausgeführt. Sie lösen sie selbst aus, wodurch Installationen schnell und Tests explizit bleiben.

Fügen Sie eine hook-delete-policy hinzu, damit abgeschlossene Test-Pods entfernt werden und Ihren Namespace zwischen den Ausführungen nicht überladen.

Üblicherweise befinden sich Test-Pods in templates/tests/. Dadurch bleiben sie organisiert und von den Manifesten Ihrer eigentlichen Workload getrennt.

In einer Pipeline installieren Sie zunächst das Chart und führen anschließend helm test aus. Ein fehlgeschlagener Test lässt den Job fehlschlagen und erkennt fehlerhafte Deployments, bevor es die Benutzer tun.

Wie entscheidet Helm, ob ein Test-Pod erfolgreich war?

Sie haben gelernt, dass helm test annotierte Test-Pods gegen ein laufendes Release ausführt, sie anhand des Exit-Codes beurteilt und sich gut in CI integrieren lässt. 🎉