Was ist Helm? Pakete für Kubernetes verwalten
Autor: Redaktion Domeny.ForSale Veröffentlicht
Kurz erklärt: Helm ist ein Paketmanager für Kubernetes, der die Installation, Konfiguration und Aktualisierung von Anwendungen im Cluster erleichtert. Statt viele Dateien mit Anwendungsbeschreibungen einzeln zu verwalten, verwendest du ein Paket, ein sogenanntes Chart, und übergibst ihm deine eigenen Einstellungen. Helm hilft auch dabei, aufeinanderfolgende Deployments nachzuverfolgen. Es ersetzt jedoch weder Kubernetes noch garantiert es sichere Updates.
Welches Problem löst Helm?
Kubernetes ist ein System zum Ausführen und Verwalten von Anwendungen in Containern. Ein Cluster besteht aus mehreren Maschinen, die von Kubernetes verwaltet werden. Er benötigt eine Beschreibung dessen, was er ausführen soll. Diese Beschreibung wird meist in Manifesten festgehalten: YAML-Dateien, die Ressourcen definieren, beispielsweise ein Deployment, das die Anwendungsinstanzen verwaltet, oder einen Service, der diese Instanzen erreichbar macht.
Eine einzige Anwendung kann mehrere bis über ein Dutzend solcher Ressourcen benötigen. Wenn du sie getrennt in einer Test- und einer Produktionsumgebung betreibst, sind manche Einstellungen identisch und andere unterschiedlich: die Anzahl der Instanzen, die Domainadresse, die Version des Container-Images oder die Speicherlimits. Manuelles Kopieren der Manifeste erschwert es, sie konsistent zu halten.
Mit Helm kannst du die Vorlagen dieser Ressourcen zu einem Paket zusammenfassen. Aus den Vorlagen und der Konfiguration erzeugt es Manifeste und übergibt sie anschließend an Kubernetes. Die Idee ähnelt einem Paketmanager für ein Betriebssystem. Allerdings verwaltet Helm Cluster-Ressourcen und keine Programme, die auf einem Laptop installiert werden.
Chart, Release und Values – drei Grundbegriffe
Chart bezeichnet ein Paket für Helm, das Vorlagen für Ressourcen von Kubernetes, Standardeinstellungen und Informationen zum Paket enthält. Es kann eine einzelne Anwendung oder mehrere zusammengehörige Komponenten beschreiben. Ein Chart kann auch Abhängigkeiten haben, also andere Charts verwenden.
Release ist eine konkrete Installation eines Charts im Cluster mit einem eigenen Namen. Dasselbe Chart kannst du mehrmals installieren, beispielsweise als shop-test und shop-prod mit unterschiedlichen Einstellungen. Ein Release bezeichnet hier also nicht einfach eine Anwendungsversion, sondern identifiziert ein von Helm verwaltetes Deployment.
Values sind Konfigurationswerte, die in die Vorlagen eingesetzt werden. Ein Chart enthält normalerweise die Datei values.yaml mit Standardwerten. Nutzer können zusätzlich eine Datei mit eigenen Einstellungen übergeben. Welche Parameternamen verfügbar sind, hängt vom jeweiligen Chart ab; Helm schreibt keine universellen Konfigurationsfelder für alle Anwendungen vor.
Ein einfaches Chart kann beispielsweise so aufgebaut sein:
meine-anwendung/
├── Chart.yaml
├── values.yaml
└── templates/
├── deployment.yaml
└── service.yaml
Die Datei Chart.yaml beschreibt das Paket, values.yaml enthält die Standardkonfiguration und das Verzeichnis templates speichert die Vorlagen. Die Chart-Version und die Anwendungsversion sind zwei verschiedene Dinge: Eine Änderung am Deployment muss nicht bedeuten, dass sich das Programm selbst ändert.
Wie läuft ein Deployment mit Helm ab?
Angenommen, ein Team betreut eine Shop-Anwendung. In der Testumgebung benötigt es eine Instanz, in der Produktionsumgebung drei. Dafür kann es ein Chart und zwei Konfigurationsdateien verwenden, statt zwei unabhängige Kopien der Manifeste anzulegen.
Wenn das Chart den Parameter replicaCount unterstützt, kann die Datei values-test.yaml Folgendes enthalten:
replicaCount: 1
Das folgende Beispiel setzt voraus, dass Helm installiert ist, du Zugriff auf den Cluster hast und ein lokales Chart im Verzeichnis meine-anwendung liegt. Zunächst kannst du die Manifeste erzeugen, ohne die Anwendung zu installieren:
helm template shop-test ./meine-anwendung -f values-test.yaml
So kannst du das Ergebnis der Vorlagen prüfen. Das bestätigt jedoch noch nicht, dass der Cluster alle Ressourcen akzeptiert oder die Anwendung funktioniert. Mit folgendem Befehl installierst oder aktualisierst du das Release:
helm upgrade --install shop-test ./meine-anwendung \
-f values-test.yaml --namespace test --create-namespace
Ein Namespace ist ein logisch abgegrenzter Bereich für Ressourcen im Cluster. Die Option --install ermöglicht die Installation, wenn das Release noch nicht existiert. Andernfalls aktualisiert der Befehl das vorhandene Release. Prüfe vor der Ausführung den aktuellen Kontext von Kubernetes, damit du die Anwendung nicht versehentlich in der Produktionsumgebung bereitstellst.
Updates und Grenzen des Rollbacks
Helm speichert die Historie der aufeinanderfolgenden Revisionen eines Releases, also der Änderungen an seinem Deployment. Der Befehl helm history shop-test -n test zeigt diese Historie an. Mit helm rollback kannst du zu einer früheren Revision zurückkehren.
Ein Rollback ist kein Backup der Anwendung oder ihrer Daten. Das Zurücksetzen der Ressourcenkonfiguration macht Datenbankmigrationen, Änderungen in einem externen Dienst oder die Auswirkungen der Programmausführung nicht automatisch rückgängig. Updates von Anwendungen, die Daten speichern, erfordern einen gesonderten Plan für Backups und die Kompatibilität der Versionen.
Auch mit Helm musst du Kubernetes verstehen. Falsche Ressourcenlimits, fehlende Berechtigungen oder ein fehlerhaftes Container-Image können den Start der Anwendung verhindern – unabhängig davon, ob die Manifeste von Hand oder aus einem Chart erstellt wurden.
Wann ist Helm sinnvoll und wie prüfst du ein fertiges Chart?
Helm ist nützlich, wenn du Deployments wiederholt ausführst, mehrere Umgebungen betreibst oder eine Anwendung installierst, die aus vielen Ressourcen besteht. Bei wenigen einfachen Manifesten, die sich selten ändern, kann es eine unnötige Vorlagenebene einführen. Eine mögliche Alternative ist Kustomize: Es passt bestehende Manifeste an, statt Vorlagen von Helm zu verwenden.
Bevor du ein fertiges Chart verwendest, prüfe seine Herkunft, die Dokumentation, die erforderlichen Versionen von Kubernetes, die Berechtigungen und den Umgang mit persistenten Daten. Sieh dir die erzeugten Manifeste an, insbesondere Ressourcen, die Berechtigungen vergeben, und Services, die die Anwendung außerhalb des Clusters zugänglich machen. Passwörter in einer Values-Datei werden nicht allein dadurch sicher, dass du Helm verwendest – speichere sie nicht in einem gewöhnlichen Code-Repository.
Beginne mit einer Testumgebung und einem Chart. Prüfe in der Dokumentation der konkreten Chart-Version, welche Parameter verfügbar sind. Teste anschließend die Installation, das Update und das Verhalten der Daten bei einem Rollback.
Siehe auch: Was ist Brave?
Lesen Sie auch
