Helm-Deployments auf Kubernetes mit Helmsman automatisieren

Die Verwaltung des Lebenszyklus von Helm Charts ist eine manuelle Aufgabe. Mit Helmsman könnt ihr sie mithilfe deklarativer Konfigurationsdateien automatisieren.

Helm bündelt Kubernetes-Anwendungen als wiederverwendbare, anpassbare und teilbare Pakete, die als „Charts“ bezeichnet werden. Helmsman ergänzt Helm um eine Abstraktionsebene und ermöglicht es Nutzern, den gewünschten Zustand ihrer Helm Charts in einem Kubernetes-Cluster deklarativ zu definieren.

Warum wir Helmsman entwickelt haben

Als wir für einen Kunden Atlassian-Produkte in einem Kubernetes-Cluster bereitstellten, erstellten wir zunächst Kubernetes-Manifestdateien für die benötigten Kubernetes-Objekte. Wir mussten die Bereitstellung dieser Objekte im Cluster automatisieren, sobald wir Änderungen in unser Git-Repository pushten. Dafür entwickelten wir ein eigenes Skript in unserer CI-Pipeline. Die Vorgänge, die wir unterstützen wollten, umfassten das Erstellen, Löschen, Aktualisieren und Verschieben von Kubernetes-Objekten in andere Namespaces. Im Laufe des Projekts wurde schnell klar, dass das Skript komplex und schwer zu warten wurde. Es musste jedes Mal aktualisiert werden, wenn wir ein neues Kubernetes-Objekt hinzufügten. Wir begannen, Helm zu nutzen, da es uns half, mehrere Kubernetes-Objekte zu einer Einheit – einem „Chart“ – zusammenzufassen. Dadurch wurde das CI-Skript etwas einfacher, musste aber weiterhin regelmäßig um neue Charts ergänzt werden. Und was ist, wenn wir dieses Setup für einen anderen Kunden nachbilden müssen? Dann müssten wir auch das CI-Skript kopieren und anpassen.

Wir brauchten eine dynamischere und weniger interaktive Lösung. So entstand die Idee, einen „gewünschten Zustand“ zu definieren – also zu beschreiben, welche Charts wo im Cluster vorhanden sein sollen – und ein Tool einzusetzen, das intelligent genug ist, diesen Zustand sicherzustellen. Ähnlich wie Infrastructure as Code, aber für Helm Charts (Kubernetes-Anwendungen). Wenn wir den gewünschten Zustand ändern, kann das Tool erkennen, welche Änderungen erforderlich sind, und sie für uns umsetzen. So müssen wir nur den gewünschten Zustand pflegen und überlassen dem Tool die Logik der Umsetzung. Wir nannten dieses Tool „Helmsman“, weil es als Autopilot für euren Kubernetes-Cluster funktioniert.

Wie funktioniert Helmsman?

Helmsman erhält seine Anweisungen aus einer deklarativen Datei namens Desired State File (DSF), die vom Nutzer (Kubernetes-Administrator) gepflegt und in der Regel versioniert wird. DSFs folgen einer Spezifikation, mit der Nutzer definieren können, wie eine Verbindung zu einem Kubernetes-Cluster hergestellt wird, welche Namespaces verwendet oder erstellt werden sollen, welche Helm-Repositories für die Suche nach Charts verwendet werden und welche Instanzen (auch Releases genannt) eines Charts installiert, gelöscht, zurückgesetzt oder aktualisiert werden sollen – einschließlich der jeweiligen Eingabeparameter.

Helmsman interpretiert eure Vorgaben aus der DSF und vergleicht sie mit dem, was im vorgesehenen Cluster läuft. Es erkennt selbstständig, welche Änderungen erforderlich sind, um eure Vorgaben umzusetzen, ohne zusätzliche Informationen irgendwo zu pflegen oder zu speichern.

Eine einfache DSF sieht wie das folgende Beispiel aus (das mit minikube funktioniert):

[metadata] org = "example.com" # using a minikube cluster [settings] kubeContext = "minikube" [namespaces]  [namespaces.staging]  protected = false  [namespaces.production]  protected = true [helmRepos] stable = "https://kubernetes-charts.storage.googleapis.com" incubator = "http://storage.googleapis.com/kubernetes-charts-incubator" [apps]    [apps.artifactory]    name = "artifactory-prod" # should be unique across all apps    description = "production artifactory"    namespace = "production"    enabled = true    chart = "stable/artifactory"    version = "6.2.0" # chart version    valuesFile = "../my-artificatory-production-values.yaml"    [apps.jenkins-test]    name = "jenkins-test" # should be unique across all apps    description = "test release of jenkins, testing xyz feature"    namespace = "staging"    enabled = true    chart = "stable/jenkins"    version = "0.9.1" # chart version    valuesFile = "../my-jenkins-testing-values.yaml" </code>

Was bietet Helmsman?

Neben der Bereitstellung von Helm Charts aus Code bietet euch Helmsman folgende Funktionen:

• Einfaches deklaratives Format: Verwendung des Toml-Formats, bei dem Leerzeichen keine Rolle spielen. Hurra!

• Portabel: Helmsman kann verwendet werden, um Chart-Deployments in jedem Kubernetes-Cluster zu verwalten. Die einzigen erforderlichen Abhängigkeiten sind helm und kubectl.

• Planen, anzeigen, anwenden: Mit Helmsman könnt ihr einen Plan erstellen und anzeigen – mit oder ohne ihn auszuführen.

• Mehrere Nutzungsoptionen: Helmsman kann als Binärdatei oder Docker-Image verwendet werden.

• Idempotent: Solange sich eure Desired State File nicht ändert, könnt ihr Helmsman mehrfach ausführen und erhaltet immer dasselbe Ergebnis.

• Nach Fehlern fortsetzen: Wenn ein bestimmtes Chart-Deployment fehlschlägt und dadurch nur eine teilweise Bereitstellung erfolgt, könnt ihr euren Helm Chart korrigieren und Helmsman erneut ausführen, ohne zuvor die teilweise erfolgreichen Deployments zurücksetzen zu müssen.

• Secrets übergeben: von Umgebungsvariablen an Charts.

• Abrufen von K8S-Secrets und Helm Charts: aus privaten Cloud-Buckets. Derzeit werden sowohl AWS als auch GCS unterstützt.

• Geschützte Releases/Namespaces: Schutz vor versehentlichen Commits.

Weitere Details zu diesen Funktionen findet ihr in der Dokumentation.

Open Source

Helmsman hat uns sehr geholfen, und wir freuen uns, es mit der Community zu teilen. Es ist Open Source, und wir freuen uns über Beiträge und Feedback jeder Art. Das Projekt wird auf Github gehostet.