Czy warto przejść na Helm 3?

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 charty, 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 do Chart.yaml
    • dodano nowy typ metadanych type do definiowania czy chart jest application czy library
    • wersja API v1 ciągle jest działająca
  • 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 na client/library
    • informacje o releasach są utrzymywane w osobnych namespaceach, a nie w przestrzeni tillera
    • informacje o deploymencie / releasie aplikacji teraz są trzymane w sekretach, a nie w ConfigMap
  • 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 na show
    • fetch zmieniono na pull
    • delete zamieniono na uninstall 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.

Rafał

Od 15 lat w branży IT. Entuzjasta podejścia Everything as a Code oraz tematyki związanej z Cyber Security. Swoją karierę zaczynał właściwie jako DevOps, kiedy jeszcze nie było to modne i tak nazywane ;)

You may also like...

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *