Helm vs Kustomize

Jeszcze dodam jedną straszną rzecz, którą kurde ileś razy widziałem i zawsze widzę ją z problemami, to jeżeli ktoś próbuje zrobić master helma...

bo dawanie tego ludziom to jak dawanie dziecku brzytwy, żeby popiegało sobie po placu zabaw, czyli helm versus customize, czyli odwieczny problem, czego powinniśmy użyć do templatingu, przygotowania deploymentów na Kubernetesa.

Dobrze, teraz Helm.

Helm natomiast jest takim engine'em template'owym do Jamla, czyli mamy Jamla, a tam elementalnie mamy jakieś while, ify i tak dalej, i tak dalej, i na koniec tego Jamla wygenerujemy i całość przedstawiamy jako paczkę i masz, instaluj sobie.

Bo ja helmem nie gardzę, gardzę sposobem użycia i to jest bardzo istotna różnica.

Dobra, i helm pierwotnie, to też jest bardzo ważne, jest package managerem i tego jego pierwsze takie przeznaczenie, takie bardzo szerokie, to jest packet manager i mamy coś, co nazywamy artifact hub.

Weźmy owianego słowom Prometeusza, jakieś operatory, third-party softy, teraz przychodzą enterprise'owe w postaci helma, więc jest to sposób dystrybucji manifestów do Kubernetesa, żeby zrobić produkt do instalacji.

Helm jest świetny do dystrybucji produktów.

Tak, i tu damy małą gwiazdkę, że mówimy oczywiście o Helm w wersji 3 i wyżej.

I teraz słuchajcie, jakie są problemy z Helmem, takie moje.

Całą tą opcję, żeby jednak mimo wszystko ten helm był rozszerzalny.

Dobra i teraz jeżeli popatrzymy o pisaniu dobrego helma, jak mówimy, bo zobacz, że sytuacja, kiedy dostarczamy i kiedy dostarczamy coś już w ten sposób, jeżeli będziemy używać właśnie patrząc na te problemy, to pod tym względem

Helm, tak jak powiedziałeś, one powinny być jawnie deklarowane.

Dla mnie kolejna siła, to ja może dam mój główny argument, czemu ja jestem znowu wywolnikiem Helma.

A przy Helmie mówimy na opcję.

Tu się zgodzisz, że Helm fajnie buduje abstrakcje.

Mało kto poprawnie używa wersjonowania w Helmie.

Jeżeli zmieniamy coś w Helm'ie, powinniśmy podbijać chart version.

Przeglądając coraz więcej rep odnośnie właśnie instalacji helma, to już stało się standardem, że naprawdę dobre praktyki w helmie weszły i już zagościły i są.

To tak, z mojej perspektywy, czy będziemy używać helma z Kubernetesem?

Uważam, że to, co przychodzi z open source'u, weźmy te Argo, Prometeusze, jakieś ingresy, inne rzeczy, to wszystko powinno być instalowane helmem.

Jeżeli dostarczasz swój software jako produkt i ktoś będzie go instalował na klastrze i to jest zupełnie poza tobą, tutaj również jest to helm w stu procentach.

Helm jest jak najbardziej świetny.

config mojej aplikacji, to on w deployu podmieni tę nazwę tej config mapy, czyli to będzie config mojej aplikacji i numerki i hash i tak samo będzie się nazywała config mapa i przykładowo zrobi pierdołę, z którą jest, jak wiesz, zawsze problem, czyli jeżeli nie zmieniamy deploymentu, to helm go nie będzie w żaden sposób...

Tak samo jak z Helmem.