Helm gegen Kapitan gegen Kustomize

TLDR;

  • Kapitan (und vermutlich Ksonnet) ist das flexiblere und anpassbarere (json und jsonnet)
  • Passen Sie die Einstellungen an, wenn dies einfacher ist. Sie wurden soeben veröffentlicht, sodass wir etwas mehr Dokumentation zu den integrierten Funktionen benötigen (nur Yaml).
  • Helm kombiniert einen Paketansatz und ein leistungsstarkes Release-Management mit den Einschränkungen von Tiller für den Release-Management-Teil (zusätzliche Quelle der Wahrheit).

UPDATE: Guter Artikel zum Umgang mit Komplexität von Matt Farina https://codeengineered.com/blog/2018/helm-kustomize-complexity/

Überblick

Während der Implementierung von https://www.weyv.com-Umgebungen in Kubernetes haben wir verschiedene Phasen durchlaufen. Von einfachen Yaml-Dateien über Helm-Charts-Releases bis hin zu Helm-Charts mit Helm-Template-Ausgabe. Jetzt, mit der Ankündigung von Kustomize, nutze ich die Gelegenheit, um unsere Werkzeugauswahl im Vergleich zu unseren Anforderungen mit drei Konkurrenten neu zu bewerten: Helm, Kapitan, Kustomize. Ich habe Ksonnet weggelassen (https://github.com/ksonnet/ksonnet), es scheint Kapitan sehr nahe zu sein.

Helm: https://github.com/kubernetes/helm

Kapitan: https://github.com/deepmind/kapitan

Anpassen: https://github.com/kubernetes-sigs/kustomize

Bedarf

Wir benötigen ein Tool zur Verwaltung unserer Kubernetes-Ressourcen, mit dem ut:

  • Geben Sie Ressourcen an
  • Wiederverwenden und erneutes Kombinieren über die Ressourcenspezifikationen hinweg
  • Versionskontrolle den gewünschten Zustand der Ressourcen

Helm

Geben Sie Ressourcen an

  • Satz von Ressourcen: Diagramm
  • Definitionen: Vorlagendateien, Go-Vorlagensyntax
  • Variablen: Standardwerte pro Diagramm, Werte überschreiben, Werte formatieren

Vorteile: Yaml-Vorlagen befinden sich in der Nähe der Yaml-Ausgabe, die an Kubernetes gesendet wird

Nachteile: Keine Wiederverwendung von Vorlagen in einem Diagramm, keine benutzerdefinierten Klassendefinitionen

Wiederverwenden und neu kombinieren

  • Diagramm kann auf andere Diagramme verweisen und diese verwenden
  • Sub-Chart-Variablen können überschrieben werden

Versionskontrolle

  • Die Standardverwendung ist das "Helm-Release", und Tiller (serverseitig in Kubernetes) verwaltet die für den Cluster bereitgestellten Versionen
  • Das Ergebnis einer „Steuerstandvorlage“ kann jedoch in der Versionskontrolle überprüft werden

Vorteile: Tiller kann das Rollback von Releases verwalten

Nachteile: Abweichungen zwischen den versionskontrollierten Ressourcen (gewünschter Status) und der Version, die Tiller kontrolliert und verwaltet. Dies führte bei uns mehrmals zu Problemen, wenn der Status einer Ressource direkt ohne Verwendung von Helm geändert wurde, und zwang uns, zur „Helm-Vorlage“ zu wechseln.

Kapitan

Geben Sie Ressourcen an

  • Reihe von Ressourcen: Komponente
  • Definitionen: jsonnet templates, json
  • Variablen: Hierarchische Datenbank von Variablen (Bestandsklassen und Ziele)

Vorteile: Mit jsonnet können Klassen, Vererbungen und hierarchische Datenbanken von Variablen mit zwei Ebenen erstellt werden: eine zur Wiederverwendung und eine zielspezifische.

Nachteile: json sieht nicht wie das generierte yaml aus, json ist etwas ausführlicher zu tippen

Wiederverwenden und neu kombinieren

  • Alles kann wiederverwendet und neu kombiniert werden

Versionskontrolle

  • Das Ergebnis eines Builds kann in der Versionskontrolle überprüft werden

Anpassen

Geben Sie Ressourcen an

  • Set von Ressourcen: Basis
  • Definitionen: einfache Yaml-Dateien
  • Variablen: Die Eigenschaftendatei kann zum Generieren von configMap (configMapGenerator) verwendet werden.

Vorteile: Alles ist Yam. eingang und ausgang sehen aus wie kubernetes ready yaml

Wiederverwenden und neu kombinieren

  • Standardmäßig wiederverwenden, Ressourcen in Überlagerungsordnern patchen
  • Mit der Deklaration in kustomization.yaml einfach neu kombinieren

Versionskontrolle

  • Das Ergebnis eines Builds kann in der Versionskontrolle überprüft werden

Fazit

In unserer aktuellen Situation kann ein Wechsel von der „Steuerschablone“ zum Anpassen sinnvoll sein und nur begrenzte Investitionen erfordern. Es ist sinnvoll, nur Vorlagenfunktionen zu verwenden, aber es scheint übertrieben, da wir nicht einmal Pakete aus anderen Quellen importieren.

UPDATE: Wir sind bei Helm geblieben und haben Wertedateivorlagen verwendet, um Wertedateien zu generieren und Helmvorlagen zu füttern, um unsere Manifeste zu generieren.

Ein Wechsel zu Kapitan würde uns mehr Kraft und Flexibilität verleihen, würde jedoch ein umfassendes Umschreiben unserer Steuervorlagen auf jsonnet erfordern.

Was ist Ihre Rückkehr der Erfahrung?

Feedback immer erwünscht