Kubernetes-Paketmanager: Helm 3 verzichtet auf Tiller
Version 3 des Tools zum Verwalten von Kubernetes-Anwendungen bringt einige grundlegende Änderungen in der Architektur mit.
- Rainald Menge-Sonnentag
Die Cloud Native Computing Foundation hat Version 3 des Kubernetes-Paketmanagers Helm freigegeben. Das Werkzeug ist seit Sommer 2018 ein Top-Level-Projekt bei der Stiftung. Das Release bringt maßgebliche Änderungen mit: Es verzichtet auf die serverseitige Komponente Tiller und führt ein erweitertes Modell für Merge-Patches ein. Außerdem verzichtet es auf standardmäßige Repositorys und hat eine kompaktere Struktur für Helm-Chart-Dateien.
Tiller war eine zentrale Komponente in Helm 2 zur Verwaltung der Historie von Deployments. Sie war vor allem bei der Arbeit von Teams auf einem geteilten Cluster wichtig, da sie verschiedenen Operatoren ermöglichte, mit denselben Releases zusammenzuarbeiten. Tiller war quasi ein zentraler Hub zum Verwalten der Helm-Releaseinformationen.
Probleme bei der Zugriffskontrolle
Schwierig wurde die Arbeit von beziehungsweise mit Tiller bereits Anfang 2017 mit dem Release von Kubernetes 1.6, das standardmäßig auf rollenbasierte Zugriffskontrolle (Role Based Access Control, RBAC) setzt. Seitdem können Administratoren unterschiedliche Zugriffsrechte anhand von Namespaces vergeben. Was die allgemeine Sicherheit verbessert, wurde im Zusammenspiel mit Tiller zur Herausforderung, und das Helm-Team setzte auf eine großzügige Rechtevergabe, um den Ausschluss von Nutzern zu verhindern.
Die Standardeinstellung bot aber potenziell Nutzern zu großzügigen Zugriff, sodass Administratoren für die Installation von Tiller in einem mandantenfähigen Cluster komplexe Konfigurationen vornehmen mussten. Bei der Suche nach einem Ausweg haben die Helm-Entwickler laut der FAQ zu Helm 3 festgestellt, dass sie völlig auf Tiller verzichten und die benötigten Release-Informationen über den Kubernetes-API-Server abrufen können.
Angenehme Nebenwirkungen
Durch das Ablegen von Tiller und den für den Einsatz benötigten Security-Verrenkungen kann Helm alle in Kubernetes vorgesehen Funktionen für Security, Identitätsmanagement und Autorisierung verwenden, und das System bestimmt die Freigaben anhand der kubeconfig-Datei.
Als Nebeneffekt speichert Helm nun die Releaseinformationen in demselben Namespace wie das jeweilige Release, wodurch Entwickler beziehungsweise Administratoren denselben Namen mehrfach verwenden können, wenn die Releases in unterschiedlichen Namensräumen angesiedelt sind. Helm 2 hatte die Releaseinformationen stets im Namespace von Tiller abgelegt, womit eine doppelte Verwendung desselben Namens auch in zwei unterschiedlichen Namensräumen nicht möglich war.
Drei Wege sind besser als zwei
Eine weitere wesentliche Neuerung betrifft die Merge Patches, mit der Helm Upgrades einspielt. Helm 3 setzt dafür auf ein Dreiwegesystem, während der Vorgänger nur zwei kannte. Helm 2 hat für Merge Patches die Unterschiede zwischen dem aktuellsten Chart-Manifest aus dem letzten helm upgrade und dem Manifest für das Update verglichen.
Dabei hat Helm jedoch potenziell manuell beispielsweise über kubectl edit vorgenommene Änderungen ignoriert. Das rächte sich, wenn Ressourcen später einen Rollback benötigten, da Helm nicht den tatsächlichen Zustand, sondern lediglich das jüngste Manifest kannte. Helm 3 verwendet stattdessen jetzt einen Dreiwegeansatz für Strategic Merge Patches, in dem es neben den beiden Manifesten auch den Istzustand beim Einspielen berücksichtigt.
Erweiterte Charts
Das Format der Helm Charts, in denen Entwickler die jeweiligen Kubernetes-Objekte beschreiben, hat sich ebenfalls geändert. Das Speichern erfolgt in chart.yaml-Dateien. Mit Helm 3 tragen die Charts nun die API-Versionsnummer v2, statt wie bisher v1. Der Befehl helm create erstellt standardmäßig Charts im neuen Format. Clients können optional beide API-Varianten unterstützen und müssen dafür jeweils das Feld apiVersion in charts.yaml abfragen.
Das neue Format ist kompakter und erlaubt neuerdings das Einbinden von Library Charts. Dabei handelt es sich um geteilte Charts. Diese dürfen keine eigenen Release-Artefakte erstellen, sondern nur define-Elemente enthalten. Auf die Weise können Entwickler Definitionen beziehungsweise Codeabschnitte wiederverwenden.
Weitere Aufräumarbeiten
Helm 3 bringt darüber hinaus zahlreiche Anpassungen und Ergänzungen mit und trennt sich neben Tiller auch von anderen Altlasten. So entfällt künftig helm serve. Die Helm-Macher hatten das damit ausgeführte lokale Repository als Hilfe beim Verwalten von Sourcecode vorgesehen, das Entwickler aber offensichtlich wenig genutzt haben. Wer es verwenden möchte, findet es nach wie vor als Plug-in.
Einige Kommandozeilenbefehle haben andere Namen: helm uninstall ersetzt helm delete, helm inspect heißt helm show und statt helm fetch gilt nun helm pull. Die alten Befehle bleiben jedoch vorerst mit jeweils derselben Funktion erhalten.
Weitere Neuerungen lassen sich dem GitHub-Repository und dem Helm-Blog entnehmen. Auf der Helm-Site findet sich zudem ein umfangreicher Migrationsleitfaden. Wer lieber Erfolgsmeldungen und CTO-Zitate als technische Informationen lesen möchte, wird bei der offiziellen Ankündigung der Cloud Native Computing Foundation fündig.
Siehe dazu auf heise Developer:
(rme)
