Wir verwenden Cookies, um unsere Webseite für Sie zu optimieren. Mit dem Besuch unserer Webseite erklären Sie sich damit einverstanden. // Our website is using cookies to improve your experience. By continuing to browse the site, you are agreeing to our use of cookies.

Weitere Informationen finden Sie in unserer Datenschutzerklärung. // For more information, please refer to our privacy policy.

Toilet Paper #102: Helm - The package manager for Kubernetes

Helm, der Package Manager für Kubernetes

Problem

Wie installiere ich Standard-Applikationen in Kubernetes? Wie konfiguriere ich diese? Wer kümmert sich um die Abhängigkeiten und um Upgrades?
Und: Wie bringe ich meine eigene Applikation in ein Kubernetes? Mit docker-compose ging das so einfach!

Lösung

Mit Helm existiert ein Package-Manager, der es erlaubt, komplexe Applikationen wie etwa Wordpress, Hadoop oder Gitlab mit einem Kommando in ein Kubernetes zu installieren, inklusive Abhängigkeiten wie etwa einer Datenbank.

Im Prinzip verhält sich Helm zu Kubernetes genauso wie yum oder aptitude zu Linux. Ein Paket kann aber mehrfach installiert werden.

Die Pakete werden Helm Charts genannt und bestehen aus den Kubernetes-Ressourcen als Templates im YAML-Format, einer Konfigurationsdatei values.yaml mit den Default-Settings des Charts, einer Liste der Abhängigkeiten zu anderen Helm Charts und noch ein paar Metadaten wie Name und Version.

Weitere Konfiguration kann in Form von weiteren YAMLs beim Aufruf an Helm übergeben werden - so werden die Defaults überschrieben.

Aus den Templates und den Default-Werten sowie aus der übergebenen Konfiguration werden dann die konkreten Ressourcen-Beschreibungen erzeugt und an Kubernetes geschickt. Kubernetes erzeugt diese Ressourcen dann: Docker-Container, Storage-Volumes usw.

Mit einem eigenen Helm-Chart für die selbst geschriebene Applikation kann man ihre genauen Laufzeitbedingungen in Code gießen – wie viele Instanzen sollen laufen, wie sind die Speicheranforderungen, welche anderen Container sollen noch parallel als Sidecars laufen, welche wie konfigurierten Datenbanken werden benötigt, welche Endpoints sollen von außen erreichbar sein, soll die Applikation dauerhaft oder nur täglich um 4 Uhr morgens laufen, wann lebt die Applikation noch und wann ist sie bereit, Traffic entgegenzunehmen, usw. – und das alles natürlich konfigurierbar.

Die Deployments in die Dev-Umgebung auf dem Laptop und in die Prod-Umgebung in der Cloud unterscheiden sich vielleicht nur noch in der Konfigurations-YAML.

Beispiel

Folgende Kommandos starten ein Minikube (Kubernetes in einer VM) auf meinem Laptop, installieren ein komplettes Wordpress mit extra viel Speicher samt Datenbank, Storage Volume und Load Balancer, und zeigen die Wordpress-Seite in meinem Browser an:

Toilet Paper #102: Helm - Der Package Manager für Kubernetes

Inclined-woodpecker ist hier ein automatisch generierter Name, sodass man ohne Namens-Clash auch noch ein zweites Wordpress installieren könnte.

Weiterführende Aspekte

---

Autor

Dr. Torsten Ackemann / Senior Systems Architect / Competence Center Platforms & Operations

Toilet Paper #102: Helm - The package manager for Kubernetes