🥇 Einführung in Helm 3

Hinweis.: Der 16. Mai dieses Jahres markiert einen bedeutenden Meilenstein in der Entwicklung des Paketmanagers für Kubernetes – Helm. An diesem Tag wurde die erste Alpha-Version der bevorstehenden Major-Version 3.0 des Projekts vorgestellt. Ihr Erscheinen wird erhebliche und lang erwartete Änderungen in Helm mit sich bringen, auf die viele in der Kubernetes-Community große Hoffnungen setzen. Auch wir sind hiervon betroffen, da wir Helm aktiv für das Deployment von Anwendungen nutzen: Wir haben es in unser CI/CD-Tool integriert. werf Von Zeit zu Zeit tragen wir auch zur Weiterentwicklung des Upstreams bei. Diese Übersetzung fasst 7 Beiträge aus dem offiziellen Helm-Blog zusammen, die an den ersten Alpha-Release von Helm 3 angeknüpft sind und die Geschichte des Projekts sowie die Hauptmerkmale von Helm 3 thematisieren. Der Autor ist Matt „bacongobbler“ Fisher, ein Mitarbeiter von Microsoft und einer der Hauptmaintainer von Helm.

Das Projekt, das heute als Helm bekannt ist, entstand am 15. Oktober 2015. Nur ein Jahr nach seiner Gründung trat die Helm-Community Kubernetes bei und arbeitete gleichzeitig aktiv an Helm 2. Im Juni 2018 wurde Helm Teil der CNCF als ein sich entwickelndes (incubating) Projekt. Lassen Sie uns in die Gegenwart zurückkehren – und nun steht der erste Alpha-Release von Helm 3 vor der Tür. (dieser Release hat bereits stattgefunden. Mitte Mai — Anmerkung des Übersetzers..

In diesem Artikel werde ich darüber sprechen, wie alles begann, wie wir zu diesem aktuellen Stand gekommen sind, einige einzigartige Funktionen, die im ersten Alpha-Release von Helm 3 verfügbar sind, vorstellen und erläutern, wie wir uns weiterentwickeln möchten.

Zusammenfassung:

Die Entstehungsgeschichte von Helm;
ein sanfter Abschied von Tiller;
Chart-Repositories;
Release-Management;
Änderungen in den Chart-Abhängigkeiten;
Bibliotheks-Charts;
was tun Sie als Nächstes?

Die Entstehungsgeschichte von Helm

Die Geburt

Helm 1 begann als Open-Source-Projekt, das von der Firma Deis ins Leben gerufen wurde. Wir waren ein kleines Startup, das im Frühjahr 2017 von Microsoft übernommen wurde. Unser anderes Open-Source-Projekt, das ebenfalls den Namen Deis trug, hatte ein Werkzeug namens deisctl, das (unter anderem) zur Installation und zum Betrieb der Deis-Plattform in einem Fleet-Clusterverwendet wurde. Zu dieser Zeit war Fleet eine der ersten Plattformen zur Orchestrierung von Containern.

Mitte 2015 entschlossen wir uns, die Richtung zu ändern und Deis (damals in Deis Workflow umbenannt) von Fleet auf Kubernetes zu migrieren. Eines der ersten Werkzeuge, das überarbeitet wurde, war das Installationswerkzeug. deisctlEs wurde verwendet, um Deis Workflow in einem Fleet-Cluster zu installieren und zu verwalten.

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

Unser erster Versuch mit Helm war erfolgreich, aber es gab ernsthafte Einschränkungen. Er nahm eine Reihe von Kubernetes-Manifesten, gewürzt mit Generatoren als Eingangs-YAML-Blöcke (front-matter)*, und lud die Ergebnisse in Kubernetes.

* Hinweis.: Mit der ersten Version von Helm wurde für die Beschreibung von Kubernetes-Ressourcen die YAML-Syntax gewählt, und beim Schreiben von Konfigurationen wurden Jinja-Templates und Python-Skripte unterstützt. Mehr dazu und zur Struktur der ersten Helm-Version haben wir im Kapitel "Kurze Geschichte von Helm" geschrieben. diesem Material.

Zum Beispiel, um ein Feld in einer YAML-Datei zu ersetzen, musste man 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-Engines gibt, nicht wahr?

Aus vielen Gründen erforderte dieser frühe Kubernetes-Installer eine festgelegte Liste von Manifest-Dateien und führte nur eine kleine, feste Abfolge von Ereignissen aus. Der Umgang damit war so schwierig, dass das Forschung- und Entwicklungsteam von Deis Workflow auf erhebliche Herausforderungen stieß, als sie versuchten, ihr Produkt auf diese Plattform zu migrieren – dennoch waren die Samen der Idee bereits gesät. Unser erster Versuch bot eine großartige Lerngelegenheit: Wir erkannten, dass wir leidenschaftlich daran interessiert sind, pragmatische Werkzeuge zu entwickeln, die alltägliche Probleme unserer Nutzer lösen.

Gestützt auf die Erfahrungen aus vergangenen Fehlern begannen wir mit der Entwicklung von Helm 2.

Die Erstellung von Helm 2

Ende 2015 trat das Google-Team an uns heran. Sie arbeiteten an einem ähnlichen Werkzeug für Kubernetes. Der Deployment Manager für Kubernetes war ein Port eines bestehenden Tools, das bereits für die Google Cloud Plattform verwendet wurde. „Möchten wir uns ein paar Tage Zeit nehmen, um die Ähnlichkeiten und Unterschiede zu besprechen?“, fragten sie.

Im Januar 2016 trafen sich die Teams von Helm und dem Deployment Manager in Seattle, um Ideen auszutauschen. Die Gespräche endeten mit einem ehrgeizigen Plan: die beiden Projekte zu vereinen und Helm 2 zu schaffen. Zusammen mit Deis und Google traten auch die Kollegen von SkippBox (jetzt Teil von Bitnami – Anmerkung d. Übers.), und wir machten uns an die Arbeit an Helm 2.

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

Chart-Vorlagen zur Anpassung;
Management innerhalb des Clusters für Teams;
ein erstklassiges Chart-Repository;
ein stabiles Paketformat mit Signierungsoption;
eine feste Verpflichtung zu semantischer Versionierung und der Wahrung der Abwärtskompatibilität zwischen Versionen.

Um diese Ziele zu erreichen, wurde ein zweites Element in das Helm-Ökosystem eingeführt. Dieses komponenteninternen Teil wurde Tiller genannt und kümmerte sich um die Installation und Verwaltung von Helm-Charts.

Seit der Veröffentlichung von Helm 2 im Jahr 2016 hat Kubernetes mehrere bedeutende Neuerungen erhalten. Es wurde eine rollenbasierte Zugriffskontrolle eingeführt (RBAC), die schließlich die attributbasierte Zugriffskontrolle (ABAC) ablöste. Neue Ressourcentypen wurden eingeführt (Deployments befanden sich zu diesem Zeitpunkt weiterhin im Beta-Status). Die Custom Resource Definitions wurden erfunden (ursprünglich als Third Party Resources oder TPRs bezeichnet). Am wichtigsten war jedoch, dass ein Satz bewährter Praktiken entstand.

Vor dem Hintergrund all dieser Veränderungen bewährte sich Helm weiterhin für die Benutzer von Kubernetes. Nach drei Jahren und zahlreichen neuen Erweiterungen wurde klar, dass es an der Zeit war, bedeutende Änderungen an der Codebasis vorzunehmen, um Helm weiterhin den wachsenden Anforderungen des sich entwickelnden Ökosystems gerecht zu machen.

Ein sanfter Abschied von Tiller

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

Seit die rollenbasierte Zugriffskontrolle (RBAC) in Kubernetes 1.6 standardmäßig aktiviert wurde, ist die Arbeit mit Tiller in der Produktion komplexer geworden. Aufgrund der Vielzahl möglicher Sicherheitsrichtlinien haben wir uns entschieden, eine erweiterte Konfiguration als Standard anzubieten. Dies ermöglichte es Anfängern, mit Helm und Kubernetes zu experimentieren, ohne sich zunächst in die Sicherheitseinstellungen vertiefen zu müssen. Leider konnte diese erweiterte Konfiguration dem Nutzer möglicherweise zu umfangreiche Berechtigungen verleihen, die er nicht benötigte. DevOps- und SRE-Teams mussten zusätzliche betriebliche Schritte lernen, um Tiller in einem Multi-Tenant-Cluster zu installieren.

Nachdem wir erfahren hatten, wie die Community Helm in spezifischen Situationen einsetzt, wurde uns klar, dass das Release-Management-System von Tiller nicht auf einen intra-cluster-Komponenten angewiesen sein muss, um Zustände zu verwalten oder als zentrales Hub für Release-Informationen zu fungieren. Stattdessen könnten wir einfach Informationen vom Kubernetes API-Server abrufen, das Chart clientseitig generieren und den Installationsdatensatz in Kubernetes speichern.

Die Hauptaufgabe von Tiller konnte auch ohne Tiller erreicht werden, weshalb eine unserer ersten Entscheidungen in Bezug auf Helm 3 der vollständige Verzicht auf Tiller war.

Mit dem Wegfall von Tiller hat sich das Sicherheitsmodell von Helm radikal vereinfacht. Helm 3 unterstützt nun alle modernen Sicherheitsmethoden, Identifizierung und Autorisierung des aktuellen Kubernetes. Die Berechtigungen von Helm werden mithilfe von der kubeconfig-Datei. Clusteradministratoren können die Benutzerrechte mit jeder gewünschten Detailgenauigkeit einschränken. Releases werden weiterhin innerhalb des Clusters gespeichert, die restliche Funktionalität von Helm bleibt erhalten.

Chart-Repositories

Ein Chart-Repository ist eine effiziente Ablage für die Speicherung und gemeinsame Nutzung von Charts. Der Helm-Client packt und sendet diese Charts an das Repository. Kurz gesagt, ein Chart-Repository fungiert im Grunde genommen als einfacher HTTP-Server mit einer index.yaml-Datei und mehreren verpackten Charts.

Obwohl das API des Chart-Repositories einige Vorteile bietet und grundlegende Anforderungen an die Speicherung erfüllt, gibt es auch einige Nachteile:

Chart-Repositories sind mit den meisten sicherheitsrelevanten Implementierungen, die in Produktionsumgebungen erforderlich sind, schwer kompatibel. Ein standardisiertes API für Authentifizierung und Autorisierung ist in Produktionsszenarien von entscheidender Bedeutung.
Die Helm-Tools zur Verfolgung der Herkunft eines Charts, die für die Signierung, Integritätsprüfung und Ursprungskontrolle genutzt werden, sind optional im Veröffentlichungsprozess eines Charts.
In Mehrbenutzerszenarien kann dasselbe Chart von einem anderen Benutzer geladen werden, was den Speicherbedarf für denselben Inhalt verdoppelt. Um dieses Problem zu lösen, wurden intelligentere Repositories entwickelt, die jedoch nicht Teil der formalen Spezifikation sind.
Die Verwendung einer einzigen Indexdatei zur Suche, Speicherung von Metadaten und zum Abrufen von Charts hat die Entwicklung sicherer Mehrbenutzer-Implementierungen kompliziert.

Projekt Docker Distribution (auch bekannt als Docker Registry v2) ist der Nachfolger der Docker Registry und stellt tatsächlich eine Sammlung von Werkzeugen zum Packen, Versenden, Speichern und Bereitstellen von Docker-Images dar. Viele große Cloud-Dienste bieten Produkte auf Basis von Distribution an. Aufgrund dieser erhöhten Aufmerksamkeit hat das Distribution-Projekt von jahrelangen Verbesserungen, Best Practices in Bezug auf Sicherheit und Tests unter „realen“ Bedingungen profitiert, wodurch es zu einem der erfolgreichsten unbekannten Helden der Open Source-Welt geworden ist.

Aber wussten Sie, dass das Distribution-Projekt entwickelt wurde, um jede Art von Inhalt zu verteilen und nicht nur Container-Images?

Dank des Engagements Open Container Initiative (oder OCI) können Helm-Charts auf jeder Instanz von Distribution gehostet werden. Dieser Prozess ist derzeit noch experimentell. Die Arbeit an der Unterstützung von Logins und weiteren Funktionen, die für ein vollständiges Helm 3 erforderlich sind, ist noch nicht abgeschlossen, aber wir freuen uns sehr über die Gelegenheit, von den Entdeckungen zu lernen, die die Teams von OCI und Distribution über die Jahre gemacht haben. Dank ihrer Mentorschaft und Führung erfahren wir, was den Betrieb eines hochverfügbaren Services in großem Maßstab ausmacht.

Eine ausführlichere Beschreibung einiger bevorstehender Änderungen in den Helm-Chart-Repositories ist verfügbar über den Link.

Verwaltung der Releases

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

release object — 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 object und das release version secret. Der Aufruf helm upgrade erfordert ein release object (das verändert werden kann) und erstellt ein neues release version secret, das neue Werte und das vorbereitete Manifest enthält.

Das Release-Objekt enthält Informationen über den Release, wobei ein Release eine spezifische Installation eines benannten Charts und dessen Werte darstellt. Dieses Objekt beschreibt die Metadaten auf oberster Ebene zum Release. Das Release-Objekt bleibt während des gesamten Lebenszyklus der Anwendung erhalten und fungiert als Eigentümer aller Secrets der Release-Versionen sowie aller Objekte, die direkt durch das Helm-Chart erstellt werden.

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

In Helm 2 waren die Revisionen ausschließlich sequenziell. Der Aufruf helm install erzeugte v1, das folgende Update (Upgrade) — v2, und so weiter. Release und Release-Version-Secret wurden zu einem einzelnen Objekt zusammengefasst, das als Revision bekannt ist. Die Revisionen wurden im selben Namensraum gespeichert wie Tiller, was bedeutete, dass jeder Release 'global' in Bezug auf den Namensraum war; folglich konnte nur eine Instanz des Namens verwendet werden.

In Helm 3 ist jede Veröffentlichung mit einem oder mehreren Release-Version-Secrets verbunden. Das Release-Objekt beschreibt immer die aktuelle Veröffentlichung, die im Kubernetes bereitgestellt ist. Jedes Release-Version-Secret beschreibt nur eine Version dieser Veröffentlichung. Bei einem Upgrade wird beispielsweise ein neues Release-Version-Secret erstellt und dann wird das Release-Objekt geändert, um auf diese neue Version zu verweisen. Bei einem Rollback können die vorherigen Release-Version-Secrets verwendet werden, um die Veröffentlichung auf den vorherigen Zustand zurückzusetzen.

Nach der Abkehr von Tiller speichert Helm 3 die Releases-Daten im gleichen Namespace wie das Release. Diese Änderung ermöglicht es, ein Chart mit demselben Release-Namen in einem anderen Namespace zu installieren, wobei die Daten zwischen Updates/Clusterneustarts in etcd gespeichert bleiben. Zum Beispiel kann WordPress im Namespace „foo“ installiert werden, und anschließend im Namespace „bar“, wobei beide Releases „wordpress“ heißen können.

Änderungen in den Chart-Abhängigkeiten

Charts, die gepackt sind (mithilfe von helm package) für die Verwendung mit Helm 2 kann mit Helm 3 installiert werden. Der Entwicklungsprozess von Charts wurde jedoch vollständig überarbeitet, weshalb einige Anpassungen erforderlich sind, um die Entwicklung von Charts mit Helm 3 fortzusetzen. Insbesondere wurde das System zur Verwaltung von Chart-Abhängigkeiten geändert.

Das System zur Verwaltung von Chart-Abhängigkeiten wurde von requirements.yaml und requirements.lock findet man Chart.yaml und Chart.lock. Das bedeutet, dass Charts, die den Befehl helm dependency, benötigen einige Anpassungen, um in Helm 3 zu funktionieren.

Schauen wir uns ein Beispiel an. Fügen wir eine Abhängigkeit zu einem Chart in Helm 2 hinzu und sehen wir uns an, was sich beim Wechsel 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 Ihrer Chart.yaml:

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

Charts werden weiterhin geladen und in das Verzeichnis charts/, deshalb funktionieren die Subcharts (subcharts), die im Verzeichnis liegen, charts/, ohne Änderungen weiter.

Einführung von 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 aber keine eigenen Release-Artefakte. Die Vorlagen für Library-Charts können nur Elemente deklarieren. definieren. Anderer Inhalt wird einfach ignoriert. Dies ermöglicht es den Nutzern, Codefragmente wiederzuverwenden und auszutauschen, die in vielen Charts verwendet werden können, wodurch Duplizierung vermieden wird und das Prinzip eingehalten wird. DRY.

Library-Charts werden im Abschnitt Abhängigkeiten in der Datei Chart.yaml. Die Installation und Verwaltung unterscheidet sich nicht von anderen Charts.

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

Wir freuen uns auf die Anwendungsfälle, die dieser Bestandteil für Chart-Entwickler eröffnen wird, sowie auf die besten Praktiken, die aus den Library-Charts hervorgehen können.

Wie geht es weiter?

Helm 3.0.0-alpha.1 ist die Grundlage, auf der wir die neue Version von Helm aufbauen. In diesem Artikel habe ich einige interessante Funktionen von Helm 3 beschrieben. Viele davon befinden sich noch in der frühen Entwicklungsphase, und das ist normal; der Zweck einer Alpha-Version besteht darin, die Idee zu testen, Rückmeldungen von den ersten Nutzern zu sammeln und unsere Annahmen zu bestätigen.

Sobald die Alpha-Version veröffentlicht wird (denken wir daran, dass dies bereits geschehen ist — Anmerkung des Übersetzers)., wir werden anfangen, Community-Patches für Helm 3 zu akzeptieren. Es ist wichtig, eine zuverlässige Basis zu schaffen, die die Entwicklung und Implementierung neuer Funktionalitäten ermöglicht, sodass die Benutzer aktiv in den Prozess eingebunden werden können, indem sie Tickets eröffnen und Korrekturen einreichen.

In diesem Artikel habe ich versucht, einige bedeutende Verbesserungen zu beleuchten, die in Helm 3 erscheinen werden, jedoch ist diese Liste keinesfalls erschöpfend. Der umfassende Plan für Helm 3 beinhaltet neue Features wie verbesserte Upgrade-Strategien, eine tiefere Integration mit OCI-Registry und die Verwendung von JSON-Schemata zur Validierung von Chart-Werten. Darüber hinaus planen wir, den Code 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 übersehen haben, freuen wir uns über Ihr Feedback!

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

#helm-users teil, um Fragen zu stellen und einfach mit der Community zu kommunizieren;
#helm-dev um Pull Requests, Code und Bugs zu besprechen.

Sie können auch an unseren wöchentlichen öffentlichen Entwicklergesprächen teilnehmen, die donnerstags um 19:30 Uhr MSK stattfinden. Diese Treffen sind der Diskussion über die Aufgaben gewidmet, an denen die Schlüsselentwickler und die Community arbeiten, sowie den Themen der Woche. Jeder Interessierte kann teilnehmen und mitdiskutieren. Der Link ist im Slack-Kanal verfügbar. #helm-dev.