🥇Wprowadzenie do Helm 3

Przyp. tłum.: 16 maja tego roku — ważna data w rozwoju menedżera pakietów dla Kubernetes — Helm. Tego dnia zaprezentowano pierwszy alfabeta przyszłej dużej wersji projektu — 3.0. Jej wydanie przyniesie do Helma znaczące i oczekiwane zmiany, na które wiele osób w społeczności Kubernetes pokłada wielkie nadzieje. Do grona tych osób zaliczamy się również my, ponieważ aktywnie używamy Helma do wdrażania aplikacji: zintegrowaliśmy go z naszym narzędziem do realizacji CI/CD. werf i od czasu do czasu wnosimy swój wkład w rozwój upstream. Tłumaczenie to łączy 7 notatek z oficjalnego bloga Helma, które są związane z pierwszym alfabeta wydaniem Helma 3 i opowiadają o historii projektu oraz głównych funkcjach Helma 3. Ich autorem jest Matt «bacongobbler» Fisher, pracownik Microsoftu i jeden z kluczowych konserwatorów Helma.

15 października 2015 roku powstał projekt znany dzisiaj jako Helm. Zaledwie rok po założeniu społeczność Helma dołączyła do Kubernetes, jednocześnie aktywnie pracując nad Helm 2. W czerwcu 2018 roku Helm dołączył do CNCF jako rozwijający się projekt (incubating). Przenieśmy się do teraźniejszości — oto zbliża się pierwsze alfabeta wydanie nowego Helma 3 (to wydanie już miało miejsce w połowie maja — przyp. tłum.).

W tym materiale opowiem o tym, jak to wszystko się rozpoczęło, jak dotarliśmy do obecnego etapu, zaprezentuję kilka unikalnych cech dostępnych w pierwszym alfabeta wydaniu Helma 3 i wyjaśnię, jak planujemy dalej się rozwijać.

Streszczenie:

historia powstania Helma;
czule pożegnanie z Tillerem;
repozytoria chartów;
zarządzanie wydaniami;
zmiany w zależnościach chartów;
library charts;
co dalej?

Historia powstania Helma

Narodziny

Helm 1 rozpoczął się jako projekt Open Source, stworzony przez firmę Deis. Byliśmy małym startupem, przejętym przez Microsoft wiosną 2017 roku. Nasz inny projekt Open Source, również noszący nazwę Deis, miał narzędzie deisctl, które było używane (między innymi) do instalacji i obsługi platformy Deis w klastrze Fleet. W tamtym czasie Fleet był jedną z pierwszych platform do orkiestracji kontenerów.

W połowie 2015 roku zdecydowaliśmy się zmienić kurs i przenieśliśmy Deis (wówczas przemianowany na Deis Workflow) z Fleet na Kubernetes. Jednym z pierwszych kroków była przebudowa narzędzia instalacyjnego deisctl. Używaliśmy go do instalacji i zarządzania Deis Workflow w klastrze Fleet.

Helm 1 został stworzony na wzór znanych menedżerów pakietów, takich jak Homebrew, apt i yum. Jego głównym celem było uproszczenie takich zadań, jak pakowanie i instalacja aplikacji w Kubernetes. Oficjalnie Helm został zaprezentowany w 2015 roku na konferencji KubeCon w San Francisco.

Nasza pierwsza próba z Helm zadziałała, jednak nie obyło się bez poważnych ograniczeń. Brał zestaw manifestów Kubernetes, wzbogaconych generatorami jako wejściowe bloki YAML. (front-matter)*, i ładował wyniki do Kubernetes.

* Przyp. tłum.: Od pierwszej wersji Helm do opisania zasobów Kubernetes wybrano składnię YAML, a przy pisaniu konfiguracji wspierano szablony Jinja i skrypty Pythona. Więcej na ten temat oraz o strukturze pierwszej wersji Helm pisaliśmy w rozdziale „Krótka historia Helm”. tego materiału.

Na przykład, aby zamienić pole w pliku YAML, należało dodać do manifestu następującą konstrukcję:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Fajnie, że dzisiaj istnieją szablonizatory, prawda?

Z wielu powodów ten wczesny instalator Kubernetes wymagał sztywno określonego zestawu plików manifestów i realizował tylko niewielką, stałą sekwencję wydarzeń. Korzystanie z niego było na tyle trudne, że zespół R&D Deis Workflow miał sporo trudności, kiedy próbowali przenieść swój produkt na tę platformę — jednakże ziarna idei już zostały zasiane. Nasza pierwsza próba stała się świetną okazją do nauki: zrozumieliśmy, że naprawdę pasjonuje nas tworzenie praktycznych narzędzi, które rozwiązują codzienne problemy naszych użytkowników.

Opierając się na doświadczeniu z przeszłych błędów, przystąpiliśmy do prac nad Helm 2.

Tworzenie Helm 2

Pod koniec 2015 roku skontaktował się z nami zespół Google. Pracowali nad podobnym narzędziem dla Kubernetes. Deployment Manager dla Kubernetes był portem istniejącego narzędzia, które było używane dla Google Cloud Platform. „Czy nie chcielibyśmy,” zapytali, „poświęcić kilku dni na omówienie podobieństw i różnic?”

W styczniu 2016 zespoły Helm i Deployment Manager spotkały się w Seattle, aby wymienić się pomysłami. Negocjacje zakończyły się ambitnym planem: połączyć oba projekty, aby stworzyć Helm 2. Wraz z Deis i Google do zespołu programistów dołączyli chłopaki z SkippBox (obecnie część Bitnami — przyp. tłum.), i przystąpiliśmy do pracy nad Helm 2.

Chcieliśmy zachować prostotę użycia Helm, ale dodać następujące elementy:

szablony chartów do dostosowywania;
zarządzanie w wewnętrznym klastrze dla zespołów;
repozytorium chartów najwyższej jakości;
stabilny format pakietów z możliwością podpisu;
silne zobowiązanie do semantycznego wersjonowania i utrzymania zgodności wstecznej między wersjami.

Aby osiągnąć te cele, do ekosystemu Helm dodano drugi element. Ten wewnętrzny komponent klastra nazywał się Tiller i zajmował się instalacją chartów Helm oraz ich zarządzaniem.

Od momentu wydania Helm 2 w 2016 roku Kubernetes zyskał kilka istotnych nowości. Wprowadzono zarządzanie dostępem oparte na rolach (RBAC), które ostatecznie zastąpiło kontrolę dostępu opartą na atrybutach (ABAC). Przedstawiono nowe typy zasobów (Deployments wciąż pozostawały w wersji beta). Wynaleziono definicje zasobów niestandardowych (początkowo nazywane zasobami osób trzecich lub TPR). A co najważniejsze – pojawił się zestaw najlepszych praktyk.

Na tle tych wszystkich zmian Helm nadal z wiernością służył użytkownikom Kubernetes. Po trzech latach i wielu nowych dodatkach stało się jasne, że nadszedł czas, aby wprowadzić znaczące zmiany w kodzie, aby Helm mógł dalej spełniać rosnące potrzeby rozwijającego się ekosystemu.

Delikatne pożegnanie z Tillerem

Podczas opracowywania Helm 2 wprowadziliśmy Tiller jako część naszej integracji z Deployment Managerem od Google. Tiller odgrywał ważną rolę dla zespołów pracujących w obrębie wspólnego klastra: pozwalał różnym specjalistom zarządzającym infrastrukturą na interakcję z tym samym zestawem wydań.

Ponieważ kontrola dostępu oparta na rolach (RBAC) została domyślnie włączona w Kubernetes 1.6, praca z Tiller'em w produkcji stała się trudniejsza. Z powodu ogromnej liczby możliwych polityk bezpieczeństwa nasza pozycja polegała na domyślnym oferowaniu konfiguracji zezwalającej. Umożliwiało to nowicjuszom eksperymentowanie z Helm i Kubernetes bez konieczności zagłębiania się w ustawienia bezpieczeństwa. Niestety, ta konfiguracja mogła nadać użytkownikowi zbyt szeroki zakres uprawnień, które nie były mu potrzebne. Inżynierowie DevOps i SRE musieli uczyć się dodatkowych kroków operacyjnych, instalując Tiller w klastrze wielo-użytkownikowym (multi-tenant).

Poznając, jak członkowie społeczności używają Helma w konkretnych sytuacjach, zrozumieliśmy, że system zarządzania wydaniami Tiller nie musi opierać się na wewnętrznym komponencie klastra, aby utrzymywać stany lub działać jako centralny hub z informacjami o wydaniu. Zamiast tego moglibyśmy po prostu pobierać informacje z serwera API Kubernetes, generować chart po stronie klienta i zapisywać rekord instalacji w Kubernetes.

Podstawowe zadanie Tiller'a można było zrealizować i bez Tiller'a, więc jednym z naszych pierwszych rozwiązań dotyczących Helm 3 było całkowite zrezygnowanie z Tiller'a.

Z odejściem Tiller'a model bezpieczeństwa Helma radykalnie się uprościł. Helm 3 teraz wspiera wszystkie nowoczesne metody bezpieczeństwa, identyfikacji i autoryzacji w obecnym Kubernetes. Uprawnienia Helma są definiowane za pomocą pliku kubeconfig. Administratorzy klastra mogą ograniczać prawa użytkowników z dowolnym poziomem szczegółowości. Wydania wciąż są przechowywane wewnątrz klastra, a pozostała funkcjonalność Helma pozostaje.

Repozytoria chartów

Na wysokim poziomie repozytorium chartów to miejsce, gdzie można przechowywać i współdzielić charty. Klient Helm pakuje i wysyła charty do repozytorium. Mówiąc prościej, repozytorium chartów to prymitywny serwer HTTP z plikiem index.yaml i pewnymi zapakowanymi chartami.

Chociaż istnieją pewne korzyści z tego, że API repozytorium chartów odpowiada najbardziej podstawowym wymaganiom przechowywania, ma ono również kilka wad:

Repozytoria chartów są źle dopasowane do większości implementacji zabezpieczeń wymaganych w środowisku produkcyjnym. Obecność standardowego API do uwierzytelniania i autoryzacji jest ekstremalnie ważna w scenariuszach produkcyjnych.
Narzędzia Helm do śledzenia pochodzenia chartu, używane do podpisywania, sprawdzania integralności i pochodzenia chartu, są opcjonalną częścią procesu publikacji chartu.
W scenariuszach wielodostępnych ten sam chart może być przesyłany przez innego użytkownika, co podwaja ilość miejsca potrzebnego do przechowywania tej samej treści. Aby rozwiązać ten problem, opracowano bardziej inteligentne repozytoria, które jednak nie są częścią formalnej specyfikacji.
Użycie jednego indeksu do wyszukiwania, przechowywania metadanych i uzyskiwania chartów skomplikowało rozwój bezpiecznych wielu użytkowników.

Projekt Docker Distribution (znany również jako Docker Registry v2) jest następcą Docker Registry i w rzeczywistości stanowi zestaw narzędzi do pakowania, wysyłania, przechowywania i dostarczania obrazów Docker. Wiele dużych usług chmurowych oferuje produkty oparte na Distribution. Dzięki takiemu zwiększonemu zainteresowaniu projekt Distribution skorzystał na wieloletnich ulepszeniach, najlepszych praktykach w zakresie bezpieczeństwa i testowaniu w warunkach "bojowych", które przekształciły go w jednego z najbardziej udanych niedocenionych bohaterów świata open source.

Ale czy wiesz, że projekt Distribution został zaprojektowany do dystrybucji dowolnej formy treści, a nie tylko obrazów kontenerów?

Dzięki wysiłkom Open Container Initiative (lub OCI), Helm-charty mogą być przechowywane na dowolnym egzemplarzu Distribution. Proces ten ma charakter eksperymentalny. Prace nad obsługą logowania i innymi funkcjami niezbędnymi do pełnego działania Helm 3 wciąż trwają, ale bardzo cieszymy się z możliwości uczenia się na odkryciach dokonanych przez zespoły OCI i Distribution na przestrzeni lat. Dzięki ich mentorstwu i kierownictwu dowiadujemy się, czym jest eksploatacja wysoko dostępnej usługi na dużą skalę.

Szczegółowy opis niektórych nadchodzących zmian w repozytoriach Helm-chartów jest dostępny pod tym linkiem.

Zarządzanie wydaniami

W Helm 3 stan aplikacji jest śledzony wewnątrz klastra przez parę obiektów:

obiekt wydania — reprezentuje egzemplarz aplikacji;
wersja wydania tajny — reprezentuje pożądany stan aplikacji w określonym momencie (na przykład, wydanie nowej wersji).

Wywołanie helm install tworzy obiekt wydania i tajny klucz wersji wydania. Wywołanie helm upgrade wymaga istnienia obiektu wydania (który może modyfikować) i tworzy nowy tajny klucz wersji wydania, zawierający nowe wartości i przygotowany manifest.

Obiekt wydania zawiera informacje o wydaniu, gdzie wydanie to konkretna instalacja nazwanej chart i wartości. Obiekt ten opisuje metadane na najwyższym poziomie o wydaniu. Obiekt wydania jest przechowywany przez cały cykl życia aplikacji i jest właścicielem wszystkich tajnych kluczy wersji wydania, a także wszystkich obiektów, które są bezpośrednio tworzone przez chart Helm.

Tajny klucz wersji wydania łączy wydanie z serią rewizji (instalacja, aktualizacje, wycofanie, usunięcie).

W Helm 2 rewizje były wyłącznie sekwencyjne. Wywołanie helm install tworzyło v1, następna aktualizacja (upgrade) — v2, i tak dalej. Wydanie i tajny klucz wersji wydania zostały połączone w jeden obiekt, znany jako rewizja. Rewizje były przechowywane w tej samej przestrzeni nazw co Tiller, co oznaczało, że każde wydanie było „globalne” w kontekście przestrzeni nazw; w rezultacie można było używać tylko jednego egzemplarza nazwy.

W Helm 3 każde wydanie jest powiązane z jednym lub większą liczbą tajnych kluczy wersji wydania. Obiekt wydania zawsze opisuje aktualne wydanie wdrożone w Kubernetes. Każdy tajny klucz wersji wydania opisuje tylko jedną wersję tego wydania. Aktualizacja (upgrade), na przykład, stworzy nowy tajny klucz wersji wydania, a następnie zmieni obiekt wydania, aby wskazywał na tę nową wersję. W przypadku wycofania (rollback) można użyć wcześniejszych tajnych kluczy wersji wydania do przywrócenia wydania do poprzedniego stanu.

Po rezygnacji z Tiller’a Helm 3 przechowuje dane o wydaniu w tej samej przestrzeni nazw co wydanie. Taka zmiana umożliwia zainstalowanie chartu o tej samej nazwie wydania w innej przestrzeni nazw, a dane są przechowywane między aktualizacjami/przeładowaniami klastra w etcd. Na przykład, można zainstalować WordPress w przestrzeni nazw „foo”, a następnie w przestrzeni nazw „bar”, a oba wydania mogą nazywać się „wordpress”.

Zmiany w zależnościach chartów

Charty, zapakowane (za pomocą helm package) do użycia z Helm 2, można zainstalować z Helm 3, jednak proces opracowywania chartów został całkowicie przeprojektowany, więc konieczne jest wprowadzenie pewnych zmian, aby kontynuować rozwój chartów z Helm 3. W szczególności zmienił się system zarządzania zależnościami chartów.

System zarządzania zależnościami chartu przeszedł na requirements.yaml i requirements.lock na Chart.yaml i Chart.lock. Oznacza to, że charty, które używały polecenia helm dependency, wymagają pewnych dostosowań, aby działać w Helm 3.

Przyjrzyjmy się przykładowi. Dodajmy zależność do chartu w Helm 2 i zobaczmy, co zmieni się przy przejściu do Helm 3.

W Helm 2 requirements.yaml wyglądał następująco:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

W Helm 3 ta sama zależność będzie odzwierciedlona w twoim Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Charty wciąż są ładowane i umieszczane w katalogu charts/, dlatego subcharty (subcharts), znajdujące się w katalogu charts/, będą działały bez zmian.

Wprowadzamy Library Charts

Helm 3 wspiera klasę chartów, nazywaną chartami-bibliotekami (library chart). Ten chart jest używany przez inne charty, ale sam nie tworzy żadnych artefaktów wydania. Szablony chartów bibliotek mogą deklarować jedynie elementy define. Inna zawartość jest po prostu ignorowana. Umożliwia to użytkownikom ponowne użycie i wymianę fragmentów kodu, które można wykorzystać w wielu chartach, unikając w ten sposób duplikacji i przestrzegając zasady DRY.

Charty bibliotekowe są deklarowane w sekcji dependencies w pliku Chart.yaml. Instalacja i zarządzanie nimi nie różni się od innych chartów.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Z niecierpliwością czekamy na zastosowania, które ten komponent otworzy przed twórcami chartów, a także na najlepsze praktyki, które mogą powstać dzięki chartom bibliotekowym.

Co dalej?

Helm 3.0.0-alpha.1 to fundament, na którym zaczynamy budować nową wersję Helma. W artykule opisałem kilka interesujących możliwości Helma 3. Wiele z nich jest jeszcze na wczesnym etapie rozwoju, co jest normalne; istotą alfy jest testowanie pomysłu, zbieranie opinii od pierwszych użytkowników oraz potwierdzanie naszych założeń.

Gdy tylko wersja alfa zostanie wydana (przypominamy, że to już się wydarzyło) — przyp. tłum.), zaczniemy przyjmować patche dla Helm 3 od społeczności. Musimy stworzyć solidne podstawy, które pozwolą rozwijać i wprowadzać nowe funkcjonalności, a użytkownicy będą mogli czuć się zaangażowani w proces, otwierając tickety i wnosząc poprawki.

W artykule starałem się omówić niektóre poważne ulepszenia, które pojawią się w Helm 3, jednak ta lista nie jest w żadnym wypadku wyczerpująca. Pełny plan dla Helm 3 obejmuje takie nowości, jak ulepszone strategie aktualizacji, głębsza integracja z rejestrem OCI oraz wykorzystanie schematów JSON do walidacji wartości chartów. Planujemy również oczyścić bazę kodu i zaktualizować te jej części, które były ignorowane przez ostatnie trzy lata.

Jeśli czujecie, że coś przeoczyliśmy, z chęcią usłyszymy wasze myśli!

Dołącz do dyskusji w naszym kanałach Slack:

#helm-users na pytania i swobodną komunikację ze społecznością;
#helm-dev na temat omawiania pull requestów, kodu i błędów.

Możecie również porozmawiać na naszych cotygodniowych Public Developer Calls w czwartki o 19:30 MSK. Spotkania są poświęcone omówieniu zadań, nad którymi pracują kluczowi deweloperzy oraz społeczność, a także tematom dyskusji na tydzień. Każdy chętny może dołączyć i wziąć udział w spotkaniu. Link jest dostępny w kanale Slack #helm-dev.

P.S. od tłumacza

Przeczytaj także na naszym blogu:

Źródło: habr.com