Istota opowieści o najpopularniejszym menedżerze pakietów dla Kubernetes może być przedstawiona za pomocą emoji:
- pudełko — to Helm (to najbardziej odpowiednie, co mamy w najnowszej wersji Emoji);
- zamknięcie — bezpieczeństwo;
- ludzika — rozwiązanie problemu.
W rzeczywistości wszystko będzie trochę bardziej skomplikowane, a opowieść jest pełna technicznych szczegółów dotyczących tego, jak uczynić Helm bezpieczniejszym.
- Krótko mówiąc, co to jest Helm, jeśli nie wiedziałeś lub zapomniałeś. Jakie problemy rozwiązuje i gdzie znajduje się w ekosystemie.
- Rozważmy architekturę Helma. Żadna rozmowa o bezpieczeństwie i o tym, jak uczynić narzędzie lub rozwiązanie bardziej bezpiecznym, nie może obejść się bez zrozumienia architektury komponentu.
- Omówimy komponenty Helma.
- Najważniejsze pytanie — przyszłość — nowa wersja Helm 3.
Wszystko w tym artykule dotyczy Helm 2. Ta wersja jest obecnie w produkcji, i prawdopodobnie właśnie jej teraz używasz, a to w niej występują zagrożenia bezpieczeństwa.
O prelegencie: Aleksander Chajorow () zajmuje się rozwojem od 10 lat, pomaga poprawiać treści i dołączył do komitetu . Obecnie pracuje w Chainstack jako lider ds. rozwoju — to hybryda między kierownikiem rozwoju a osobą odpowiedzialną za dostarczanie ostatecznych wersji. To znaczy, że jest na pierwszej linii frontu, gdzie odbywa się wszystko, od tworzenia produktu po jego eksploatację.
Chainstack to niewielki, prężnie rozwijający się startup, którego celem jest umożliwienie klientom zapomnienie o infrastrukturze i wyzwaniach związanych z obsługą zdecentralizowanych aplikacji, zespół programistyczny znajduje się w Singapurze. Nie proście Chainstack o sprzedaż lub zakup kryptowaluty, ale zaproponujcie rozmowę na temat ram blockchain dla przedsiębiorstw, a chętnie wam odpowiedzą.
Helm
To menedżer pakietów (chartów) dla Kubernetes. Najbardziej zrozumiały i uniwersalny sposób wprowadzania aplikacji do klastra Kubernetes.
Mowa oczywiście o bardziej strukturalnym i przemysłowym podejściu, niż tworzenie własnych manifestów YAML i pisanie małych narzędzi.
Helm to najlepsze, co obecnie mamy z dostępnych i popularnych opcji.
Dlaczego Helm? Przede wszystkim dlatego, że jest wspierany przez CNCF. Cloud Native to duża organizacja, która jest macierzystą dla projektów Kubernetes, etcd, Fluentd i innych.
Innym ważnym faktem jest to, że Helm to bardzo popularny projekt. Kiedy w styczniu 2019 roku zaczynałem myśleć o tym, jak uczynić Helm bezpiecznym, projekt miał tysiąc gwiazdek na GitHubie. Do maja ich liczba wzrosła do 12 tysięcy.
Wielu interesuje się Helmem, dlatego nawet jeśli nadal go nie używasz, wiedza na temat jego bezpieczeństwa będzie przydatna. Bezpieczeństwo jest ważne.
Główny zespół Helma wspierany jest przez Microsoft Azure, co czyni ten projekt dość stabilnym w odróżnieniu od wielu innych. Wydanie Helm 3 Alpha 2 w połowie lipca świadczy o tym, że nad projektem pracuje wystarczająco dużo ludzi, którzy mają chęć i siłę, aby rozwijać i poprawiać Helm.
Helm rozwiązuje kilka podstawowych problemów związanych z zarządzaniem aplikacjami w Kubernetes.
- Pakietowanie aplikacji. Nawet aplikacja typu ‘Hello, World’ na WordPressie przedstawia już kilka usług, które chcemy zapakować razem.
- Zarządzanie złożonością, która pojawia się przy zarządzaniu tymi aplikacjami.
- Cykl życia, który nie kończy się po zainstalowaniu lub wdrożeniu aplikacji. Aplikacja wciąż żyje, trzeba ją aktualizować, w czym pomaga Helm, starając się wprowadzić właściwe środki i polityki dla tego procesu.
Pakietowanie jest zorganizowane w zrozumiały sposób: są metadane w pełnej zgodności z działaniem tradycyjnego menedżera pakietów dla Linuxa, Windowsa czy MacOS. Oznacza to repozytorium, zależności od różnych pakietów, metainformacje dla aplikacji, ustawienia, szczegóły konfiguracji, indeksowanie informacji itp. Wszystko to Helm pozwala uzyskać i wykorzystać dla aplikacji.
Zarządzanie złożonością. Jeśli masz wiele podobnych aplikacji, potrzebujesz parametryzacji. Z tego wynikają szablony, ale aby nie wymyślać własnych sposobów tworzenia szablonów, można skorzystać z tego, co Helm oferuje prosto z pudełka.
Zarządzanie cyklem życia aplikacji — moim zdaniem to najciekawszy i nierozwiązany problem. To właśnie dlatego kiedyś zacząłem interesować się Helm. Musieliśmy śledzić cykl życia aplikacji, chcieliśmy przenieść nasze CI/CD i cykle aplikacji do tej paradygmy.
Helm pozwala:
- zarządzać wdrożeniami, wprowadza pojęcie konfiguracji i rewizji;
- skutecznie przeprowadzać rollback;
- wykorzystywać hooki na różne zdarzenia;
- dodawać dodatkowe kontrole aplikacji i reagować na ich wyniki.
Ponadto Helm ma swoje ‘baterie’. — ogromna ilość pysznych rzeczy, które można włączyć jako wtyczki, upraszczając sobie życie. Wtyczki można pisać samodzielnie, są dość izolowane i nie wymagają złożonej architektury. Jeśli chcesz coś zrealizować, polecam zrobić to w formie wtyczki, a potem ewentualnie włączyć do upstream.
Helm opiera się na trzech głównych koncepcjach:
- Repozytorium Chart — opis i zbiór parametrów, które mogą być zastosowane w twoim manifeście.
- Konfiguracja — to znaczy wartości, które będą miały zastosowanie (tekst, wartości liczbowej itp.).
- Release łączy dwa górne komponenty, które razem przekształcają się w Release. Wydania można wersjonować, co pozwala na organizację cyklu życia: małe w momencie instalacji, a duże w momencie aktualizacji, obniżenia lub przywrócenia.
Architektura Helm
Na schemacie conceptualnie odzwierciedlona jest wysokopoziomowa architektura Helm.
Przypomnę, że Helm to coś, co jest związane z Kubernetes. Dlatego nie obędzie się bez klastra Kubernetes (prostokąt). Komponent kube-apiserver znajduje się na masterze. Bez Helma mamy Kubeconfig. Helm przynosi jedną małą binarną, jeśli można to tak nazwać, użyteczność Helm CLI, która jest instalowana na komputerze, laptopie, mainframe — na czymkolwiek.
Ale to nie wystarcza. Helm ma komponent serwera Tiller. Reprezentuje on interesy Helma wewnątrz klastra, jest to tak samo aplikacja wewnątrz klastra Kubernetes, jak każda inna.
Następnym komponentem jest Chart Repo — repozytorium z chartami. Istnieje oficjalne repozytorium i może być prywatne repozytorium firmy lub projektu.
Interakcja
Rozważmy, jak komponenty architektury interagują, gdy chcemy zainstalować aplikację za pomocą Helma.
- Mówimy
Helm install, zwracamy się do repozytorium (Chart Repo) i otrzymujemy Helm-chart.
- Narzędzie Helm (Helm CLI) interaguje z Kubeconfig, aby ustalić, do którego klastra się odwołać.
- Uzyskawszy te informacje, narzędzie zwraca się do Tiller, który znajduje się w naszym klastrze, już jako aplikacja.
- Tiller zwraca się do Kube-apiserver, aby wykonać działania w Kubernetes, stworzyć określone obiekty (usługi, podzie, repliki, sekrety itp.).
Następnie uprościmy schemat, aby zobaczyć wektory ataku, którym może zostać poddana cała architektura Helm. A potem spróbujemy ją zabezpieczyć.
Wektory ataku
Pierwsze potencjalnie słabe miejsce — uprzywilejowane API—użytkownik. W ramach schematu to haker, który uzyskał dostęp administratora do Helm CLI.
Nieprivilegowany użytkownik API też może stanowić zagrożenie, jeśli znajduje się gdzieś w pobliżu. Taki użytkownik będzie miał inny kontekst, na przykład może być zarejestrowany w jednym namespace klastra w ustawieniach Kubeconfig.
Najbardziej interesującym wektorem ataku może być proces, który znajduje się wewnątrz klastra gdzieś w pobliżu Tillera i może się do niego zwrócić. Może to być serwer WWW lub mikroserwis, który widzi sieciowe otoczenie klastra.
Egzotyczna, ale rosnąca w popularność, opcja ataku związana jest z Chart Repo. Chart stworzony przez nieuczciwego autora może zawierać niebezpieczny zasób, a Ty go uruchomisz, przyjmując to na wiarę. Albo może on podmienić chart, który ściągasz z oficjalnego repozytorium, i na przykład stworzyć zasób w postaci polityk i eskalować sobie dostęp.
Spróbujemy obronić się przed atakami ze wszystkich tych czterech stron i dowiedzieć się, gdzie są problemy w architekturze Helma, a gdzie być może ich nie ma.
Uprośćmy schemat, dodajmy więcej elementów, ale zachowajmy wszystkie podstawowe składniki.
Helm CLI komunikuje się z Chart Repo, wchodzi w interakcję z Kubeconfig, a praca jest przekazywana do klastra do komponentu Tiller.
Tiller reprezentowany jest przez dwa obiekty:
- Tiller-deploy svc, który wystawia pewien serwis;
- Tiller-deploy pod (na schemacie w jedynym egzemplarzu w jednej replikacji), na którym działa cały obciążenie, który zwraca się do klastra.
Do interakcji używane są różne protokoły i schemy. Z punktu widzenia bezpieczeństwa najbardziej interesują nas:
- Mechanizm, za pomocą którego Helm CLI zwraca się do repozytoriów chartów: jaki protokół, czy jest autoryzacja i co można z tym zrobić.
- Protokół, po którym Helm CLI, używając kubectl, komunikuje się z Tillerem. To serwer RPC, zainstalowany wewnątrz klastra.
- Sam Tiller jest dostępny dla mikroserwisów, które znajdują się w klastrze, i wchodzi w interakcję z Kube-apiserver.
Omówimy wszystkie te kierunki po kolei.
RBAC
Bezsensownie jest mówić o jakimkolwiek bezpieczeństwie Helma lub innej usługi wewnątrz klastra, jeśli RBAC nie jest włączony.
Wydaje się, że to nie najświeższa rekomendacja, ale jestem pewien, że do tej pory wielu nie włączyło RBAC nawet w produkcji, ponieważ to dużo zachodu i trzeba wiele rzeczy ustawić. Niemniej jednak, zachęcam do zrobienia tego.
— strona adwokacka dla RBAC. Zgromadzono tam ogromną ilość interesujących materiałów, które pomogą w konfiguracji RBAC, pokażą, dlaczego jest on dobry i jak w ogóle żyć z nim w produkcji.
Postaram się wyjaśnić, jak działa Tiller i RBAC. Tiller działa wewnątrz klastra pod pewnym kontem serwisowym. Zazwyczaj, jeśli RBAC nie jest skonfigurowany, to będzie superuser. W podstawowej konfiguracji Tiller będzie administratorem. Dlatego często mówi się, że Tiller to tunel SSH do waszego klastra. W rzeczywistości tak jest, więc można użyć osobnego, wyspecjalizowanego konta serwisowego zamiast Domyślnego Konta Serwisowego na powyższym schemacie.
Gdy inicjalizujesz Helm, po raz pierwszy go instalując na serwerze, możesz określić konto serwisowe za pomocą --service-account. To pozwoli używać użytkownika z minimalnym zestawem niezbędnych uprawnień. Jednak trzeba będzie stworzyć taką „łańcuch”: Role i RoleBinding.
Niestety, Helm nie zrobi tego za ciebie. Ty lub twój administrator klastra Kubernetes musicie wcześniej przygotować zestaw Role, RoleBinding dla konta serwisowego, aby przekazać Helm.
Pojawia się pytanie — jaka jest różnica między Role a ClusterRole? Różnica polega na tym, że ClusterRole działa dla wszystkich przestrzeni nazw, w przeciwieństwie do zwykłych Role i RoleBinding, które działają tylko dla wyspecjalizowanej przestrzeni nazw. Można skonfigurować polityki zarówno dla całego klastra i wszystkich przestrzeni nazw, jak i spersonalizowane dla każdej przestrzeni nazw oddzielnie.
Warto wspomnieć, że RBAC pozwala rozwiązać jeszcze jeden poważny problem. Wiele osób skarży się, że Helm, niestety, nie jest multitenancy (nie wspiera multiarendności). Jeśli kilka zespołów korzysta z klastra i używa Helma, zasadniczo niemożliwe jest skonfigurowanie polityk i ograniczenie ich dostępu w ramach tego klastra, ponieważ istnieje pewne konto serwisowe, z którego działa Helm i które tworzy wszystkie zasoby w klastrze, co czasami bywa bardzo niewygodne. Tak, to prawda — zarówno sam plik binarny, jak i proces, Helm Tiller nie ma pojęcia o multiarendności..
Jednak istnieje doskonały sposób, który pozwala uruchomić Tillera w klastrze kilka razy. Nie ma z tym żadnych problemów, Tiller można uruchomić w każdej przestrzeni nazw. Dzięki temu można skorzystać z RBAC, Kubeconfig jako kontekstu i ograniczyć dostęp do specjalnego Helma.
Będzie to wyglądać następująco.
Na przykład, istnieją dwa Kubeconfig z kontekstem dla różnych zespołów (dwa namespace): zespół X dla zespołu deweloperów oraz klaster administratora. Klaster administratora ma swój szeroki Tiller, który znajduje się w przestrzeni Kube-system namespace, więc posiada zaawansowane konto usługi. Jest oddzielny namespace dla zespołu deweloperów, mogą oni wprowadzać swoje usługi w specjalnym namespace.
To jest praktyczne podejście, Tiller nie jest na tyle zasobożerny, aby to miało poważny wpływ na Twój budżet. To jedno z szybciej działających rozwiązań.
Nie krępuj się dostosować osobno Tiller i dostarczyć Kubeconfig z kontekstem dla zespołu, konkretnego dewelopera lub dla środowiska: Dev, Staging, Production (mało prawdopodobne, że wszystko będzie w jednym klastrze, jednak można to zrealizować).
Kontynuując naszą opowieść, przełączymy się od RBAC i porozmawiamy o ConfigMaps.
ConfigMaps
Helm używa ConfigMaps jako magazynu danych. Kiedy mówiliśmy o architekturze, nie było tam żadnej bazy danych, w której przechowywane byłyby informacje o wydaniach, konfiguracjach, rollbacks itd. W tym celu używane są ConfigMaps.
Głównym problemem z ConfigMaps jest to, że są one zasadniczo niebezpieczne, ponieważ nie można w nich przechowywać danych wrażliwych.. Mówimy tu o wszystkim, co nie powinno wychodzić poza usługę, na przykład hasłach. Najbardziej natywnym sposobem dla Helma jest obecnie przejście od używania ConfigMaps do sekretów.
Jest to bardzo proste do zrealizowania. Przedefiniowujesz ustawienia Tillera i wskazujesz, że magazynem będą sekrety. Wtedy przy każdym wdrożeniu otrzymasz nie ConfigMap, a sekret.
Możesz zaprotestować, że sekrety same w sobie to dziwna koncepcja i nie są zbyt bezpieczne. Jednak warto zrozumieć, że tym zajmują się sami deweloperzy Kubernetes. Od wersji 1.10, a więc dość dawno temu, istnieje możliwość podłączenia odpowiedniego magazynu do przechowywania sekretów, przynajmniej w publicznych chmurach. Obecnie zespół pracuje nad tym, aby lepiej zarządzać dostępem do sekretów dla poszczególnych podów lub innych bytów.
Magazyn Helm lepiej przekształcić na sekrety, a te z kolei zabezpieczyć w sposób scentralizowany.
Oczywiście pozostanie limit przechowywania danych wynoszący 1 MB. Helm używa etcd jako rozproszonego magazynu dla ConfigMaps. Uznali tam, że to odpowiedni kawałek danych do replikacji itd. W tej kwestii jest ciekawe dyskusja na Reddit, polecam poszukać tej zabawnej lektury na weekend lub przeczytać podsumowanie. .
Repozytoria Chartów
Charty są najbardziej społecznie wrażliwe i mogą stać się źródłem «Man in the middle», szczególnie jeśli używasz domyślnego rozwiązania. Przede wszystkim chodzi o repozytoria, które są udostępniane przez HTTP.
Zdecydowanie należy udostępniać Helm Repo przez HTTPS — to najlepsza opcja i kosztuje niewiele.
Zwróć uwagę na mechanizm podpisów chartów. Technologia jest banalnie prosta. To to samo, co wykorzystujesz na GitHubie, zwykła maszyna PGP z kluczami publicznymi i prywatnymi. Skonfiguruj ją i będziesz miał pewność, że mając odpowiednie klucze, podpisujesz wszystko, co jest naprawdę twoim chartem.
Ponadto, Klient Helm obsługuje TLS (nie w sensie HTTP z serwera, a wzajemny TLS). Możesz użyć kluczy serwerowych i klienckich do komunikacji. Powiem szczerze, nie używam takiego mechanizmu z powodu niechęci do wzajemnych certyfikatów. W zasadzie, — główne narzędzie do udostępniania Helm Repo dla Helm 2 — obsługuje także basic auth. Można użyć basic auth, jeśli to wygodniejsze i zapewnia większy komfort.
Jest też wtyczka , która pozwala umieszczać Repozytoria Chartów w Google Cloud Storage. To dość wygodne, działa świetnie i jest dość bezpieczne, ponieważ wszystkie opisane mechanizmy są wdrażane.
Jeżeli włączysz HTTPS lub TLS, użyjesz mTLS, dodasz basic auth, aby jeszcze bardziej zmniejszyć ryzyko, uzyskasz bezpieczny kanał komunikacji między Helm CLI a Repozytorium Chartów.
gRPC API
Następny krok jest bardzo odpowiedzialny — zabezpieczyć Tiller, który znajduje się w klastrze i jest z jednej strony serwerem, a z drugiej strony — sam zwraca się do innych komponentów i stara się przedstawiać jako ktoś inny.
Jak już powiedziałem, Tiller — usługa, która udostępnia gRPC, klient Helm łączy się z nim przez gRPC. Domyślnie, oczywiście, TLS jest wyłączony. Dlaczego to zrobiono — to kwestia dyskusyjna, wydaje mi się, że dla uproszczenia konfiguracji na początku.
Dla produkcji, a nawet dla stagingu, zalecam włączenie TLS w gRPC.
Moim zdaniem, w przeciwieństwie do mTLS dla chartów, tutaj jest to na miejscu i robi się to bardzo prosto — generujesz infrastrukturę PQI, tworzysz certyfikat, uruchamiasz Tiller, przekazujesz certyfikat podczas inicjalizacji. Po tym wszystkim możesz wykonywać wszystkie polecenia Helm, posługując się wygenerowanym certyfikatem i kluczem prywatnym.
W ten sposób zabezpieczysz się przed wszystkimi zapytaniami do Tiller z zewnątrz klastra.
Więc zabezpieczyliśmy kanał połączenia z Tiller, już omówiliśmy RBAC i dostosowaliśmy prawa apiserwera Kubernetes, zmniejszyliśmy domenę, z którą może on współdziałać.
Zabezpieczony Helm
Przyjrzyjmy się ostatecznej schemacie. To ta sama architektura z tymi samymi strzałkami.
Wszystkie połączenia teraz można odważnie rysować na zielono:
- dla Chart Repo używamy TLS lub mTLS oraz uwierzytelniania podstawowego;
- mTLS dla Tiller, i jest on wystawiony jako usługa gRPC z TLS, używamy certyfikatów;
- w klastrze używany jest specjalny konto usługi z Rolą i RoleBinding.
Znacznie zabezpieczyliśmy klaster, ale ktoś mądry powiedział:
„Absolutnie bezpieczne rozwiązanie może być tylko jedno — wyłączony komputer, który znajduje się w betonowej skrzynce i jest strzeżony przez żołnierzy”.
Istnieją różne sposoby manipulacji danymi i znajdowania nowych wektorów ataków. Jednak jestem pewien, że te zalecenia pozwolą zrealizować podstawowy przemysłowy standard bezpieczeństwa.
Bonus
Ta część nie odnosi się bezpośrednio do bezpieczeństwa, ale również będzie przydatna. Pokażę niektóre interesujące rzeczy, o których niewiele osób wie. Na przykład, jak szukać chartów — oficjalnych i nieoficjalnych.
W repozytorium aktualnie jest około 300 chartów i dwa strumienie: stable i incubator. Ten, kto kontrybuuje, dobrze wie, jak trudno jest przejść z incubator do stable, i jak łatwo wylecieć ze stable. Jednak nie jest to najlepsze narzędzie do wyszukiwania chartów dla Prometheusa i wszystkiego, co lubisz, z jednego prostego powodu — to nie portal, gdzie wygodnie można szukać pakietów.
Ale jest usługa , z pomocą której łatwiej jest znaleźć chart. Najważniejsze, że jest tam znacznie więcej zewnętrznych repozytoriów i dostępnych jest prawie 800 chartów. Dodatkowo, możesz podłączyć swoje repozytorium, jeśli z jakichkolwiek powodów nie chcesz wysyłać swoich chartów do stable.
Wypróbuj hub.helm.sh i rozwijajmy go razem. Ta usługa jest pod projektem Helm, a ty możesz kontrybucjować nawet w jego UI, jeśli jesteś frontendowcem i chcesz po prostu poprawić wygląd.
Chciałbym jeszcze zwrócić uwagę na integrację Open Service Broker API. Brzmi to skomplikowanie i niejasno, ale rozwiązuje problemy, z którymi wszyscy się borykają. Wyjaśnię na prostym przykładzie.
Mamy klaster Kubernetes, w którym chcemy uruchomić klasyczną aplikację — WordPress. Zazwyczaj do pełnej funkcjonalności potrzebna jest baza danych. Istnieje wiele różnych rozwiązań, na przykład można uruchomić własną usługę stateful. To nie jest zbyt wygodne, ale wielu tak robi.
Inni, na przykład my w Chainstack, korzystają z zarządzanych baz danych, takich jak MySQL czy PostgreSQL, dla serwerów. Dlatego nasza baza danych znajduje się gdzieś w chmurze.
Ale pojawia się problem: trzeba połączyć naszą usługę z bazą danych, stworzyć flavor bazy danych, przekazać dane uwierzytelniające i jakoś nimi zarządzać. Wszystko to zazwyczaj wykonywane jest ręcznie przez administratora systemu lub programistę. Nie ma problemu, gdy jest mało aplikacji. Gdy jest ich dużo, potrzebny jest kombajn. Taki kombajn istnieje — to Service Broker. Umożliwia korzystanie ze specjalnego pluginu do klastra chmurowego i zamawianie zasobów od dostawcy przez Brokera, jakby to był API. Można do tego wykorzystać natywne narzędzia Kubernetes.
To bardzo proste. Można na przykład zażądać Managed MySQL w Azure z podstawowym tier (można to skonfigurować). Korzystając z API Azure, baza danych zostanie utworzona i przygotowana do użycia. Nie będziesz musiał w to ingerować, tym zajmuje się plugin. Na przykład, OSBA (plugin Azure) zwróci dane uwierzytelniające do usługi i przekaże je Helm. Będziesz mógł korzystać z WordPressa z chmurowym MySQL, nie martwiąc się o zarządzane bazy danych i o stateful usługi wewnątrz.
Można powiedzieć, że Helm pełni rolę kleju, który z jednej strony pozwala wdrażać usługi, a z drugiej — korzystać z zasobów dostawców chmury.
Możesz napisać własny plugin i wykorzystać tę historię on-premise. Wtedy po prostu będziesz mieć własny plugin do korporacyjnego dostawcy chmury. Polecam spróbować takiego podejścia, szczególnie jeśli masz dużą skalę i chcesz szybko uruchomić dev, staging lub całą infrastrukturę pod funkcjonalność. To uprości życie twoim działom operacyjnym lub DevOps.
Jeszcze jedno odkrycie, które już wspominałem — to plugin helm-gcs, który pozwala korzystać z Google-bucketów (przechowywanie obiektowe), aby przechowywać wykresy Helm.
Potrzebujesz tylko czterech poleceń, aby zacząć go używać:
- zainstalować plugin;
- zainicjować go;
- ustaw ścieżkę do bucketa znajdującego się w GCP;
- opublikować wykresy w standardowy sposób.
Piękno polega na tym, że będzie używana natywna metoda GCP do autoryzacji. Możesz użyć konta usługowego, konta dewelopera – czegokolwiek. To bardzo wygodne i nie kosztuje nic w eksploatacji. Jeśli, tak jak ja, propagujesz filozofię opsless, będzie to bardzo wygodne, zwłaszcza dla małych zespołów.
Alternatywy
Helm nie jest jedynym rozwiązaniem do zarządzania usługami. Wokół niego jest wiele pytań, więc może dlatego tak szybko pojawiła się trzecia wersja. Oczywiście istnieją alternatywy.
Mogą to być zarówno wyspecjalizowane rozwiązania, takie jak Ksonnet czy Metaparticle. Możesz użyć swoich klasycznych narzędzi do zarządzania infrastrukturą (Ansible, Terraform, Chef itp.) do tych samych celów, o których mówiłem.
Wreszcie, istnieje rozwiązanie , którego popularność rośnie.
Operator Framework to główna alternatywa dla Helma, na którą warto zwrócić uwagę.
Jest bardziej natywne dla CNCF i Kubernetes, ale próg wejścia jest znacznie wyższy, wymaga więcej programowania i mniej opisywania manifestów.
Istnieją różne dodatki, takie jak Draft, Scaffold. Znacznie ułatwiają życie, na przykład deweloperom upraszczają cykl wysyłania i uruchamiania Helma do wdrożenia środowiska testowego. Nazwałbym je rozszerzeniami możliwości.
Oto obrazkowy wykres pokazujący, gdzie co się znajduje.
Na osi X poziom twojej osobistej kontroli nad tym, co się dzieje, a na osi Y poziom natywności Kubernetes. Helm wersji 2 znajduje się gdzieś pośrodku. W wersji 3 nie jest to kolosalna zmiana, ale poprawiły się zarówno kontrola, jak i poziom natywności. Rozwiązania poziomu Ksonnet wciąż ustępują nawet Helmowi 2. Niemniej jednak warto im się przyjrzeć, aby wiedzieć, co jeszcze jest w tym świecie. Oczywiście twój menedżer konfiguracji będzie pod twoją kontrolą, ale zupełnie nie jest natywny dla Kubernetes.
Operator Framework jest absolutnie natywny dla Kubernetes i pozwala zarządzać nim znacznie elegancko i skrupulatnie (ale pamiętajmy o poziomie wejścia). Raczej nadaje się do specjalizowanej aplikacji i tworzenia dla niej zarządzania, a nie jako maszynka do pakowania ogromnej liczby aplikacji za pomocą Helma.
Rozszerzenia po prostu nieco poprawiają kontrolę, uzupełniają workflow lub przyspieszają CI/CD pipelines.
Przyszłość Helma
Dobrą wiadomością jest to, że pojawia się Helm 3. Już wydano wersję alfa Helm 3.0.0-alpha.2, można ją wypróbować. Jest dość stabilna, ale funkcjonalność jest póki co ograniczona.
Po co potrzebny jest Helm 3? Przede wszystkim to historia o zniknięciu Tiller, jako komponentu. To, jak już rozumiesz, ogromny krok naprzód, ponieważ z punktu widzenia bezpieczeństwa architektury wszystko staje się prostsze.
Kiedy tworzono Helm 2, a to było w czasach Kubernetes 1.8 lub nawet wcześniej, wiele koncepcji było niedojrzałych. Na przykład koncepcja CRD jest teraz aktywnie wdrażana, a Helm będzie korzystać z CRD, aby przechowywać struktury. Będzie możliwe używanie tylko klienta i nieposiadanie części serwerowej. W związku z tym można będzie używać natywnych komend Kubernetes do pracy ze strukturami i zasobami. To ogromny krok naprzód.
Pojawi się wsparcie dla natywnych repozytoriów OCI (Open Container Initiative). To ogromna inicjatywa, a Helm interesuje się nią przede wszystkim w celu umieszczania własnych chartów. Dochodzi do tego, że na przykład Docker Hub wspiera wiele standardów OCI. Nie chcę niczego przewidywać, ale być może klasyczni dostawcy repozytoriów Docker zaczną oferować możliwość umieszczania swoich Helm-chartów.
Kontrowersyjna dla mnie kwestia to wsparcie Lua, jako silnik szablonów do pisania skryptów. Nie jestem wielkim fanem Lua, ale to będzie całkowicie opcjonalna możliwość. Sprawdziłem to trzy razy — użycie Lua nie będzie obowiązkowe. Dlatego ten, kto chce, może korzystać z Lua, a ci, którzy wolą Go — dołączcie do naszego ogromnego obozu i używajcie go-tmpl do tego.
Wreszcie to, czego na pewno mi brakowało — to pojawienie się schemy i walidacja typów danych. Nie będzie już problemów z int czy string, nie będzie trzeba opakowywać zera w podwójne cudzysłowy. Pojawi się schema JSON, która pozwoli to wyraźnie opisać dla wartości.
Będzie bardzo silnie przepracowany model oparty na zdarzeniach. Jest już konceptualnie opisany. Sprawdźcie w wątku Helm 3 i zobaczycie, ile dodano zdarzeń, hooków i innych rzeczy, które znacznie uproszczą oraz, z drugiej strony, dodadzą kontroli nad procesami wdrożeniowymi i ich reakcjami.
Helm 3 będzie prostszy, bezpieczniejszy i ciekawszy nie dlatego, że nie lubimy Helm 2, ale dlatego, że Kubernetes staje się coraz bardziej zaawansowany. W związku z tym Helm może wykorzystać osiągnięcia Kubernetes i stworzyć na jego podstawie doskonałe menedżery dla Kubernetes.
Jeszcze jedną dobrą wiadomością jest to, że Aleksandr Chajorow opowie, Przypominamy, że konferencja poświęcona integracji procesów rozwoju, testowania i eksploatacji odbędzie się w Moskwie 30 września i 1 października. Do 20 sierpnia wciąż można i podzielić się swoim doświadczeniem w rozwiązywaniu zadań podejścia DevOps.
Śledź punkty kontrolne konferencji i nowości w i .
Źródło: habr.com
