Author
Wer oder was ist eigentlich Helm? Bei Helm handelt es sich um einen Paketmanager für Kubernetes, der es erleichtert, Anwendungen und Dienste in einem typischen K8s-Cluster bereitzustellen, falls diese hochgradig wiederholbar sind oder in mehreren Szenarien verwendet werden.
Dieser Blogeintrag aus unserer Reihe „Kubernetes Beratung“ ist von IBM inspiriert und kann ebenfalls im folgenden Video angeschaut werden:
Um die Rolle von Helm besser zu verstehen, müssen wir zuallererst einen Blick auf ein typisches Szenario werfen, in dem Anwendungen und Dienste für Kubernetes bereitgestellt werden.
Können wir Sie bei Ihrem nächsten Entwicklungsprojekt unterstützen?
DevOps-Teams und Beratung
So arbeitet Helm mit Kubernetes
Für dieses Beispiel nehmen wir eine E-Commerce-Plattform. Große E-Commerce-Plattformen nutzen in der Regel Marketing-Kampagnen, um noch vor den Winterferien neue Kunden zu gewinnen.
Nehmen wir an, wir haben eine Node.js-Anwendung geschrieben, die wir in unserem Kubernetes-Cluster bereitstellen werden. Da diese vor allem in der Hochsaison besonders verfügbar sein muss, haben wir zwei Replikate der Anwendung erstellt, um alle eingehenden Anforderungen verarbeiten zu können.
Unter den beiden Node.js-Anwendungen befindet sich eine MongoDB-Datenbank. Hierdurch wird die Kommunikation zu und von jedem der Replikate abgewickelt.
In diesem Beispiel haben wir zusätzlich noch einen Dienst als Node Port geschrieben, um auf unsere Anwendung zuzugreifen. „Node Port“ bedeutet, dass zwischen den IPs innerhalb und außerhalb unseres Kubernetes-Clusters ein 1:1-Verhältnis besteht.
- JS-Anwendung in 2 Replikaten
- MongoDB-Datenbank
- Node Port
Um den beschriebenen Stack bereitzustellen, müssen wir ihn zuerst definieren. Eine Möglichkeit, den Stack mit Kubernetes zu definieren, besteht darin, einige YAML-Dateien zu schreiben. Hierdurch werden folgende Punkte beschrieben:
- Wie werden die Bereitstellungen aussehen?
- Wie wird der Service aussehen?
Schauen wir uns hierzu einige der wichtigsten Elemente an.
Durch die Bereitstellung der Node.js-Anwendung im Zusammenhang mit MongoDB wissen wir, dass wir ein Image von Node und Mongo erstellen werden. Im Klartext bedeutet das, dass unsere YAML-Datei ungefähr so aussehen sollte:
Wir haben uns dazu entschieden, dass unser Service ein Node Port sein wird. Dieser wird wie folgt geschrieben:
Mit diesem 1:1-Verhältnis zwischen IPs innerhalb und außerhalb können wir den Service einfach umleiten, da wir über zwei Replikate verfügen, was die Last bei der Bereitstellung verringert.
Nehmen wir für dieses Beispiel an, der Service wird auf Port 8080 bereitgestellt. Wir können dies dann in unsere service.YAML-Datei schreiben.
Falls wir die Anwendungs- und YAML-Dateien selbst geschrieben haben und wir mit den Konfigurationen vertraut sind, können relativ einfach Änderungen und Aktualisierungen vorgenommen werden, wenn sich die Anforderungen ändern – solange wir selbst noch an der Anwendung arbeiten.
Wenn wir die Anwendung am Ende der Ferienzeit reduzieren möchten, verringern wir hierzu die Replikate der Anwendung, die wegen der geringeren Nachfrage nicht mehr benötigt werden. Wir wissen genau, wo wir die Anzahl der Replikate finden und wie wir die Änderung vornehmen können.
Aber was passiert, wenn wir zu einem neuen Job oder Projekt wechseln und jetzt jemand anderes dort weitermachen muss, wo wir aufgehört haben? Unsere Kollegen wissen möglicherweise nicht, wo sie suchen müssen, um die Anzahl der Replikate der jeweiligen Anwendung zu ändern.
Wäre es nicht großartig, wenn es eine einfachere Möglichkeit gäbe, die Konfiguration eines gesamten Stacks zu verwalten? Und noch dazu, wenn alles logisch von der jeweiligen Vorlagenanwendung getrennt werden könnte?
Helm – der Paketmanager von Kubernetes
Genau hier kommt Helm ins Spiel. Man kann sich Helm am besten als eine Kombination zweier Komponenten für den Anwendungsstapel vorstellen:
- Eine Konfiguration – definiert durch unsere Values.YAML-Datei.
- Eine Vorlage, die in Helm als „Diagramm“ bezeichnet wird.
Das Helm-Diagramm besteht aus allen Dateien, die wir links im Diagramm als Vorlage verwenden.
Aber wie kriegen wir diese Dateien in die Vorlage und wie können wir anschließend Variablen einfügen? Wir nehmen unsere Konfiguration und verwenden stattdessen die Vorlagensprache, um zu entscheiden, ob diese Werte in unsere Vorlage oder doch in unser Diagramm eingefügt werden sollen.
Angenommen, wir möchten, dass die Anzahl der Replikate durch unsere Konfiguration bestimmt wird, anstatt dieses in einer bestimmten Deployment.YAML-Datei fest zu codieren. Dies können wir machen, indem wir die Replikate unter values.deployments.replicas verwalten.
Wir werden jetzt auf den Node values.deployment.replicas verweisen, der in der Konfiguration viel einfacher zu finden ist. Das bedeutet konkret, dass wir selbst entscheiden können, was in unserer Vorlage fest codiert werden sollte und wofür wir einen Verweis zu Values.YAML erstellen.
Das Gleiche gilt für unseren Service. Wenn wir in Zukunft von einem Node Port zu einem Load Balancer wechseln möchten, können wir dies wie folgt ändern:
Für:
Das bedeutet, dass ein Entwickler, der an dem Projekt arbeitet, oder jemand, der in der Infrastruktur tätig ist, die Konfiguration hier ohne Probleme verändern kann:
Wie fügt Helm die Vorlagenkonfigurationen in Kubernetes ein, sodass es das Cluster versteht?
Wie kombinieren wir alles in unserem Kubernetes-Cluster?
Wenn wir alles in einem Helm-Diagramm zusammenfassen möchten, schreiben wir einfach etwas Ähnliches wie – helm install myApp -, wenn wir die Helm-CLI auf unserem Computer installieren.
Helm nimmt dann das erstellte Vorlagendiagramm und sucht nach den Teilen, in denen Variablen in der Konfiguration definiert wurden. Anschließend wird die Konfigurationsdatei aufgerufen, mit YAML die benötigten Nodes ermittelt und in die Vorlagendatei eingefügt.
Sobald alles von Helm eingerichtet wurde, werden die Daten an das Kubernetes-Cluster gesendet. Bis zur Veröffentlichung von Helm 3 im Jahre 2019 wurde die enthaltene Vorlagendatei an Tiller gesendet, einer weiteren Komponente, die im Kubernetes-Cluster installiert werden musste. Tiller kann als serverseitige Komponente von Helm umschrieben werden. Tiller nimmt die vom Helm-Client gesendeten Befehle und macht diese für das Kubernetes-Cluster verständlich.
Warum wurde Tiller von Helm 3 entfernt?
Helm 2 war stark von Tiller abhängig, um den Lebenszyklus eines Diagramms in ein für Kubernetes verständliches Format zu übersetzen. Denoch wurde Tiller von Helm 3 entfernt.
Tiller hatte nämlich Sicherheitsprobleme und die Inbetriebnahme in der Produktion bedeutete, dass sorgfältig nachgebessert werden musste. Dies fügte zusätzliche Lernschritte für die DevOps hinzu. In Helm 3 bleibt das Sicherheitsmanagement Kubernetes überlassen, während sich Helm auf das Paketmanagement konzentrieren kann. Dies reduziert ebenfalls die Belastung für DevOps.
Helm ist besonders nützlich, wenn wir ein Upgrade von einer Konfiguration oder einen Rollback durchführen möchten
In unserem Beispiel für eine E-Commerce-Anwendung müssen wir diese nicht mehr herunterfahren und mit der neuen Konfiguration bereitstellen, sobald wir die Weihnachtszeit hinter uns haben und uns auf nur ein Replikat beschränken möchten. Wir können einfach schreiben:
Helm Upgrade MyApp
Helm legt erneut alles vor, stellt sicher, dass alles wie vorgesehen funktioniert und sendet die Konfiguration an Kubernetes, sodass die Verfügbarkeit als wichtigstes Merkmal des jeweiligen Stacks verwaltet werden kann.
Was geschieht jedoch, wenn wir beim Upgrade einen Fehler machen und etwas nicht funktioniert? Wir geben Helm einfach den Befehl „Rollback“. Helm führt hierdurch einen Versionsverlauf verschiedener Konfigurationen aus, die an Kubernetes gesendet wurden. Hierdurch können wir jederzeit zur letzten bekannten Arbeitskonfiguration zurückkehren, falls dies erforderlich ist.
Helm Repos
Wir können die Helm-Charts in einem Repo mit dem folgenden Befehl bereitstellen:
Helm package
Wir verwenden anschließend Helm repo index, um ihn an das Repository zu senden. Das bedeutet, dass die gleichen Helm-Diagramme von allen anderen Mitarbeitern verwendet werden können.
Die Verwendung von Helm mit Kubernetes verbessert das Paketmanagement, die Effizienz der App-Aktualisierung und die Zusammenarbeit im Team
Durch die Parametrisierung einer fest codierten YAML durch Helm ist es einfacher, Pakete zu verwalten und bei Bedarf zu aktualisieren oder zurückzusetzen. Helm macht es auch für alle anderen Team-Mitglieder einfacher, den Prozess nachzuvollziehen, Variablen zu finden und zu ändern und Diagramme zu verwenden, die bereits im Repo enthalten sind.
Mehr Infos zu Helm und Kubernetes
Dieser Blog-Beitrag wurde inspiriert durch das verlinkte YouTube-Video, in dem IBM die Rolle von Helm in Kubernetes erklärt. Für alle, die an einer detaillierteren, aber dennoch zugänglichen Einführung zu Helm interessiert sind, bietet IBM auch einen großartigen Kurs über die Grundlagen von Helm an.
K&C – WIR KREIEREN EINZIGARTIGE TECH-LÖSUNGEN SEIT ÜBER 20 JAHREN. WIR VERSCHAFFEN IHNEN IHREN WETTBEWERBSVORTEIL!
Schreiben Sie uns eine Nachricht, um Ihre individuellen Bedürfnisse oder das nächste Projekt zu besprechen.
