Przedstawiamy Helm 3

Notatka. przeł.: 16 maja tego roku przypada znaczący kamień milowy w rozwoju menedżera pakietów dla Kubernetes – Helm. Tego dnia zaprezentowano pierwszą wersję alfa przyszłej głównej wersji projektu – 3.0. Jego wydanie przyniesie znaczące i długo oczekiwane zmiany w Helmie, z którymi wielu członków społeczności Kubernetes wiąże duże nadzieje. My sami jesteśmy jednym z nich, ponieważ aktywnie używamy Helma do wdrażania aplikacji: zintegrowaliśmy go z naszym narzędziem do wdrażania CI/CD werf i od czasu do czasu wnosimy swój wkład w rozwój upstreamu. To tłumaczenie łączy w sobie 7 notatek z oficjalnego bloga Helma, które są poświęcone pierwszej wersji alfa Helm 3 i opowiadają o historii projektu oraz głównych cechach Helm 3. Ich autorem jest Matt „bacongobbler” Fisher, pracownik Microsoftu i jeden z kluczowych opiekunów Helma.

15 października 2015 roku narodził się projekt znany obecnie jako Helm. Zaledwie rok po założeniu społeczność Helm dołączyła do Kubernetesa, aktywnie pracując nad Helm 2. W czerwcu 2018 r. Helm dołączył do CNCF jako projekt rozwijający się (inkubujący). Przejdźmy szybko do teraźniejszości, a pierwsza wersja alfa nowego Helm 3 jest już w drodze. (to wydanie już miało miejsce w połowie maja – ok. tłumacz.).

W tym artykule opowiem o tym, gdzie to wszystko się zaczęło, jak dotarliśmy do miejsca, w którym jesteśmy dzisiaj, przedstawię niektóre unikalne funkcje dostępne w pierwszej wersji alfa Helm 3 i wyjaśnię, w jaki sposób planujemy działać dalej.

Podsumowanie:

• historia powstania Helma;
• czułe pożegnanie z Tillerem;
• repozytoria wykresów;
• zarządzanie wydaniami;
• zmiany w zależnościach wykresów;
• wykresy biblioteczne;
• co dalej?

Historia Helma

Narodziny

Helm 1 zaczynał jako projekt Open Source stworzony przez Deisa. Byliśmy małym startupem zaabsorbowany Microsoftu wiosną 2017 r. Nasz inny projekt Open Source, również nazwany Deis, miał takie narzędzie deisctl, który został wykorzystany (między innymi) do instalacji i obsługi platformy Deis w Klaster flotowy. W tamtym czasie Fleet była jedną z pierwszych platform do orkiestracji kontenerów.

W połowie 2015 roku postanowiliśmy zmienić kurs i przenieśliśmy Deis (wówczas przemianowany na Deis Workflow) z Fleet na Kubernetes. Jednym z pierwszych, które zostało przeprojektowane, było narzędzie instalacyjne. deisctl. Użyliśmy go do zainstalowania i zarządzania Deis Workflow w klastrze Fleet.

Helm 1 został stworzony na obraz i podobieństwo znanych menedżerów pakietów, takich jak Homebrew, apt i yum. Jego głównym celem było uproszczenie zadań takich jak pakowanie i instalowanie aplikacji na Kubernetesie. Helm został oficjalnie zaprezentowany w 2015 roku na konferencji KubeCon w San Francisco.

Nasza pierwsza próba z Helmem zadziałała, ale nie obyło się bez poważnych ograniczeń. Wziął zestaw manifestów Kubernetesa, wzbogacony generatorami jako wprowadzające bloki YAML (przednia sprawa)* i załadował wyniki do Kubernetes.

* Notatka. przeł.: Od pierwszej wersji Helma wybrano składnię YAML do opisu zasobów Kubernetes, a podczas pisania konfiguracji obsługiwane były szablony Jinja i skrypty Python. Więcej o tym i ogólnie o strukturze pierwszej wersji Helma pisaliśmy w rozdziale „Krótka historia Helma” ten materiał.

Na przykład, aby zastąpić pole w pliku YAML, trzeba było dodać do manifestu następującą konstrukcję:

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

To wspaniale, że istnieją dziś silniki szablonów, prawda?

Z wielu powodów ten wczesny instalator Kubernetesa wymagał zakodowanej na stałe listy plików manifestu i wykonywał tylko małą, stałą sekwencję zdarzeń. Korzystanie z niego było tak trudne, że zespół badawczo-rozwojowy Deis Workflow miał trudności, próbując przenieść swój produkt na tę platformę – jednak nasiona pomysłu zostały już zasiane. Nasza pierwsza próba była świetną okazją do nauki: zdaliśmy sobie sprawę, że naprawdę pasjonujemy się tworzeniem pragmatycznych narzędzi, które rozwiązują codzienne problemy naszych użytkowników.

Bazując na doświadczeniach z błędów z przeszłości, rozpoczęliśmy prace nad Helm 2.

Tworzenie hełmu 2

Pod koniec 2015 roku skontaktował się z nami zespół Google. Pracowali nad podobnym narzędziem dla Kubernetesa. Deployment Manager for Kubernetes był portem istniejącego narzędzia, które zostało wykorzystane w Google Cloud Platform. „Czy chcielibyśmy” – zapytali – „spędzić kilka dni na dyskusję o podobieństwach i różnicach?”

W styczniu 2016 r. 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 w celu stworzenia Helm 2. Wraz z Deisem i Google, chłopaki z SkippBox (obecnie część Bitnami - ok. tłum.)i rozpoczęliśmy pracę nad Helmem 2.

Chcieliśmy zachować łatwość obsługi Helma, ale dodaliśmy następujące elementy:

• szablony wykresów do personalizacji;
• zarządzanie wewnątrzklastrowe zespołami;
• światowej klasy repozytorium wykresów;
• stabilny format pakietu z możliwością podpisu;
• silne zaangażowanie w wersjonowanie semantyczne i utrzymanie kompatybilności wstecznej między wersjami.

Aby osiągnąć te cele, do ekosystemu Helm dodano drugi element. Ten wewnątrzklastrowy komponent nazywał się Tiller i był odpowiedzialny za instalowanie wykresów Helma i zarządzanie nimi.

Od wydania Helm 2 w 2016 roku Kubernetes dodał kilka ważnych innowacji. Dodano kontrolę dostępu opartą na rolach (RBAC), który ostatecznie zastąpił kontrolę dostępu opartą na atrybutach (ABAC). Wprowadzono nowe typy zasobów (Wdrożenia były wówczas jeszcze w fazie beta). Wynaleziono niestandardowe definicje zasobów (pierwotnie nazywane zasobami stron trzecich lub TPR). A co najważniejsze, powstał zestaw najlepszych praktyk.

Pomimo tych wszystkich zmian Helm w dalszym ciągu wiernie służył użytkownikom Kubernetes. Po trzech latach i wielu nowych dodatkach stało się jasne, że nadszedł czas na wprowadzenie znaczących zmian w bazie kodu, aby zapewnić, że Helm będzie mógł w dalszym ciągu spełniać rosnące potrzeby rozwijającego się ekosystemu.

Czułe pożegnanie z Tillerem

Podczas opracowywania Helm 2 wprowadziliśmy Tiller w ramach naszej integracji z Menedżerem wdrażania Google. Tiller odegrał ważną rolę dla zespołów pracujących w ramach wspólnego klastra: umożliwił różnym specjalistom obsługującym infrastrukturę interakcję z tym samym zestawem wydań.

Ponieważ w Kubernetes 1.6 domyślnie włączona była kontrola dostępu oparta na rolach (RBAC), praca z Tillerem w środowisku produkcyjnym stała się trudniejsza. Ze względu na ogromną liczbę możliwych polityk bezpieczeństwa, naszym stanowiskiem było domyślnie oferowanie konfiguracji zezwalającej. Umożliwiło to nowicjuszom eksperymentowanie z Helmem i Kubernetesem bez konieczności wcześniejszego zagłębiania się w ustawienia zabezpieczeń. Niestety taka konfiguracja uprawnień może zapewnić użytkownikowi zbyt szeroki zakres uprawnień, których nie potrzebuje. Inżynierowie DevOps i SRE musieli nauczyć się dodatkowych kroków operacyjnych podczas instalowania Tillera w klastrze z wieloma dzierżawcami.

Po dowiedzeniu się, jak społeczność korzystała z Helma w określonych sytuacjach, zdaliśmy sobie sprawę, że system zarządzania wersjami Tillera nie musi polegać na komponencie wewnątrzklastrowym, aby utrzymać stan lub funkcjonować jako centralny węzeł informacji o wydaniach. Zamiast tego moglibyśmy po prostu otrzymać informacje z serwera Kubernetes API, wygenerować wykres po stronie klienta i zapisać zapis instalacji w Kubernetes.

Główny cel Tillera można było osiągnąć bez Tillera, więc jedną z naszych pierwszych decyzji dotyczących Helm 3 było całkowite porzucenie Tillera.

Po odejściu Tillera model bezpieczeństwa Helma został radykalnie uproszczony. Helm 3 obsługuje teraz wszystkie nowoczesne metody zabezpieczeń, tożsamości i autoryzacji obecnego Kubernetesa. Uprawnienia Helma są określane za pomocą plik kubeconfig. Administratorzy klastrów mogą ograniczać prawa użytkowników do dowolnego poziomu szczegółowości. Wersje są nadal zapisywane w klastrze, a reszta funkcjonalności Helma pozostaje nienaruszona.

Repozytoria wykresów

Na wyższym poziomie repozytorium wykresów to miejsce, w którym można przechowywać i udostępniać wykresy. Klient Helm pakuje i wysyła wykresy do repozytorium. Mówiąc najprościej, repozytorium wykresów to prymitywny serwer HTTP z plikiem Index.yaml i kilkoma spakowanymi wykresami.

Chociaż interfejs API Charts Repository spełnia większość podstawowych wymagań dotyczących pamięci ma kilka zalet, ma też kilka wad:

• Repozytoria wykresów nie są kompatybilne z większością implementacji zabezpieczeń wymaganych w środowisku produkcyjnym. Posiadanie standardowego interfejsu API do uwierzytelniania i autoryzacji jest niezwykle ważne w scenariuszach produkcyjnych.
• Narzędzia firmy Helm do sprawdzania pochodzenia wykresów, używane do podpisywania, weryfikowania integralności i pochodzenia wykresów, stanowią opcjonalną część procesu publikowania wykresów.
• W scenariuszach obejmujących wielu użytkowników ten sam wykres może zostać przesłany przez innego użytkownika, co podwaja ilość miejsca wymaganego do przechowywania tej samej treści. Aby rozwiązać ten problem, opracowano inteligentniejsze repozytoria, ale nie są one częścią formalnej specyfikacji.
• Używanie jednego pliku indeksu do wyszukiwania, przechowywania metadanych i pobierania wykresów utrudnia tworzenie bezpiecznych implementacji dla wielu użytkowników.

Projekt Dystrybucja Dockera (znany również jako Docker Registry v2) jest następcą Docker Registry i zasadniczo działa jako zestaw narzędzi do pakowania, wysyłki, przechowywania i dostarczania obrazów Docker. Wiele dużych usług w chmurze oferuje produkty oparte na dystrybucji. Dzięki tej zwiększonej uwadze projekt Distribution skorzystał z lat ulepszeń, najlepszych praktyk w zakresie bezpieczeństwa i testów w terenie, które uczyniły go jednym z niedocenionych bohaterów świata Open Source, którzy odnieśli największe sukcesy.

Ale czy wiesz, że projekt dystrybucyjny miał na celu dystrybucję dowolnej formy treści, a nie tylko obrazów kontenerów?

Dzięki wysiłkom Inicjatywa Open Container (lub OCI), wykresy Helm można umieścić w dowolnej instancji dystrybucji. Na razie proces ten ma charakter eksperymentalny. Obsługa logowania i inne funkcje potrzebne do pełnego Helma 3 są w toku, ale jesteśmy podekscytowani możliwością uczenia się na podstawie odkryć, których dokonały zespoły OCI i Dystrybucja na przestrzeni lat. Dzięki ich mentoringowi i wskazówkom dowiadujemy się, jak to jest świadczyć usługi o wysokiej dostępności na dużą skalę.

Dostępny jest bardziej szczegółowy opis niektórych nadchodzących zmian w repozytoriach wykresów Helm по ссылке.

Zarządzanie wydaniami

W Helmie 3 stan aplikacji jest śledzony w klastrze za pomocą pary obiektów:

• obiekt wydania - reprezentuje instancję aplikacji;
• tajna wersja wersji — reprezentuje pożądany stan aplikacji w określonym momencie (na przykład wydanie nowej wersji).

Zadzwoń helm install tworzy obiekt wydania i sekret wersji wydania. Dzwonić helm upgrade wymaga obiektu release (który może zmienić) i tworzy sekret nowej wersji zawierający nowe wartości i przygotowany manifest.

Obiekt Release zawiera informacje o wydaniu, gdzie wydanie jest konkretną instalacją nazwanego wykresu i wartości. Ten obiekt opisuje metadane najwyższego poziomu dotyczące wydania. Obiekt wydania utrzymuje się przez cały cykl życia aplikacji i jest właścicielem wszystkich kluczy tajnych wersji wydania, a także wszystkich obiektów tworzonych bezpośrednio przez wykres Helm.

Sekret wersji wydania wiąże wydanie z serią wersji (instalacja, aktualizacje, wycofanie zmian, usunięcie).

W Helmie 2 poprawki były niezwykle spójne. Dzwonić helm install utworzono v1, późniejszą aktualizację (upgrade) - v2 i tak dalej. Wydanie i sekret wersji wydania zostały zwinięte w jeden obiekt znany jako wersja. Wersje były przechowywane w tej samej przestrzeni nazw co Tiller, co oznaczało, że każde wydanie było „globalne” pod względem przestrzeni nazw; w rezultacie można było użyć tylko jednego wystąpienia nazwy.

W Helmie 3 każde wydanie jest powiązane z co najmniej jednym kluczem tajnym wersji wydania. Obiekt release zawsze opisuje bieżącą wersję wdrożoną w Kubernetes. Każdy sekret wersji wydania opisuje tylko jedną wersję tego wydania. Na przykład aktualizacja utworzy klucz tajny nowej wersji, a następnie zmieni obiekt wydania, aby wskazywał tę nową wersję. W przypadku wycofania można użyć wpisów tajnych poprzedniej wersji, aby przywrócić poprzedni stan.

Po porzuceniu Tillera Helm 3 przechowuje dane wydania w tej samej przestrzeni nazw, co wydanie. Ta zmiana umożliwia zainstalowanie wykresu o tej samej nazwie wydania w innej przestrzeni nazw, a dane są zapisywane pomiędzy aktualizacjami/ponownymi uruchomieniami klastra w itp. Na przykład możesz zainstalować WordPressa w przestrzeni nazw „foo”, a następnie w przestrzeni nazw „bar”, a obie wersje będą mogły nosić nazwę „wordpress”.

Zmiany w zależnościach wykresów

Spakowane wykresy (przy użyciu helm package) do użytku z Helmem 2 można zainstalować z Helmem 3, jednak proces tworzenia wykresów został całkowicie zmieniony, więc należy wprowadzić pewne zmiany, aby móc kontynuować tworzenie wykresów z Helmem 3. W szczególności zmienił się system zarządzania zależnościami wykresów.

System zarządzania zależnościami wykresu został przeniesiony z requirements.yaml и requirements.lock na Chart.yaml и Chart.lock. Oznacza to, że wykresy, w których zastosowano polecenie helm dependency, wymagają pewnej konfiguracji do pracy w Helmie 3.

Spójrzmy na przykład. Dodajmy zależność do wykresu w Helmie 2 i zobaczmy, co się zmieni po przejściu do Helma 3.

W Helmie 2 requirements.yaml wyglądało tak:

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

W Helmie 3 ta sama zależność zostanie odzwierciedlona w pliku Chart.yaml:

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

Wykresy są nadal pobierane i umieszczane w katalogu charts/, więc podwykresy (podwykresy), leżące w katalogu charts/, będzie nadal działać bez zmian.

Przedstawiamy wykresy biblioteczne

Helm 3 obsługuje klasę wykresów zwanych wykresami bibliotecznymi (wykres biblioteczny). Ten wykres jest używany przez inne wykresy, ale sam nie tworzy żadnych artefaktów wydania. Szablony wykresów bibliotecznych mogą deklarować tylko elementy define. Inne treści są po prostu ignorowane. Pozwala to użytkownikom na ponowne wykorzystanie i udostępnianie fragmentów kodu, które można wykorzystać na wielu wykresach, unikając w ten sposób powielania i przestrzegając zasady DRY.

Wykresy biblioteczne zadeklarowane są w sekcji dependencies w pliku Chart.yaml. Instalacja i zarządzanie nimi nie różni się od innych wykresów.

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

Jesteśmy podekscytowani możliwościami użycia tego komponentu dla twórców wykresów, a także najlepszymi praktykami, które mogą wyniknąć z wykresów bibliotecznych.

Co dalej?

Helm 3.0.0-alpha.1 to podstawa, na której zaczynamy budować nową wersję Helma. W artykule opisałem kilka interesujących funkcji Helma 3. Wiele z nich jest wciąż na wczesnym etapie rozwoju i jest to normalne; Celem wersji alfa jest przetestowanie pomysłu, zebranie opinii od pierwszych użytkowników i potwierdzenie naszych założeń.

Jak tylko wyjdzie wersja alfa (pamiętaj, że to jest już się stało - około. tłumacz.), zaczniemy przyjmować od społeczności łatki dla Helma 3. Musisz stworzyć mocne podstawy, które pozwolą na opracowanie i przyjęcie nowych funkcjonalności, a użytkownicy poczują się zaangażowani w proces poprzez otwieranie zgłoszeń i wprowadzanie poprawek.

Próbowałem podkreślić niektóre z głównych ulepszeń wprowadzonych do Helm 3, ale ta lista w żadnym wypadku nie jest wyczerpująca. Pełny plan działania dla Helm 3 obejmuje takie funkcje, jak ulepszone strategie aktualizacji, głębsza integracja z rejestrami OCI i wykorzystanie schematów JSON do sprawdzania wartości wykresów. Planujemy także uporządkować bazę kodu i zaktualizować jego części, które były zaniedbywane przez ostatnie trzy lata.

Jeśli czujesz, że coś przeoczyliśmy, chętnie poznamy Twoją opinię!

Dołącz do dyskusji na naszym Luźne kanały:

• #helm-users w przypadku pytań i prostej komunikacji ze społecznością;
• #helm-dev aby omówić żądania ściągnięcia, kod i błędy.

Możesz także rozmawiać podczas naszych cotygodniowych publicznych rozmów z programistami w czwartki o 19:30 MSK. Spotkania poświęcone są omówieniu zagadnień, nad którymi pracują kluczowi programiści i społeczność, a także tematów dyskusji na dany tydzień. Każdy może dołączyć i wziąć udział w spotkaniu. Link dostępny na kanale Slack #helm-dev.

PS od tłumacza

Przeczytaj także na naszym blogu:

• «Menedżer pakietów dla Kubernetes - Helm: przeszłość, teraźniejszość, przyszłość";
• «Trzeźwe spojrzenie na Helm 2: „O to właśnie chodzi…”";
• «Praktyczne wprowadzenie do menadżera pakietów dla Kubernetesa – Helm";
• «Porady i triki Kubernetes: przesyłanie zasobów działających w klastrze do zarządzania Helm 2";
• «Poćwicz z dappem. Część 2. Wdrażanie obrazów Dockera na Kubernetesie przy użyciu Helma".

Źródło: www.habr.com