{"id":34735,"date":"2019-10-31T22:00:06","date_gmt":"2019-10-31T19:00:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/znakomstvo-s-helm-3\/"},"modified":"2019-10-31T22:00:06","modified_gmt":"2019-10-31T19:00:06","slug":"znakomstvo-s-helm-3","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/znakomstvo-s-helm-3","title":{"rendered":"Einf\u00fchrung in Helm 3","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Einf\u00fchrung in Helm 3\" src=\"\/wp-content\/uploads\/2019\/05\/6de0e2887ddcc802f1dd71c902325401.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Anmerkung des \u00dcbersetzers.<\/b>: 16. Mai dieses Jahres \u2013 ein bedeutender Meilenstein in der Entwicklung des Paketmanagers f\u00fcr Kubernetes \u2013 Helm. An diesem Tag wurde die erste Alpha-Version der zuk\u00fcnftigen Hauptversion des Projekts \u2013 3.0 \u2013 vorgestellt. Deren Ver\u00f6ffentlichung wird Helm wesentliche und lang erwartete \u00c4nderungen bringen, auf die viele im Kubernetes-Community gro\u00dfe Hoffnungen setzen. Dazu z\u00e4hlen auch wir selbst, da wir Helm aktiv f\u00fcr das Deployment von Anwendungen verwenden: Wir haben es in unser CI\/CD-Tool integriert <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">werf<\/a><\/noindex> und leisten von Fall zu Fall unseren Beitrag zur Entwicklung des Upstreams. Diese \u00dcbersetzung 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 \u201ebacongobbler\u201c Fisher, Mitarbeiter bei Microsoft und einer der Hauptpfleger von Helm.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Am 15. Oktober 2015 wurde das Projekt geboren, das heute als Helm bekannt ist. Nur ein Jahr nach seiner Gr\u00fcndung trat die Helm-Community der Kubernetes-Community bei, w\u00e4hrend sie aktiv an Helm 2 arbeitete. Im Juni 2018 wurde Helm <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cncf.io\/blog\/2018\/06\/01\/cncf-to-host-helm\/\">Teil der CNCF<\/a><\/noindex> als sich entwickelndes (incubating) Projekt. Kommen wir in die Gegenwart \u2013 und schon steht die erste Alpha-Version des neuen Helm 3 vor der T\u00fcr <i>(dieser Release <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">hat bereits stattgefunden<\/a><\/noindex> in der Mitte Mai \u2013 Anm. d. \u00dcbers.)<\/i>.<\/p>\n<p>In diesem Material werde ich erl\u00e4utern, wie alles begann, wie wir den aktuellen Stand erreicht haben, einige einzigartige Merkmale vorstellen, die in der ersten Alpha-Version von Helm 3 verf\u00fcgbar sind, und erkl\u00e4ren, wie wir weiter vorankommen wollen.<\/p>\n<p>Zusammenfassung:<\/p>\n<ul>\n<li>die Geschichte von Helm;<\/li>\n<li>z\u00e4rtlicher Abschied von Tiller<\/li>\n<li>Chart-Repositories;<\/li>\n<li>Release-Verwaltung;<\/li>\n<li>\u00c4nderungen der Chart-Abh\u00e4ngigkeiten;<\/li>\n<li>Library Charts;<\/li>\n<li>und was kommt als N\u00e4chstes?<\/li>\n<\/ul>\n<p><\/p>\n<h2>Die Geschichte von Helm<\/h2>\n<p><\/p>\n<h3>Die Geburt<\/h3>\n<p>\nHelm 1 begann als Open-Source-Projekt, das von der Firma Deis ins Leben gerufen wurde. Wir waren ein kleines Start-up, <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.microsoft.com\/blog\/2017\/04\/10\/microsoft-acquire-deis-help-companies-innovate-containers\/\">das im Fr\u00fchjahr 2017 von<\/a><\/noindex> Microsoft \u00fcbernommen wurde. Unser anderes Open-Source-Projekt, das ebenfalls Deis hie\u00df, hatte ein Werkzeug <code>deisctl<\/code>, das (unter anderem) zur Installation und Verwaltung der Deis-Plattform in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/coreos\/fleet\">Fleet-Clusters<\/a><\/noindex>. Zu diesem Zeitpunkt war Fleet eine der ersten Plattformen zur Orchestrierung von Containern.<\/p>\n<p>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 \u00fcberarbeitet wurde, war das Installationswerkzeug <code>deisctl<\/code>. Wir verwendeten es zur Installation und Verwaltung von Deis Workflow in einem Fleet-Cluster.<\/p>\n<p>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.<\/p>\n<p>Unser erster Versuch mit Helm war erfolgreich, jedoch gab es erhebliche Einschr\u00e4nkungen. Er nahm eine Reihe von Kubernetes-Manifests, angereichert mit Generatoren als eingehende YAML-Bl\u00f6cke <i>(front-matter)<\/i>*, und lud die Ergebnisse in Kubernetes hoch.<\/p>\n<p><i>* <b>Anmerkung des \u00dcbersetzers.<\/b>: Ab der ersten Version von Helm wurde f\u00fcr die Beschreibung von Kubernetes-Ressourcen die YAML-Syntax gew\u00e4hlt, und bei der Erstellung von Konfigurationen wurden Jinja-Vorlagen und Python-Skripte unterst\u00fctzt. Mehr dazu und zu den Eigenschaften der ersten Helm-Version haben wir im Kapitel \u201eKurze Geschichte von Helm\u201c <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">dieses Materials<\/a><\/noindex>.<\/i><\/p>\n<p>Zum Beispiel musste man, um ein Feld in einer YAML-Datei zu ersetzen, die folgende Konstruktion zum Manifest hinzuf\u00fcgen:<\/p>\n<pre><code class=\"plaintext\">#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my\/pod.yaml<\/code><\/pre>\n<p>\nEs ist toll, dass es heute Template-Systeme gibt, oder?<\/p>\n<p>Aus verschiedenen Gr\u00fcnden erforderte dieser fr\u00fche Kubernetes-Installer eine festgelegte Liste von Manifestdateien und f\u00fchrte nur eine kleine feste Abfolge von Ereignissen aus. Die Nutzung war so schwierig, dass das R&amp;D-Team von Deis Workflow es schwer hatte, als sie versuchten, ihr Produkt auf diese Plattform zu portieren \u2013 allerdings waren die Samen der Idee bereits ges\u00e4t. Unser erster Versuch wurde zu einer gro\u00dfartigen Lerngelegenheit: Wir erkannten, dass wir wirklich leidenschaftlich daran interessiert sind, pragmatische Werkzeuge zu schaffen, die allt\u00e4gliche Probleme unserer Benutzer l\u00f6sen.<\/p>\n<p>Basierend auf den Erfahrungen aus fr\u00fcheren Fehlern begannen wir mit der Entwicklung von Helm 2.<\/p>\n<h3>Entwicklung von Helm 2<\/h3>\n<p>\nEnde 2015 kontaktierte uns das Team von Google. Sie arbeiteten an einem \u00e4hnlichen Tool f\u00fcr Kubernetes. Der Deployment Manager f\u00fcr Kubernetes war ein Port eines bestehenden Tools, das f\u00fcr die Google Cloud Platform verwendet wurde. \u201eWollen wir nicht\u201c, fragten sie, \u201eein paar Tage damit verbringen, die \u00c4hnlichkeiten und Unterschiede zu diskutieren?\u201c<\/p>\n<p>Im Januar 2016 trafen sich die Teams von Helm und Deployment Manager in Seattle, um Ideen auszutauschen. Die Gespr\u00e4che endeten mit einem ehrgeizigen Plan: beide Projekte zu vereinen, um Helm 2 zu schaffen. Zusammen mit Deis und Google schlossen sich die Entwickler auch die Jungs von <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/skippbox\">SkippBox<\/a><\/noindex> <i>(heute Teil von Bitnami \u2013 Anm. d. \u00dcbers.)<\/i>, und wir begannen mit der Arbeit an Helm 2.<\/p>\n<p>Wir wollten die Benutzerfreundlichkeit von Helm bewahren, aber Folgendes hinzuf\u00fcgen:<\/p>\n<ul>\n<li> Chart-Vorlagen zur Anpassung;<\/li>\n<li> interne Clusterverwaltung f\u00fcr Teams;<\/li>\n<li> erstklassiges Chart-Repository;<\/li>\n<li> stabiler Paketformat mit Signaturm\u00f6glichkeiten;<\/li>\n<li> festes Bekenntnis zur semantischen Versionierung und zur Wahrung der Abw\u00e4rtskompatibilit\u00e4t zwischen Versionen.<\/li>\n<\/ul>\n<p>\nUm diese Ziele zu erreichen, wurde der Ecosystem Helm ein zweites Element hinzugef\u00fcgt. Diese interne Cluster-Komponente wurde Tiller genannt und war f\u00fcr die Installation und Verwaltung von Helm-Charts verantwortlich.<\/p>\n<p>Seit der Ver\u00f6ffentlichung von Helm 2 im Jahr 2016 hat Kubernetes mehrere bedeutende Neuerungen erfahren. Es kam zur rollenbasierten Zugriffskontrolle (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/422801\/\">RBAC<\/a><\/noindex>), die schlie\u00dflich die attributbasierte Zugriffskontrolle (ABAC) ersetzte. Neue Ressourcentypen wurden eingef\u00fchrt (Deployments waren zu dieser Zeit noch in der Beta-Phase). Es wurden benutzerdefinierte Ressourcendefinitionen erfunden (zun\u00e4chst als Third Party Resources oder TPRs bezeichnet). Und das Wichtigste: Es entstand ein Satz bew\u00e4hrter Verfahren.<\/p>\n<p>Vor dem Hintergrund all dieser Ver\u00e4nderungen blieb Helm weiterhin den Kubernetes-Nutzern treu. Nach drei Jahren und vielen neuen Erg\u00e4nzungen wurde klar, dass es an der Zeit war, wesentliche \u00c4nderungen an der Codebasis vorzunehmen, damit Helm weiterhin den wachsenden Anforderungen des sich entwickelnden \u00d6kosystems gerecht werden konnte.<\/p>\n<h2>Z\u00e4rtlicher Abschied von Tiller<\/h2>\n<p>\nW\u00e4hrend der Entwicklung von Helm 2 f\u00fchrten wir Tiller als Teil unserer Integration mit dem Deployment Manager von Google ein. Tiller spielte eine wichtige Rolle f\u00fcr Teams, die innerhalb eines gemeinsamen Clusters arbeiteten: Er erm\u00f6glichte es verschiedenen Fachleuten, die Infrastruktur betreuen, mit demselben Set an Releases zu interagieren.<\/p>\n<p>Da die rollenbasierte Zugriffskontrolle (RBAC) standardm\u00e4\u00dfig in Kubernetes 1.6 aktiviert war, wurde die Arbeit mit Tiller in der Produktion komplexer. Aufgrund der Vielzahl m\u00f6glicher Sicherheitsrichtlinien bestand unsere Position darin, standardm\u00e4\u00dfig eine permissive Konfiguration anzubieten. Dies erm\u00f6glichte es Anf\u00e4ngern, mit Helm und Kubernetes zu experimentieren, ohne sich zuerst mit den Sicherheitseinstellungen auseinandersetzen zu m\u00fcssen. Leider konnte diese permissive Konfiguration den Benutzer mit einem zu breiten Spektrum an Berechtigungen ausstatten, die er nicht ben\u00f6tigte. DevOps- und SRE-Ingenieure mussten zus\u00e4tzliche betriebliche Schritte erlernen, um Tiller in einem Multi-Tenant-Cluster zu installieren.<\/p>\n<p>Als wir herausfanden, wie die Mitglieder der Gemeinschaft Helm in konkreten Situationen verwendeten, wurden wir klar, dass das Release-Management-System Tiller nicht auf eine Intra-Cluster-Komponente angewiesen sein musste, um Zust\u00e4nde zu halten oder als zentraler Hub f\u00fcr Informationen \u00fcber Releases zu fungieren. Stattdessen k\u00f6nnten wir einfach Informationen vom Kubernetes-API-Server abrufen, das Chart auf der Client-Seite generieren und die Installationsaufzeichnung in Kubernetes speichern.<\/p>\n<p>Die Hauptaufgabe von Tiller konnte auch ohne Tiller erledigt werden, weshalb eine unserer ersten Entscheidungen bez\u00fcglich Helm 3 der vollst\u00e4ndige Verzicht auf Tiller war.<\/p>\n<p>Mit dem Weggang von Tiller wurde das Sicherheitsmodell von Helm radikal vereinfacht. Helm 3 unterst\u00fctzt nun alle g\u00e4ngigen Sicherheits-, Identifizierungs- und Autorisierungsmechanismen des aktuellen Kubernetes. Die Berechtigungen von Helm werden mithilfe von <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/organize-cluster-access-kubeconfig\/\">die kubeconfig-Datei<\/a><\/noindex>definiert. Cluster-Administratoren k\u00f6nnen die Rechte der Benutzer mit beliebigem Detaillierungsgrad einschr\u00e4nken. Releases bleiben weiterhin innerhalb des Clusters gespeichert, die \u00fcbrigen Funktionen von Helm bleiben erhalten.<\/p>\n<h2>Chart-Repositories<\/h2>\n<p>\nAuf hoher Ebene ist ein Chart-Repository ein Ort, an dem Charts gespeichert und gemeinsam genutzt werden k\u00f6nnen. 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.<\/p>\n<p>Obwohl es einige Vorteile hat, dass die API des Chart-Repositories die grundlegendsten Anforderungen an einen Speicher erf\u00fcllt, hat sie auch einige Nachteile:<\/p>\n<ul>\n<li> Chart-Repositories sind schlecht kompatibel mit den meisten Sicherheitsimplementierungen, die in Produktionsumgebungen erforderlich sind. Das Vorhandensein einer standardisierten API f\u00fcr Authentifizierung und Autorisierung ist in Produktionsszenarien von \u00e4u\u00dferster Wichtigkeit.<\/li>\n<li> Die Helm-Tools zur Verfolgung des Ursprungs von Charts, die zur Signierung, Integrit\u00e4tspr\u00fcfung und Herkunftsverfolgung von Charts verwendet werden, sind ein optionaler Bestandteil des Ver\u00f6ffentlichungsprozesses f\u00fcr Charts.<\/li>\n<li> In Multi-User-Szenarien kann dasselbe Chart von einem anderen Benutzer hochgeladen werden, wodurch sich der f\u00fcr die Speicherung desselben Inhalts erforderliche Platz verdoppelt. Um dieses Problem zu l\u00f6sen, wurden intelligentere Repositories entwickelt, die jedoch nicht Teil der formalen Spezifikation sind.<\/li>\n<li> Die Verwendung einer einzelnen Indexdatei zur Suche, Speicherung von Metadaten und zum Abrufen von Charts hat die Entwicklung sicherer Multi-User-Implementierungen erschwert.<\/li>\n<\/ul>\n<p>\nProjekt <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/docker\/distribution\">Docker Distribution<\/a><\/noindex> (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\u00dfe Cloud-Dienste bieten Produkte basierend auf Distribution an. Durch diese erh\u00f6hte Aufmerksamkeit hat das Projekt Distribution von jahrelangen Verbesserungen, bew\u00e4hrten Sicherheitspraktiken und Tests in Produktionsbedingungen profitiert und sich damit zu einem der erfolgreichsten unbesungenen Helden der Open Source-Welt entwickelt.<\/p>\n<p>Aber wussten Sie, dass das Projekt Distribution zur Verbreitung jeder Art von Inhalten und nicht nur von Container-Images entwickelt wurde?<\/p>\n<p>Dank der Bem\u00fchungen <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opencontainers.org\/\">Open Container Initiative<\/a><\/noindex> (oder OCI) k\u00f6nnen Helm-Charts auf jedem Distribution-Instanz gehostet werden. W\u00e4hrend dieser Prozess experimentellen Charakter hat. Die Arbeit an der Unterst\u00fctzung von Logins und anderen Funktionen, die f\u00fcr ein vollst\u00e4ndiges Helm 3 erforderlich sind, ist noch nicht abgeschlossen, aber wir freuen uns sehr \u00fcber die M\u00f6glichkeit, 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\u00fcgbaren Dienst in gro\u00dfem Ma\u00dfstab zu betreiben.<\/p>\n<p>Eine ausf\u00fchrlichere Beschreibung einiger bevorstehender \u00c4nderungen bei den Helm-Chart-Repositories ist verf\u00fcgbar <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.bacongobbler.com\/post\/2019-01-25-distributing-with-distribution\/\">unter diesem Link<\/a><\/noindex>.<\/p>\n<h2>Release-Management<\/h2>\n<p>\nIn Helm 3 wird der Zustand der Anwendung innerhalb des Clusters durch ein Paar von Objekten verfolgt:<\/p>\n<ul>\n<li> Release-Objekt \u2014 stellt eine Instanz der Anwendung dar;<\/li>\n<li> Release-Version-Secret \u2014 stellt den gew\u00fcnschten Zustand der Anwendung zu einem bestimmten Zeitpunkt dar (z. B. die Ver\u00f6ffentlichung einer neuen Version).<\/li>\n<\/ul>\n<p>\nAufruf <code>helm install<\/code> erstellt das Release-Objekt und das Release-Version-Secret. Aufruf <code>helm upgrade<\/code> ben\u00f6tigt ein Release-Objekt (das es \u00e4ndern kann) und erstellt ein neues Release-Version-Secret, das neue Werte und ein vorbereitete Manifest enth\u00e4lt.<\/p>\n<p>Das Release-Objekt enth\u00e4lt Informationen \u00fcber das Release, wobei ein Release eine spezifische Installation eines benannten Charts und dessen Werte darstellt. Dieses Objekt beschreibt die Metadaten auf oberster Ebene des Releases. Das Release-Objekt wird w\u00e4hrend des gesamten Lebenszyklus der Anwendung gespeichert und ist der Eigent\u00fcmer aller Release-Version-Secrets sowie aller Objekte, die direkt durch das Helm-Chart erstellt werden.<\/p>\n<p>Das Release-Version-Secret verbindet die Ver\u00f6ffentlichung mit einer Reihe von Revisionen (Installation, Updates, Rollbacks, L\u00f6schungen).<\/p>\n<p>In Helm 2 waren Revisionen ausschlie\u00dflich sequenziell. Ein Aufruf <code>helm install<\/code> Erstellte v1, das nachfolgende Upgrade \u2013 v2, und so weiter. Release und Release-Version-Secret wurden zu einem einzigen Objekt zusammengefasst, das als Revision bekannt ist. Revisions wurden im selben Namespace wie Tiller gespeichert, was bedeutete, dass jedes Release in Bezug auf den Namespace \u201eglobal\u201c war; in der Folge konnte nur eine Instanz eines Namens verwendet werden.<\/p>\n<p>In Helm 3 ist jedes Release mit einem oder mehreren Release-Version-Secrets verkn\u00fcpft. Das Release-Objekt beschreibt immer das aktuelle Release, das in Kubernetes bereitgestellt wurde. Jedes Release-Version-Secret beschreibt nur eine Version dieses Releases. Ein Upgrade beispielsweise erstellt ein neues Release-Version-Secret und \u00e4ndert dann das Release-Objekt, um auf diese neue Version zu verweisen. Im Falle eines Rollbacks k\u00f6nnen die vorherigen Release-Version-Secrets verwendet werden, um das Release auf den vorherigen Zustand zur\u00fcckzusetzen.<\/p>\n<p>Nach dem Verzicht auf Tiller speichert Helm 3 die Daten \u00fcber das Release im gleichen Namespace wie das Release. Diese \u00c4nderung erm\u00f6glicht es, ein Chart mit demselben Release-Namen in einen anderen Namespace zu installieren, und die Daten bleiben zwischen Updates\/Neustarts des Clusters in etcd erhalten. Beispielsweise kann WordPress im Namespace \u201efoo\u201c installiert werden, und anschlie\u00dfend im Namespace \u201ebar\u201c, wobei beide Releases \u201ewordpress\u201c genannt werden k\u00f6nnen.<\/p>\n<h2>\u00c4nderungen in den Abh\u00e4ngigkeiten der Charts<\/h2>\n<p>\nCharts, die gepackt wurden (mit Hilfe von <code>helm package<\/code>) zur Verwendung mit Helm 2 kann mit Helm 3 installiert werden, jedoch wurde der Entwicklungsprozess f\u00fcr Charts vollst\u00e4ndig \u00fcberarbeitet, sodass einige \u00c4nderungen erforderlich sind, um die Entwicklung von Charts mit Helm 3 fortzusetzen. Insbesondere hat sich das Abh\u00e4ngigkeitsmanagement der Charts ge\u00e4ndert.<\/p>\n<p>Das Abh\u00e4ngigkeitsmanagement der Charts wechselte von <code>requirements.yaml<\/code> und <code>requirements.lock<\/code> auf <code>Chart.yaml<\/code> und <code>Chart.lock<\/code>. Das bedeutet, dass Charts, die den Befehl <code>helm dependency<\/code>, einige Anpassungen erfordern, um in Helm 3 zu funktionieren.<\/p>\n<p>Lassen Sie uns ein Beispiel betrachten. F\u00fcgen wir eine Abh\u00e4ngigkeit zu einem Chart in Helm 2 hinzu und sehen wir, was sich beim \u00dcbergang zu Helm 3 \u00e4ndert.<\/p>\n<p>In Helm 2 <code>requirements.yaml<\/code> sah es folgenderma\u00dfen aus:<\/p>\n<pre><code class=\"plaintext\">dependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https:\/\/kubernetes-charts.storage.googleapis.com\/\n  condition: mariadb.enabled\n  tags:\n    - database<\/code><\/pre>\n<p>\nIn Helm 3 wird dieselbe Abh\u00e4ngigkeit in Ihrem <code>Chart.yaml<\/code>:<\/p>\n<pre><code class=\"plaintext\">dependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https:\/\/kubernetes-charts.storage.googleapis.com\/\n  condition: mariadb.enabled\n  tags:\n    - database<\/code><\/pre>\n<p>\nCharts weiterhin heruntergeladen und in das Verzeichnis <code>charts\/<\/code>, daher funktionieren die Subcharts <i>(subcharts)<\/i>, die sich im Verzeichnis <code>charts\/<\/code>, befinden, weiterhin unver\u00e4ndert.<\/p>\n<h2>Einf\u00fchrung der Library Charts<\/h2>\n<p>\nHelm 3 unterst\u00fctzt eine Klasse von Charts, die als Bibliothekscharts bezeichnet wird <i>(library chart)<\/i>. Dieses Chart wird von anderen Charts verwendet, selbst erstellt jedoch keine Release-Artefakte. Die Vorlagen der Library-Charts k\u00f6nnen nur Elemente deklarieren <code>definieren<\/code>. Anderer Inhalt wird einfach ignoriert. Dies erlaubt es Benutzern, Code-Schnipsel wiederzuverwenden und auszutauschen, die in vielen Charts verwendet werden k\u00f6nnen, wodurch Duplikate vermieden werden und das Prinzip <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Don%27t_repeat_yourself\">DRY<\/a><\/noindex>.<\/p>\n<p>gewahrt bleibt. Bibliothekscharts werden im Abschnitt <code>dependencies<\/code> in der Datei <code>Chart.yaml<\/code>. Die Installation und Verwaltung dieser Charts unterscheidet sich nicht von anderen Charts.<\/p>\n<pre><code class=\"plaintext\">dependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io<\/code><\/pre>\n<p>\nWir freuen uns auf die Anwendungsm\u00f6glichkeiten, die dieser Bestandteil den Chart-Entwicklern er\u00f6ffnet, sowie auf die besten Praktiken, die durch Bibliothekscharts entstehen k\u00f6nnen.<\/p>\n<h2>Was folgt jetzt?<\/h2>\n<p>\nHelm 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\u00e4tigen.<\/p>\n<p>Sobald die Alpha-Version ver\u00f6ffentlicht wird, <i>denken Sie daran, dass dies <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">bereits geschehen ist<\/a><\/noindex> \u2014 Anm. d. \u00dcbersetzer)<\/i>, wir beginnen, Patches f\u00fcr Helm 3 von der Community anzunehmen. Es ist notwendig, ein stabiles Fundament zu schaffen, das die Entwicklung und Implementierung neuer Funktionen erm\u00f6glicht, und die Benutzer sollen sich in den Prozess einbezogen f\u00fchlen, indem sie Tickets er\u00f6ffnen und Fehlerbehebungen einbringen.<\/p>\n<p>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\u00dfend bezeichnet werden. Der umfassende Plan f\u00fcr 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\u00e4ssigt wurden.<\/p>\n<p>Wenn Sie das Gef\u00fchl haben, dass wir etwas ausgelassen haben, w\u00fcrden wir uns \u00fcber Ihre Gedanken freuen!<\/p>\n<p>Treten Sie der Diskussion in unseren <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.slack.com\/\">Slack-Kan\u00e4len<\/a><\/noindex>:<\/p>\n<ul>\n<li> <code>#helm-users<\/code> f\u00fcr Fragen und einfache Kommunikation mit der Community;<\/li>\n<li> <code>#helm-dev<\/code> f\u00fcr Diskussionen \u00fcber Pull-Requests, Code und Bugs.<\/li>\n<\/ul>\n<p>\nSie k\u00f6nnen auch an unseren w\u00f6chentlichen Public Developer Calls teilnehmen, die donnerstags um 19:30 Uhr MSK stattfinden. Die Treffen sind der Diskussion der Aufgaben gewidmet, an denen Schl\u00fcsselentwickler 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\u00fcgbar. <code>#helm-dev<\/code>.<\/p>\n<h2>P.S. vom \u00dcbersetzer<\/h2>\n<p>\nLesen Sie auch in unserem Blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">Paketmanager f\u00fcr Kubernetes \u2013 Helm: Vergangenheit, Gegenwart, Zukunft<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438814\/\">Ein n\u00fcchterner Blick auf Helm 2: \u201eSo, wie es ist\u2026\u201c<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/420437\/\">Praktische Einf\u00fchrung in den Paketmanager f\u00fcr Kubernetes \u2013 Helm<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/441964\/\">Kubernetes Tipps &amp; Tricks: Migration von Ressourcen im Cluster zu Helm 2<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/336170\/\">Praxis mit dapp. Teil 2. Deployment von Docker-Images in Kubernetes mit Helm<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/453734\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: 16 \u043c\u0430\u044f \u044d\u0442\u043e\u0433\u043e \u0433\u043e\u0434\u0430 \u2014 \u0437\u043d\u0430\u0447\u0438\u043c\u0430\u044f \u0432\u0435\u0445\u0430 \u0432 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0430 \u043f\u0430\u043a\u0435\u0442\u043e\u0432 \u0434\u043b\u044f Kubernetes \u2014 Helm. \u0412 \u044d\u0442\u043e\u0442 \u0434\u0435\u043d\u044c \u0431\u044b\u043b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d \u043f\u0435\u0440\u0432\u044b\u0439 \u0430\u043b\u044c\u0444\u0430-\u0440\u0435\u043b\u0438\u0437 \u0431\u0443\u0434\u0443\u0449\u0435\u0439 \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u2014 3.0. \u0415\u0451 \u0432\u044b\u0445\u043e\u0434 \u043f\u0440\u0438\u043d\u0435\u0441\u0451\u0442 \u0432 Helm \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0435 \u0438 \u0434\u043e\u043b\u0433\u043e\u0436\u0434\u0430\u043d\u043d\u044b\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043d\u043e\u0433\u0438\u0435 \u0432 Kubernetes-\u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0435 \u0432\u043e\u0437\u043b\u0430\u0433\u0430\u044e\u0442 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u043d\u0430\u0434\u0435\u0436\u0434\u044b. \u041a \u0442\u0430\u043a\u043e\u0432\u044b\u043c \u043e\u0442\u043d\u043e\u0441\u0438\u043c\u0441\u044f \u0438 \u043c\u044b \u0441\u0430\u043c\u0438, \u043f\u043e\u0441\u043a\u043e\u043b\u044c\u043a\u0443 \u0430\u043a\u0442\u0438\u0432\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26173,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34735","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 Helm 3 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:00:06+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:06+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Einf\u00fchrung in Helm 3 | ProHoster","description":"z.B.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/znakomstvo-s-helm-3","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 Helm 3 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/znakomstvo-s-helm-3","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:00:06+00:00","article:modified_time":"2019-10-31T19:00:06+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34735","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 20:26:53","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 23:08:04","updated":"2026-01-21 20:26:53","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/34735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=34735"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/34735\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/26173"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=34735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=34735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=34735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}