Überlegen Sie zweimal, bevor Sie Helm verwenden.

Helm ohne Hype. Nüchterner Blick

Helm ist Paketmanager für Kubernetes.

Auf den ersten Blick nicht schlecht. Dieses Tool vereinfacht den Veröffentlichungsprozess erheblich, aber manchmal kann es problematisch sein, dass Sie nichts erledigen können!

Kürzlich wurde Helm offiziell als das Top-Projekt @CloudNativeFdn anerkannt , das von der Community weit verbreitet ist. Das sagt viel aus, aber ich möchte kurz auf die unangenehmen Momente eingehen, die mit diesem Paketmanager verbunden sind.

Was ist der wahre Wert von Helm?

Ich kann diese Frage immer noch nicht mit Zuversicht beantworten. Helm bietet keine Besonderheiten. Welche Vorteile bringt Tiller (Server-Seite)?

Viele Helm-Diagramme sind alles andere als perfekt, und die Verwendung im Kubernetes-Cluster erfordert zusätzlichen Aufwand. Beispielsweise fehlen ihnen RBAC, Ressourcenlimits und Netzwerkrichtlinien. Das Helm-Diagramm einfach in binärer Form zu greifen und zu installieren - ohne darüber nachzudenken, wie es funktionieren wird - funktioniert nicht.

Es reicht nicht aus, Helm mit den einfachsten Beispielen zu loben. Sie werden erklären, warum es so gut ist - insbesondere im Hinblick auf eine sichere mandantenfähige Arbeitsumgebung.

Worte sind leer. Zeig mir den Code!
- Linus Torvalds

Eine zusätzliche Ebene der Autorisierung und Zugriffskontrolle

Ich erinnere mich an jemanden, der Tiller mit einem "riesigen Sudo-Server" verglichen hat. Meiner Meinung nach ist dies nur die nächste Berechtigungsstufe, für die gleichzeitig zusätzliche TLS-Zertifikate erforderlich sind, die jedoch keine Zugriffssteuerungsfunktionen bietet. Warum nicht die Kubernetes-API und das vorhandene Sicherheitsmodell verwenden, das Auditing und RBAC unterstützt?

Ein überbewertetes Tool zur Vorlagenverarbeitung?

Tatsache ist, dass für die Verarbeitung und statische Analyse von Go-Vorlagendateien die Konfiguration aus der Datei values.yaml wird und anschließend das verarbeitete Kubernetes-Manifest mit den entsprechenden in ConfigMap gespeicherten Metadaten verwendet wird.

Und Sie können ein paar einfache Befehle verwenden:

 $ # render go-template files using golang or python script $ kubectl apply --dry-run -f . $ kubectl apply -f . 

Ich habe festgestellt, dass Entwickler normalerweise eine Datei values.yaml pro Umgebung verwendet haben oder diese vor der Verwendung sogar aus values.yaml.tmpl haben.

Dies ist nicht sinnvoll, wenn Sie mit Kubernetes-Geheimnissen arbeiten, die häufig verschlüsselt sind und mehrere Versionen im Repository haben. Um diese Einschränkung zu --set key=value , müssen Sie das Plugin für --set key=value oder den --set key=value . In jedem Fall wird eine weitere Komplexitätsstufe hinzugefügt.

Helm als Tool für das Management des Infrastrukturlebenszyklus

Vergiss es. Dies ist nicht möglich, insbesondere wenn es sich um die Hauptkomponenten von Kubernetes handelt, wie z. B. kube-dns, den CNI-Anbieter, Cluster-Autoscaler usw. Die Lebenszyklen dieser Komponenten variieren und Helm passt nicht in sie.

Meine Erfahrung mit Helm zeigt, dass dieses Tool sich hervorragend für einfache Bereitstellungen auf den Kernressourcen von Kubernetes eignet, die einfach von Grund auf neu implementiert werden können und keinen komplizierten Release-Prozess erfordern.

Leider kann Helm bei komplexeren und häufigeren Bereitstellungen, einschließlich Namespace, RBAC, NetworkPolicy, ResourceQuota und PodSecurityPolicy, nicht damit umgehen.

Ich verstehe, dass Helm-Fans meine Worte vielleicht nicht mögen, aber das ist die Realität.

Staatshelm

Der Tiller-Server speichert Informationen in ConfigMap-Dateien in Kubernetes. Er braucht keine eigene Datenbank.

Leider darf die Größe von ConfigMap aufgrund von etcd-Einschränkungen 1 MB nicht überschreiten.

Hoffentlich hat jemand eine Möglichkeit gefunden, den ConfigMap-Speichertreiber zu verbessern, um die serialisierte Version zu komprimieren, bevor er in den Speicher wechselt. Ich denke jedoch, dass das eigentliche Problem immer noch nicht gelöst werden kann.

Zufällige Abstürze und Fehlerbehandlung

Für mich ist Helms größtes Problem die Unsicherheit.

Fehler: UPGRADE FEHLGESCHLAGEN: "foo" hat keine bereitgestellten Releases

Dies ist meiner Meinung nach eines der nervigsten Probleme von Helm.

Wenn es nicht möglich war, die erste Version zu erstellen, schlägt jeder nachfolgende Versuch mit einem Fehler fehl, der darauf hinweist, dass eine Aktualisierung von einem unbekannten Status unmöglich ist.

Die folgende Anforderung zum Einbeziehen von Änderungen behebt den Fehler durch Hinzufügen des --force , das das Problem nur durch Ausführen des Befehls helm delete & helm install —replace .

In den meisten Fällen müssen Sie die Version jedoch vollständig reinigen.

 helm delete --purge $RELEASE_NAME 

Fehler: Release foo fehlgeschlagen: Zeitüberschreitung beim Warten auf die Bedingung

Wenn ServiceAccount fehlt oder RBAC die Erstellung einer bestimmten Ressource nicht zulässt, gibt Helm die folgende Fehlermeldung zurück:

 Error: release foo failed: timed out waiting for the condition 

Leider kann die Hauptursache für diesen Fehler nicht erkannt werden:

 kubectl -n foo get events --sort-by='{.lastTimestamp}' 

 Error creating: pods "foo-5467744958" is forbidden: error looking up service account foo/foo: serviceaccount "foo" not found 

Aus heiterem Himmel scheitern

In den fortgeschrittensten Fällen gibt Helm einen Fehler aus, ohne überhaupt eine Aktion auszuführen. Beispielsweise werden manchmal keine Ressourcenlimits aktualisiert.

helm init führt die Pinne mit einer Kopie aus, nicht in der HA-Konfiguration

Pinne bedeutet standardmäßig keine hohe Verfügbarkeit, und die Anforderung, Änderungen per Referenz zu aktivieren, ist noch offen.

Eines Tages wird es zu Ausfallzeiten kommen ...

Helm 3? Betreiber? Die Zukunft?

Die nächste Version von Helm wird einige vielversprechende Funktionen hinzufügen:

• Single-Service-Architektur ohne Trennung zwischen Client und Server. Keine Pinne mehr;
• eingebaute Lua Scripting Engine;
• DevOps-Workflow basierend auf Einschlussanforderungen und dem neuen Helm Controller-Projekt.

Weitere Informationen finden Sie unter Helm 3-Projektvorschläge .

Ich mag die Idee der Architektur ohne Tiller sehr, aber die auf Lua basierenden Skripte sind zweifelhaft, weil sie die Diagramme komplizieren können.

Ich habe festgestellt, dass in letzter Zeit Betreiber , die für Kubernetes viel besser geeignet sind als Helm-Charts, an Popularität gewonnen haben.

Ich hoffe wirklich, dass sich die Community bald mit Helmproblemen befasst (natürlich mit unserer Hilfe), aber im Moment werde ich selbst versuchen, dieses Tool so wenig wie möglich zu verwenden.

Verstehen Sie dies: Dieser Artikel ist meine persönliche Meinung, zu der ich beim Erstellen einer Hybrid-Cloud-Plattform für Bereitstellungen auf der Basis von Kubernetes gekommen bin.