Hinweis perev. : Das kürzlich beobachtete verstärkte Interesse am „Kubernetes-Paketmanager“ - Helm ist leicht zu erklären. Das lang erwartete große Update von Helm v3, über das wir bereits geschrieben haben , befindet sich in der aktiven Phase - und zwar nicht nur in Bezug auf die Entwicklung, sondern auch in Bezug auf Veröffentlichungen. Seine letzte Beta, die dritte in Folge , wurde Anfang September veröffentlicht. Und vor kurzem fand eine ziemlich große Veranstaltung (für ein derart spezialisiertes Open Source-Projekt) statt, deren Eindrücke von den Besuchern von CloudARK geteilt werden, das iPaaS (Integrationsplattform als Service) für Kubernetes anbietet.
Originalfoto vom CNCF Flickr-KontoDer Helmgipfel fand letzte Woche in Amsterdam statt. Es brachte etwa 150 Enthusiasten zusammen, die verschiedene Benutzer und Dienstleister auf Kubernetes vertraten. Hier sind fünf wichtige Punkte dieser Veranstaltung.
1. In Helm 3.0 - bessere Sicherheit, CRD-Unterstützung und einige Änderungen, die den üblichen Ansatz brechen
An dem Gipfel nahmen einige der wichtigsten Mitglieder des Kern-Helm-Entwicklungsteams teil. Aus ihren Reden und ihrer Kommunikation am Rande wurde deutlich, dass Helm 3.0 ein wichtiger Meilenstein für das Projekt sein wird. Viele von Ihnen haben wahrscheinlich gehört, dass die dritte Version nicht Tiller enthalten wird - die Helm-Serverkomponente.
( Hinweis : Weitere Informationen hierzu finden Sie in diesem Artikel .) Weitere wichtige Neuerungen werden in Helm 3.0 vorgestellt, z. B. engere Sicherheitskontrollen und eine bessere Unterstützung für benutzerdefinierte Ressourcendefinitionen (CRDs). Hier sind drei Schlüsselaspekte, an die ich mich besonders erinnere:
- Im Sicherheitsbereich sind die vorkonfigurierten Berechtigungen für Benutzer standardmäßig minimal. Im Gegensatz zu Tiller, der automatisch Administratorrechte für den gesamten Cluster erhalten hat, müssen Sie in Helm 3.0 Benutzer- (Benutzer) und Dienstkonten (Dienst) , die für die Arbeit mit Helm entwickelt wurden, manuell Berechtigungen erteilen. Diese Änderung garantiert den Administratoren fundierte Entscheidungen über die Sicherheit ihrer Cluster.
- Die zweite wichtige Änderung ist die verbesserte CRD-Unterstützung. In der aktuellen Version von Helm wird CRD über den als Anmerkung definierten
crd-install Hook crd-install . Es wird jedoch nicht von allen CRD-Entwicklern und -Betreibern verwendet. Dies macht die Helm-Diagramme anfällig für Installationsfehler, da für die korrekte Einstellung der Diagramme CRDs vor benutzerdefinierten Ressourcenmanifesten platziert werden müssen. Helm 3.0 wird die CRD-Unterstützung auf ein neues Niveau bringen. Das Unterverzeichnis chrts wird im crd chrts . Es reicht aus, wenn der Benutzer alle CRD YAML-Dateien zu diesem Verzeichnis hinzufügt. Helm verarbeitet es, bevor der Rest des Diagramms festgelegt wird. Durch dieses Verfahren wird sichergestellt, dass CRD installiert ist, bevor benutzerdefinierte Ressourcenmanifeste installiert werden. - Wesentliche Änderungen wirken sich auf die Arbeit mit der CLI aus. Beispielsweise wird jetzt während der Installation des Diagramms ein zufälliger Versionsname generiert, wenn dieser nicht als Eingabeparameter angegeben wird. In Helm 3.0 ist die Situation umgekehrt: Ein Parameter mit einem Namen wird obligatorisch. Um die zufällige Benennung von Releases beizubehalten, müssen Sie bei der Eingabe des Befehls ein spezielles Flag angeben.
2. Konsolidierung von Cloud-nativen Artefakten
In mehreren Sitzungen wurden die Probleme beim Speichern von Helmkarten behandelt. Diese Sitzungen wurden von
Josh Dolitsky , Autor des
ChartMuseums, geleitet . Er stellte das Problem und die vorhandenen Lösungen vor und sprach über die allgemeinen Trends in diesem Bereich. Die Hauptschlussfolgerung ist, dass die Arbeit mit verschiedenen Artefakten, die im Cloud-nativen Ansatz behandelt werden müssen (Docker-Bilder, Helmdiagramme, Kustomize-Patch-Dateien), auf die gleiche Weise erfolgen sollte.
Das
ORAS- Projekt - OCI-Registrierung als Speicher ist
erforderlich , um die Speicherung all dieser Artefakte in einer einzigen Registrierung sicherzustellen. Für Kubernetes-Benutzer ist dies definitiv ein Schritt in die richtige Richtung, da Sie damit verschiedene Artefakte in einer Registrierung konsolidieren und gleichzeitig Dinge wie die Partitionierung der Registrierung, die Zugriffskontrolle usw. unterstützen können.
3. Helm und Bediener
Mehrere Redner haben sich in ihren Reden mit dem Thema Benutzersteuerungen und Bediener befasst.
Die Präsentation von CloudARK konzentrierte sich auf Best Practices für die Erstellung von
Helmdiagrammen für Bediener.
Das Red Hat-Team sprach über Operatoren und den
Operator Hub .
Vertreter von
Workday ,
Weaveworks und der
University of Notre Dame diskutierten den Kubernetes-nativen Ansatz, um Helm-basierte Releases in einem Cluster mithilfe eines Prozesses namens GitOps kontinuierlich auszuhandeln.
( Hinweis übersetzen : Lesen Sie hier mehr über GitOps.)Die wichtigste Schlussfolgerung all dieser Leistungen war, dass sich Helm und die Betreiber gut ergänzen. Während sich der erstere (Helm) auf die Vorlage und Einfachheit der Verwaltung von Artefakten konzentriert, konzentrieren sich die letzteren (Bediener) auf die Verwaltung von Aufgaben des zweiten Tages
(d. H. In der Phase des Lebenszyklus des Systems, in der es anfängt, Früchte für seine Schöpfer zu tragen - ca. ) für Software von Drittanbietern wie relationale / nicht relationale Datenbanken, die in einem Kubernetes-Cluster ausgeführt werden.
4. Probleme bei der Verwaltung von Helmdiagrammen
Bei großen Unternehmensanwendungen reicht ein Helm-Diagramm nicht aus. Einige Diagramme sind erforderlich.
Die Präsentation von GitLab war in diesem Sinne eine echte Entdeckung. Sie haben viele Diagramme, während die durchschnittliche Größe des Diagramms auch ziemlich groß ist (mehrere tausend Zeilen). Das Verwalten all dieser Diagramme ist an sich keine leichte Aufgabe.
Es gab zwei interessante Präsentationen zu verschiedenen Aspekten dieses Problems. In einem
Fall stellte
das IBM-Team sein internes Tool vor, das die Suche nach Helm-Diagrammen nach verschiedenen Kriterien vereinfacht. Sie konzentrierten sich auf die Lösung des Problems der DevOps-Ingenieure, die gezwungen waren, Diagramme in ihren Clustern auszuwählen und zu installieren. In einem anderen
Fall sprach
das Replizierte Team über den Versuch, das Problem der Verwaltung von Helmdiagrammbearbeitungen zu lösen, ohne Kopien oder Gabeln zu erstellen. Der Kern ihres Ansatzes besteht darin, das grundlegende Helmdiagramm zu trennen und benutzerdefinierte Helmdiagramme zu erstellen, indem die Idee der Anpassung aus Patch-Dateien übernommen wird. In Zukunft können wir eine rasche Aktivität in diese Richtung beobachten, da sich verschiedene Anbieter auf verschiedene Aspekte der Helm-Diagramme konzentrieren, die ihr Management beeinflussen. Beispielsweise konzentrieren wir uns bei CloudARK auf Helmdiagramme für Bediener, die spezielle
platform-as-code Anmerkungen erhalten, um das Auffinden und die Verwendung benutzerdefinierter Ressourcen zu vereinfachen.
5. Gastfreundliche Gemeinschaft
Helmentwickler und wichtige Mitglieder der Community erwiesen sich als sehr freundliche Menschen. Sie waren offen und für Diskussionen und Fragen wie Veröffentlichungstermine, Gedanken zu Helm und kustomize, gemeinsame Veranstaltungen mit KubeCon usw. verfügbar.
Sie sprachen auch über den Prozess der Teilnahme an der Entwicklung von Helm. Er schien nicht zu kompliziert zu sein. Das Helm-Projekt hat den KEP-Prozess (Kubernetes Enhancement Proposal) noch nicht übernommen. Dies kann sich jedoch nach Abschluss der Inkubationsphase ändern.
CloudARK beim Helm Summit
Unsere Präsentation auf dem Gipfel war den Prinzipien und Best Practices der Erstellung von Helmdiagrammen für Bediener gewidmet. Wir bieten iPaaS an, mit dem DevOps-Teams ihre eigenen Kubernetes-Plattformstacks erstellen können, ohne eine Verbindung zum Kubernetes-Anbieter oder zu proprietären Schnittstellen herzustellen. Die erforderlichen CRD / Operatoren sind in Form von Helmdiagrammen verpackt, wobei der Schwerpunkt auf der Kompatibilität der benutzerdefinierten Ressourcen verschiedener Operatoren liegt.
Die Präsentation basierte auf Lehren aus der unabhängigen Entwicklung mehrerer Betreiber und der Analyse von mehr als hundert öffentlich verfügbaren Betreibern, um eine benutzerdefinierte Kubernetes Native-Plattformschicht für den Unternehmensgebrauch bereitzustellen.
Amsterdam
Der Konferenzort bietet einen malerischen Blick auf einen der vielen Amsterdamer Kanäle.
Fazit
Helm steht kurz davor, ein CNCF-Spitzenprojekt zu werden. In den letzten Jahren ist er reifer geworden, hat eine starke Gemeinschaft und hohe Popularität gewonnen. Wenn Sie es noch nicht verwenden, probieren Sie es aus. Es bietet eine der einfachsten Möglichkeiten zum Erstellen und Verwalten von Kubernetes-Artefakten. Für diejenigen, die es bereits stark nutzen, sollte Helm 3.0 viele Sicherheitsbedenken zerstreuen und die Erweiterbarkeit von Kubernetes durch CRD explizit unterstützen.
PS vom Übersetzer
Weitere Eindrücke des vergangenen Helm Summit und seiner Berichte finden Sie auf Twitter unter dem Tag
#HelmSummit .
Lesen Sie auch in unserem Blog: