👩🏽‍🚀 💊 🌠 Einführung in Helm 3 🏄 🤷🏽 ⌨️

Hinweis perev. : Der 16. Mai dieses Jahres ist ein wichtiger Meilenstein in der Entwicklung des Paketmanagers für Kubernetes - Helm. An diesem Tag wurde die erste Alpha-Version der zukünftigen Hauptversion des Projekts vorgestellt - 3.0. Ihre Freilassung wird bedeutende und lang erwartete Veränderungen für Helm bringen, auf die viele in der Kubernetes-Community große Hoffnungen haben. Wir selbst behandeln diese, indem wir Helm aktiv für die Bereitstellung von Anwendungen verwenden: Wir haben es in unser Tool zur Implementierung von CI / CD werf integriert und leisten von Zeit zu Zeit einen praktikablen Beitrag zur Entwicklung von Upstream. Diese Übersetzung enthält 7 Notizen aus dem offiziellen Helm-Blog, die zeitlich auf die erste Alpha-Version von Helm 3 abgestimmt sind und über die Geschichte des Projekts und die Hauptmerkmale von Helm 3 berichten. Ihr Autor ist Matt "bacongobbler" Fisher, ein Microsoft-Mitarbeiter und einer der wichtigsten Helm-Betreuer.

Am 15. Oktober 2015 wurde das Projekt geboren, das heute als Helm bekannt ist. Nur ein Jahr nach ihrer Gründung schloss sich die Helm-Community Kubernetes an und arbeitete aktiv an Helm 2. Im Juni 2018 trat Helm CNCF als Inkubationsprojekt bei. Schneller Vorlauf in die Gegenwart - und jetzt ist die erste Alpha-Version des neuen Helm 3 auf dem Weg (diese Veröffentlichung fand bereits Mitte Mai statt - ca. übersetzt) .

In diesem Artikel werde ich darüber sprechen, wie alles begann, wie wir zum gegenwärtigen Stadium gekommen sind, einige einzigartige Funktionen vorstellen, die in der ersten Alpha-Version von Helm 3 verfügbar sind, und erklären, wie wir uns weiterentwickeln wollen.

Zusammenfassung:

Geschichte der Erschaffung von Helm;
sanfter Abschied von Tiller;
Diagramm-Repositorys;
Release-Management;
Änderungen der Diagrammabhängigkeiten;
Bibliotheksdiagramme;
was weiter?

Geschichte von Helm

Geburt

Helm 1 begann als Open Source-Projekt von Deis. Wir waren ein kleines Startup, das im Frühjahr 2017 von Microsoft übernommen wurde. Unser anderes Open Source-Projekt, ebenfalls Deis genannt, verfügte über ein deisctl Tool, mit dem (unter anderem) die Deis-Plattform im Fleet-Cluster installiert und betrieben wurde. Die Flotte war zu dieser Zeit eine der ersten Plattformen für die Container-Orchestrierung.

Mitte 2015 beschlossen wir, den Kurs zu ändern und Deis (damals in Deis Workflow umbenannt) von Fleet nach Kubernetes zu übertragen. Einer der ersten, der das deisctl Installationstool neu gestaltet hat. Wir haben damit Deis Workflow in einem Flottencluster installiert und verwaltet.

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

Unser erster Versuch mit Helm hat funktioniert, aber es gab ernsthafte Einschränkungen. Er nahm eine Reihe von Kubernetes-Manifesten, die mit Generatoren aromatisiert waren, als Front-Materie- YAML-Blöcke und lud die Ergebnisse auf Kubernetes hoch.

* Hinweis perev. : Ab der ersten Version von Helm wurde die YAML-Syntax ausgewählt, um Kubernetes-Ressourcen zu beschreiben, und Jinja-Vorlagen und Python-Skripte wurden beim Schreiben von Konfigurationen unterstützt. Wir haben mehr darüber und über das Gerät der ersten Version von Helm im Kapitel „Eine kurze Geschichte von Helm“ dieses Materials geschrieben .

Um beispielsweise ein Feld in einer YAML-Datei zu ersetzen, mussten Sie dem Manifest das folgende Konstrukt hinzufügen:

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

Es ist cool, dass es heute Template-Engines gibt, nicht wahr?

Aus vielen Gründen erforderte dieses frühe Kubernetes-Installationsprogramm eine fest codierte Liste von Manifestdateien und führte nur eine kleine feste Folge von Ereignissen aus. Es war so schwer zu bedienen, dass es dem Forschungs- und Entwicklungsteam von Deis Workflow schwer fiel, sein Produkt auf diese Plattform zu übertragen - die Saat der Idee war jedoch bereits gelegt. Unser erster Versuch war eine großartige Gelegenheit zum Lernen: Wir stellten fest, dass wir wirklich leidenschaftlich daran interessiert waren, pragmatische Tools zu entwickeln, die alltägliche Probleme für unsere Benutzer lösen.

Basierend auf den Erfahrungen mit Fehlern in der Vergangenheit haben wir begonnen, Helm 2 zu entwickeln.

Schöpfungshelm 2

Ende 2015 hat uns das Google-Team kontaktiert. Sie arbeiteten an einem ähnlichen Tool für Kubernetes. Deployment Manager für Kubernetes war der Port des vorhandenen Tools, das für die Google Cloud Platform verwendet wurde. "Würden wir", 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 Verhandlungen endeten mit einem ehrgeizigen Plan: Beide Projekte zu Helm 2 zu kombinieren. Zusammen mit Deis und Google schlossen sich die Mitarbeiter von SkippBox (jetzt Teil von Bitnami - ca. Transl.) Dem Entwicklungsteam an und wir begannen mit der Arbeit an Helm 2.

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

Diagrammvorlagen zur Anpassung;
Intracluster-Management für Teams;
Erstklassiges Diagramm-Repository
stabiles Paketformat mit der Fähigkeit zu signieren;
Starkes Engagement für die semantische Versionierung und die Aufrechterhaltung der Abwärtskompatibilität zwischen Versionen.

Um diese Ziele zu erreichen, wurde dem Helm-Ökosystem ein zweites Element hinzugefügt. Diese Intracluster-Komponente wurde Tiller genannt und war an der Installation von Helm-Diagrammen und deren Verwaltung beteiligt.

Seit der Veröffentlichung von Helm 2 im Jahr 2016 hat Kubernetes eine Reihe wichtiger Innovationen erhalten. Die rollenbasierte Zugriffskontrolle ( RBAC ) wurde eingeführt , die schließlich die attributbasierte Zugriffskontrolle (ABAC) ersetzte. Es wurden neue Arten von Ressourcen eingeführt (die Bereitstellungen befanden sich zu diesem Zeitpunkt noch im Beta-Status). Benutzerdefinierte Ressourcendefinitionen (ursprünglich als Third Party Resources oder TPRs bezeichnet) wurden erfunden. Und vor allem ist eine Reihe von Best Practices erschienen.

Inmitten all dieser Änderungen diente Helm den Kubernetes-Benutzern weiterhin treu. Nach drei Jahren und vielen Neuzugängen wurde klar, dass es an der Zeit war, wesentliche Änderungen an der Codebasis vorzunehmen, damit Helm weiterhin den wachsenden Anforderungen eines sich entwickelnden Ökosystems gerecht werden konnte.

Sanfter Abschied von Tiller

Während der Entwicklung von Helm 2 haben wir Tiller im Rahmen unserer Integration mit dem Deployment Manager von Google eingeführt. Tiller spielte eine wichtige Rolle für Teams, die in einem gemeinsamen Cluster arbeiten: Verschiedene Spezialisten, die die Infrastruktur betreiben, konnten mit denselben Releases interagieren.

Da die rollenbasierte Zugriffssteuerung (RBAC) in Kubernetes 1.6 standardmäßig aktiviert war, wurde die Arbeit mit Tiller in der Produktion schwieriger. Aufgrund der Vielzahl möglicher Sicherheitsrichtlinien bestand unsere Position darin, standardmäßig Berechtigungen vorzuschlagen. Dies ermöglichte es Anfängern, mit Helm und Kubernetes zu experimentieren, ohne zuerst in die Sicherheitseinstellungen eintauchen zu müssen. Leider könnte diese zulässige Konfiguration dem Benutzer einen übermäßig großen Bereich von Berechtigungen verleihen, die er nicht benötigt. Die Ingenieure von DevOps und SRE mussten zusätzliche Betriebsschritte erlernen, indem sie Tiller in einem mandantenfähigen Cluster installierten.

Nachdem wir erfahren hatten, wie Community-Mitglieder Helm in bestimmten Situationen verwenden, stellten wir fest, dass das Release-Management-System von Tiller nicht auf eine Intra-Cluster-Komponente angewiesen sein musste, um den Status aufrechtzuerhalten oder als zentraler Hub mit Release-Informationen zu fungieren. Stattdessen könnten wir einfach Informationen vom Kubernetes-API-Server abrufen, ein clientseitiges Diagramm erstellen und den Installationsdatensatz in Kubernetes speichern.

Die Hauptaufgabe von Tiller konnte ohne Tiller ausgeführt werden, daher war eine unserer ersten Entscheidungen in Bezug auf Helm 3 die vollständige Ablehnung von Tiller.

Mit Tillers Abgang wurde das Helm-Sicherheitsmodell radikal vereinfacht. Helm 3 unterstützt jetzt alle modernen Sicherheits-, Identifikations- und Autorisierungsmethoden der heutigen Kubernetes. Helmberechtigungen werden mithilfe der kubeconfig-Datei ermittelt . Clusteradministratoren können Benutzerrechte mit jeder Granularitätsstufe einschränken. Releases werden weiterhin im Cluster gespeichert, der Rest der Helm-Funktionalität bleibt erhalten.

Diagramm-Repositorys

Auf hoher Ebene ist das Diagramm-Repository ein Ort, an dem Sie Diagramme speichern und freigeben können. Der Helm-Client packt die Diagramme und sendet sie an das Repository. Einfach ausgedrückt ist das Diagramm-Repository ein primitiver HTTP-Server mit einer index.yaml-Datei und einigen gepackten Diagrammen.

Obwohl die Diagramm-Repository-API einige Vorteile bietet, die die grundlegendsten Anforderungen für das Repository erfüllen, weist sie auch mehrere Nachteile auf:

Diagramm-Repositorys sind mit den meisten in einer Produktionsumgebung erforderlichen Sicherheitsimplementierungen schlecht kompatibel. Eine Standard-API für die Authentifizierung und Autorisierung ist in Produktionsszenarien von entscheidender Bedeutung.
Die Tools von Helm zur Verfolgung des Ursprungs des Diagramms, die zum Signieren, Überprüfen der Integrität und des Ursprungs des Diagramms verwendet werden, sind ein optionaler Bestandteil des Veröffentlichungsprozesses des Diagramms.
In Mehrbenutzerszenarien kann dasselbe Diagramm von einem anderen Benutzer geladen werden, wodurch sich der zum Speichern desselben Inhalts erforderliche Speicherplatz verdoppelt. Zur Lösung dieses Problems wurden intelligentere Repositories entwickelt, die jedoch nicht Teil der formalen Spezifikation sind.
Die Verwendung einer einzelnen Indexdatei zum Suchen, Speichern von Metadaten und Abrufen von Diagrammen erschwerte die Entwicklung sicherer Mehrbenutzerimplementierungen.

Das Docker Distribution- Projekt (auch als Docker Registry v2 bezeichnet) ist der Nachfolger der Docker Registry und fungiert als eine Reihe von Tools zum Verpacken, Senden, Speichern und Bereitstellen von Docker-Images. Viele große Cloud-Dienste bieten verteilungsbasierte Produkte an. Dank dieser erhöhten Aufmerksamkeit hat das Distributionsprojekt von langjährigen Verbesserungen, Best Practices in Bezug auf Sicherheit und Tests unter „Kampfbedingungen“ profitiert, die es zu einem der erfolgreichsten unbesungenen Helden der Open Source-Welt gemacht haben.

Aber wussten Sie, dass das Distributionsprojekt darauf ausgelegt war, jede Form von Inhalten zu verbreiten, nicht nur Containerbilder?

Dank der Bemühungen der Open Container Initiative (oder OCI) können Helmdiagramme auf jeder Verteilungsinstanz platziert werden. Bisher ist dieser Prozess experimentell. Die Arbeit an der Unterstützung von Anmeldungen und anderen Funktionen, die für einen vollwertigen Helm 3 erforderlich sind, ist noch nicht abgeschlossen, aber wir freuen uns sehr, aus den Entdeckungen der OCI- und Distribution-Teams im Laufe der Jahre zu lernen. Und dank ihrer Betreuung und Führung lernen wir, wie ein hoch zugänglicher Dienst in großem Maßstab funktioniert.

Eine detailliertere Beschreibung einiger anstehender Änderungen an den Helm-Charts-Repositorys finden Sie hier .

Release-Management

In Helm 3 wird der Status einer Anwendung innerhalb eines Clusters von mehreren Objekten überwacht:

Objekt freigeben - stellt eine Instanz der Anwendung dar;
Versionsgeheimnis freigeben - repräsentiert den gewünschten Status der Anwendung zu einem bestimmten Zeitpunkt (z. B. die Freigabe einer neuen Version).

Durch Aufrufen von helm install werden ein Release-Objekt und ein Release-Versionsgeheimnis erstellt. Das Aufrufen des helm upgrade erfordert ein Release-Objekt (das geändert werden kann) und erstellt ein neues Release-Versionsgeheimnis mit neuen Werten und einem vorbereiteten Manifest.

Das Release-Objekt enthält Release-Informationen, wobei Release eine bestimmte Installation eines benannten Diagramms und von Werten ist. Dieses Objekt beschreibt die Metadaten der obersten Ebene zur Version. Das Release-Objekt bleibt während des gesamten Lebenszyklus der Anwendung erhalten und fungiert als Eigentümer aller Geheimnisse der Release-Version sowie aller Objekte, die direkt vom Helm-Diagramm erstellt werden.

Das Versionsversionsgeheimnis verknüpft ein Release mit einer Reihe von Revisionen (Installation, Updates, Rollbacks, Deinstallation).

In Helm 2 waren die Überarbeitungen äußerst konsistent. Der helm install erstellt, das nachfolgende Upgrade Upgrade Version 2 und so weiter. Release und Release-Versionsgeheimnis wurden zu einem einzigen Objekt zusammengefasst, das als Revision bezeichnet wird. Revisionen wurden im selben Namespace wie Tiller gespeichert, was bedeutete, dass jede Version in Bezug auf den Namespace „global“ war. Infolgedessen konnte nur eine Instanz des Namens verwendet werden.

In Helm 3 ist jede Version einem oder mehreren Versionsversionsgeheimnissen zugeordnet. Das Release-Objekt beschreibt immer das aktuelle Release, das in Kubernetes bereitgestellt wird. Jedes Release-Versionsgeheimnis beschreibt nur eine Version dieser Version. Ein Upgrade erstellt beispielsweise ein neues Geheimnis der Release-Version und ändert das Release-Objekt so, dass es auf diese neue Version verweist. Im Falle eines Rollbacks können Sie die Geheimnisse der vorherigen Release-Version verwenden, um das Release auf den vorherigen Status zurückzusetzen.

Nach dem Verlassen von Tiller speichert Helm 3 Release-Daten mit dem Release in einem einzigen Namespace. Mit einer solchen Änderung können Sie ein Diagramm mit demselben Versionsnamen in einem anderen Namespace installieren und die Daten zwischen Cluster-Updates / Neustarts in etcd speichern. Beispielsweise können Sie Wordpress im Namespace "foo" und dann im Namespace "bar" installieren. Beide Versionen können als "wordpress" bezeichnet werden.

Änderungen der Diagrammabhängigkeit

Diagramme, die (unter Verwendung des helm package ) für die Verwendung mit Helm 2 gepackt wurden, können mit Helm 3 installiert werden. Der Workflow für die Diagrammentwicklung wurde jedoch vollständig überarbeitet. Daher müssen einige Änderungen vorgenommen werden, um die Entwicklung von Diagrammen mit Helm 3 fortzusetzen. Insbesondere hat sich das Managementsystem geändert Diagrammabhängigkeiten.

Das System zur Verwaltung von Diagrammabhängigkeiten wurde von requirements.yaml und requirements.lock zu Chart.yaml und Chart.lock . Dies bedeutet, dass Diagramme, die den Befehl helm dependency eine gewisse Konfiguration erfordern, um in Helm 3 zu funktionieren.

Schauen wir uns ein Beispiel an. Fügen Sie dem Diagramm in Helm 2 eine Abhängigkeit hinzu und sehen Sie, was sich ändert, wenn Sie zu Helm 3 wechseln.

In Helm 2 requirements.yaml sah yaml so aus:

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

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

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

Die charts/ werden weiterhin geladen und im Verzeichnis chart charts/ abgelegt, sodass die Unterdiagramme im Verzeichnis chart charts/ unverändert weiter funktionieren.

Einführung in Bibliotheksdiagramme

Helm 3 unterstützt eine Diagrammklasse namens Bibliotheksdiagramm . Dieses Diagramm wird von anderen Diagrammen verwendet, erstellt jedoch keine eigenen Release-Artefakte. Bibliotheksdiagrammvorlagen können nur define Elemente deklarieren. Andere Inhalte werden einfach ignoriert. Auf diese Weise können Benutzer Codefragmente wiederverwenden und freigeben, die in vielen Diagrammen verwendet werden können, wodurch Doppelarbeit vermieden und das DRY- Prinzip eingehalten wird.

Bibliotheksdiagramme werden im Abschnitt " dependencies " der Datei " Chart.yaml . Installation und Verwaltung unterscheiden sich nicht von anderen Diagrammen.

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

Wir freuen uns auf die Anwendungsfälle, die diese Komponente für Diagrammentwickler öffnen wird, sowie auf die Best Practices, die sich aus Bibliotheksdiagrammen ergeben können.

Was weiter?

Helm 3.0.0-alpha.1 - die Basis, auf der wir mit der Erstellung einer neuen Version von Helm beginnen. In dem Artikel habe ich einige interessante Merkmale von Helm 3 beschrieben. Viele von ihnen befinden sich noch in einem frühen Entwicklungsstadium, und dies ist normal. Die Essenz der Alpha-Version 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 ist (denken Sie daran, dass dies bereits geschehen ist - ca. übersetzt) , werden wir von der Community Patches für Helm 3 erhalten. Es ist notwendig, eine solide Grundlage zu schaffen, auf der Sie neue Funktionen entwickeln und übernehmen können, und die Benutzer können sich in den Prozess involviert fühlen, Tickets öffnen und Korrekturen vornehmen.

In dem Artikel habe ich versucht, einige ernsthafte Verbesserungen hervorzuheben, die in Helm 3 erscheinen werden, aber diese Liste ist keineswegs vollständig. Der vollständige Plan für Helm 3 umfasst Innovationen wie verbesserte Aktualisierungsstrategien, eine tiefere Integration in OCI-Register und die Verwendung von JSON-Schemata zur Überprüfung von Diagrammwerten. Wir planen auch, die Codebasis zu löschen und die Teile davon zu aktualisieren, die in den letzten drei Jahren vernachlässigt wurden.

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

Nehmen Sie an der Diskussion in unseren Slack-Kanälen teil :

#helm-users für Fragen und einfache Kommunikation mit der Community;
#helm-dev , um Pull-Anfragen, Code und Fehler zu besprechen.

Sie können auch donnerstags um 19:30 Uhr MSK in unseren wöchentlichen öffentlichen Entwickleranrufen chatten. Die Meetings sind der Erörterung der Aufgaben gewidmet, an denen wichtige Entwickler und die Community arbeiten, sowie der Diskussionsthemen für die Woche. Jeder kann an dem Meeting teilnehmen. Der Link ist im #helm-dev Slack-Kanal verfügbar.

PS vom Übersetzer

Lesen Sie auch in unserem Blog:

Einführung in Helm 3