1. Foren
  2. Kommentare
  3. Applikationen-Forum
  4. Alle Kommentare zum Artikel
  5. › Kubernetes-Kontrollcenter…

Helm? Kustomize?

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. Helm? Kustomize?

    Autor: WolfspiritM 23.05.22 - 09:14

    Also ich sehe, dass das ganze via ytt ggf. flexibler ist als via helm oder kustomize aber das in dem ganzen Beitrag kein einziges mal helm oder kustomize als meistgenutzte (helm) sowie native (kustomize) implementierung erwähnt wird finde ich doch ein bisschen schade.

    Ein vergleich wäre nicht schlecht gewesen



    1 mal bearbeitet, zuletzt am 23.05.22 09:14 durch WolfspiritM.

  2. Re: Helm? Kustomize?

    Autor: massenhaft 23.05.22 - 10:43

    Wir fahren zweigleisig:
    - Helm, weil es einfach sehr viel fertig gibt.
    - Jsonnet (+Tanka) mit dem Gitlab-Kubernetes-Agent, weil es sehr flexibel ist und wir auf CI-Daten zurückgreifen können.

  3. Re: Helm? Kustomize?

    Autor: Doubleslash 23.05.22 - 11:22

    Habe mich das beim Lesen ebenfalls gefragt. YTT sieht deutlicher komplexer aus und der Code im GitHub erscheint mir nicht sonderlich intuitiv. Ich sehe dass YTT durchaus mächtiger ist (templating + variables statt nur overlays), aber man hätte die Beispiele sicherlich auch mit kustomize umsetzen können und sich damit die Abhängigkeit zu einem Projekt gespart, das eigentlich ausschliesslich von einem einzigen Hersteller (VMware) gepflegt wird und zu dem es praktisch keinerlei Community gibt.

    Mit kustomize haette man dagegen ein von der CNCF gepflegtes, direkt in kubectl integriertes und weit verbreitetes Projekt gehabt, das wahrscheinlich am Ende genau das gleiche kann fuer den Use Case hier.
    Es sei denn dem ist fuer das genannte Beispiel nicht so, das haette ich als Leser gerne erfahren. Ansonsten scheint mir die Anbindung an eine GitOps Pipeline unnoetig kompliziert, Projekte wie ArgoCD or FluxCD verstehe kustomize nativ, fuer YTT muesste man da wieder extra Code schreiben. Wahrscheinlich setzt das Unternehmen des Authors einfach auf VMware Tanzu.

  4. Re: Helm? Kustomize?

    Autor: kayozz 23.05.22 - 13:46

    Doubleslash schrieb:
    --------------------------------------------------------------------------------
    > Mit kustomize haette man dagegen ein von der CNCF gepflegtes, direkt in
    > kubectl integriertes und weit verbreitetes Projekt gehabt, das
    > wahrscheinlich am Ende genau das gleiche kann fuer den Use Case hier.

    Ich denke der Benefit ist, dass das Produkt nicht auf kubernetes festgelegt ist, sondern im Prinzip überall dort funktioniert, wo markup verwendet wird.

    Ich kannte das tool nicht und mir sind spontan schon ein paar use cases dafür eingefallen.

    In Hinblick auf kubernetes sehe ich den Vorteil, das man die yaml-config Erzeugung vorab in seinem repo ausführen kann und ggf. direkt die Auswirkungen von Änderungen sieht.

    Mir gefällt die Kommentarbasierte Syntax aber nicht. Wenn man nicht den Anspruch hätte, dass die templates an sich gültiges yaml erzeugen, wäre das ganze bestimmt lesbarer, wenn auch mit mehr Code verbunden.

    als statt so

    > kind: Pod
    > apiVersion: v1
    > metadata:
    > name: echo-app
    > labels: #@ labels()

    eher so

    > kind: Pod
    > apiVersion: v1
    > metadata:
    > name: echo-app
    > @if labels.any
    > labels:
    > @foreach label in labels
    > @label.key: @label.value
    > @endif

  5. Re: Helm? Kustomize?

    Autor: Jochen R. Meyer 24.05.22 - 09:53

    Interessante Fragen und Anregungen auf die ich (als Autor) gerne eingehe. :-)

    Helm, Kustomize und Tanka standen damals bei uns auch zur Auswahl. Aber keins der Tools konnte unseren Ansprüchen mit vertretbarem Aufwand genügen.
    Einen Vergleich habe ich bei meinem Artikel mit Absicht weggelassen da ich mich darauf fokussieren wollte was man mit ytt erreichen kann, was seine Stärken sind und wo/wie man davon profitieren kann. Es ging mir darum zu zeigen was mit ytt möglich ist. Wenn man diese Möglichkeiten nicht braucht, ist Kustomize ja auch vollkommen OK. Ich sage ja nicht dass ytt die "einzig wahre Lösung" ist.

    Die Syntax muss man in der Tat nicht mögen. Auch ich bin da nicht so angetan. Doch die sich bietenden Möglichkeiten lassen diese "Befindlichkeiten" für mich schnell verblassen. :-)



    1 mal bearbeitet, zuletzt am 24.05.22 09:54 durch Jochen R. Meyer.

  6. Re: Helm? Kustomize?

    Autor: Jochen R. Meyer 24.05.22 - 10:09

    Doubleslash schrieb:
    --------------------------------------------------------------------------------
    > Habe mich das beim Lesen ebenfalls gefragt. YTT sieht deutlicher komplexer
    > aus und der Code im GitHub erscheint mir nicht sonderlich intuitiv. Ich
    > sehe dass YTT durchaus mächtiger ist (templating + variables statt nur
    > overlays), aber man hätte die Beispiele sicherlich auch mit kustomize
    > umsetzen können ...
    Stimmt. Ich behaupte aber mal dass der Aufwand deutlich höher wäre. Wir haben unsere Versuche mit Kustomize damals nach einem Tag abgebrochen weil der Aufwand um ein vielfaches höher war als mit ytt. Ich war damals übrigens pro-Kustomize. :-)

    > Mit kustomize haette man dagegen ein von der CNCF gepflegtes, direkt in
    > kubectl integriertes und weit verbreitetes Projekt gehabt, das
    > wahrscheinlich am Ende genau das gleiche kann fuer den Use Case hier.
    > Es sei denn dem ist fuer das genannte Beispiel nicht so, das haette ich als
    > Leser gerne erfahren.
    Der Artikel befasst sich mit den Möglichkeiten von ytt, nicht mit dem exakten Use-Case. Ich hatte gedacht dass das im Artikel klar wird.

    > Ansonsten scheint mir die Anbindung an eine GitOps
    > Pipeline unnoetig kompliziert, Projekte wie ArgoCD or FluxCD verstehe
    > kustomize nativ, fuer YTT muesste man da wieder extra Code schreiben.
    Das sehe ich so nicht. Da wir mit den "finalen" YAML-Dateien arbeiten (wollen) müssen wir nur eine Reihe von Dateien im Kubernetes anwenden. Zu dem Zeitpunkt ist ytt fertig und hat dadurch mit ArgCO/FluxCD keine Berührungspunkte.

    > Wahrscheinlich setzt das Unternehmen des Authors einfach auf VMware Tanzu.
    Nein, VMware Tanzu setzen wir nicht ein.

  7. Re: Helm? Kustomize?

    Autor: Jochen R. Meyer 24.05.22 - 10:18

    kayozz schrieb:
    --------------------------------------------------------------------------------
    > Ich kannte das tool nicht und mir sind spontan schon ein paar use cases
    > dafür eingefallen.
    Das war eins meiner Ziele! :-)


    > In Hinblick auf kubernetes sehe ich den Vorteil, das man die yaml-config
    > Erzeugung vorab in seinem repo ausführen kann und ggf. direkt die
    > Auswirkungen von Änderungen sieht.
    Genau das ist einer der Vorteile. Das "git diff" sagt Dir was sich ändert. Bevor irgendwas angewendet wird.

    > Mir gefällt die Kommentarbasierte Syntax aber nicht.
    Kann ich verstehen. Das ytt-Plugin für VSCode ist da sehr hilfreich und stellt die Syntax dann (etwas) besser dar. Eine gewisse Gewöhnungszeit muss man in der Tat in Kauf nehmen.
    Der ytt-Playground ist da auch sehr hilfreich.

  8. Re: Helm? Kustomize?

    Autor: Doubleslash 24.05.22 - 10:26

    Jochen R. Meyer schrieb:
    --------------------------------------------------------------------------------
    > Stimmt. Ich behaupte aber mal dass der Aufwand deutlich höher wäre. Wir
    > haben unsere Versuche mit Kustomize damals nach einem Tag abgebrochen weil
    > der Aufwand um ein vielfaches höher war als mit ytt. Ich war damals
    > übrigens pro-Kustomize. :-)

    Wann war denn damals? Habt ihr es euch seit dem mal wieder angesehen? Welche Kriterien haben bei euch den Ausschlag gegeben?

    > Der Artikel befasst sich mit den Möglichkeiten von ytt, nicht mit dem
    > exakten Use-Case. Ich hatte gedacht dass das im Artikel klar wird.

    Klar wird es schon, aber YTT ist ein ziemlich grosser Hammer um ein einfaches Beispiel zu illustrieren. Von daher wäre es interessant gewesen zu wissen, warum es gerade hier einen Vorteil gegenüber reinen Overlay oder reinen Templating-Ansätzen hat. Wenn man sich die Zielgruppe des Artikels anschaut, dürfte wahrscheinlich die Mehrheit bereits mit mindestens Helm und teilweise auch kustomize vertraut sein.

    > > Ansonsten scheint mir die Anbindung an eine GitOps
    > > Pipeline unnoetig kompliziert, Projekte wie ArgoCD or FluxCD verstehe
    > > kustomize nativ, fuer YTT muesste man da wieder extra Code schreiben.
    > Das sehe ich so nicht. Da wir mit den "finalen" YAML-Dateien arbeiten
    > (wollen) müssen wir nur eine Reihe von Dateien im Kubernetes anwenden. Zu
    > dem Zeitpunkt ist ytt fertig und hat dadurch mit ArgCO/FluxCD keine
    > Berührungspunkte.

    D.h. euer Flow startet nicht mit einem Commit sondern mit einem ytt rendering? Wie habt ihr das verknüpft, so dass sowohl die Revisionshistorie der YTT templates als auch die des resultierenden YAML erhalten bleiben?
    Normalerweise sieht ein GitOps-Flow ja oft so aus: helm/kustomize/YAML wird als PR/MR in ein Repo geschickt, von dort aus laufen Tests auf Staging, bei Erfolg wird der PR gemerged. Das "apply" wird client-seitig direkt in der GitOps-Loesung, bspw. ArgoCD, ausgeführt, in git selbst bleibt einfach nur der Helm Chart mit den Werten bzw. die Kustomize Bases und Overlays, gerendert wird durch ArgoCD / Flux selbst als Teil der Synchronisation. So gesehen gibt es die "finalen YAML-Dateien" in dem Sinne nicht, die Manifeste sind immutable und existieren sich ausschliesslich zur Laufzeit auf den Clustern als Ergebnis des GitOps-Flows.
    Ein sehr robustes und leicht zu debuggendes Model. Wie sieht das bei euch aus?

  9. Re: Helm? Kustomize?

    Autor: WolfspiritM 24.05.22 - 11:00

    >> In Hinblick auf kubernetes sehe ich den Vorteil, das man die yaml-config
    >> Erzeugung vorab in seinem repo ausführen kann und ggf. direkt die
    >> Auswirkungen von Änderungen sieht.
    > Genau das ist einer der Vorteile. Das "git diff" sagt Dir was sich ändert. Bevor irgendwas
    > angewendet wird.
    Im Vergleich zu was ist das den ein Vorteil? Sowohl bei kustomize als auch bei helm lässt sich das "Ergebnis" auch einfach ausgeben und theoretisch in eine Datei speichern die man dann einchecken und ausführen kann. Helm bietet sogar ein plugin "helm diff" was einem genau die änderungen aufzeigt zu dem was im cluster deployed ist. Aber das ist genau der Punkt den ich machen wollte. Ich finde es gut neue Sichtweisen und Tools aufzuzeigen und das macht der Artikel auch. Ich kannte ytt auch nicht und werde es mir definitiv mal ansehen. Ich denke es wäre jedoch sinnvoll gewesen hier vergleiche zu ähnlichen Produkten zu ziehen ;-) Ich verstehe nach dem Artikel zwar wie es geht aber nicht warum ich das so machen sollte anstelle "altbekannte" tools zu verwenden.

  10. Re: Helm? Kustomize?

    Autor: Jochen R. Meyer 24.05.22 - 13:51

    WolfspiritM schrieb:
    --------------------------------------------------------------------------------
    > Im Vergleich zu was ist das den ein Vorteil? Sowohl bei kustomize als auch
    > bei helm lässt sich das "Ergebnis" auch einfach ausgeben und theoretisch in
    > eine Datei speichern die man dann einchecken und ausführen kann.
    Guter Punkt. In dem Fall ist das dann kein "Vorteil".

    > Helm bietet sogar ein plugin "helm diff" was einem genau die änderungen aufzeigt
    > zu dem was im cluster deployed ist. Aber das ist genau der Punkt den ich
    > machen wollte. Ich finde es gut neue Sichtweisen und Tools aufzuzeigen und
    > das macht der Artikel auch. Ich kannte ytt auch nicht und werde es mir
    > definitiv mal ansehen. Ich denke es wäre jedoch sinnvoll gewesen hier
    > vergleiche zu ähnlichen Produkten zu ziehen ;-) Ich verstehe nach dem
    > Artikel zwar wie es geht aber nicht warum ich das so machen sollte anstelle
    > "altbekannte" tools zu verwenden.
    Dann hast Du vielleicht keinen Bedarf ytt einzusetzen.
    Wir haben viele Deployments die sehr ähnlich aussehen. Mal heißen ein paar Properties anders, mal gibt es einen Volume-Mount, mal eine DB-Verbindung, ... Wir wollten nun keine YAML-Dateien für alle Kombinationen schreiben die man dann mit Werten füllt. Wir haben eine Funktion geschrieben die anhand von Parametern das fertige YAML ausspuckt (inkl. dem Anwenden von Konfigurationswerten).

  11. Re: Helm? Kustomize?

    Autor: Jochen R. Meyer 24.05.22 - 13:54

    Doubleslash schrieb:
    --------------------------------------------------------------------------------
    > Wann war denn damals?
    Damals war Mitte 2020 - sorry, hatte ich dazu schreiben sollen.
    > Habt ihr es euch seit dem mal wieder angesehen?
    Nein. Ich sehe da auch kein Weg "zurück"
    > Welche Kriterien haben bei euch den Ausschlag gegeben?
    Wir brauchten/wollten Overlays (einfache für Variablen, komplexere für YAML-Fragmente) und wiederverwendbare Funktionen (mit Parametern) die YAML-Fragmente erzeugen.

    > Klar wird es schon, aber YTT ist ein ziemlich grosser Hammer um ein
    > einfaches Beispiel zu illustrieren.
    Das Beispiel ist ja synthetisch und wurde so "designed" dass man einige Vorzüge von ytt erkennen kann. Außerdem wurde es klein gehalten um nicht den Rahmen zu sprengen. Es soll das Potential aufzeigen, die Phantasie anregen und gleichzeitig eine mini-Referenz für einen ersten Schritt mit ytt sein.

    > Von daher wäre es interessant gewesen
    > zu wissen, warum es gerade hier einen Vorteil gegenüber reinen Overlay oder
    > reinen Templating-Ansätzen hat.
    Man kann beides kombinieren.

    > Wenn man sich die Zielgruppe des Artikels
    > anschaut, dürfte wahrscheinlich die Mehrheit bereits mit mindestens Helm
    > und teilweise auch kustomize vertraut sein.
    Genau auf diese "Vertrautheit" hatte ich gesetzt. Denn dann kann jeder selbst entscheiden ob die Nutzung von ytt einen Versuch wert ist.

    > D.h. euer Flow startet nicht mit einem Commit sondern mit einem ytt
    > rendering?
    Ja.

    > Wie habt ihr das verknüpft, so dass sowohl die Revisionshistorie
    > der YTT templates als auch die des resultierenden YAML erhalten bleiben?
    Mit Git. Da ist beides drin. Wichtig für die Revision ist für uns aber nur das resultierende, "generierte" YAML.

    > Normalerweise sieht ein GitOps-Flow ja oft so aus:
    Was ist heute schon "normal". :-) Ich bin kein Freund von "man macht das so". Meiner Erfahrung nach sorgt das nur für Probleme. Man muss sich die Anforderungen anschauen und zu guten Lösungen kommen. Im Idealfall ist das das gleich einem Standard, oder nah dran.

    > die Manifeste sind immutable und existieren sich ausschliesslich zur Laufzeit
    > auf den Clustern als Ergebnis des GitOps-Flows.
    > Ein sehr robustes und leicht zu debuggendes Model. Wie sieht das bei euch
    > aus?
    Das "apply" passiert bei uns mit den "finalen YAML-Dateien". Dadurch sieht jeder Entwickler auch direkt was im Cluster läuft und wie die Konfig aussieht - mit einem Blick ins Repo.

    > Das "apply" wird client-seitig direkt in der
    > GitOps-Loesung, bspw ArgoCD, ausgeführt, in git selbst bleibt einfach nur
    > der Helm Chart mit den Werten bzw. die Kustomize Bases und Overlays,
    > gerendert wird durch ArgoCD / Flux selbst als Teil der Synchronisation. So
    > gesehen gibt es die "finalen YAML-Dateien" in dem Sinne nicht,
    Genau das ist bei uns anders. Wir wollen und müssen die "finalen YAML-Dateien" erstellen und historisieren. Wir können also immer exakt sehen was wann im Cluster lief - und das soll / muss so sein.



    4 mal bearbeitet, zuletzt am 24.05.22 14:01 durch Jochen R. Meyer.

  12. Re: Helm? Kustomize?

    Autor: WolfspiritM 25.05.22 - 10:46

    Jochen R. Meyer schrieb:
    --------------------------------------------------------------------------------
    > Dann hast Du vielleicht keinen Bedarf ytt einzusetzen.
    > Wir haben viele Deployments die sehr ähnlich aussehen. Mal heißen ein paar
    > Properties anders, mal gibt es einen Volume-Mount, mal eine DB-Verbindung,
    > ... Wir wollten nun keine YAML-Dateien für alle Kombinationen schreiben die
    > man dann mit Werten füllt.

    Das haben wir in unserem Fall auch. Wir nutzen dafür helm und haben in unserer values.yaml die einzelnen services eingetragen.

    services:
    service1:
    enabled: true
    connections:
    - sql
    - redis
    service2:
    enabled: true
    connections:
    - eventhub

    Unser helm deployment template für alle microservices macht dann ein range über diese Services und generiert das yaml daraus ;-)

    Aber ja ich sehe, dass ytt da vermutlich flexibler ist :-)

  13. Re: Helm? Kustomize?

    Autor: Jochen R. Meyer 25.05.22 - 15:30

    > Unser helm deployment template für alle microservices macht dann ein range über diese
    > Services und generiert das yaml daraus ;-)
    Ich verstehe. Das Prinzip ist in der Tat ähnlich.

    > Aber ja ich sehe, dass ytt da vermutlich flexibler ist :-)
    Solange Ihr mit Helm zurecht kommt, ist ja auch alles gut.
    Der Artikel sagt ja nicht dass ytt immer besser ist als alles andere, sondern beschreibt einen Weg des YAML-Templatings und seine Vorteile. Er soll im Idealfall anderen als Inspiration dienen - ohne Vergleiche und Pro/Contra Listen - genau deswegen sind auch keine Vergleiche drin.

    Für mich persönlich ist Helm aber keine Alternative zu ytt da es mir zu statisch und sperrig ist. Jedes Mal wenn ich ein Helm-Chart checke/anpasse bin ich froh dass unser eigenes Templating nicht auf Helm basiert. Aber wie gesagt: dass ist meine persönliche Erfahrung. Es gibt bestimmt viele die das anders sehen. :-)

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Softwareintegrator / Systemintegrator C# & .NET Maschinenbau (m/w/d)
    Packsize GmbH, Herford, Bielefeld, Gütersloh, Paderborn, Lippstadt
  2. Koordinator Informationssicherheit und Managementsysteme (m/w/d)
    RheinEnergie AG, Köln
  3. Wissenschaftliche Mitarbeiterin / Wissenschaftlicher Mitarbeiter (m/w/d)
    Bundesanstalt für Straßenwesen, Bergisch Gladbach
  4. IT Business Analyst (m/w/d)
    MLP Finanzberatung SE, Wiesloch bei Heidelberg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. ab 69,99€ (inkl. digitaler Bonusinhalte + Lanyard im God of War-Design)
  2. 8,49€ (UVP 89€)
  3. (stündlich aktualisiert)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Einsparverordnungen: So sollen Verwaltung, Bürger und Firmen Energie sparen
Einsparverordnungen
So sollen Verwaltung, Bürger und Firmen Energie sparen

Reduzierte Raumtemperaturen und ungeheizte Swimmingpools: Die Regierung fordert eine "nationale Kraftanstrengung" wegen des Gasmangels.

  1. AKW Saporischschja Ukraine äußert Sorge vor Atomkatastrophe
  2. UN-Generalsekretär Angriffe auf ukrainisches Atomkraftwerk "selbstmörderisch"
  3. Gas- und Energiekrise Klimaanlagen runter, Lichter aus, Türen zu in Spanien

Rollerdrome im Test: Ballern beim Rollen
Rollerdrome im Test
Ballern beim Rollen

Wer Bunny Hop oder Rocket Jump schon kann, wirft einen Blick auf Rollerdrome: Das Actionspiel bietet Kämpfe mit fortgeschrittener Steuerung.
Von Peter Steinlechner


    Antimaterie: Antiprotonen in supraflüssigem Helium gefangen
    Antimaterie
    Antiprotonen in supraflüssigem Helium gefangen

    Forscher haben Antiprotonen in supraflüssigem Helium eingefangen und spektroskopisch untersucht. Das ermöglicht neue Untersuchungen an exotischen Atomen.
    Ein Bericht von Dirk Eidemüller

    1. Hybridmagnet Chinesische Forscher erzeugen Rekord-Magnetfeld
    2. Biologisch abbaubar Schweizer Team entwickelt Papierbatterie
    3. Supraleiter DNA baut Kohlenstoffnanoröhren um