🥇Wir stellen vor: Helm 3

Notiz. übersetzen: Der 16. Mai dieses Jahres ist 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. Seine Veröffentlichung wird bedeutende und lang erwartete Änderungen an Helm mit sich bringen, auf die viele in der Kubernetes-Community große Hoffnungen setzen. Wir selbst gehören dazu, da wir Helm aktiv für die Bereitstellung von Anwendungen nutzen: Wir haben es in unser Tool zur Implementierung von CI / CD integriert Hof und von Fall zu Fall leisten wir einen sinnvollen Beitrag zur Entwicklung des Upstreams. Diese Übersetzung vereint 7 Notizen aus dem offiziellen Helm-Blog, die der ersten Alpha-Version von Helm 3 gewidmet sind und über die Geschichte des Projekts und die Hauptfunktionen von Helm 3 berichten. Ihr Autor ist Matt „Bacongobbler“ Fisher, ein Microsoft-Mitarbeiter und einer der wichtigsten Betreuer von Helm.

Am 15. Oktober 2015 wurde das Projekt, das heute Helm heißt, geboren. Nur ein Jahr nach der Gründung trat die Helm-Community Kubernetes bei und arbeitete gleichzeitig aktiv an Helm 2. Im Juni 2018 wurde Helm trat der CNCF bei als Inkubationsprojekt. Spulen wir in die Gegenwart vor und die erste Alpha-Version des neuen Helm 3 ist unterwegs. (diese Veröffentlichung hat bereits stattgefunden Mitte Mai - ca. übersetzt).

In diesem Artikel gehe ich darauf ein, wie alles begann, wie wir dorthin gelangt sind, wo es heute ist, stelle einige der einzigartigen Funktionen vor, die in der ersten Alpha-Version von Helm 3 verfügbar sind, und erkläre, wie wir weiterentwickeln wollen.

Zusammenfassung:

die Geschichte der Entstehung von Helm;
zärtlicher Abschied von Tiller;
Diagramm-Repositorys;
Release-Management;
Änderungen in Diagrammabhängigkeiten;
Bibliothekskarten;
was weiter?

Geschichte von Helm

Geburt

Helm 1 begann als Open-Source-Projekt von Deis. Wir waren ein kleines Startup absorbiert Microsoft im Frühjahr 2017. Unser anderes Open-Source-Projekt, ebenfalls Deis genannt, hatte ein Tool deisctlmit dem (unter anderem) die Deis-Plattform installiert und betrieben wurde Flottencluster. Zu dieser Zeit war Fleet eine der ersten Container-Orchestrierungsplattformen.

Mitte 2015 entschieden wir uns für einen Kurswechsel und migrierten Deis (damals in Deis Workflow umbenannt) von Fleet zu Kubernetes. Eines der ersten war das neu gestaltete Installationstool deisctl. Wir haben es verwendet, um Deis Workflow auf einem Flottencluster zu installieren und zu verwalten.

Helm 1 wurde in Anlehnung an bekannte Paketmanager wie Homebrew, apt und yum erstellt. Sein Hauptziel 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 funktionierte, verlief jedoch nicht ohne gravierende Einschränkungen. Er nahm eine Reihe von Kubernetes-Manifesten, die mit Generatoren aromatisiert waren, als einführende YAML-Blöcke. (Vorderseite)* und die Ergebnisse auf Kubernetes hochgeladen.

* Notiz. übersetzen: Ab der ersten Version von Helm wurde die YAML-Syntax zur Beschreibung von Kubernetes-Ressourcen gewählt, und beim Schreiben von Konfigurationen wurden Jinja-Vorlagen und Python-Skripte unterstützt. Mehr darüber und über das Gerät der ersten Version von Helm im Allgemeinen haben wir im Kapitel „Eine kurze Geschichte von Helm“ geschrieben. dieses Material.

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

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

Es ist cool, dass es heute Templating-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 Abfolge von Ereignissen aus. Die Bedienung war so schwierig, dass es dem Forschungs- und Entwicklungsteam von Deis Workflow schwer fiel, sein Produkt auf diese Plattform zu übertragen – der Grundstein für die Idee war jedoch bereits gelegt. Unser erster Versuch war eine großartige Gelegenheit zum Lernen, da uns klar wurde, dass uns die Entwicklung pragmatischer Tools, die alltägliche Probleme unserer Benutzer lösen, wirklich am Herzen liegt.

Basierend auf den Erfahrungen vergangener Fehler haben wir mit der Entwicklung von Helm 2 begonnen.

Helm 2 herstellen

Ende 2015 wurden wir vom Google-Team kontaktiert. Sie arbeiteten an einem ähnlichen Tool für Kubernetes. Der Deployment Manager für Kubernetes war eine Portierung eines vorhandenen Tools, das für die Google Cloud Platform verwendet wurde. „Sind wir bereit“, fragten sie, „ein paar Tage damit zu verbringen, Gemeinsamkeiten und Unterschiede zu diskutieren?“

Im Januar 2016 trafen sich die Helm- und Deployment-Manager-Teams in Seattle, um Ideen auszutauschen. Die Gespräche gipfelten in einem ehrgeizigen Plan, beide Projekte zu Helm 2 zusammenzuführen. Gemeinsam mit Deis und Google haben die Jungs von SkipBox (jetzt Teil von Bitnami – ca. übersetzt), und wir begannen mit der Arbeit an Helm 2.

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

Diagrammvorlagen zur individuellen Anpassung;
Intracluster-Management für Teams;
erstklassiges Diagramm-Repository;
stabiles Paketformat mit Signierfunktion;
ein 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 Cluster-interne Komponente hieß Tiller 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 große Innovationen erlebt. Es wurde eine rollenbasierte Zugriffskontrolle eingeführt (RBAC), die schließlich die attributbasierte Zugriffskontrolle (ABAC) ersetzte. Neue Ressourcentypen wurden eingeführt (die Bereitstellungen befanden sich zu diesem Zeitpunkt noch in der Betaphase). Es wurden benutzerdefinierte Ressourcendefinitionen erfunden (ursprünglich als Third Party Resources oder TPRs bezeichnet). Und was am wichtigsten ist: Es ist eine Reihe von Best Practices erschienen.

Trotz all dieser Änderungen hat Helm den Kubernetes-Benutzern weiterhin treu zur Seite gestanden. Nach drei Jahren und vielen Neuzugängen war 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.

Zärtlicher 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 innerhalb eines gemeinsamen Clusters arbeiteten: Es ermöglichte verschiedenen Spezialisten, die die Infrastruktur betreiben, mit denselben Releases zu interagieren.

Da die rollenbasierte Zugriffskontrolle (RBAC) in Kubernetes 1.6 standardmäßig aktiviert war, wurde die Arbeit mit Tiller in der Produktion schwieriger. Aufgrund der Vielzahl möglicher Sicherheitsrichtlinien war es unsere Position, standardmäßig eine freizügige Konfiguration anzubieten. Dies ermöglichte es Anfängern, mit Helm und Kubernetes zu experimentieren, ohne sich zuerst mit den Sicherheitseinstellungen befassen zu müssen. Leider könnte diese freizügige Konfiguration dem Benutzer einen zu großen Umfang an Berechtigungen gewähren, die er nicht benötigt. DevOps- und SRE-Ingenieure mussten bei der Installation von Tiller in einem Multi-Tenant-Cluster zusätzliche Betriebsschritte erlernen.

Indem wir erfuhren, wie die Community Helm in bestimmten Situationen verwendet, wurde uns klar, dass das Release-Management-System von Tiller nicht auf eine Cluster-Komponente angewiesen sein muss, um Zustände aufrechtzuerhalten oder als zentraler Knotenpunkt für Release-Informationen zu fungieren. Stattdessen könnten wir einfach Informationen vom Kubernetes-API-Server abrufen, auf der Clientseite ein Diagramm erstellen und einen Kubernetes-Installationsdatensatz speichern.

Das Hauptziel von Tiller könnte ohne Tiller erreicht werden, daher war eine unserer ersten Entscheidungen bezüglich Helm 3, Tiller vollständig aufzugeben.

Mit dem Abgang von Tiller wurde Helms Sicherheitsmodell radikal vereinfacht. Helm 3 unterstützt jetzt alle modernen Sicherheits-, Identifikations- und Autorisierungsfunktionen des heutigen Kubernetes. Helm-Berechtigungen werden mit definiert kubeconfig-Datei. Clusteradministratoren können Benutzerrechte auf jede beliebige Granularität beschränken. Releases werden weiterhin im Cluster gespeichert, der Rest der Helm-Funktionalität bleibt erhalten.

Diagramm-Repositorys

Auf hoher Ebene ist ein Diagramm-Repository ein Ort, an dem Diagramme gespeichert und gemeinsam genutzt werden können. Der Helm-Client packt die Diagramme und überträgt sie in das Repository. Einfach ausgedrückt ist ein Diagramm-Repository ein einfacher HTTP-Server mit einer index.yaml-Datei und einigen gepackten Diagrammen.

Obwohl die Charts Repository API einige Vorteile bietet und die meisten grundlegenden Speicheranforderungen erfüllt, weist sie auch einige Nachteile auf:

Diagrammrepositorys sind mit den meisten Sicherheitsimplementierungen, die in einer Produktionsumgebung erforderlich sind, nicht kompatibel. In Produktionsszenarien ist eine Standard-API für Authentifizierung und Autorisierung unerlässlich.
Die Helm-Tools zur Verfolgung des Diagrammursprungs, die zum Signieren, Überprüfen der Integrität und des Diagrammursprungs verwendet werden, sind ein optionaler Teil des Veröffentlichungsprozesses des Diagramms.
In Mehrbenutzerszenarien kann dasselbe Diagramm von einem anderen Benutzer geladen werden, wodurch sich der zum Speichern desselben Inhalts benötigte Speicherplatz verdoppelt. Um dieses Problem zu lösen, wurden intelligentere Repositories entwickelt, die jedoch nicht Teil der formalen Spezifikation sind.
Die Verwendung einer einzigen Indexdatei zum Suchen, Speichern von Metadaten und Abrufen von Diagrammen hat die Entwicklung sicherer Mehrbenutzerimplementierungen erschwert.

Projekt Docker-Verteilung (auch bekannt als Docker Registry v2) ist der Nachfolger von Docker Registry und besteht eigentlich aus einer Reihe von Tools zum Verpacken, Versenden, Speichern und Verteilen von Docker-Images. Viele große Cloud-Dienste bieten Produkte an, die auf Distribution basieren. Mit dieser erhöhten Aufmerksamkeit hat das Distribution-Projekt von jahrelangen Verbesserungen, bewährten Sicherheitspraktiken und Feldtests profitiert, die es zu einem der erfolgreichsten unbesungenen Helden der Open-Source-Welt gemacht haben.

Aber wussten Sie, dass das Distribution-Projekt darauf ausgelegt ist, jegliche Form von Inhalten zu verbreiten, nicht nur Container-Bilder?

Dank der Bemühungen Offene Container-Initiative (oder OCI) können Helm-Charts auf jeder Distributionsinstanz platziert werden. Bisher ist dieser Prozess experimentell. Die Arbeit an der Anmeldeunterstützung und anderen Funktionen, die für ein vollständiges Helm 3 erforderlich sind, ist noch im Gange, aber wir freuen uns, aus den Entdeckungen zu lernen, die die OCI- und Distributionsteams im Laufe der Jahre gemacht haben. Und durch ihre Betreuung und Anleitung lernen wir, wie es ist, einen hochverfügbaren Dienst in großem Maßstab zu betreiben.

Eine detailliertere Beschreibung einiger der bevorstehenden Änderungen in den Helm Chart-Repositorys ist verfügbar. Link.

Release-Management

In Helm 3 wird der Anwendungsstatus innerhalb des Clusters durch einige Objekte verfolgt:

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

Вызов helm install Erstellt ein Release-Objekt und ein Release-Versionsgeheimnis. Anruf helm upgrade erfordert ein Release-Objekt (das es ändern kann) und erstellt ein neues Release-Versionsgeheimnis, das die neuen Werte und ein vorbereitetes Manifest enthält.

Das Release-Objekt enthält Informationen über das Release, wobei Release eine spezifische Installation des benannten Diagramms und der genannten Werte ist. Dieses Objekt beschreibt Metadaten der obersten Ebene zum Release. Das Release-Objekt bleibt während des gesamten Anwendungslebenszyklus bestehen und ist Eigentümer aller Release-Versionsgeheimnisse sowie aller Objekte, die direkt vom Helm-Chart erstellt werden.

Das Release-Versionsgeheimnis verknüpft ein Release mit einer Reihe von Revisionen (Installation, Updates, Rollbacks, Löschungen).

In Helm 2 waren die Überarbeitungen äußerst konsistent. Anruf helm install erstellt v1, das nachfolgende Update (Upgrade) - v2 und so weiter. Release und Release-Versionsgeheimnis wurden in einer einzigen Einheit zusammengefasst, die als Revision bezeichnet wird. Revisionen wurden im selben Namensraum wie Tiller gehalten, was bedeutete, dass jede Veröffentlichung im Hinblick auf den Namensraum „global“ war; Daher konnte nur eine Instanz des Namens verwendet werden.

In Helm 3 ist jede Veröffentlichung mit einem oder mehreren Veröffentlichungsversionsgeheimnissen verknüpft. Das Release-Objekt beschreibt immer die aktuelle Version, die auf Kubernetes bereitgestellt wird. Jedes Versionsgeheimnis einer Veröffentlichung beschreibt nur eine Version dieser Veröffentlichung. Bei einem Upgrade wird beispielsweise ein neues Release-Versionsgeheimnis erstellt und dann das Release-Objekt so geändert, 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 einen früheren Status zurückzusetzen.

Nach der Abschaffung von Tiller speichert Helm 3 Release-Daten im selben Namespace wie das Release. Eine solche Änderung ermöglicht es Ihnen, ein Diagramm mit demselben Release-Namen in einem anderen Namespace zu installieren und die Daten zwischen Cluster-Updates/Neustarts in etcd zu speichern. Beispielsweise können Sie WordPress im Namespace „foo“ und dann im Namespace „bar“ installieren und beide Versionen können „Wordpress“ heißen.

Änderungen der Diagrammabhängigkeit

Diagramme gepackt (mit helm package) zur Verwendung mit Helm 2 kann mit Helm 3 installiert werden. Der Diagrammentwicklungs-Workflow wurde jedoch komplett überarbeitet, sodass einige Änderungen vorgenommen werden müssen, um weiterhin Diagramme mit Helm 3 entwickeln zu können. Insbesondere das Diagrammabhängigkeitsverwaltungssystem hat sich geändert.

Das Abhängigkeitsmanagementsystem von Chart wurde verschoben requirements.yaml и requirements.lock auf Chart.yaml и Chart.lock. Dies bedeutet, dass die Diagramme, die den Befehl verwendet haben helm dependency, erfordern einige Konfigurationen, um in Helm 3 zu funktionieren.

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

In Helm 2 requirements.yaml sah so aus:

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

In Helm 3 wird sich die gleiche Abhängigkeit in Ihrem widerspiegeln Chart.yaml:

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

Diagramme werden weiterhin heruntergeladen und im Verzeichnis abgelegt charts/, also die Subcharts (Subcharts), befindet sich im Verzeichnis charts/wird unverändert weiterarbeiten.

Einführung in Bibliotheksdiagramme

Helm 3 unterstützt eine Klasse von Diagrammen, die als Bibliotheksdiagramme bezeichnet werden (Bibliotheksdiagramm). Dieses Diagramm wird von anderen Diagrammen verwendet, generiert jedoch selbst keine Release-Artefakte. Bibliotheksdiagrammvorlagen können nur Elemente deklarieren define. Andere Inhalte werden einfach ignoriert. Dies ermöglicht es Benutzern, Codeausschnitte, die in vielen Diagrammen verwendet werden können, wiederzuverwenden und zu teilen, wodurch Duplizierungen vermieden werden und das Prinzip eingehalten wird TROCKEN.

Bibliotheksdiagramme werden im Abschnitt deklariert dependencies im Ordner Chart.yaml. Die Installation und Verwaltung unterscheidet sich nicht von anderen Diagrammen.

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

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

Was kommt als nächstes?

Helm 3.0.0-alpha.1 ist die Grundlage, auf der wir beginnen, eine neue Version von Helm zu erstellen. In dem Artikel habe ich einige interessante Funktionen von Helm 3 beschrieben. Viele davon befinden sich noch in einem frühen Entwicklungsstadium, und das ist normal; Der Sinn einer Alpha-Version besteht darin, die Idee zu testen, Feedback von Erstanwendern einzuholen und unsere Annahmen zu validieren.

Sobald die Alpha-Version veröffentlicht wird (Denken Sie daran Du hast es geschafft - ca. übersetzt), werden wir damit beginnen, Patches für Helm 3 von der Community anzunehmen. Es muss eine solide Grundlage geschaffen werden, damit neue Funktionen entwickelt und übernommen werden können und sich die Benutzer durch das Öffnen von Tickets und das Vornehmen von Korrekturen in den Prozess eingebunden fühlen.

In diesem Artikel habe ich versucht, einige der wichtigsten Verbesserungen von Helm 3 hervorzuheben, aber diese Liste ist keineswegs vollständig. Der vollständige Plan für Helm 3 umfasst neue Funktionen wie verbesserte Aktualisierungsstrategien, eine tiefere Integration mit OCI-Registern und die Verwendung von JSON-Schemas zur Validierung von Diagrammwerten. Wir planen außerdem, die Codebasis zu bereinigen 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, würden wir gerne Ihre Meinung hören!

Beteiligen Sie sich an der Diskussion in unserem Slack-Kanäle:

#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 bei unseren wöchentlichen öffentlichen Entwickleranrufen chatten. Bei den Treffen geht es um die Erörterung der Aufgaben, an denen wichtige Entwickler und die Community arbeiten, sowie um die Diskussionsthemen der Woche. Jeder kann beitreten und am Treffen teilnehmen. Link im Slack-Kanal verfügbar #helm-dev.

PS vom Übersetzer

Lesen Sie auch auf unserem Blog:

Source: habr.com

Einführung in Helm 3