Jeśli pracujesz już z kubernetesem to zapewne wiesz, że fajnym rozwiązaniem ułatwiającym zarządzanie opisem struktury aplikacji jest Helm. Przy jego pomocy możesz stworzyć pakiety ze wszystkimi zależnościami dla Twojej aplikacji i w łatwy sposób utrzymywać definicje w postaci kodu, co przy podejściu EaaC (Everything as a Code) jest bardzo porządane. Porównując helma do kubernetesowych manifestów można powiedzieć, że dzięki helmowi możemy w łatwy i przyjemny sposób parametryzować manifesty.
Wersja druga tego narzędzia jednak, ze względu na swoją budowę miała pewne wady. Główną z tych wad była jego architektura, a mianowicie istnienie tillera
czyli serwera z którym komunikowal się klient helma. Następnie wszystkie przesłane chart
y, tiller
uzupełniał odpowiednimi zmiennymi i wykonywał dalsze działania na klastrze poprzez komunikację z API. Jak wiesz, bądź się domyślasz to rozwiązanie przysparza wielu problemów. Zaczynając od tego, że tiller
odpalony na klastrze jest pojedynczym czynnikiem narażonym na awarie – SPoF (Single Point of Failier), a kończąc na problemach z uprawnieniami.
Na szczęście autorzy Helm’a rozpoczęli pracę nad wersją 3 i 13.11.2019 wypuścili pierwsze stabilne wydanie tej wersji. Poniżej przedstawiam Ci listę głównych zmian jakie pojawiły się w stosunku do wersji drugiej:
- zmieniono wersję API (użycie v2):
- poprzednie pole zależności (dependencies) które było w
requirements.yaml
przeniesiono doChart.yaml
- dodano nowy typ metadanych
type
do definiowania czy chart jestapplication
czylibrary
- wersja API v1 ciągle jest działająca
- poprzednie pole zależności (dependencies) które było w
- usunięto
tillera
i klient helma bezpośrednio komunikuje się z API kubernetesa (usunięcie SPoF)- możemy teraz w łatwy sposób używać naszego
service account
w CI, bez potrzeby definiowania dodatkowych dostępów - zamiana architektury
client/server
naclient/library
- informacje o releasach są utrzymywane w osobnych
namespaceach
, a nie w przestrzenitillera
- informacje o deploymencie / releasie aplikacji teraz są trzymane w sekretach, a nie w
ConfigMap
- możemy teraz w łatwy sposób używać naszego
- zmieniono trochę CLI:
- search umożliwia szukanie i w lokalnym repo i w helm hubie
init
jest zbędny i usunięty z CLI- podczas wykonywania
install
musimy podać nazwę dla naszego releasu – już nie jest generowana automatycznie inspect
zmieniono nashow
fetch
zmieniono napull
delete
zamieniono nauninstall
który usuwa wszystkie releasy więc nie trzeba już dawać flagi--purge
- nie są
by default
skonfigurowane żadne repozytoria ani lokalne ani zdalne więc jeżeli z nich korzystasz musisz je teraz dodać ręcznie- helm odchodzi od trzymania jednego centralnego repozytorium i zaleca samemu utrzymywanie sobie swoich chartów
Przejście na Helm3 jest praktycznie bezbolesne, gdyż charty z wersji 2 powinny także działać. Jeśli chcesz dowiedzieć się więcej na temat samej migracji to odsyłam Cię do dokumentacji. Odpowiadając na pytanie czy warto przechodzić na helm 3 odpowiedź jest jednoznaczna – warto.
Źródła:
- workstation: Owned by the author