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.