🥇Einführung in Helm 3

Anmerkung des Übersetzers.: 16. Mai dieses Jahres – ein bedeutender Meilenstein in der Entwicklung des Paketmanagers für Kubernetes – Helm. An diesem Tag wurde die erste Alpha-Version der zukünftigen Hauptversion des Projekts – 3.0 – vorgestellt. Deren Veröffentlichung wird Helm wesentliche und lang erwartete Änderungen bringen, auf die viele im Kubernetes-Community große Hoffnungen setzen. Dazu zählen auch wir selbst, da wir Helm aktiv für das Deployment von Anwendungen verwenden: Wir haben es in unser CI/CD-Tool integriert werf und leisten von Fall zu Fall unseren Beitrag zur Entwicklung des Upstreams. Diese Übersetzung vereint 7 Notizen aus dem offiziellen Helm-Blog, die an die erste Alpha-Version von Helm 3 angelehnt sind und die Geschichte des Projekts sowie die wichtigsten Funktionen von Helm 3 beschreiben. Der Autor ist Matt „bacongobbler“ Fisher, Mitarbeiter bei Microsoft und einer der Hauptpfleger von Helm.

Am 15. Oktober 2015 wurde das Projekt geboren, das heute als Helm bekannt ist. Nur ein Jahr nach seiner Gründung trat die Helm-Community der Kubernetes-Community bei, während sie aktiv an Helm 2 arbeitete. Im Juni 2018 wurde Helm Teil der CNCF als sich entwickelndes (incubating) Projekt. Kommen wir in die Gegenwart – und schon steht die erste Alpha-Version des neuen Helm 3 vor der Tür (dieser Release hat bereits stattgefunden in der Mitte Mai – Anm. d. Übers.).

In diesem Material werde ich erläutern, wie alles begann, wie wir den aktuellen Stand erreicht haben, einige einzigartige Merkmale vorstellen, die in der ersten Alpha-Version von Helm 3 verfügbar sind, und erklären, wie wir weiter vorankommen wollen.

Zusammenfassung:

die Geschichte von Helm;
ein liebevoller Abschied von Tiller;
Chart-Repositories;
Release-Verwaltung;
Änderungen der Chart-Abhängigkeiten;
Library Charts;
und was kommt als Nächstes?

Die Geschichte von Helm

Die Geburt

Helm 1 begann als Open-Source-Projekt, das von der Firma Deis ins Leben gerufen wurde. Wir waren ein kleines Start-up, das im Frühjahr 2017 von Microsoft übernommen wurde. Unser anderes Open-Source-Projekt, das ebenfalls Deis hieß, hatte ein Werkzeug deisctl, das (unter anderem) zur Installation und Verwaltung der Deis-Plattform in Fleet-Clusters. Zu diesem Zeitpunkt war Fleet eine der ersten Plattformen zur Orchestrierung von Containern.

Mitte 2015 entschieden wir uns, den Kurs zu wechseln und Deis (damals in Deis Workflow umbenannt) von Fleet auf Kubernetes zu migrieren. Eines der ersten Werkzeuge, das überarbeitet wurde, war das Installationswerkzeug deisctl. Wir verwendeten es zur Installation und Verwaltung von Deis Workflow in einem Fleet-Cluster.

Helm 1 wurde nach dem Vorbild bekannter Paketmanager wie Homebrew, apt und yum erstellt. Seine Hauptaufgabe bestand darin, Aufgaben wie das Verpacken und Installieren von Anwendungen in Kubernetes zu vereinfachen. Offiziell wurde Helm 2015 auf der KubeCon in San Francisco vorgestellt.

Unser erster Versuch mit Helm war erfolgreich, jedoch gab es erhebliche Einschränkungen. Er nahm eine Reihe von Kubernetes-Manifests, angereichert mit Generatoren als eingehende YAML-Blöcke (front-matter)*, und lud die Ergebnisse in Kubernetes hoch.

* Anmerkung des Übersetzers.: Ab der ersten Version von Helm wurde für die Beschreibung von Kubernetes-Ressourcen die YAML-Syntax gewählt, und bei der Erstellung von Konfigurationen wurden Jinja-Vorlagen und Python-Skripte unterstützt. Mehr dazu und zu den Eigenschaften der ersten Helm-Version haben wir im Kapitel „Kurze Geschichte von Helm“ dieses Materials.

Zum Beispiel musste man, um ein Feld in einer YAML-Datei zu ersetzen, die folgende Konstruktion zum Manifest hinzufügen:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Es ist toll, dass es heute Template-Systeme gibt, oder?

Aus verschiedenen Gründen erforderte dieser frühe Kubernetes-Installer eine festgelegte Liste von Manifestdateien und führte nur eine kleine feste Abfolge von Ereignissen aus. Die Nutzung war so schwierig, dass das R&D-Team von Deis Workflow es schwer hatte, als sie versuchten, ihr Produkt auf diese Plattform zu portieren – allerdings waren die Samen der Idee bereits gesät. Unser erster Versuch wurde zu einer großartigen Lerngelegenheit: Wir erkannten, dass wir wirklich leidenschaftlich daran interessiert sind, pragmatische Werkzeuge zu schaffen, die alltägliche Probleme unserer Benutzer lösen.

Basierend auf den Erfahrungen aus früheren Fehlern begannen wir mit der Entwicklung von Helm 2.

Entwicklung von Helm 2

Ende 2015 kontaktierte uns das Team von Google. Sie arbeiteten an einem ähnlichen Tool für Kubernetes. Der Deployment Manager für Kubernetes war ein Port eines bestehenden Tools, das für die Google Cloud Platform verwendet wurde. „Wollen wir nicht“, fragten sie, „ein paar Tage damit verbringen, die Ähnlichkeiten und Unterschiede zu diskutieren?“

Im Januar 2016 trafen sich die Teams von Helm und Deployment Manager in Seattle, um Ideen auszutauschen. Die Gespräche endeten mit einem ehrgeizigen Plan: die beiden Projekte zu объединить, um Helm 2 zu schaffen. Zusammen mit Deis und Google schlossen sich die Jungs von SkippBox (heute Teil von Bitnami – Anm. d. Übers.), und wir begannen mit der Arbeit an Helm 2.

Wir wollten die Benutzerfreundlichkeit von Helm bewahren, aber Folgendes hinzufügen:

Chart-Vorlagen zur Anpassung;
interne Clusterverwaltung für Teams;
erstklassiges Chart-Repository;
stabiler Paketformat mit Signaturmöglichkeiten;
festes Bekenntnis zur semantischen Versionierung und zur Wahrung der Abwärtskompatibilität zwischen Versionen.

Um diese Ziele zu erreichen, wurde der Ecosystem Helm ein zweites Element hinzugefügt. Diese interne Cluster-Komponente wurde Tiller genannt und war für die Installation und Verwaltung von Helm-Charts verantwortlich.

Seit der Veröffentlichung von Helm 2 im Jahr 2016 hat Kubernetes mehrere bedeutende Neuerungen erfahren. Es kam zur rollenbasierten Zugriffskontrolle (RBAC), die schließlich die attributbasierte Zugriffskontrolle (ABAC) ersetzte. Neue Ressourcentypen wurden eingeführt (Deployments waren zu dieser Zeit noch in der Beta-Phase). Es wurden benutzerdefinierte Ressourcendefinitionen erfunden (zunächst als Third Party Resources oder TPRs bezeichnet). Und das Wichtigste: Es entstand ein Satz bewährter Verfahren.

Vor dem Hintergrund all dieser Veränderungen blieb Helm weiterhin den Kubernetes-Nutzern treu. Nach drei Jahren und vielen neuen Ergänzungen wurde klar, dass es an der Zeit war, wesentliche Änderungen an der Codebasis vorzunehmen, damit Helm weiterhin den wachsenden Anforderungen des sich entwickelnden Ökosystems gerecht werden konnte.

Sanfter Abschied von Tiller

Während der Entwicklung von Helm 2 haben wir Tiller als Teil unserer Integration mit dem Deployment Manager von Google vorgestellt. Tiller spielte eine wichtige Rolle für Teams, die innerhalb eines gemeinsamen Clusters arbeiteten: Er ermöglichte verschiedenen Fachleuten, die die Infrastruktur betrieben, mit demselben Satz von Releases zu interagieren.

Da die rollenbasierte Zugriffskontrolle (RBAC) standardmäßig in Kubernetes 1.6 aktiviert war, wurde die Arbeit mit Tiller in der Produktion komplizierter. Aufgrund der Vielzahl an möglichen Sicherheitsrichtlinien war unsere Position, standardmäßig eine erlaubende Konfiguration anzubieten. Dies ermöglichte es Einsteigern, mit Helm und Kubernetes zu experimentieren, ohne sich zuerst mit den Sicherheitseinstellungen auseinandersetzen zu müssen. Leider konnte diese erlaubende Konfiguration den Benutzern zu umfangreiche Berechtigungen gewähren, die sie nicht benötigten. DevOps- und SRE-Ingenieure mussten zusätzliche Betriebstätigkeiten erlernen, um Tiller in einem Multi-tenant-Cluster zu installieren.

Als wir erfuhren, wie die Community Helm in bestimmten Situationen einsetzt, verstanden wir, dass das Release-Management-System von Tiller nicht auf einen Cluster-internen Bestandteil angewiesen sein sollte, um Zustände zu verwalten oder als zentraler Hub für Informationen zu Releases zu fungieren. Stattdessen könnten wir einfach Informationen vom Kubernetes API-Server abrufen, das Chart auf der Client-Seite generieren und einen Installationsdatensatz in Kubernetes speichern.

Die Hauptaufgabe von Tiller konnte auch ohne ihn erfüllt werden, daher war eine unserer ersten Entscheidungen in Bezug auf Helm 3 die vollständige Abschaffung von Tiller.

Mit dem Wegfall von Tiller wurde das Sicherheitsmodell von Helm radikal vereinfacht. Helm 3 unterstützt nun alle modernen Methoden der Sicherheit, Identifizierung und Autorisierung des aktuellen Kubernetes. Die Berechtigungen von Helm werden über die kubeconfig-Dateidefiniert. Cluster-Administratoren können die Rechte der Benutzer mit beliebigem Detaillierungsgrad einschränken. Releases bleiben weiterhin innerhalb des Clusters gespeichert, die übrigen Funktionen von Helm bleiben erhalten.

Chart-Repositories

Auf hoher Ebene ist ein Chart-Repository ein Ort, an dem Charts gespeichert und gemeinsam genutzt werden können. Der Helm-Client packt und sendet Charts an das Repository. Einfacher gesagt, ein Chart-Repository ist ein einfacher HTTP-Server mit einer index.yaml-Datei und einigen gepackten Charts.

Obwohl es einige Vorteile hat, dass die API des Chart-Repositories die grundlegendsten Anforderungen an einen Speicher erfüllt, hat sie auch einige Nachteile:

Chart-Repositories sind schlecht kompatibel mit den meisten Sicherheitsimplementierungen, die in Produktionsumgebungen erforderlich sind. Das Vorhandensein einer standardisierten API für Authentifizierung und Autorisierung ist in Produktionsszenarien von äußerster Wichtigkeit.
Die Helm-Tools zur Verfolgung des Ursprungs von Charts, die zur Signierung, Integritätsprüfung und Herkunftsverfolgung von Charts verwendet werden, sind ein optionaler Bestandteil des Veröffentlichungsprozesses für Charts.
In Multi-User-Szenarien kann dasselbe Chart von einem anderen Benutzer hochgeladen werden, wodurch sich der für die Speicherung desselben Inhalts erforderliche Platz verdoppelt. Um dieses Problem zu lösen, wurden intelligentere Repositories entwickelt, die jedoch nicht Teil der formalen Spezifikation sind.
Die Verwendung einer einzelnen Indexdatei zur Suche, Speicherung von Metadaten und zum Abrufen von Charts hat die Entwicklung sicherer Multi-User-Implementierungen erschwert.

Projekt Docker Distribution (auch bekannt als Docker Registry v2) ist der Nachfolger der Docker Registry und fungiert in der Tat als eine Sammlung von Werkzeugen zum Packen, Versenden, Speichern und Bereitstellen von Docker-Images. Viele große Cloud-Dienste bieten Produkte basierend auf Distribution an. Durch diese erhöhte Aufmerksamkeit hat das Projekt Distribution von jahrelangen Verbesserungen, bewährten Sicherheitspraktiken und Tests in Produktionsbedingungen profitiert und sich damit zu einem der erfolgreichsten unbesungenen Helden der Open Source-Welt entwickelt.

Aber wussten Sie, dass das Projekt Distribution zur Verbreitung jeder Art von Inhalten und nicht nur von Container-Images entwickelt wurde?

Dank der Bemühungen Open Container Initiative (oder OCI) können Helm-Charts auf jedem Distribution-Instanz gehostet werden. Während dieser Prozess experimentellen Charakter hat. Die Arbeit an der Unterstützung von Logins und anderen Funktionen, die für ein vollständiges Helm 3 erforderlich sind, ist noch nicht abgeschlossen, aber wir freuen uns sehr über die Möglichkeit, aus den Entdeckungen der Teams von OCI und Distribution in den letzten Jahren zu lernen. Und dank ihrer Mentorship und Anleitung erfahren wir, was es bedeutet, einen hochverfügbaren Dienst in großem Maßstab zu betreiben.

Eine ausführlichere Beschreibung einiger bevorstehender Änderungen bei den Helm-Chart-Repositories ist verfügbar unter diesem Link.

Release-Management

In Helm 3 wird der Zustand der Anwendung innerhalb des Clusters durch ein Paar von Objekten verfolgt:

Release-Objekt — stellt eine Instanz der Anwendung dar;
Release-Version-Secret — stellt den gewünschten Zustand der Anwendung zu einem bestimmten Zeitpunkt dar (z. B. die Veröffentlichung einer neuen Version).

Aufruf helm install erstellt das Release-Objekt und das Release-Version-Secret. Aufruf helm upgrade benötigt ein Release-Objekt (das es ändern kann) und erstellt ein neues Release-Version-Secret, das neue Werte und ein vorbereitete Manifest enthält.

Das Release-Objekt enthält Informationen über die Veröffentlichung, wobei die Veröffentlichung eine spezifische Installation eines benannten Charts und der Werte ist. Dieses Objekt beschreibt Metadaten auf oberster Ebene über die Veröffentlichung. Das Release-Objekt wird während des gesamten Lebenszyklus der Anwendung gespeichert und ist Eigentümer aller Release-Version-Secrets sowie aller Objekte, die direkt vom Helm-Chart erstellt werden.

Das Release-Version-Secret verbindet die Veröffentlichung mit einer Reihe von Revisionen (Installation, Updates, Rollbacks, Löschungen).

In Helm 2 waren Revisionen ausschließlich sequenziell. Ein Aufruf helm install erstellte v1, das nachfolgende Upgrade — v2, und so weiter. Release und Release-Version-Secret wurden zu einem einzigen Objekt zusammengefasst, das als Revision bekannt ist. Revisionen wurden im selben Namensraum wie Tiller gespeichert, was bedeutete, dass jede Veröffentlichung im Hinblick auf den Namensraum 'global' war; daher konnte nur eine Instanz eines Namens verwendet werden.

In Helm 3 ist jede Veröffentlichung mit einem oder mehreren Release-Version-Secrets verknüpft. Das Release-Objekt beschreibt immer die aktuelle Veröffentlichung, die in Kubernetes bereitgestellt ist. Jedes Release-Version-Secret beschreibt nur eine Version dieser Veröffentlichung. Ein Upgrade erstellt beispielsweise ein neues Release-Version-Secret und ändert dann das Release-Objekt, sodass es auf diese neue Version verweist. Im Falle eines Rollbacks können die vorherigen Release-Version-Secrets verwendet werden, um die Veröffentlichung in ihren vorherigen Zustand zurückzusetzen.

Nach der Abkehr von Tiller speichert Helm 3 die Daten zur Veröffentlichung im gleichen Namensraum wie die Veröffentlichung. Diese Änderung ermöglicht es, ein Chart mit dem gleichen Veröffentlichungsnamen in einem anderen Namensraum zu installieren, und die Daten bleiben zwischen Updates/Cluster-Neustarts in etcd erhalten. Zum Beispiel kann WordPress im Namensraum 'foo' installiert werden und anschließend im Namensraum 'bar', wobei beide Veröffentlichungen 'wordpress' heißen können.

Änderungen in den Abhängigkeiten der Charts

Charts, die gepackt wurden (mit Hilfe von helm package) zur Verwendung mit Helm 2 kann mit Helm 3 installiert werden, jedoch wurde der Entwicklungsprozess für Charts vollständig überarbeitet, sodass einige Änderungen erforderlich sind, um die Entwicklung von Charts mit Helm 3 fortzusetzen. Insbesondere hat sich das Abhängigkeitsmanagement der Charts geändert.

Das Abhängigkeitsmanagement der Charts wechselte von requirements.yaml und requirements.lock auf Chart.yaml und Chart.lock. Das bedeutet, dass Charts, die den Befehl helm dependency, einige Anpassungen erfordern, um in Helm 3 zu funktionieren.

Lassen Sie uns ein Beispiel betrachten. Fügen wir eine Abhängigkeit zu einem Chart in Helm 2 hinzu und sehen wir, was sich beim Übergang zu Helm 3 ändert.

In Helm 2 requirements.yaml sah es folgendermaßen aus:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

In Helm 3 wird dieselbe Abhängigkeit in Ihrem Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Charts weiterhin heruntergeladen und in das Verzeichnis charts/, daher funktionieren die Subcharts (subcharts), die sich im Verzeichnis charts/, befinden, weiterhin unverändert.

Einführung der Library Charts

Helm 3 unterstützt eine Klasse von Charts, die als Bibliothekscharts bezeichnet wird (library chart). Dieses Chart wird von anderen Charts verwendet, erstellt jedoch selbst keine Release-Artefakte. Die Vorlagen von Bibliothekscharts können nur Elemente definieren. Anderer Inhalt wird einfach ignoriert. Dies erlaubt es Benutzern, Code-Schnipsel wiederzuverwenden und auszutauschen, die in vielen Charts verwendet werden können, wodurch Duplikate vermieden werden und das Prinzip DRY.

gewahrt bleibt. Bibliothekscharts werden im Abschnitt dependencies in der Datei Chart.yaml. Die Installation und Verwaltung dieser Charts unterscheidet sich nicht von anderen Charts.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Wir freuen uns auf die Anwendungsmöglichkeiten, die dieser Bestandteil den Chart-Entwicklern eröffnet, sowie auf die besten Praktiken, die durch Bibliothekscharts entstehen können.

Was folgt jetzt?

Helm 3.0.0-alpha.1 ist die Grundlage, auf der wir eine neue Version von Helm entwickeln. In diesem Artikel habe ich einige interessante Funktionen von Helm 3 beschrieben. Viele davon befinden sich noch in den Anfangsstadien der Entwicklung, und das ist in Ordnung; der Sinn eines Alpha-Releases besteht darin, die Idee zu testen, Feedback von den ersten Benutzern zu sammeln und unsere Annahmen zu bestätigen.

Sobald die Alpha-Version veröffentlicht wird, denken Sie daran, dass dies bereits geschehen ist — Anm. d. Übersetzer), wir beginnen, Patches für Helm 3 von der Community anzunehmen. Es ist notwendig, ein stabiles Fundament zu schaffen, das die Entwicklung und Implementierung neuer Funktionen ermöglicht, und die Benutzer sollen sich in den Prozess einbezogen fühlen, indem sie Tickets eröffnen und Fehlerbehebungen einbringen.

In diesem Artikel habe ich versucht, einige der wesentlichen Verbesserungen zu beleuchten, die in Helm 3 erscheinen werden, jedoch kann diese Liste keinesfalls als abschließend bezeichnet werden. Der umfassende Plan für Helm 3 umfasst Neuerungen wie verbesserte Upgrade-Strategien, tiefere Integration mit OCI-Registries und den Einsatz von JSON-Schemas zur Validierung der Chart-Werte. Wir planen auch, die Codebasis zu bereinigen und die Teile zu aktualisieren, die in den letzten drei Jahren vernachlässigt wurden.

Wenn Sie das Gefühl haben, dass wir etwas ausgelassen haben, würden wir uns über Ihre Gedanken freuen!

Treten Sie der Diskussion in unseren Slack-Kanälen:

#helm-users für Fragen und einfache Kommunikation mit der Community;
#helm-dev für Diskussionen über Pull-Requests, Code und Bugs.

Sie können auch an unseren wöchentlichen Public Developer Calls teilnehmen, die donnerstags um 19:30 Uhr MSK stattfinden. Die Treffen sind der Diskussion der Aufgaben gewidmet, an denen Schlüsselentwickler und die Community arbeiten, sowie den Themen, die in der Woche behandelt werden. Jeder Interessierte kann teilnehmen und mitwirken. Der Link ist im Slack-Kanal verfügbar. #helm-dev.

P.S. vom Übersetzer

Lesen Sie auch in unserem Blog:

Quelle: habr.com