Kubernetes & Helm Fundamentals

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Kubernetesa i Helma, odcinek 1 z 10. Przez lata Google zarządzało swoją globalną infrastrukturą wyszukiwania i poczty e-mail przy użyciu ściśle tajnego systemu, nazwanego na cześć najstraszniejszych czarnych charakterów ze Star Treka. Musieli go wymyślić, ponieważ istniejące rozwiązania do zarządzania serwerami po prostu nie wyrabiały przy ich skali. Dzisiaj przyjrzymy się jego początkom, od Borga do Kubernetesa, i dowiemy się, dlaczego współczesne firmy tak bardzo na nim polegają. Żeby zrozumieć, dlaczego Kubernetes w ogóle istnieje, musisz spojrzeć na to, jak ewoluował deployment aplikacji. W erze tradycyjnego deploymentu uruchamiałeś aplikacje na fizycznych serwerach. Nie było sposobu na zdefiniowanie limitów zasobów. Jeśli jedna aplikacja zajmowała większość pamięci, cierpiały na tym inne aplikacje na tym samym fizycznym serwerze. Mogłeś kupić osobną fizyczną maszynę dla każdej aplikacji, ale to prowadziło do drogiego i niedostatecznie wykorzystanego sprzętu. Potem nadeszła era zwirtualizowanego deploymentu. Uruchamiałeś wiele maszyn wirtualnych, czyli VM-ek, na procesorze jednego fizycznego serwera. VM-ki izolowały aplikacje i zapewniały pewien poziom bezpieczeństwa, ale każda z nich wciąż wymagała pełnego, ciężkiego systemu operacyjnego. W końcu dotarliśmy do ery deploymentu kontenerów. Kontenery są podobne do maszyn wirtualnych, ale współdzielą bazowy system operacyjny między aplikacjami. Ponieważ są odseparowane od sprzętu, są lekkie, szybko się uruchamiają i można je łatwo przenosić między różnymi chmurami i dystrybucjami systemów operacyjnych. Ale kontenery wprowadziły nowy problem. Jeśli uruchamiasz globalną aplikację enterprise, nie masz tylko jednego kontenera. Masz ich tysiące. Jeśli kontener padnie, natychmiast musi wystartować kolejny. Jeśli ruch skoczy, musisz odpalić więcej kontenerów i równomiernie rozłożyć load w sieci. Nie jesteś w stanie zarządzać tym ręcznie na setkach maszyn. Google zmierzyło się z dokładnie tym samym problemem na długo przed resztą branży. Zbudowali wewnętrznego menedżera klastrów kontenerowych o nazwie Borg, żeby zautomatyzować orkiestrację setek tysięcy jobów. Kiedy stało się jasne, że reszta świata software'u potrzebuje dokładnie tego samego, inżynierowie Google wystartowali z projektem open-source, opartym na lekcjach wyciągniętych z Borga. Dodali do niego nawiązanie do Star Treka, początkowo nazywając go Project Seven of Nine, co było ukłonem w stronę drona Borg, który uciekł z kolektywu. Ten projekt ostatecznie ujrzał światło dzienne jako Kubernetes. Logo steru, które widzisz dzisiaj, ma siedem ramion jako cichy hołd dla tej oryginalnej nazwy projektu. I to jest ta najważniejsza część. Kubernetes daje ci framework do niezawodnego uruchamiania systemów rozproszonych. Dba o skalowanie i failover twojej aplikacji. Jeśli kontener zaliczy crasha, Kubernetes go zastępuje. Jeśli node padnie, robi reschedule kontenerów na zdrowe node'y. Ogarnia service discovery, co oznacza, że kontener można znaleźć po nazwie DNS lub jego własnym adresie IP, i robi load balancing, żeby żaden pojedynczy kontener nie był przeciążony. Zarządza też orkiestracją storage'u, pozwalając ci automatycznie montować lokalny storage lub ten od dostawców chmurowych, a do tego automatyzuje rollouty i rollbacki. Opisujesz pożądany stan swoich zdeployowanych kontenerów, a Kubernetes zmienia aktualny stan na ten pożądany w kontrolowanym tempie. Nie piszesz skryptów do zarządzania stanem serwera; deklarujesz, czego chcesz, a system po prostu to robi. Główny wniosek jest taki, że Kubernetes to nie tylko środowisko hostingowe, to control loop, który stale porównuje rzeczywistość z twoimi oczekiwaniami i koryguje różnice. Zanim skończymy, jeśli chcesz nam pomóc w dalszym tworzeniu tych odcinków, wyszukaj DevStoriesEU w serwisie Patreon — doceniamy wsparcie. To wszystko na dzisiaj. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Kubernetesa i Helma, odcinek 2 z 10. Masz dziesiątki serwerów, na których działają setki kontenerów. Kiedy maszyna nagle padnie, coś musi zdecydować, gdzie trafią te osierocone workloady. Orkiestra bez dyrygenta to tylko hałas, a flota kontenerów bez scentralizowanego mózgu to chaos nie do opanowania. Ten scentralizowany mózg, razem z maszynami wykonującymi właściwą pracę, tworzą architekturę klastra Kubernetes. Klaster Kubernetes dzieli się na dwie wyraźne części. Masz Control Plane, który pełni rolę mózgu, oraz Worker Nodes, które są siłą roboczą. Control Plane podejmuje wszystkie globalne decyzje, takie jak scheduling workloadów, a także wykrywa eventy w klastrze i na nie reaguje. Worker Nodes hostują twoje aplikacje i wykonują instrukcje wysyłane przez Control Plane. Każdy klaster musi mieć co najmniej jeden worker node, żeby uruchamiać aplikacje. Spójrzmy najpierw na Control Plane. Jego głównym komponentem jest kube-apiserver. Słuchacze czasem słyszą API server i wyobrażają sobie standardowy web server obsługujący requesty HTTP dla aplikacji. Ale to nie to. Kube-apiserver to centralny układ nerwowy całego klastra. To frontend dla Control Plane. Każda pojedyncza komunikacja, niezależnie czy pochodzi od człowieka, worker node'a, czy wewnętrznego komponentu, przechodzi przez ten API server. Ponieważ API server jest całkowicie bezstanowy, klaster potrzebuje pamięci. Jest nią etcd. To spójny, wysoce dostępny key-value store, który zawiera wszystkie dane klastra. Za każdym razem, gdy tworzona jest konfiguracja lub zmienia się stan systemu, prawdziwy zapis tej zmiany ląduje w etcd. Kolejny jest kube-scheduler. Kiedy prosisz klaster o uruchomienie nowego workloadu w kontenerze, ten workload początkowo nie ma przypisanej maszyny. Scheduler zauważa ten nieprzypisany workload. Ocenia wymagania zasobowe, ograniczenia sprzętowe i reguły polityk, a następnie przypisuje workload do najbardziej odpowiedniego worker node'a. Na koniec masz kube-controller-manager. Ten komponent uruchamia ciągłe pętle w tle, nazywane kontrolerami. Te kontrolery stale obserwują obecny stan klastra przez API server i aktywnie pracują, żeby zbliżyć ten obecny stan do twojego pożądanego stanu. Jeśli worker node padnie, controller manager zauważa brakującą maszynę i triggeruje reakcję, żeby zastąpić utracone workloady. To by było na tyle, jeśli chodzi o mózg. Teraz spójrzmy na worker nodes, które wykonują zadania. Komponenty node'a działają na każdej maszynie typu worker, żeby utrzymać środowisko runtime. Najbardziej krytycznym komponentem jest tutaj kubelet. To agent działający na każdym nodzie, który komunikuje się bezpośrednio z Control Plane. Kubelet pobiera instrukcje z API servera i upewnia się, że wymagane kontenery faktycznie działają i są zdrowe na jego konkretnej maszynie. Kubelet nie uruchamia kontenerów samodzielnie. Deleguje to zadanie do Container Runtime. Runtime to właściwe oprogramowanie, takie jak containerd, odpowiedzialne za pobieranie obrazów kontenerów z registry i uruchamianie procesów w systemie operacyjnym. Na koniec zostaje kube-proxy. To sieciowe proxy działające na każdym nodzie. Utrzymuje ono lokalne reguły sieciowe, które pozwalają komunikacji sieciowej dotrzeć do twoich kontenerów z wewnątrz lub z zewnątrz klastra. Oto kluczowy wniosek. Control Plane dyktuje, co powinno się wydarzyć, ale nigdy nie wykonuje kodu aplikacji. Worker Nodes uruchamiają kod aplikacji, ale polegają całkowicie na Control Plane, który mówi im, co mają uruchomić. To ścisłe oddzielenie podejmowania decyzji od ich wykonywania pozwala Kubernetesowi na skalowanie horyzontalne i automatyczne podnoszenie się po awariach sprzętu. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Kubernetesa i Helma, odcinek 3 z 10. Budujesz kontener, testujesz go lokalnie i przekazujesz do uruchomienia w Kubernetesie. Ale Kubernetes absolutnie odmawia bezpośredniej obsługi twojego kontenera. Zamiast tego wymaga od ciebie najpierw opakowania go w zupełnie inną abstrakcję. Odczarowujemy Pody, faktyczną jednostkę pracy w tym ekosystemie. Jeśli kontenery to samotne wieloryby w tradycyjnym świecie konteneryzacji, to Pody są zgranymi stadami, w których pływają razem. Pod to najmniejszy, najbardziej podstawowy obiekt, jaki możesz zdeployować i którym możesz zarządzać w Kubernetesie. Reprezentuje pojedynczą instancję uruchomionego procesu w twoim klastrze. Możesz się zastanawiać, dlaczego Kubernetes wprowadza tę dodatkową warstwę, zamiast po prostu bezpośrednio zarządzać kontenerami. Odpowiedź leży w abstrakcji i współdzielonym kontekście. Kubernetes potrzebuje jednolitego sposobu obsługi sieci, storage'u i schedulingu, niezależnie od konkretnego runtime'u kontenerów, którego używasz. Opakowując kontenery w Poda, Kubernetes traktuje tego Poda jako logicznego hosta. Oto kluczowa sprawa. Pod nie tylko opakowuje pojedynczy kontener; tworzy on współdzielone środowisko uruchomieniowe. Chociaż Pod często zawiera tylko jeden kontener, może pomieścić wiele kontenerów, które muszą ze sobą ściśle współpracować. Kiedy wiele kontenerów trafia do tego samego Poda, masz gwarancję, że zostaną zaplanowane przez scheduler na dokładnie tej samej maszynie fizycznej lub wirtualnej. Co ważniejsze, te kontenery współdzielą ten sam network namespace. Każdy kontener wewnątrz jednego Poda współdzieli jeden adres IP i jedną przestrzeń portów. Ponieważ istnieją w tym samym kontekście sieciowym, mogą się ze sobą komunikować, po prostu używając localhost. Nie ma potrzeby wewnętrznych zapytań DNS ani złożonego routingu serwisów, tylko po to, żeby dwa lokalne procesy mogły ze sobą pogadać. Jeśli kontener A binduje się do portu osiem tysięcy, kontener B w tym samym Podzie może się z nim połączyć pod adresem localhost port osiem tysięcy. Ten współdzielony kontekst obejmuje również storage. Możesz definiować współdzielone wolumeny storage'u na poziomie Poda. Po ich zdefiniowaniu, każdy kontener w tym Podzie może zamontować te współdzielone wolumeny we własnym systemie plików. Dzięki temu ściśle powiązane kontenery mogą bezproblemowo czytać i zapisywać dokładnie te same pliki. Weźmy pod uwagę główny kontener serwera WWW. Jego zadaniem jest serwowanie ruchu HTTP, ale zapisuje on również surowe access logi do lokalnego katalogu. Chcesz wysyłać te logi do centralnego systemu monitorowania, ale nie chcesz zaśmiecać obrazu serwera WWW agentami do logowania i plikami konfiguracyjnymi. Zamiast tego tworzysz drugi kontener – lekkie narzędzie do logowania. Deployujesz zarówno serwer WWW, jak i kontener logujący wewnątrz dokładnie tego samego Poda. Serwer WWW zapisuje swoje logi na współdzielonym wolumenie storage'u. Kontener logujący, działający jako sidecar, montuje ten sam wolumen, odczytuje przychodzące pliki logów i streamuje je do twojego systemu monitorowania. Działają jako jedna zintegrowana jednostka, współdzieląc zasoby bez mieszania swoich indywidualnych obowiązków. Decydując, czy dwa kontenery powinny znaleźć się w tym samym Podzie, zadaj sobie pytanie, czy z natury muszą wylądować na dokładnie tej samej maszynie i współdzielić identyczny cykl życia. Jeśli nie muszą absolutnie być deployowane, startować i umierać razem, ich miejsce jest w oddzielnych Podach. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Kubernetes i podstawy Helma, odcinek 4 z 10. Śpisz. O trzeciej nad ranem memory leak kładzie Twój główny serwer aplikacji. W tradycyjnym setupie odpala się alert, a Ty budzisz się, żeby ręcznie zrestartować proces. W Kubernetesie system ogarnia nocną zmianę za Ciebie. To jest właśnie potęga zarządzania stanem za pomocą Deploymentów. Deployment zapewnia deklaratywne update'y dla Twoich aplikacji. Zamiast pisać skrypty, które krok po kroku instruują system, jak uruchomić Twój soft, opisujesz dokładnie, jak ma wyglądać stan końcowy. Przekazujesz ten pożądany stan do Deployment controllera, a on zmienia stan rzeczywisty, żeby do niego pasował, w kontrolowanym tempie. Żeby zrozumieć, jak to robi, musisz znać hierarchię. Rzadko tworzysz pojedyncze Pody bezpośrednio. Zamiast tego tworzysz Deployment. Deployment tworzy wtedy obiekt podrzędny o nazwie ReplicaSet. ReplicaSet to mechanizm ściśle odpowiedzialny za to, żeby w każdym momencie działała dokładnie określona liczba replik Podów. Jeśli node serwera padnie, albo Pod zcrashuje się przez ten memory leak, ReplicaSet zauważa, że liczby spadły poniżej Twojego pożądanego stanu. Natychmiast podnosi nowy Pod, żeby zastąpić ten utracony. To jest Twój mechanizm self-healingu. Ty w ogóle nie interweniujesz. Ta sama logika dotyczy skalowania. Jeśli ruch skoczy do góry, updatujesz swój plik Deploymentu, żeby poprosić o pięć replik zamiast trzech. Controller widzi rozbieżność między Twoim żądaniem a rzeczywistością i instruuje ReplicaSet, żeby odpalił dwa kolejne Pody. To deklaratywne podejście jest najbardziej kluczowe podczas update'ów aplikacji. Powiedzmy, że masz trzy Pody odpalone na obrazie Nginxa w wersji 1.14. Musisz zrobić upgrade do wersji 1.16 bez ubijania ruchu użytkowników. Po prostu updatujesz wersję obrazu w konfiguracji swojego Deploymentu. Deployment nie ubija wszystkich Twoich starych Podów naraz. Zamiast tego tworzy zupełnie nowy ReplicaSet specjalnie dla wersji 1.16. Następnie zaczyna rolling update. Odpala nowy Pod w nowym ReplicaSecie. Kiedy ten nowy Pod jest healthy, skaluje w dół stary ReplicaSet, ubijając jeden Pod w wersji 1.14. Powtarza ten ostrożny, stopniowy proces, aż wszystkie trzy stare Pody znikną, a trzy nowe będą działać. Przejście jest całkowicie płynne. A co się stanie, jeśli update jest zepsuty? Tu leży klucz do całej sprawy. Ponieważ Deployment controller orkiestruje tymi ReplicaSetami, daje Ci to wbudowaną siatkę bezpieczeństwa. Jeśli przypadkowo wpiszesz nazwę obrazu jako Nginx 1.16-typo, nowe Pody zcrashują się przy starcie. Deployment wykrywa błąd i natychmiast wstrzymuje rollout. Zostawia Twoje pozostałe stare Pody odpalone, dzięki czemu aplikacja zostaje online. Kiedy zauważysz błąd, możesz wydać komendę rollback. Deployment po prostu skaluje w górę stary, sprawdzony ReplicaSet, a ten zepsuty skaluje w dół do zera. Prawdziwą siłą Deploymentu nie jest tylko odpalanie kontenerów, ale jego nieustanna, ciągła pętla porównywania tego, o co prosiłeś, z tym, co faktycznie istnieje, i wymuszanie na rzeczywistości, żeby się dopasowała. Chciałbym poświęcić chwilę, żeby podziękować Ci za słuchanie — to bardzo nam pomaga. Trzymaj się!

Cześć, tu Alex z DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, odcinek 5 z 10. Pody są śmiertelne. Crashują, skalują się w dół, są evictowane, a kiedy zostają zastąpione, dostają zupełnie nowy adres IP. Jeśli masz aplikację, która próbuje się z nimi komunikować, to tak, jakbyś ciągle strzelał do ruchomego celu. Kubernetes Services rozwiązują dokładnie ten problem. Pomyśl o typowej aplikacji webowej. Masz deployment frontendu i bazę danych na backendzie. Jeśli twój Pod bazy danych się zrestartuje, control plane klastra podnosi nowego Poda na jego miejsce. Ten nowy Pod dostaje zupełnie inny adres IP w sieci klastra. Jeśli twój frontend był skonfigurowany do bezpośredniej komunikacji ze starym IP, połączenie zostaje zerwane, a twoja aplikacja przestaje działać. Nie możesz polegać na pojedynczych adresach IP Podów, jeśli chodzi o cokolwiek trwałego. Kubernetes Service to abstrakcja, która zapewnia stabilną, długotrwałą tożsamość sieciową dla dynamicznej grupy Podów. Kiedy tworzysz Service, dostaje on adres IP, który nigdy się nie zmieni, dopóki ten Service istnieje. Twoja aplikacja na frontendzie nie musi śledzić, które dokładnie Pody bazy danych żyją w danej sekundzie. Po prostu wysyła ruch na IP Service'u. Co więcej, klaster przypisuje do Service'u stabilną nazwę DNS. Twój kod na frontendzie może po prostu połączyć się z prostym hostnamem, a klaster automatycznie rozwiąże go na właściwy adres IP. Pod spodem Service działa jako wewnętrzny load balancer. Opiera się na komponencie o nazwie kube-proxy, działającym na każdym nodzie, który implementuje właściwe reguły routingu. Kiedy ruch dociera do Service'u, jest przekazywany do jednego ze zdrowych Podów, które za nim stoją. Żeby połączyć Service z odpowiednimi Podami, używasz labeli i selektorów. Możesz skonfigurować Service z selektorem, który szuka labela wskazującego na aplikację bazy danych. Service stale obserwuje klaster. Jeśli Pod bazy danych padnie, jego IP jest usuwane z aktywnej puli. Kiedy wstaje zastępczy Pod, dodawane jest jego nowe IP. Aplikacja na frontendzie pozostaje całkowicie nieświadoma, że topologia sieci pod spodem właśnie się zmieniła. Jest kilka sposobów na wystawienie Service'u, w zależności od tego, skąd pochodzi ruch. Domyślny typ to ClusterIP. Service typu ClusterIP dostaje wewnętrzny adres IP, osiągalny tylko z wnętrza klastra. To właściwy wybór dla twojej bazy danych na backendzie, dzięki czemu pozostaje bezpiecznie odizolowana od świata zewnętrznego. Ale twój frontend musi odbierać ruch od zewnętrznych użytkowników. W tym celu zmieniasz typ Service'u na LoadBalancer. Kiedy tworzysz Service typu LoadBalancer, Kubernetes komunikuje się z twoim cloud providerem, żeby postawić standardowy, zewnętrzny load balancer. Zewnętrzny ruch z internetu uderza w ten zasób chmurowy, który przekazuje połączenie do twojego klastra, przepuszczając je przez Service, a ostatecznie do twoich Podów na frontendzie. Oto kluczowa sprawa. Services oddzielają adresowalną tożsamość twojej aplikacji od fizycznych workloadów, które faktycznie wykonują logikę. Przestajesz routować ruch do konkretnych, kruchych instancji, a zaczynasz routować go do odpornego, trwałego konceptu. To wszystko w tym odcinku. Dzięki za wysłuchanie i koduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Kubernetes i Helm, odcinek 6 z 10. Chcesz zrobić deploy pojedynczej aplikacji, ale kończysz zarządzając setkami linijek statycznego YAML-a w deploymentach, serwisach i ingressach. Kiedy musisz wypchnąć tę samą aplikację na środowisko stagingowe, kopiujesz te pliki do nowego katalogu i ręcznie wyszukujesz i podmieniasz image tagi i hostname'y. Jest to kruche, bardzo powtarzalne i niemożliwe do utrzymania w miarę jak twoja infrastruktura rośnie. I to jest dokładnie ten problem, który ma rozwiązywać Helm. Helm to package manager dla Kubernetesa. Możesz o nim myśleć jak o apt, yum czy Homebrew, ale zaprojektowanym specjalnie dla zasobów Kubernetesa. Zamiast traktować twoją aplikację jako luźny zbiór niezależnych manifestów YAML, Helm paczkuje je razem w jedną, spójną całość. Ten format paczki nazywa się Chart. Chart to w zasadzie katalog zawierający pliki, które opisują powiązany zestaw zasobów Kubernetesa. Przechowuje wszystkie definicje, których twoja aplikacja potrzebuje do działania. Głównym mechanizmem, który sprawia, że Chart jest użyteczny, jest templating. Surowe manifesty Kubernetesa są całkowicie statyczne. Helm Chart z kolei zastępuje zahardkodowane szczegóły infrastruktury zmiennymi z template'u. Zamiast wpisywać konkretny replica count, stały image tag kontenera czy konkretną zmienną środowiskową bezpośrednio do pliku deploymentu, definiujesz placeholdery. Kiedy przychodzi czas na deploy, Helm łączy te template'y z oddzielnym plikiem zawierającym twoje konkretne wartości. Taka architektura oznacza, że utrzymujesz tylko jeden Chart dla swojej aplikacji. Po prostu przekazujesz mu różne parametry konfiguracyjne w zależności od tego, czy robisz deploy lokalnie, na staging, czy na produkcję. Kiedy bierzesz Chart, łączysz go ze swoimi konkretnymi wartościami konfiguracyjnymi i robisz deploy na klaster Kubernetesa, tworzysz to, co Helm nazywa Release. I tu zaczyna się robić ciekawie. Chart to po prostu ogólny blueprint. Release to rzeczywista, zdeployowana instancja działająca w twoim klastrze. Dzięki temu ścisłemu podziałowi na blueprint i instancję, możesz zainstalować dokładnie ten sam Chart wielokrotnie na dokładnie tym samym klastrze. Jeśli potrzebujesz trzech oddzielnych instancji serwera cache'ującego, nie duplikujesz YAML-a. Instalujesz Chart cache'ujący trzy razy. Helm śledzi każdą instalację jako osobny Release z własną, unikalną nazwą, własnymi wartościami konfiguracyjnymi i własnym, odizolowanym cyklem życia. Helm śledzi również stan i historię tych Release'ów wewnątrz klastra. Kiedy aktualizujesz aplikację podając nowy image tag albo modyfikując jakieś ustawienie, Helm ocenia różnice i tworzy nową rewizję tego konkretnego Release'u. Aplikuje tylko niezbędne zmiany do bazowych zasobów Kubernetesa. Jeśli update się nie powiedzie albo aplikacja zacznie zachowywać się nieprzewidywalnie, wydajesz Helmowi polecenie rollbacku do poprzedniej rewizji. Helm dokładnie wie, które zasoby Kubernetesa należą do której wersji twojej aplikacji, obsługując tworzenie, modyfikację i usuwanie tych zasobów jako pojedynczą operację. Kluczową zmianą, jaką wprowadza Helm, jest abstrakcja. Przestajesz zarządzać niezależnymi plikami tekstowymi reprezentującymi niepowiązane pody, serwisy i wolumeny, a zaczynasz robić deploy, konfigurować i aktualizować kompletne aplikacje. Dzięki za wysłuchanie, miłego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, odcinek 7 z 10. Musisz zaktualizować hasło do bazy danych, ale dane uwierzytelniające są zahardcodowane w piętnastu różnych plikach YAML. Jeden pominięty plik i cały deployment kończy się błędem. Hardcodowanie konfiguracji bezpośrednio w strukturze deploymentu jest kruche. Rozwiązaniem jest zrozumienie anatomii Helm charta. Helm chart to standardowy pakiet zawierający wszystkie definicje zasobów niezbędne do uruchomienia aplikacji, narzędzia lub usługi w klastrze Kubernetes. Cały system opiera się na jednej podstawowej filozofii: ścisłym oddzieleniu definicji strukturalnej od konfiguracji specyficznej dla danego środowiska. Definiujesz kształt swojego deploymentu tylko raz, a konkretne szczegóły wstrzykujesz dopiero podczas deploymentu. Kiedy zajrzysz do wnętrza Helm charta, znajdziesz tam określony układ katalogów. Główny folder zawsze nosi nazwę samego charta. Wewnątrz tego folderu, trzy główne komponenty napędzają cały system pakietowania. Pierwszym z nich jest plik o nazwie Chart dot yaml. To jest centrum metadanych. Mówi ono Helmowi dokładnie, czym jest ten pakiet. Zawiera wersję API dla standardu charta, nazwę charta, opis i numery wersji. Co kluczowe, śledzi zarówno wersję samego charta, jak i wersję aplikacji, czyli wersję faktycznego oprogramowania, które jest deployowane. Obok możesz też znaleźć katalog charts, który przechowuje wszystkie subcharts, od których zależy twoja aplikacja, ale to plik metadanych jest głównym identyfikatorem. Drugim kluczowym komponentem jest katalog templates. To właśnie tutaj żyje definicja strukturalna. Wewnątrz umieszczasz swoje standardowe pliki manifestów Kubernetes, takie jak deployments i services. Jednak zamiast pisać statyczny YAML, te pliki zawierają logikę Go template. Zamiast hardcodować liczbę replik na trzy, albo wklejać konkretne hasło do bazy danych, piszesz dyrektywę template. Ta dyrektywa instruuje Helma, aby dynamicznie wyszukał wymaganą wartość podczas deploymentu. Trzeci komponent odpowiada na te dynamiczne zapytania. Jest to plik o nazwie values dot yaml, znajdujący się w głównym katalogu charta, tuż obok pliku metadanych. Ten plik przechowuje domyślne ustawienia konfiguracji. Kiedy template prosi o image repository, numer portu albo hasło, plik values dostarcza bazową odpowiedź. I tu jest kluczowa sprawa. Templates dyktują architekturę twojej aplikacji, podczas gdy values dyktują, jak ta architektura zachowuje się w konkretnym środowisku. Kiedy odpalasz komendę install, Helm bierze surowe templates, łączy je z plikiem values i renderuje ostateczne, poprawne manifesty Kubernetes. Następnie wysyła te wyrenderowane manifesty do API Kubernetes. To rozdzielenie sprawia, że charty są w tak dużym stopniu reużywalne. Wyobraź sobie scenariusz, w którym musisz zdeployować dokładnie tę samą aplikację zarówno na środowisko staging, jak i na produkcję. Nie kopiujesz i nie modyfikujesz charta. Używasz dokładnie tej samej struktury katalogów i dokładnie tych samych templates. Dla deploymentu na staging, przekazujesz Helmowi customowy plik values podczas komendy install. Ten plik nadpisuje domyślne ustawienia, określając jedną replikę poda, URL lokalnej testowej bazy danych i logowanie na poziomie debug. Kiedy deployujesz na produkcję, przekazujesz zupełnie inny plik values. Ten produkcyjny plik określa dziesięć replik, URL zarządzanej bazy danych i ścisłe limity zasobów. Helm łączy ten jeden zestaw templates z odpowiednimi customowymi plikami values, tworząc dwa zupełnie różne profile deploymentu. Siła Helm charta tkwi nie w YAML-u, który zawiera, ale w granicach, które tworzy. Blokuje on architekturę infrastruktury w templates, jednocześnie zachowując pełną elastyczność szczegółów operacyjnych w plikach values. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, odcinek 8 z 10. To, że możesz otemplować każdą linijkę manifestu Kubernetesa, wcale nie oznacza, że powinieneś. Kiedy próbujesz zrobić każde pole konfigurowalnym, kończysz z chartem, którego nikt nie potrafi przeczytać, a co dopiero utrzymać. W tym odcinku omawiamy best practices dla chartów Helma, czyli zasady, które sprawią, że twoje konfiguracje nie zawalą się pod własnym ciężarem. Największą pułapką przy tworzeniu chartów jest over-templating. Wielu developerów traktuje template'y Helma jak zwykły skrypt do podmieniania tekstu. To częste nieporozumienie. Helm używa silnika template'ów w Go, żeby wygenerować ustrukturyzowany, poprawny YAML. Jeśli wrzucisz zmienną do pliku bez uważnego zarządzania wcięciami i typami danych, wygenerowany YAML całkowicie się posypie. Z tego powodu powinieneś templować tylko te wartości, które faktycznie zmieniają się między środowiskami. Pomyśl o image tagach, replikach, limitach zasobów czy regułach ingress. Główne pola strukturalne zostaw zahardcodowane. Jeśli user nigdy nie musi zmieniać konkretnego security contextu albo volume mounta, nie wystawiaj tego jako zmiennej. Plik values dot yaml działa jak publiczne API dla twojego charta. Organizując ten plik, musisz znaleźć balans między strukturą a użytecznością. Oficjalna rekomendacja jest taka, żeby trzymać hierarchię tak płaską, jak to tylko możliwe. Choć powinieneś grupować powiązane parametry, unikaj głębokiego zagnieżdżania. Pomyśl o userze, który przekazuje override'y przez command line. Zmuszanie go do wpisywania ścieżki oddzielonej kropkami na pięć poziomów w dół, tylko po to, żeby zmienić numer portu, powoduje niepotrzebne utrudnienia. Jeśli masz konfigurację web serwera, wrzuć te propertiesy pod jeden klucz server, ale wewnętrzne propertiesy trzymaj płasko. Nazywając te zmienne, zawsze używaj camel case'a. Zacznij od małej litery, a każde kolejne słowo zaczynaj wielką literą. Nie używaj myślników ani podkreśleń w swoim pliku values. Możesz stworzyć zmienną o nazwie externalPort, zamiast external dash port. Konsekwentny camel case zapobiega błędom parsowania podczas renderowania template'ów i pasuje do szerszych standardów ekosystemu Kubernetesa. Pilnuj też ścisłej spójności typów. Jeśli parametr jest integerem w Kubernetesie, jak numer portu, zostaw go jako integer w pliku values. Nie owijaj go w cudzysłowy i nie zamieniaj w stringa. Ta spójność przekłada się bezpośrednio na to, jak tagujesz zasoby, które generuje twój chart. Każdy obiekt potrzebuje standardowych labeli. Best practices Helma nakazują używanie oficjalnych app labeli Kubernetesa. Konkretnie, używaj prefiksu app dot kubernetes dot io. Label name powinien mapować się na nazwę charta, podczas gdy label instance powinien mapować się na nazwę release'u. Dodaj też label version i zaznacz, że zasób jest zarządzany przez Helma. Przypisanie dokładnie tych labeli do każdego deploymentu, poda, service'u i config mapy sprawia, że zewnętrzne narzędzia do monitorowania i service meshe mogą automatycznie wykrywać i grupować komponenty twojej aplikacji bez ręcznej konfiguracji. Oto kluczowa sprawa. Najlepszy chart Helma to nie ten z największą liczbą opcji konfiguracji. To ten, który wymaga najmniejszej liczby override'ów, żeby bez problemu działać out of the box. Jeśli chcesz pomóc nam tworzyć ten podcast, wyszukaj DevStoriesEU na Patreonie — naprawdę doceniamy twoje wsparcie. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Kubernetes i Helm, odcinek 9 z 10. Budowanie klastra od zera to świetne ćwiczenie, ale przy skalowaniu do setek mikrousług nie chcesz samodzielnie zarządzać control plane'em. Chcesz, żeby dostawca chmury wziął na siebie najcięższą pracę, dzięki czemu twoi inżynierowie będą mogli skupić się na dostarczaniu kodu. Właśnie tak wygląda enterprise'owa implementacja Kubernetes i Helm w Azure. W standardowej architekturze Kubernetes masz control plane, który podejmuje globalne decyzje, oraz worker node'y, które je wykonują. Utrzymanie wysokiej dostępności tego control plane'u jest niezwykle trudne. Klient enterprise, który robi deploy na Azure, zazwyczaj korzysta z Azure Kubernetes Service, czyli AKS. AKS abstrahuje control plane. Azure zarządza API serverem, schedulerem i key-value data store'em. Twój zespół operacyjny odpowiada tylko za worker node'y, na których faktycznie działają twoje aplikacje. Jak więc aplikacja trafia z komputera dewelopera na te worker node'y? I tutaj do workflow wkracza Helm. Aplikacja enterprise rzadko składa się z pojedynczego kontenera. Zazwyczaj jest to zbiór mikrousług, z których każda potrzebuje własnych deploymentów, serwisów i konfiguracji. Zamiast zarządzać dziesiątkami statycznych plików YAML, deweloperzy pakują te zasoby w Helm chart. Chart działa jak pojedynczy, wersjonowany blueprint dla mikrousługi. Ponieważ Helm korzysta z template'ów, deweloperzy mogą raz napisać logikę strukturalną i wstrzykiwać różne wartości konfiguracji w zależności od tego, czy robią deploy na klaster dev, staging czy produkcję. Zanim cokolwiek zostanie uruchomione, kod aplikacji jest budowany w obrazy kontenerowe. Te obrazy są pushowane do bezpiecznej lokalizacji, takiej jak container registry. Same Helm charty można również spakować i spushować do registry, co pozwala zespołom enterprise traktować definicje infrastruktury dokładnie tak samo, jak skompilowany kod aplikacji. Oto kluczowa sprawa. Kiedy release pipeline triggeruje deployment, Helm ewaluuje swoje template'y z wartościami specyficznymi dla środowiska i wysyła ostateczne manifesty do API servera AKS. Control plane AKS odczytuje ten pożądany stan i zaczyna schedulować Pody na twoich worker node'ach. Node'y łączą się z container registry, bezpiecznie się uwierzytelniają, pullują określone wersje obrazów i odpalają kontenery. Kubernetes stale monitoruje ten stan. Jeśli worker node ulegnie awarii, control plane natychmiast rescheduluje jego Pody na zdrowe node'y, aby utrzymać replica count zdefiniowany w Helm charcie. Kiedy Pody już działają, muszą zacząć odbierać ruch. Helm chart zazwyczaj zawiera definicję serwisu, która wystawia aplikację. Kiedy jest to zdeployowane na AKS, Kubernetes komunikuje się bezpośrednio z bazową infrastrukturą Azure. Jeśli serwis żąda publicznego entry pointu, AKS automatycznie provisionuje Azure Load Balancer. Ten load balancer odbiera przychodzący ruch zewnętrzny i bezpiecznie routuje go do klastra, dystrybuując go pomiędzy zdrowe Pody. Twoi deweloperzy nie musieli nawet dotykać Azure portal ani pisać konkretnych reguł cloud routingu. Po prostu zdefiniowali standardowy serwis Kubernetes w swoim Helm charcie, a zarządzana platforma zajęła się fizycznym network provisioningiem. Prawdziwą siłą tej architektury enterprise jest czyste separation of concerns. Helm standaryzuje sposób definiowania aplikacji w różnych środowiskach, registry zabezpiecza wersjonowane artefakty, a zarządzana platforma chmurowa dba o to, żeby bazowa infrastruktura faktycznie działała i mogła to wszystko uruchomić. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Kubernetes i Helm, odcinek 10 z 10. Masz już teorię i narzędzia. Ale kiedy patrzysz na pusty terminal, przepaść między ogromną infrastrukturą w chmurze a twoim laptopem wydaje się niezwykle szeroka. Zniwelowanie tej przepaści to dokładnie to, o co chodzi w rozpoczęciu pracy z Minikube. Produkcyjny klaster Kubernetes składa się z wielu maszyn, które działają jako control plane i worker nodes. Provisioning tego w chmurze kosztuje, zajmuje czas i wymaga skomplikowanej konfiguracji sieci. Jako solowy developer lub mały zespół projektujący architekturę od zera, potrzebujesz lokalnego środowiska, które zachowuje się dokładnie tak jak produkcja, ale bez tego całego overheadu. Minikube to lekka implementacja Kubernetes, która tworzy maszynę wirtualną lub kontener bezpośrednio na twoim laptopie. Wewnątrz tego odizolowanego środowiska, robi deploy prostego klastra single-node. Zazwyczaj Kubernetes oddziela control plane, który zarządza stanem klastra, od worker nodes, które uruchamiają kontenery twojej aplikacji. Minikube je łączy. Twoja lokalna maszyna uruchamia jeden node, który obsługuje zarówno logikę zarządzania, jak i właściwe workloady aplikacji. Nie jest on przeznaczony do obsługi ruchu na produkcji. Istnieje wyłącznie po to, żebyś mógł bezpiecznie testować orkiestrację kontenerów. I tu jest kluczowa sprawa. Interfejs, którego używasz do interakcji z Minikube, jest identyczny z tym, którego używasz do ogromnego klastra w chmurze. Używasz narzędzia command-line o nazwie kubectl. Kiedy wykonujesz komendę kubectl, komunikuje się ona bezpośrednio z control plane Minikube przez jego API. Nie musisz uczyć się żadnej specjalnej składni do lokalnego developmentu. Twój workflow idealnie pasuje do oficjalnego tutoriala z podstaw Kubernetes. Inicjujesz klaster prostą komendą start. Minikube robi provisioning środowiska i automatycznie konfiguruje kubectl, żeby wskazywał na twoją nową lokalną instancję. Następnie używasz kubectl, żeby utworzyć deployment. Mówisz do control plane, żeby zrobił pull konkretnego obrazu kontenera i go uruchomił. Po zrobieniu deployu, twoja aplikacja działa wewnątrz poda na tym pojedynczym nodzie. Jest jednak odizolowana od sieci twojego hosta. Żeby uzyskać do niej dostęp z przeglądarki na laptopie, musisz zrobić expose, tworząc service. Service routuje ruch z konkretnego portu na twojej lokalnej maszynie do właściwego portu na podzie działającym w Minikube. Od tego momentu możesz ćwiczyć każdą podstawową funkcję Kubernetes. Możesz skalować swoją aplikację, mówiąc kubectl, żeby zwiększył replica count. Minikube postawi dodatkowe pody obok tego pierwszego. Możesz ćwiczyć rolling updates, zmieniając wersję obrazu kontenera w swoim deploymencie. Minikube płynnie zamknie stare pody i uruchomi nowe, symulując zero-downtime deployment. Ponieważ Minikube wystawia standardowe API Kubernetes, twój zewnętrzny tooling integruje się bezproblemowo. Helm działa od razu. Możesz instalować złożone bazy danych, ingress controllers albo kolejki wiadomości używając Helm charts dokładnie tak, jak w środowisku live. Minikube zawiera nawet wbudowane addony, takie jak lokalny web dashboard, pozwalający ci wizualnie sprawdzić stan klastra, czytać logi i monitorować zużycie zasobów. Prawdziwą siłą lokalnego klastra jest parity. Kiedy piszesz konfigurację deploymentu albo Helm chart, który z sukcesem działa na Minikube, masz już napisaną dokładną konfigurację, która zadziała w chmurze. Poświęć chwilę na zapoznanie się z oficjalną dokumentacją Kubernetes i wypróbuj te komendy w praktyce. Jeśli masz sugestie dotyczące tematów, które powinniśmy poruszyć w naszej kolejnej serii, odwiedź devstories dot eu i daj nam znać. To wszystko na dziś. Dzięki za wysłuchanie, idź zbudować coś fajnego.