Istotę opowieści o najpopularniejszym menedżerze pakietów dla Kubernetesa można zobrazować za pomocą emoji:
- pudełko to Helm (co jest najbardziej zbliżone do najnowszej wersji Emoji);
- zamek - bezpieczeństwo;
- mały człowiek jest rozwiązaniem problemu.
W rzeczywistości wszystko będzie trochę bardziej skomplikowane, a historia jest pełna szczegółów technicznych Jak sprawić, by Helm był bezpieczny.
- Krótko o tym, czym jest Helm, na wypadek gdybyś nie wiedział lub zapomniał. Jakie problemy rozwiązuje i gdzie się znajduje w ekosystemie.
- Przyjrzyjmy się architekturze Helma. Żadna rozmowa na temat bezpieczeństwa i sposobów zwiększania bezpieczeństwa narzędzia lub rozwiązania nie jest kompletna bez zrozumienia architektury komponentu.
- Omówmy komponenty Helma.
- Najbardziej palącym pytaniem jest przyszłość – nowa wersja Helma 3.
Wszystko w tym artykule dotyczy Helma 2. Ta wersja jest obecnie w fazie produkcyjnej i najprawdopodobniej jest tą, której aktualnie używasz, i jest to wersja zawierająca zagrożenia bezpieczeństwa.
O głośniku: Aleksander Chajorow () rozwija się od 10 lat, pomagając udoskonalać treści i dołączył do komisji . Teraz pracuje w Chainstack jako lider rozwoju - jest to hybryda pomiędzy menadżerem ds. rozwoju a osobą odpowiedzialną za dostarczanie finalnych wydań. Oznacza to, że znajduje się na polu bitwy, gdzie dzieje się wszystko, od stworzenia produktu po jego eksploatację.
Chainstack to mały, aktywnie rozwijający się startup, którego misją jest umożliwienie klientom zapomnienia o infrastrukturze i zawiłościach obsługi zdecentralizowanych aplikacji; zespół programistów zlokalizowany jest w Singapurze. Nie proś Chainstack o sprzedaż lub kupno kryptowaluty, ale zaproponuj rozmowę na temat frameworków blockchain dla przedsiębiorstw, a oni z radością Ci odpowiedzą.
Ster
To jest menedżer pakietów (wykresów) dla Kubernetes. Najbardziej intuicyjny i uniwersalny sposób na przeniesienie aplikacji do klastra Kubernetes.
Mówimy oczywiście o podejściu bardziej strukturalnym i przemysłowym niż tworzenie własnych manifestów YAML i pisanie małych narzędzi.
Helm jest najlepszym, jaki jest obecnie dostępny i popularny.
Dlaczego Helm? Przede wszystkim dlatego, że jest wspierany przez CNCF. Cloud Native jest dużą organizacją i jest spółką-matką dla projektów Kubernetes itp., Fluentd i innych.
Kolejnym ważnym faktem jest to, że Helm jest projektem bardzo popularnym. Kiedy w styczniu 2019 roku zacząłem mówić o tym, jak zapewnić bezpieczeństwo Helmowi, projekt miał tysiąc gwiazdek na GitHubie. W maju było ich już 12 tysięcy.
Wiele osób interesuje się Helmem, więc nawet jeśli jeszcze z niego nie korzystasz, skorzystasz na wiedzy o jego bezpieczeństwie. Bezpieczeństwo jest ważne.
Główny zespół Helm jest wspierany przez Microsoft Azure i dlatego jest dość stabilnym projektem, w przeciwieństwie do wielu innych. Wydanie Helm 3 Alpha 2 w połowie lipca wskazuje, że nad projektem pracuje całkiem sporo osób, które mają chęć i energię do rozwijania i ulepszania Helma.
Helm rozwiązuje kilka podstawowych problemów zarządzania aplikacjami w Kubernetesie.
- Opakowanie aplikacyjne. Nawet aplikacja taka jak „Hello, World” na WordPressie składa się już z kilku usług i chcesz je spakować w jedną całość.
- Zarządzanie złożonością związaną z zarządzaniem tymi aplikacjami.
- Cykl życia, który nie kończy się po zainstalowaniu lub wdrożeniu aplikacji. Nadal żyje, wymaga aktualizacji, a Helm pomaga w tym i stara się wprowadzić odpowiednie środki i polityki w tym zakresie.
Parcianka jest to zorganizowane w przejrzysty sposób: znajdują się tam metadane w pełni zgodne z pracą zwykłego menedżera pakietów dla systemów Linux, Windows czy MacOS. Oznacza to repozytorium, zależności od różnych pakietów, metainformacje dla aplikacji, ustawienia, funkcje konfiguracyjne, indeksowanie informacji itp. Helm pozwala uzyskać i wykorzystać to wszystko w aplikacjach.
Zarządzanie złożonością. Jeśli masz wiele aplikacji tego samego typu, konieczna jest parametryzacja. Z tego pochodzą szablony, ale aby uniknąć konieczności wymyślania własnego sposobu tworzenia szablonów, możesz skorzystać z tego, co oferuje Helm od razu po wyjęciu z pudełka.
Zarządzanie cyklem życia aplikacji - moim zdaniem to najciekawsza i nierozwiązana kwestia. Dlatego właśnie przyjechałem kiedyś do Helmu. Musieliśmy mieć oko na cykl życia aplikacji i chcieliśmy przenieść nasze cykle CI/CD i aplikacji do tego paradygmatu.
Helm umożliwia:
- zarządzać wdrożeniami, wprowadza koncepcję konfiguracji i rewizji;
- pomyślnie przeprowadzić wycofanie;
- używaj haków do różnych wydarzeń;
- dodaj dodatkowe kontrole aplikacji i reaguj na ich wyniki.
Ponadto Hełm ma „baterie” - ogromna liczba smacznych rzeczy, które można zawrzeć w formie wtyczek, upraszczając swoje życie. Wtyczki można pisać niezależnie, są dość izolowane i nie wymagają harmonijnej architektury. Jeśli chcesz coś zaimplementować, polecam zrobić to jako wtyczkę, a następnie ewentualnie dołączyć to do źródła.
Helm opiera się na trzech głównych koncepcjach:
- Repozytorium wykresów — opis i tablica parametrów możliwych dla Twojego manifestu.
- Config —czyli wartości, które zostaną zastosowane (tekst, wartości liczbowe itp.).
- Wydanie zbiera dwa górne składniki i razem zamieniają się w Uwolnienie. Wersje można wersjonować, uzyskując w ten sposób zorganizowany cykl życia: mały w momencie instalacji i duży w momencie aktualizacji, obniżenia wersji lub wycofania.
Architektura steru
Diagram koncepcyjnie przedstawia architekturę wysokiego poziomu Helma.
Przypomnę, że Helm to coś powiązanego z Kubernetesem. Dlatego nie możemy obejść się bez klastra Kubernetes (prostokąt). Komponent kube-apiserver znajduje się na serwerze głównym. Bez Helma mamy Kubeconfig. Helm oferuje jeden mały plik binarny, jeśli można to tak nazwać, narzędzie Helm CLI, które jest instalowane na komputerze, laptopie, komputerze mainframe - na czymkolwiek.
Ale to nie wystarczy. Helm ma komponent serwerowy o nazwie Tiller. Reprezentuje interesy Helma w klastrze, jest aplikacją w obrębie klastra Kubernetes, jak każda inna.
Kolejnym elementem Chart Repo jest repozytorium z wykresami. Istnieje oficjalne repozytorium i może istnieć prywatne repozytorium firmy lub projektu.
Wzajemne oddziaływanie
Przyjrzyjmy się, jak komponenty architektury współdziałają, gdy chcemy zainstalować aplikację za pomocą Helma.
- Rozmawiamy
Helm install, uzyskaj dostęp do repozytorium (Chart Repo) i pobierz wykres Helm.
- Narzędzie Helm (Helm CLI) współdziała z Kubeconfig, aby dowiedzieć się, z którym klastrem się skontaktować.
- Po otrzymaniu tej informacji narzędzie odnosi się do Tillera, który znajduje się w naszym klastrze, jako aplikacji.
- Tiller wywołuje Kube-apiserver w celu wykonania akcji w Kubernetesie, utworzenia niektórych obiektów (usług, podów, replik, sekretów itp.).
Następnie skomplikujemy diagram, aby zobaczyć wektor ataku, na który może być narażona cała architektura Helm. A potem postaramy się ją chronić.
Wektor ataku
Pierwszym potencjalnym słabym punktem jest uprzywilejowane API-użytkownik. W ramach schematu jest to haker, który uzyskał dostęp administracyjny do interfejsu wiersza polecenia Helm.
Nieuprzywilejowany użytkownik API może również stanowić zagrożenie, jeśli znajduje się gdzieś w pobliżu. Taki użytkownik będzie miał inny kontekst, np. można go ustawić w jednej przestrzeni nazw klastra w ustawieniach Kubeconfig.
Najciekawszym wektorem ataku może być proces znajdujący się w klastrze gdzieś w pobliżu Tillera i mający do niego dostęp. Może to być serwer WWW lub mikrousługa, która widzi środowisko sieciowe klastra.
Egzotyczny, ale coraz bardziej popularny wariant ataku obejmuje Chart Repo. Wykres stworzony przez pozbawionego skrupułów autora może zawierać niebezpieczne zasoby, a Ty go uzupełnisz, przyjmując go na wiarę. Lub może zastąpić wykres, który pobierzesz z oficjalnego repozytorium i np. utworzyć zasób w postaci polityk i eskalować jego dostęp.
Spróbujmy odeprzeć ataki ze wszystkich czterech stron i dowiedzieć się, gdzie występują problemy w architekturze Helma, a gdzie być może ich nie ma.
Powiększmy diagram, dodajmy więcej elementów, ale zachowajmy wszystkie podstawowe elementy.
Interfejs wiersza polecenia Helm komunikuje się z Chart Repo, współdziała z Kubeconfig, a praca jest przenoszona do klastra do komponentu Tiller.
Tiller jest reprezentowany przez dwa obiekty:
- Tiller-deploy svc, który udostępnia określoną usługę;
- Tiller-deploy pod (na schemacie w jednym egzemplarzu w jednej replice), na którym pracuje całe obciążenie, które uzyskuje dostęp do klastra.
Do interakcji wykorzystywane są różne protokoły i schematy. Z punktu widzenia bezpieczeństwa najbardziej interesują nas:
- Mechanizm, za pomocą którego interfejs wiersza polecenia Helm uzyskuje dostęp do repozytorium wykresów: jaki protokół, czy istnieje uwierzytelnianie i co można z nim zrobić.
- Protokół, za pomocą którego Helm CLI za pomocą kubectl komunikuje się z Tillerem. Jest to serwer RPC zainstalowany wewnątrz klastra.
- Sam Tiller jest dostępny dla mikrousług znajdujących się w klastrze i współdziałających z Kube-apiserverem.
Omówmy wszystkie te obszary w kolejności.
RBAC
Nie ma sensu mówić o jakimkolwiek bezpieczeństwie Helma lub jakiejkolwiek innej usługi w klastrze, chyba że włączona jest funkcja RBAC.
Wydaje się, że nie jest to najnowsza rekomendacja, ale jestem pewien, że wiele osób nadal nie włączyło RBAC nawet na produkcji, bo jest z tym sporo zamieszania i mnóstwo rzeczy trzeba skonfigurować. Zachęcam Cię jednak do tego.
— prawnik zajmujący się stroną internetową RBAC. Zawiera ogromną ilość ciekawych materiałów, które pomogą Ci założyć RBAC, pokażą dlaczego jest dobry i jak w zasadzie z nim żyć na produkcji.
Spróbuję wyjaśnić, jak działają Tiller i RBAC. Tiller działa wewnątrz klastra w ramach określonego konta usługi. Zazwyczaj, jeśli funkcja RBAC nie jest skonfigurowana, będzie to superużytkownik. W podstawowej konfiguracji Tiller będzie administratorem. Dlatego często mówi się, że Tiller jest tunelem SSH do Twojego klastra. Faktycznie jest to prawdą, dlatego zamiast Domyślnego Konta Usługowego pokazanego na powyższym schemacie możesz skorzystać z osobnego, dedykowanego konta serwisowego.
Kiedy inicjujesz Helm i instalujesz go na serwerze po raz pierwszy, możesz ustawić konto usługi za pomocą --service-account. Umożliwi to korzystanie z użytkownika z minimalnym wymaganym zestawem uprawnień. To prawda, że \u200b\u200bbędziesz musiał stworzyć taką „girlandę”: Rolę i RoleBinding.
Niestety Helm nie zrobi tego za Ciebie. Aby przekazać Helm, Ty lub Twój administrator klastra Kubernetes musicie przygotować zestaw ról i powiązań ról dla konta usługi.
Powstaje pytanie - jaka jest różnica między rolą a rolą klastra? Różnica polega na tym, że ClusterRole działa dla wszystkich przestrzeni nazw, w przeciwieństwie do zwykłych ról i RoleBindings, które działają tylko w wyspecjalizowanej przestrzeni nazw. Możesz skonfigurować zasady dla całego klastra i wszystkich przestrzeni nazw lub spersonalizować je indywidualnie dla każdej przestrzeni nazw.
Warto wspomnieć, że RBAC rozwiązuje kolejny duży problem. Wiele osób narzeka, że Helm niestety nie obsługuje wielu dzierżawców (nie obsługuje wielu dzierżawców). Jeśli kilka zespołów korzysta z klastra i korzysta z Helma, zasadniczo niemożliwe jest skonfigurowanie zasad i ograniczenie ich dostępu w ramach tego klastra, ponieważ istnieje określone konto usługi, w ramach którego Helm działa i z niego tworzy wszystkie zasoby w klastrze , co czasami jest bardzo niewygodne. To prawda – podobnie jak sam plik binarny, podobnie jak proces, Helm Tiller nie ma koncepcji wielodostępności.
Istnieje jednak świetny sposób, który pozwala na wielokrotne uruchamianie Tillera w klastrze. Nie ma z tym problemu, Tiller można uruchomić w każdej przestrzeni nazw. W ten sposób możesz użyć RBAC, Kubeconfig jako kontekstu i ograniczyć dostęp do specjalnego Helma.
To będzie wyglądać tak.
Na przykład istnieją dwie Kubeconfigs z kontekstem dla różnych zespołów (dwie przestrzenie nazw): X Team dla zespołu programistów i klaster administracyjny. Klaster administracyjny ma swój własny, szeroki Tiller, który znajduje się w przestrzeni nazw Kube-system, odpowiednio zaawansowane konto usługi. Dzięki oddzielnej przestrzeni nazw dla zespołu programistów będą mogli wdrażać swoje usługi w specjalnej przestrzeni nazw.
Jest to wykonalne podejście, Tiller nie jest tak energochłonny, że będzie to miało duży wpływ na Twój budżet. To jedno z szybkich rozwiązań.
Zapraszam do osobnej konfiguracji Tillera i zapewnienia Kubeconfig kontekstu dla zespołu, dla konkretnego dewelopera czy dla środowiska: Dev, Staging, Production (wątpliwe jest, żeby wszystko było w tym samym klastrze, jednak da się to zrobić).
Kontynuując naszą historię, przejdźmy od RBAC i porozmawiajmy o ConfigMaps.
ConfigMap
Helm używa ConfigMaps jako magazynu danych. Kiedy rozmawialiśmy o architekturze, nie było nigdzie bazy danych, która przechowywałaby informacje o wydaniach, konfiguracjach, wycofaniach itp. Służy do tego ConfigMaps.
Główny problem ConfigMaps jest znany - z zasady są one niebezpieczne; nie ma możliwości przechowywania wrażliwych danych. Mówimy o wszystkim, co nie powinno wykraczać poza usługę, na przykład hasłach. Najbardziej natywnym sposobem dla Helma jest obecnie przejście z używania ConfigMaps na sekrety.
Odbywa się to bardzo prosto. Zastąp ustawienie Tiller i określ, że magazyn będzie tajny. Następnie do każdego wdrożenia otrzymasz nie ConfigMap, ale sekret.
Można argumentować, że tajemnice same w sobie są dziwną koncepcją i niezbyt bezpieczną. Warto jednak zrozumieć, że robią to sami programiści Kubernetesa. Począwszy od wersji 1.10, tj. Od dłuższego czasu możliwe jest, przynajmniej w chmurach publicznych, podłączenie odpowiedniego magazynu do przechowywania sekretów. Zespół pracuje obecnie nad sposobami lepszego rozpowszechniania dostępu do sekretów, poszczególnych zasobników lub innych podmiotów.
Lepiej przenieść Hełm Magazynu do sekretów, a one z kolei są zabezpieczone centralnie.
Oczywiście, że tak pozostanie limit przechowywania danych 1 MB. Helm używa tutaj etcd jako rozproszonej pamięci masowej dla ConfigMaps. I tam uznali, że jest to odpowiedni fragment danych do replikacji itp. Na Reddicie jest ciekawa dyskusja na ten temat, polecam znaleźć tę zabawną lekturę na weekend lub przeczytać fragment .
Repozytorium wykresów
Wykresy są najbardziej wrażliwe społecznie i mogą stać się źródłem „Człowieka pośrodku”, szczególnie jeśli korzystasz z rozwiązania giełdowego. Przede wszystkim mówimy o repozytoriach udostępnianych za pośrednictwem protokołu HTTP.
Zdecydowanie musisz udostępnić Helm Repo przez HTTPS — jest to najlepsza opcja i niedroga.
Zwróć uwagę na mechanizm podpisu wykresu. Technologia jest prosta jak cholera. To jest to samo, czego używasz na GitHubie, zwykłej maszynie PGP z kluczami publicznymi i prywatnymi. Skonfiguruj i upewnij się, mając niezbędne klucze i podpisując wszystko, że to naprawdę Twój wykres.
RљSЂRѕRјRμ S, RѕRіRѕ, Klient Helm obsługuje protokół TLS (nie w sensie HTTP po stronie serwera, ale wzajemny TLS). Do komunikacji można używać kluczy serwera i klienta. Szczerze mówiąc nie korzystam z takiego mechanizmu, bo nie lubię wzajemnych certyfikatów. Zasadniczo, - główne narzędzie do konfigurowania Helm Repo dla Helm 2 - obsługuje również podstawowe uwierzytelnianie. Możesz użyć podstawowego uwierzytelniania, jeśli jest to wygodniejsze i cichsze.
Jest też wtyczka , która umożliwia hostowanie repozytoriów wykresów w Google Cloud Storage. Jest to dość wygodne, działa świetnie i jest całkiem bezpieczne, ponieważ wszystkie opisane mechanizmy podlegają recyklingowi.
Jeśli włączysz HTTPS lub TLS, użyj mTLS i włączysz podstawowe uwierzytelnianie, aby jeszcze bardziej zmniejszyć ryzyko, otrzymasz bezpieczny kanał komunikacji z Helm CLI i Chart Repo.
API gRPC
Bardzo ważny jest kolejny krok - zabezpieczenie Tillera, który znajduje się w klastrze i jest z jednej strony serwerem, z drugiej sam uzyskuje dostęp do innych komponentów i stara się kogoś podszywać.
Jak już powiedziałem, Tiller to usługa udostępniająca gRPC, klient Helm przychodzi do niej za pośrednictwem gRPC. Domyślnie TLS jest oczywiście wyłączony. Dlaczego tak zrobiono, jest kwestią dyskusyjną, wydaje mi się, że upraszcza to konfigurację na początku.
W przypadku produkcji, a nawet przemieszczania, polecam włączenie TLS na gRPC.
Moim zdaniem, w przeciwieństwie do mTLS dla wykresów, jest to tutaj właściwe i odbywa się w bardzo prosty sposób - wygeneruj infrastrukturę PQI, utwórz certyfikat, uruchom Tillera, przenieś certyfikat podczas inicjalizacji. Następnie możesz wykonać wszystkie polecenia Helma, prezentując wygenerowany certyfikat i klucz prywatny.
W ten sposób zabezpieczysz się przed wszystkimi żądaniami kierowanymi do Tillera spoza klastra.
Zabezpieczyliśmy więc kanał połączenia do Tillera, omówiliśmy już RBAC i dostosowaliśmy uprawnienia apiservera Kubernetes, ograniczając domenę, z którą może on współdziałać.
Chroniony hełm
Spójrzmy na końcowy diagram. To ta sama architektura z tymi samymi strzałkami.
Wszystkie połączenia można teraz bezpiecznie narysować na zielono:
- w przypadku Chart Repo używamy TLS lub mTLS i podstawowego uwierzytelniania;
- mTLS dla Tillera i jest udostępniany jako usługa gRPC z TLS, używamy certyfikatów;
- klaster używa specjalnego konta usługi z rolami i rolami.
Klaster znacząco zabezpieczyliśmy, ale ktoś mądry powiedział:
„Może być tylko jedno całkowicie bezpieczne rozwiązanie – wyłączony komputer, który znajduje się w betonowej skrzyni i jest strzeżony przez żołnierzy”.
Istnieją różne sposoby manipulowania danymi i znajdowania nowych wektorów ataku. Jestem jednak pewien, że te zalecenia pozwolą osiągnąć podstawowy standard branżowy w zakresie bezpieczeństwa.
Bonus
Ta część nie jest bezpośrednio związana z bezpieczeństwem, ale również będzie przydatna. Pokażę Ci kilka ciekawych rzeczy, o których niewiele osób wie. Na przykład, jak wyszukiwać wykresy - oficjalne i nieoficjalne.
W repozytorium Obecnie istnieje około 300 wykresów i dwa strumienie: stabilny i inkubator. Każdy, kto pomaga, doskonale wie, jak trudno jest dostać się z inkubatora do stajni i jak łatwo wylecieć ze stajni. Nie jest to jednak najlepsze narzędzie do wyszukiwania wykresów dla Prometheusa i czegokolwiek innego, z jednego prostego powodu - nie jest to portal, na którym można wygodnie wyszukiwać pakiety.
Ale jest usługa , co znacznie ułatwia wyszukiwanie wykresów. Co najważniejsze, dostępnych jest znacznie więcej zewnętrznych repozytoriów i prawie 800 uroków. Dodatkowo możesz podłączyć swoje repozytorium, jeśli z jakiegoś powodu nie chcesz wysyłać swoich wykresów do wersji stabilnej.
Wypróbuj hub.helm.sh i wspólnie go opracujmy. Ta usługa jest objęta projektem Helm i możesz nawet wnieść swój wkład w jej interfejs użytkownika, jeśli jesteś programistą front-end i chcesz po prostu poprawić wygląd.
Na co również chciałbym zwrócić Państwa uwagę Integracja API Open Service Broker. Brzmi uciążliwie i niejasno, ale rozwiązuje problemy, z którymi boryka się każdy. Wyjaśnię to na prostym przykładzie.
Istnieje klaster Kubernetes, w którym chcemy uruchomić klasyczną aplikację - WordPress. Ogólnie rzecz biorąc, do pełnej funkcjonalności potrzebna jest baza danych. Istnieje wiele różnych rozwiązań, możesz na przykład uruchomić własną usługę statefull. Nie jest to zbyt wygodne, ale wiele osób tak robi.
Inni, jak my w Chainstack, używają zarządzanych baz danych, takich jak MySQL lub PostgreSQL na swoich serwerach. Dlatego nasze bazy danych znajdują się gdzieś w chmurze.
Pojawia się jednak problem: musimy połączyć naszą usługę z bazą danych, stworzyć wersję bazy danych, przenieść dane uwierzytelniające i jakoś nią zarządzać. Wszystko to zwykle robi ręcznie administrator systemu lub programista. I nie ma problemu, gdy aplikacji jest niewiele. Gdy jest ich dużo, potrzebny jest kombajn. Jest taki kombajn - jest to Service Broker. Umożliwia wykorzystanie specjalnej wtyczki dla klastra chmury publicznej i zamawianie zasobów od dostawcy poprzez Brokera, tak jakby był to API. Można w tym celu skorzystać z natywnych narzędzi Kubernetes.
To jest bardzo proste. Możesz na przykład wysyłać zapytania do zarządzanego MySQL na platformie Azure za pomocą warstwy podstawowej (można to skonfigurować). Za pomocą Azure API baza danych zostanie utworzona i przygotowana do użycia. Nie musisz się w to ingerować, wtyczka jest za to odpowiedzialna. Na przykład OSBA (wtyczka Azure) zwróci poświadczenia do usługi i przekaże je do Helm. Będziesz mógł używać WordPressa z chmurą MySQL, w ogóle nie zajmować się zarządzanymi bazami danych i nie martwić się o usługi stanowe w środku.
Można powiedzieć, że Helm działa jak klej, który z jednej strony pozwala na wdrażanie usług, a z drugiej konsumuje zasoby dostawców chmury.
Możesz napisać własną wtyczkę i korzystać z całej tej historii lokalnie. Wtedy będziesz mieć po prostu własną wtyczkę dla korporacyjnego dostawcy chmury. Polecam wypróbowanie tego podejścia, szczególnie jeśli masz dużą skalę i chcesz szybko wdrożyć programowanie, przemieszczanie lub całą infrastrukturę dla danej funkcji. Ułatwi to życie Twoim operacjom lub DevOps.
Kolejnym znaleziskiem, o którym już wspomniałem, jest wtyczka Helm-gcs, która umożliwia używanie zasobników Google (przechowywanie obiektów) do przechowywania wykresów Helm.
Aby zacząć z niego korzystać, potrzebujesz tylko czterech poleceń:
- zainstaluj wtyczkę;
- zainicjuj to;
- ustaw ścieżkę do wiadra, który znajduje się w gcp;
- publikuj wykresy w standardowy sposób.
Piękno polega na tym, że do autoryzacji zostanie użyta natywna metoda gcp. Możesz używać konta usługi, konta programisty, cokolwiek chcesz. Jest to bardzo wygodne i nic nie kosztuje w obsłudze. Jeśli tak jak ja propagujesz filozofię opsless, będzie to bardzo wygodne, szczególnie dla małych zespołów.
Alternatywy
Helm nie jest jedynym rozwiązaniem do zarządzania usługami. Pytań na ten temat jest mnóstwo, pewnie dlatego tak szybko pojawiła się trzecia wersja. Oczywiście, że istnieją alternatywy.
Mogą to być specjalistyczne rozwiązania, na przykład Ksonnet lub Metaparticle. Możesz używać 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 najlepsza alternatywa Helma do rozważenia.
Jest bardziej natywny dla CNCF i Kubernetes, ale bariera wejścia jest znacznie wyższa, musisz więcej programować i mniej opisywać manifesty.
Istnieją różne dodatki, takie jak Draft, Scaffold. Bardzo ułatwiają życie, na przykład upraszczają cykl wysyłania i uruchamiania Helma dla programistów w celu wdrożenia środowiska testowego. Nazwałbym ich autorytetami.
Oto wizualny wykres pokazujący, gdzie wszystko się znajduje.
Na osi x poziom Twojej osobistej kontroli nad tym, co się dzieje, na osi y poziom natywności Kubernetesa. Helm w wersji 2 plasuje się gdzieś pośrodku. W wersji 3 nie bardzo, ale poprawiono zarówno kontrolę, jak i poziom natywności. Rozwiązania na poziomie Ksonnet nadal ustępują nawet Helmowi 2. Warto jednak się im przyjrzeć, żeby wiedzieć, co jeszcze na tym świecie. Oczywiście Twój menedżer konfiguracji będzie pod Twoją kontrolą, ale absolutnie nie jest on natywny dla Kubernetes.
Operator Framework jest całkowicie natywny dla Kubernetesa i pozwala zarządzać nim znacznie bardziej elegancko i skrupulatnie (pamiętaj jednak o poziomie podstawowym). Raczej nadaje się to do specjalistycznej aplikacji i tworzenia dla niej zarządzania, a nie zbiorczego zbioru do pakowania ogromnej liczby aplikacji za pomocą Helma.
Extendery po prostu poprawiają nieco kontrolę, uzupełniają przepływ pracy lub skracają drogę w potokach CI/CD.
Przyszłość Helma
Dobra wiadomość jest taka, że nadchodzi Helm 3. Wersja alfa Helma 3.0.0-alpha.2 została już wydana, możesz ją wypróbować. Jest dość stabilny, ale funkcjonalność jest nadal ograniczona.
Dlaczego potrzebujesz Helma 3? Przede wszystkim jest to opowieść o zniknięcie Tillera, jako komponent. To, jak już rozumiesz, jest ogromnym krokiem naprzód, ponieważ z punktu widzenia bezpieczeństwa architektury wszystko jest uproszczone.
Kiedy tworzono Helm 2, czyli mniej więcej w czasie Kubernetesa 1.8 lub nawet wcześniej, wiele koncepcji było niedojrzałych. Na przykład koncepcja CRD jest obecnie aktywnie wdrażana i Helm to zrobi skorzystaj z CRDdo przechowywania konstrukcji. Będzie można korzystać wyłącznie z klienta i nie zajmować się częścią serwerową. W związku z tym używaj natywnych poleceń Kubernetes do pracy ze strukturami i zasobami. To ogromny krok naprzód.
Pojawi się obsługa natywnych repozytoriów OCI (Inicjatywa Otwartego Kontenera). To ogromna inicjatywa, a Helm jest zainteresowany przede wszystkim po to, aby publikować swoje wykresy. Dochodzi do tego, że np. Docker Hub obsługuje wiele standardów OCI. Nie zgaduję, ale być może klasyczni dostawcy repozytoriów Dockera zaczną dawać Ci możliwość hostowania wykresów Helm.
Dla mnie kontrowersyjna historia Wsparcie Lui, jako silnik szablonów do pisania skryptów. Nie jestem wielkim fanem Lua, ale byłaby to całkowicie opcjonalna funkcja. Sprawdziłem to 3 razy - używanie Lua nie będzie konieczne. Dlatego ci, którzy chcą móc korzystać z Lua, ci, którzy lubią Go, dołączają do naszego ogromnego obozu i używają do tego go-tmpl.
Wreszcie to, czego zdecydowanie mi brakowało pojawienie się schematu i walidacja typu danych. Nie będzie już problemów z int lub stringiem, nie będzie potrzeby zawijania zera w cudzysłów. Pojawi się schemat JSONS, który pozwoli ci jawnie opisać to dla wartości.
Zostanie mocno przerobiony model sterowany zdarzeniami. Zostało to już koncepcyjnie opisane. Spójrz na gałąź Helm 3, a zobaczysz, ile zdarzeń, hooków i innych rzeczy zostało dodanych, co z jednej strony znacznie uprości, a z drugiej strony doda kontrolę nad procesami wdrażania i reakcjami na nie.
Helm 3 będzie prostszy, bezpieczniejszy i przyjemniejszy nie dlatego, że nie lubimy Helm 2, ale dlatego, że Kubernetes staje się coraz bardziej zaawansowany. W związku z tym Helm może korzystać z rozwoju Kubernetesa i tworzyć na nim doskonałych menedżerów dla Kubernetesa.
Kolejna dobra wiadomość jest taka Aleksander Chajorow powie ci, Przypomnijmy, że w Moskwie odbędzie się konferencja poświęcona integracji procesów rozwoju, testowania i eksploatacji 30 września i 1 października. Można to zrobić jeszcze do 20 sierpnia i opowiedz nam o swoich doświadczeniach z rozwiązaniem zadania podejścia DevOps.
Śledź punkty kontrolne konferencji i aktualności na stronie и .
Źródło: www.habr.com