Dzisiaj porozmawiamy o czymś, o czym niemal każdy słyszał, ale nikt nie potrafi wyjaśnić Kubernetes. To mylące, ponieważ rozwiązuje problem, którego większość ludzi nie dostrzega, dopóki się z nim nie zderzy. Wszyscy wiedzą, że to ważne, ale zapytaj, co to robi, a zobaczysz tylko puste spojrzenie. To nie jest zamiennik Dockera ani system operacyjny w chmurze, choć ludzie często tak zgadują. To zamieszanie jest zrozumiałe, bo Kubernetes rozwiązuje problem, o którym nie wiesz, póki go nie napotkasz. To narzędzie, które staje się niezbędne, gdy masz do zarządzania więcej niż garstkę kontenerów. Pod koniec tego odcinka zrozumiesz, czym właściwie jest Kubernetes, jak współpracuje z kontenerami i dlaczego Azure Kubernetes Service czyni go praktycznym dla zespołów, które nie chcą budować wszystkiego od zera. Chwyć kawę i zaczynajmy. Problem sprzed ery kontenerów. Wróćmy do samego problemu. Wyobraź sobie firmę programistyczną sprzed 10 lat.

Masz kilka aplikacji do uruchomienia, więc kupujesz serwery, instalujesz systemy operacyjne i wszystko wdrażasz ręcznie. Każda aplikacja dostaje własną maszynę i nie możesz dzielić zasobów między nimi. Jeśli jedna aplikacja potrzebuje dużo pamięci, a inna prawie wcale obie i tak dostają własny serwer. Marnotrawstwo było ogromne. Serwery działały może na 20% wydajności, ale nie można było ich skonsolidować, bo aplikacje kłóciłyby się o zależności. Kończyłeś z pokojem pełnym serwerów, z których każdy prawie nie pracował, zużywał prąd i wymagał chłodzenia, a wszystkie potrzebowały ciągłej konserwacji. Jedna aplikacja potrzebuje Pythona 3.7, inna Pythona 3.8. Jedna wymaga starszej biblioteki, inna najnowszej. Nie możesz ich uruchomić na tej samej maszynie bez popsucia czegoś, więc kupujesz kolejne serwery i płacisz za sprzęt, który głównie stoi bezczynnie. Maszyny wirtualne pomogły trochę, pozwalając podzielić serwer fizyczny na mniejsze kawałki, z których każdy uruchamiał własny system, ale każda maszyna wirtualna jest ciężka, zawiera pełne os, zajmuje miejsce na dysku, pamięć i uruchamia się minuty.

Do tego każdą trzeba było skonfigurować osobno, co było ogromem pracy. Wciąż zarządzasz wszystkimi tymi systemami operacyjnymi, łatając je, aktualizując i zabezpieczając. Zespoły potrzebowały czegoś lżejszego i przenośnego, sposobu na spakowanie aplikacji ze wszystkim, czego potrzebuje do działania, bez narzutu pełnej maszyny wirtualnej, co można łatwo przenosić między serwerami. Wtedy właśnie pojawiły się kontenery. Czym właściwie są kontenery? Kontener to mała paczka, która zawiera Twoją aplikację i wszystko, co jest jej potrzebne do uruchomienia. Oznacza to, że kod środowisko uruchomieniowe, biblioteki i pliki konfiguracyjne są zgrupowane w jedną całość. Pomyśl o tym, jak o kontenerze transportowym dla oprogramowania. Kontener transportowy może trafić na ciężarówkę, pociąg lub statek, a sam kontener pozostaje taki sam. Twój kontener oprogramowania działa w ten sam sposób. Budujesz go raz, a działa tak samo na Twoim laptopie, serwerze testowym i w środowisku produkcyjnym.

Kluczowa różnica między kontenerami a maszynami wirtualnymi polega na ich wydajności. Maszyna wirtualna uruchamia własny, pełny system operacyjny, więc każda VM ma własne jądro, pliki systemowe i wszystko inne. Kontener współdzieli system operacyjny gospodarza. To po prostu proces z własnym, odizolowanym widokiem na świat. Oznacza to, że kontenery uruchamiają się w sekundy, a nie minuty. Zużywają mniej pamięci i możesz upakować ich więcej na jednej maszynie. Docker spopularyzował kontenery, dając programistom prosty sposób na ich budowanie i uruchamianie za pomocą jednego polecenia. Nagle problem u mnie działa, zaczął znikać. Jeśli Twoja aplikacja działa w kontenerze na laptopie, będzie działać tak samo na serwerze. Środowisko jest wszędzie spójne, jednak kontenery rozwiązują jeden problem, tworząc kolejny. Przy kilku kontenerach ręczne zarządzanie sprawdza się dobrze. Możesz je sam uruchamiać, zatrzymywać i śledzić.

Ale co się dzieje, gdy masz ich setki? Musisz zdecydować, który serwer uruchamia, który kontener, restartować te, które zawiodły, łączyć je ze sobą i skalować w górę przy skokach ruchu. To nowe wyzwanie i właśnie tutaj pojawia się Kubernetes. Problem orkiestracji. Masz więc działające kontenery, pakujesz aplikację, działa ona wszędzie tak samo i życie jest piękne. Ale tylko przez chwilę. Mając 10 lub 20 kontenerów, możesz zarządzać wszystkim ręcznie. Wiesz, który serwer uruchamia, który kontener, możesz zrestartować coś, jeśli się zawiesi i wprowadzić drobne poprawki tu i ówdzie. To jest do ogarnięcia, ale potem Twoja aplikacja rośnie. Przechodzisz na mikrousługi, więc zamiast jednej wielkiej aplikacji masz 20 mniejszych. Każda wymaga wielu kopii dla niezawodności i teraz patrzysz na 200 kontenerów. Ręczne zarządzanie już nie wystarcza. Musisz decydować, który serwer uruchamia dany kontener, restartować je po awarii i łączyć, by mogły się komunikować.

Musisz też skalować w górę, gdy rośnie ruch, na przykład, podczas wyprzedaży lub premiery produktu i skalować w dół, gdy sytuacja się uspokaja. Musisz też wdrażać aktualizację bez przestojów, co oznacza wymianę starych kontenerów na nowe, jeden po drugim, ostrożnie i bez psucia czegokolwiek. To są problemy orkiestracji i właśnie po to stworzono Kubernetes. Kubernetes to platforma open source, która automatyzuje wdrażanie, skalowanie i zarządzanie skonteneryzowanymi aplikacjami. Pomyśl o nim jak o systemie operacyjnym dla Twojego centrum danych. Tak jak Windows lub Linux zarządza zasobami pojedynczego komputera, takimi jak procesor, pamięć czy dysk, Kubernetes zarządza zasobami wszystkich Twoich serwerów. Traktuje on wszystkie Twoje maszyny jak jedną wielką pulę mocy obliczeniowej. Mówisz mu, co chcesz uruchomić, a on ustala, gdzie to umieścić, jak utrzymać działanie i jak połączyć to z resztą.

Podstawowe koncepcje – pody, węzły i klastry. Przyjrzyjmy się, jak Kubernetes działa w praktyce. Najmniejsza jednostka w Kubernetesie nazywa się podem. Pod zawiera jeden lub więcej kontenerów. Kontenery wewnątrz tego samego poda współdzielą pamięć i sieć, dzięki czemu mogą komunikować się przez localhost. Możesz myśleć o podzie jako o pojedynczej jednostce wdrożeniowej. W Kubernetesie nie wdraża się kontenerów bezpośrednio. Wdraża się pody. Pody nie działają same, uruchamiane są na węzłach. Węzeł to serwer fizyczny lub wirtualny, będący częścią Twojego klastra Kubernetes. Każdy węzeł uruchamia oprogramowanie potrzebne do działania podów oraz kilka innych elementów, o których wspomnimy za chwilę. Klaster to zbiór wszystkich węzłów zarządzanych jako jeden zintegrowany system. Mówiąc prościej, pod to Twoja aplikacja węzeł to miejsce, gdzie ona działa, a klaster to całe środowisko. Pody są efemeryczne.

Mogą być tworzone, niszczone lub przenoszone w dowolnym momencie. Tak zostało to zaprojektowane. Jeśli węzeł ulegnie awarii, Kubernetes przenosi pody na inny. W celu zwiększenia skali tworzy nowe pody, a gdy pod ulegnie awarii, jest automatycznie zastępowany. Cały system traktuje pody jako tymczasowe. Skoro jednak pody ciągle powstają i znikają, potrzebujesz sposobu, by się z nimi komunikować. Zamiast rozmawiać z podem bezpośrednio, komunikujesz się z serwisem. Serwis zapewnia stabilny adres sieciowy, który kieruje ruch do odpowiednich podów, nawet gdy te się zmieniają. Wyobraź sobie hotel. Numer telefonu do hotelu to właśnie serwis. Goście w pokojach ciągle się zmieniają, ale numer telefonu pozostaje ten sam. Dzwonisz do recepcji, a oni przekierowują Twoją rozmowę do właściwego pokoju. Dokładnie tak działa serwis w Kubernetesie. Daje Ci stały adres, który zawsze wskazuje na pody aktualnie obsługujące Twoją aplikację.

Control Plane, czyli mózg klastra. Mamy więc pody, węzły i klaster. Pytanie brzmi, kto decyduje o tym, co i gdzie jest uruchamiane? To zadanie dla Control Plane'a. Każdy klaster Kubernetes go posiada i jest on mózgiem całej operacji. Wszystkie decyzje zapadają właśnie tutaj. Płaszczyzna sterowania ma kilka komponentów. Pierwszym z nich jest serwer API, który stanowi główne wejście do Twojego klastra. Każde polecenie wysyłane do Kubernetes, czy to zwiersza poleceń pulpitu nawigacyjnego, czy automatycznego skryptu, przechodzi przez serwer API. Uwierzytelnia on Twoje żądanie, sprawdza, czy masz uprawnienia do wykonania danej czynności, a następnie przekazuje je w odpowiednie miejsce. Nic w Kubernetes nie dzieje się bez wcześniejszego przejścia przez serwer API. Kolejnym jest scheduler, który decyduje, który węzeł uruchomi poszczególne pody. Gdy mówisz, chce, aby ta aplikacja działała, scheduler analizuje dostępne węzły, sprawdza zasoby, takie jak procesor, pamięć i miejsce na dysku, a następnie wybiera najlepszy z nich.

To jak kierownik hotelu przydzielający pokoje zgodnie z potrzebami gości. Gość z dużą ilością bagażu dostaje większy pokój, podczas gdy lekka aplikacja otrzymuje mniejszy węzeł z wolnymi zasobami. Następnie mamy menedżer kontrolerów. Ten komponent monitoruje klaster i dba o to, by stan faktyczny był zgodny z deklaracją. Powiedziałeś, że chcesz uruchomić trzy kopie swojej aplikacji internetowej. Menedżer kontrolerów sprawdza, czy rzeczywiście działają trzy kopie. Jeśli jedna ulegnie awarii, zauważa to i uruchamia zastępczą. Jeśli ktoś przypadkowo usunie, poda, tworzy nowy. To komponent, który dba o poprawność działania klastra. I na koniec mamy ETT, czyli bazę danych klastra. Przechowuje ona wszystko, co działa, gdzie działa i jak jest skonfigurowane. To źródło prawdy dla całego klastra. Jeśli serwer API to główne wejście, to ETT jest szafką na dokumenty w biurze, gdzie trzymane są wszystkie zapisy.

Piękno tego projektu polega na tym, że opisujesz, czego chcesz, a Kubernetes sam zajmuje się realizacją. Nie mówisz mu, jak ma coś zrobić, mówisz tylko, jak ma wyglądać rezultat końcowy. To model deklaratywny i jest on podstawą wszystkiego, co robi Kubernetes. Obciążenia, wdrożenia, usługi i skalowanie. Porozmawiajmy więc o tym, jak faktycznie uruchamiać aplikację w Kubernetes. Nie będziesz tworzyć podów bezpośrednio. Zamiast tego użyjesz obiektu wyższego poziomu, zwanego wdrożeniem deployment. Pomyśl o wdrożeniu jak o menedżerze, który mówi Kubernetesowi, ile kopii poda uruchomić, którego obrazu kontenera użyć i jak je aktualizować, gdy pojawi się nowa wersja. To standardowy sposób uruchamiania aplikacji bez stanowych. Gdy aktualizujesz wdrożenie, np. wysyłasz nową wersję swojej aplikacji, Kubernetes wykonuje aktualizację kroczącą rolling update. Zastępuje pody jeden po drugim, upewniając się, że przynajmniej jedna kopia zawsze działa.

Oznacza to brak przestojów i nagłych przerw dla Twoich użytkowników. A jeśli coś pójdzie nie tak z nową wersją, możesz przywrócić poprzednią za pomocą jednego polecenia. To potężna siatka bezpieczeństwa. Twoje pody muszą jednak być osiągalne. Tutaj z pomocą przychodzą serwisy, services. Serwis zapewnia stabilny adres sieciowy, który kieruje ruch do odpowiednich podów. Może on również udostępnić te pody innym częściom aplikacji lub światu zewnętrznemu. Serwis może być wewnętrzny, dostępny tylko wewnątrz klastra lub zewnętrzny, z publicznym adresem IP dostępnym z internetu. A teraz kwestia skalowania. Kubernetes potrafi automatycznie zwiększać i zmniejszać aplikację w zależności od zapotrzebowania. Ustawiasz cel, na przykład 70% użycia procesora, a Kubernetes dodaje pody, gdy zużycie przekroczy ten próg i usuwa je, gdy spadnie. Twoja aplikacja skaluje się w górę podczas wzrostu ruchu i w dół, gdy sytuacja się uspokaja.

Bez konieczności ręcznej interwencji. Jednak cała ta moc wiąże się ze złożonością. Uruchamianie własnego klastra Kubernetes oznacza, że odpowiadasz za płaszczyznę sterowania, aktualizację, poprawki bezpieczeństwa i kopie zapasowe. Potrzebujesz głębokiej wiedzy, aby obsługiwać awarię węzłów, konfigurację sieci i skalowanie klastra. Wiele zespołów spędza więcej czasu na zarządzaniu klastrem niż na budowaniu aplikacji. I tutaj wchodzi zarządzany Kubernetes. Kubernetes zarządzany samodzielnie kontra zarządzany przez dostawcę. Porozmawiajmy więc o realiach samodzielnego prowadzenia Kubernetesa. Kiedy tworzysz własny klaster, odpowiadasz za wszystko, płaszczyznę sterowania, aktualizację, poprawki bezpieczeństwa i kopie zapasowe etcd. Jeśli serwer API przestanie działać, to twój problem. Jeśli w używanej wersji zostanie wykryta luka w zabezpieczeniach, musisz ją załatać. Jeśli baza etcd ulegnie uszkodzeniu, musisz ją odtworzyć z kopii zapasowej.

Wszystko to wymaga specjalistycznej wiedzy. Musisz rozumieć, jak zawodzą węzły, jak działa sieć na poziomie klastra i jak skalować zasoby, by ich nie uszkodzić. Oto coś, co zaskakuje wiele zespołów. Wiele organizacji poświęca więcej czasu na zarządzanie klastrem Kubernetes niż na tworzenie aplikacji, które na nim działają. Ciągle zmagają się z aktualizacjami, rozwiązywaniem problemów sieciowych i awariami węzłów. Klaster staje się pracą na pełen etat. To nie był powód, dla którego na początku wybraliście Kubernetesa. Właśnie tutaj z pomocą przychodzą zarządzane usługi Kubernetes. Usługi takie jak Azure Kubernetes Service, czyli AKS, zajmują się płaszczyzną sterowania za ciebie. Azure zarządza serwerem API, bazą AD, harmonogramem, scheduler oraz menedżerem kontrolerów. Nie musisz martwić się o ich aktualizowanie ani dbanie o to, by działały. Płacisz tylko za węzły robocze, czyli maszyny wirtualne, na których faktycznie działają twoje obciążenia.

Sam płaszczyzna sterowania jest darmowa. To diametralnie zmienia sytuację. Zamiast poświęcać czas na utrzymanie klastra, twój zespół może skupić się na tym, co naprawdę ważne, tworzonych aplikacjach. Dla większości zespołów, zwłaszcza tych na początku drogi, zarządzany Kubernetes jest właściwym wyborem. Otrzymujesz pełną moc Kubernetesa bez narzutu operacyjnego. AKS, czyli Kubernetes w prostym wydaniu na platformie Azure. Czym więc dokładnie jest AKS? To zarządzana usługa Kubernetes na Azure, dająca ci w pełni funkcjonalny klaster bez budowania go od podstaw. Płaszczyzna sterowania jest darmowa, jak wspomnieliśmy, więc płacisz tylko za maszyny wirtualne obsługujące twoje obciążenia. Oznacza to, że możesz zacząć od małej skali, płacić niewiele i zwiększać zasoby wraz z rozwojem potrzeb. Azure bierze na siebie całą ciężką pracę. Aktualizacje, poprawki i monitorowanie stanu płaszczyzny sterowania są w pełni obsługiwane.

Nie potrzebujesz dedykowanego zespołu ekspertów od Kubernetesa, aby utrzymać wszystko w działaniu. A ponieważ AKS jest częścią ekosystemu Azure, integruje się z narzędziami, których prawdopodobnie już używasz. Azure Active Directory do uwierzytelniania Azure Monitor do logów i metryk oraz Azure Policy do zarządzania z godnością. Wszystkie współpracują ze sobą od razu po skonfigurowaniu, bez konieczności łączenia osobnych elementów. Konfiguracja potoków CI, CD za pomocą GitHub Actions lub Azure DevOps zajmuje zaledwie minuty. Wypchnij zmianę do repozytorium, a system automatycznie zbuduje nowy obraz kontenera, prześle go do Azure Container, registry i zaktualizuje wdrożenie w AKS. Bez ręcznych kroków, bez logowania przez SSH na serwery. Wszystko jest zautomatyzowane. Dla początkujących dostępny jest tryb automatyczny AKS zaprojektowany dla zespołów, które nie chcą podejmować każdej decyzji dotyczącej konfiguracji klastra.

Zapewnia gotowe do użycia ustawienia domyślne dla skalowania, w sieci, bezpieczeństwa i aktualizacji. Nie musisz być ekspertem od Kubernetesa, aby zacząć. Wystarczy opisać swoją aplikację, a AKS zajmie się resztą. Jedno polecenie tworzy klaster, jeden plik manifestu uruchamia twoją aplikację. Umiejętności zdobyte w AKS przenoszą się na każde inne środowisko Kubernetes, ponieważ pod spodem to standardowy Kubernetes. Nie uczysz się systemu własnościowego, lecz prawdziwego rozwiązania, gdzie Azure obsługuje złożoność operacyjną. Masz już więc pełny obraz sytuacji. Kontenery pakują aplikacje tak, aby działały spójnie wszędzie, a Kubernetes orkiestruje je na dużą skalę, automatycznie zarządzając wdrażaniem, skalowaniem i odzyskiwaniem. AKS czyni tę orkiestrację łatwą w zarządzaniu, przejmując opiekę nad płaszczyzną sterowania i integrując się z narzędziami Azure, które już znasz. Główny wniosek jest taki.

Kubernetes nie jest tylko dla wielkich firm technologicznych z ogromnymi zespołami inżynierskimi. Dzięki usługom zarządzanym, takim jak AKS, jest dostępny dla każdego zespołu. Twoje zadanie domowe na ten tydzień jest proste. Załóż darmowe konto Azure, uruchom klaster AKS i wdroż prostą aplikację. Zajmie to kilka minut i zobaczysz, jak bardzo rozwinęła się ta platforma. Gotowy, by wejść głębiej? W następnym odcinku pokażemy, jak zbudować pierwszy obraz kontenera i przesłać go do Azure Container Registry. Zasubskrybuj na swojej ulubionej platformie podcastowej i udostępnij to komuś, kto dopiero zaczyna swoją przygodę z Kubernetesem.