Planując proces wdrożenia konteneryzacji w firmie, nasz wybór najczęściej pada na Kubernetesa. Jest to rozumowanie jak najbardziej słuszne. Platforma jest bowiem obecna na rynku od lat. Jest udostępniana na licencji open source, znana i popularna oraz w pełni konfigurowalna i bezpieczna, a przy tym łatwo zarządzalna. Przynajmniej tak się może wydawać, zwłaszcza po przebrnięciu przez setki stron opisujących zalety konteneryzacji w tym właśnie wydaniu. Tylko czy na pewno wszystkie te przymiotniki są w odniesieniu do Kubernetesa zgodnie z prawdą? Zacznijmy od początku. Czym właściwie jest Kubernetes i skąd się wzięła jego popularność?
Zgodnie z definicją, którą znajdziemy w internecie, Kubernetes jest otwartoźródłową platformą do zarządzania i automatyzacji aplikacji kontenerowych. Historia Kubernetes sięga roku 2014, gdy upubliczniona przez firmę Google została jego pierwsza wersja. Przez lata przeszedł on jednak szereg zmian, a pewne funkcjonalności zostały ustandaryzowane. Niemniej jego nazwa stała się niejako synonimem konteneryzacji, chociaż de facto sam w sobie konteneryzatorem nie jest. Aby wyjaśnić, o co w tym wszystkim chodzi, musimy sobie odpowiedzieć na pytanie, czym właściwie jest kontener i jakie zadania bierze na siebie orkiestrator.
Jak powstała idea konteneryzacji?
Myślę, że tok rozumowania twórców idei konteneryzacji mógł przebiegać następująco: co by było, gdybyśmy z jednej z popularnych dystrybucji Linuksa, na której działa nasza aplikacja, usunęli wszystko, co jest nam niepotrzebne i zostawili wyłącznie podstawowe elementy niezbędne do uruchomienia tejże aplikacji? Dodatkowo, gdybyśmy skonfigurowali system tak, aby automatycznie uruchamiał wszystko to, co jest niezbędne i w razie awarii uruchamiał się z utworzonego wcześniej obrazu? Otrzymalibyśmy maszynę wirtualną o bardzo niewielkich rozmiarach, wymagającą minimalnych zasobów, a przy okazji praktycznie bezawaryjną i bezobsługową. W razie problemów usuwamy ją i tworzymy na nowo.
Takie podejście miałoby oczywiście swoje ograniczenia, ponieważ uruchamianie maszyny wirtualnej z zapisanego obrazu sprawia, że wszystkie dane przechowywane wewnątrz niej są efemeryczne. W związku z tym każda uruchamiana wewnątrz aplikacja musiałaby być bezstanowa i korzystać jedynie z zewnętrznego storage’u lub bazy danych, a każda zmiana konfiguracji systemu wymagałaby od nas utworzenia obrazu na nowo. Oczywiście takie wyjaśnienie działania kontenerów jest dosyć dużym uproszczeniem i miało na celu raczej przedstawienie toku myślenia, jaki mogli mieć twórcy konteneryzacji, niż technicznym wyjaśnieniem, czym jest kontener. Jednak nie zagłębiając się zbyt mocno w szczegóły techniczne – kontenery nie są maszynami wirtualnymi i ich zasada działania jest nieco inna niż klasycznych wirtualek. Jednak podobieństw nie da się nie zauważyć.
Czym jest kontener?
Jest to platforma, która zawiera wszystkie niezbędne elementy, w tym biblioteki czy pliki konfiguracyjne potrzebne do uruchomienia danego programu. Bazą kontenera jest zawsze system operacyjny oparty na jądrze Linuksa. Warto tutaj nadmienić, że w znakomitej większości systemy bazowe są darmowe. Nie ponosimy zatem kosztów licencji jak w przypadku klasycznych rozwiązań, chyba że zdecydujemy się na wykorzystanie dodatkowych płatnych komponentów.
Kontenery działają niezależnie od siebie i nie są świadome swojej obecności. Oczywiście kontenery mogą się komunikować zarówno ze sobą, jak i z hostem, na którym działają poprzez sieć i to w ściśle kontrolowany sposób. O tym jednak powiemy sobie nieco więcej w dalszej części materiału.
Maszyna wirtualna może być hostem dla kontenera, ale ten z kolei nie jest traktowany jako wirtualka i nie może być hostem dla kolejnych kontenerów. Zagnieżdżanie kontenerów zwyczajnie nie istnieje, a pojedynczy kontener uruchamia najczęściej jedną aplikację. Najczęściej – bo nie zawsze. To trochę od nas zależy, co my do takiego kontenera włożymy. Niemniej pewne założenia, o których wspomnimy jeszcze nieco szerzej, sprawiają, że pojedynczy kontener powinien być jak najprostszy, a aplikacja, która w klasycznym modelu najczęściej stanowi jedną całość, jest rozbita na komponenty stanowiące zbiór luźno połączonych ze sobą serwisów.
Ideą takiego rozwiązania jest między innymi niezależność mikroserwisów – taka nazwa funkcjonuje w tym podejściu. Pozwala to między innymi na niezależne ich rozwijanie bez konieczności ingerencji w pozostałe komponenty aplikacji. Możemy sobie naturalnie wyobrazić podejście do tematu, w którym mikroserwisy są rozłożone na klasycznych maszynach wirtualnych, czy to na jednej, czy na wielu. Powiedzmy sobie wprost – takie rozwiązanie wciąż bardzo często funkcjonuje, ale jest zwyczajnie mało elastyczne, mało wydajne i biorąc pod uwagę wielkość i złożoność współczesnych aplikacji, trudne w zarządzaniu. Dodając do tego jeszcze konieczność zarządzania systemem operacyjnym jako takim i przeprowadzanie częstych wdrożeń – borykamy się z problemami, które w dużej mierze konteneryzacja rozwiązuje.
Kubernetes i jego rola w konteneryzacji
No dobrze, powiedzieliśmy sobie o konteneryzacji jako takiej, ale gdzie w tym wszystkim znajduje się Kubernetes i jaką pełni rolę? Gdy planujemy wdrożenie aplikacji napisanej w postaci współpracujących ze sobą mikroserwisów, zazwyczaj chcemy, aby każdy z nich działał w dedykowanym kontenerze. Szybko dojdziemy jednak do wniosku, że poszczególne mikroserwisy różnią się od siebie nie tylko funkcjonalnością wynikającą z ich przeznaczenia i struktury samej aplikacji, ale również ilością alokowanych zasobów. O pionowym skalowaniu kontenera możemy praktycznie zapomnieć, ponieważ kłóci się to z samą ideą kontenera, który przede wszystkim powinien być lekki i szybki w uruchamianiu.
Problem wydajności rozwiązuje się poprzez skalowanie poziome, które jest niczym innym jak dodawaniem kolejnych podów (pojedynczy kontener) sprzęgniętych ze sobą poprzez definicję wdrożenia, zwaną manifestem. Czyli tworzymy coś w rodzaju klastra aplikacyjnego, znanego z klasycznych rozwiązań opartych na przykład na serwerach JBoss czy WebLogic.
Kilka słów na temat Dockera
Docker, najpopularniejszy i najczęściej wykorzystywany konteneryzator, rozprowadzany również na licencji open source, jest oprogramowaniem, które czuwa nad naszym klastrem aplikacyjnym. Słowo klaster zostało tutaj użyte trochę niefortunnie, ponieważ w dalszej części artykułu będziemy mieli do czynienia również z klastrami, ale w odniesieniu do samego Kubernetesa. Znaczenia tych słów nie należy mylić. Zadaniem Dockera jest tworzenie, uruchamianie i utrzymywanie kontenerów, jednak kontrola jest całkowicie po naszej stronie. Docker jest oprogramowaniem, które spełnia i całkowicie wykorzystuje ideę konteneryzacji, jednak nie umożliwia nic poza tym. Wracając do naszej aplikacji, szybko dojdziemy do wniosku, że brakuje nam chociażby opcji autoskalowania podów w zależności od wykorzystania zasobów czy liczby nawiązanych sesji użytkowników. Sam Docker nie umożliwia też samoleczenia, czyli zastępowania nieodpowiadających bądź uszkodzonych kontenerów nowymi, czy równoważenia obciążenia.
Naturalnie, wszystkie te brakujące funkcje można obsłużyć przy pomocy zewnętrznego oprogramowania, jak chociażby Docker Swarm, którego można nazwać natywnym orkiestratorem, umożliwiającym zarządzanie kontenerami w sposób, jakiego nie przewiduje Docker. Jednak pomimo tego, że stosując narzędzia, takie jak Docker Swarm, zyskamy dużo większą elastyczność i sporo nowych funkcjonalności, to wielu z nich nadal nie doświadczymy. Dodatkowo będziemy nieco ograniczeni samą ideą Docker Swarma, który bądź co bądź jest narzędziem stricte dockerowym i powinien być postrzegany raczej jako rozszerzenie funkcjonalności konteneryzatora, niż jako pełnoprawny orkiestrator.
Docker a Kubernetes
Być może moja ocena jest trochę niesprawiedliwa, ale uważam, że Kubernetes w tej kwestii pozostawia Swarma daleko z tyłu. Jest bowiem narzędziem pomyślanym i stworzonym od podstaw, które co prawda może wykorzystywać Dockera jako silnik konteneryzacji, ale nie jest do niego ograniczone. Kubernetes jest platformą, która na bazie silnika kontenerów pozwala stworzyć środowisko w pełni skalowalne, wysokodostępne i odporne na awarie, a przy tym w pełni konfigurowalne z możliwością automatyzacji.
Skoro Kubernetes jest taki dobry, to po co go poprawiać?
Pytanie jest bardzo trafne, bo faktycznie Kubernetes pozwala pokonywać ograniczenia, jakie ma Docker czy nawet Docker Swarm, ale trzeba go trochę traktować jako rdzeń, na bazie którego jesteśmy w stanie uruchomić i skonfigurować system, który będzie kompletny i wyposażony we wszystkie narzędzia, których potrzebujemy.
Kubernetes posiada ograniczenia w postaci choćby braku routowalnej sieci, pełnoprawnej kontroli dostępu opartej o zewnętrzne systemy uwierzytelniające, obsługi potoków CI/CD czy graficznego interfejsu użytkownika. Każdy z tych elementów możemy, a często nawet musimy zainstalować i skonfigurować (tak jest chociażby w przypadku sieci), aby móc w pełni wykorzystać potencjał konteneryzacji. Oczywiście wszystko to przy odpowiednim nakładzie pracy będzie działać, ale jeżeli zależy nam na szybkim postawieniu kompletnego i stabilnego środowiska kontenerowego, warto rozważyć alternatywy w postaci Ranchera i OpenShifta, czyli dwa pozornie podobne, ale, jak się okaże w dalszej części artykułu, kompletnie różne orkiestratory.
Czy warto konfigurować Kubernetesa samodzielnie?
Przypominają mi się tutaj czasy początków Linuksa. W tej chwili mamy systemy, które po zainstalowaniu są właściwie gotowe do pracy i wymagają od nas niewielkiego wysiłku, aby stały się stabilne, bezpieczne i w pełni funkcjonalne. Jednak nie zawsze tak było i początkowo Linux wymagał od użytkownika olbrzymiego nakładu pracy, żeby w ogóle stać się pełnoprawnym systemem operacyjnym. Nadal jest wielu „zapaleńców”, którzy uwielbiają konfigurować, grzebać w plikach, kontrolować każdy szczegół, ale powiedzmy sobie wprost – większość z nas, no może duża część, oczekuje systemu, który zwyczajnie działa, bez konieczności poświęcania setek godzin na jego konfigurację.
Wynika to trochę z braku czasu, ale też ze stopnia skomplikowania współczesnych systemów. Trochę podobnie jest z Kubernetesem, który sam w sobie jest dobry, ale wymaga sporego wysiłku i dużego nakładu pracy, abyśmy mogli powiedzieć, że jest skonfigurowany optymalnie i zawiera wszystkie elementy niezbędne do prawidłowego działania. W znakomitej większości przypadków zależy nam na solidnym i bezpiecznym systemie, który jest w stanie udźwignąć nasze aplikacje, umożliwiać proste i skuteczne administrowanie, a jednocześnie pozostawia naprawdę dużo miejsca na własną konfigurację. Dodatkowo nie możemy zapomnieć, że Kubernetes jest projektem open source i jako taki nie posiada żadnego wsparcia, no może poza olbrzymią społecznością. Nie mamy tutaj jednak żadnej gwarancji, że komponenty, które wykorzystamy do budowy naszego orkiestratora, będą w pełni ze sobą współpracowały i że któryś z kolei update nie spowoduje problemów.
Oczywiście wszystkiego można uniknąć i przy odpowiednio dużym nakładzie pracy będziemy w stanie zbudować platformę konteneryzacyjną, która będzie lepsza niż opisywane produkty. Jednak, jak się, mam nadzieję, okaże w dalszej części artykułu, nakład takiej pracy jest zwyczajnie nieopłacalny, ponieważ otrzymujemy tutaj produkty kompletne, które dokładnie w ten sposób należy traktować.
Czy można znać się na wszystkim?
Dochodzi do tego jeszcze pewna zmiana podejścia, która na przestrzeni ostatnich lat bardzo mocno wkroczyła na rynek IT. Gdy zaczynałem pracę, większość ludzi z branży stawiała sobie za cel posiadanie jak największej i bardzo rozległej wiedzy z wielu dziedzin, dzięki której byliby w stanie postawić samodzielnie dowolny system, zadbać o niego od każdej strony, a jednocześnie zapewnić mu całkowite bezpieczeństwo. Czasy trochę się zmieniły i stopień zaawansowania systemów informatycznych jest obecnie tak duży, że trudno wymagać od kogokolwiek, żeby się znał na wszystkim. Obecnie coraz częściej oczekujemy produktów, na których będziemy mogli pracować. Wydaje mi się, że właśnie słowo produkt jest tutaj kluczowe.
Rozwiązania all-in-one
No dobrze, ale czy to nie jest trochę tak, że produkty all-in-one są mniej bezpieczne, słabo konfigurowalne, przyjmujące jedno tylko słuszne podejście i niepozostawiające miejsca na własną konfigurację? Z jednej strony można tak właśnie na to spojrzeć, ale z drugiej, patrząc chociażby na nowoczesne dystrybucje Linuksa, otrzymujemy produkt kompletny, z zainstalowanym oprogramowaniem czy predefiniowanymi politykami bezpieczeństwa. Rozwiązania tego typu dają nam przede wszystkim duże bezpieczeństwo i pewność działania osiągnięte między innymi kompatybilnością użytych elementów składowych, ale także dużą możliwość konfiguracji i swobodę dostosowania instalacji do naszych potrzeb.
Rancher vs OpenShift — pierwsze spojrzenie
Historia Ranchera sięga roku 2016, kiedy to została wypuszczona pierwsza jego wersja. Jednak właściwa historia zaczyna się w roku 2020, gdy został on przejęty przez firmę SUSE, aby od tego momentu stanowić pewnego rodzaju wizytówkę i okręt flagowy firmy – przynajmniej w zakresie konteneryzacji. Rancher jest oprogramowaniem open source, posiada jednak pełną wersję supportowaną o nazwie Rancher Prime.
Rancher jest otwartoźródłową platformą służącą do zarządzania wieloma klastrami kubernetesowymi. Oznacza to, że instalując Ranchera, otrzymujemy środowisko, w którym możemy zarówno stworzyć klaster, jak i podpiąć praktycznie każdy inny oparty o platformę Kubernetes. Dzięki temu otrzymujemy środowisko z jednolitym interfejsem, przy pomocy którego możemy zarządzać naszymi klastrami.
Co znaczy, że możemy podpiąć praktycznie każdy klaster? Stwierdzenie zostało użyte być może nieco na wyrost, biorąc pod uwagę jak szybko rynek IT się rozwija i ile się w nim zmienia. Niełatwo jest nadążyć za zmianami, nawet starając się być na bieżąco. Trudno więc wymagać, aby jakikolwiek system deklarował zgodność z każdą platformą pojawiającą się na rynku. Jednak w znakomitej większości przypadków będzie to prawda – większość klastrów, jakie posiadamy, będą z Rancherem kompatybilne. Wystarczy tylko pamiętać o minimalnych wersjach Kubernetesa, z jakimi Rancher współpracuje.
Inne podejście OpenShifta
W przypadku OpenShifta mamy do czynienia z nieco innym podejściem. Jest to platforma zamknięta, opracowana i utrzymywana przez firmę Red Hat. OpenShift wykorzystuje Kubernetesa jako konteneryzator z dodatkowymi warstwami zarządzania, bezpieczeństwa i automatyzacji. Mocno integruje się on z innymi produktami Red Hata, co nie powinno nas dziwić, gdyż firma ta przez lata przyzwyczaiła nas do tego. OpenShift jest oprogramowaniem komercyjnym, posiada jednak wersję otwartoźródłową o nazwie OKD.
Zarządzanie zewnętrznymi klastrami Kubernetes z poziomu platformy OpenShift jest jak najbardziej możliwe, jednak po pierwsze wymaga dodatku Advanced Cluster Management, po drugie nie do końca jestem przekonany, czy jest to dobre rozwiązanie. Według mnie OpenShift nie jest dobry do tego typu działań ze względu na to, że jest produktem zamkniętym i kompletnym i jako taki powinien być postrzegany. W końcu Red Hat oferuje nam platformę komercyjną i w pełni supportowaną.
Instalacja i interfejs
Instalacja Ranchera
Rancher to orkiestrator, który służy do zarządzania klastrami, ale sam w sobie również jest instalowany w klastrze. Zalecaną metodą instalacji jest wykorzystanie klastra RKE (Rancher Kubernetes Engine) bądź RKE2, czyli tak naprawdę odpowiednio przygotowanego silnika opartego na Kubernetesie, na którym działa sam Rancher. Jedną z cech odróżniających RKE2 od jego wcześniejszej wersji jest to, że nie wymaga do działania Dockera, ponieważ konteneryzacja w tym przypadku opiera się na rozwiązaniu containerd.
No dobrze, tyle powiedzieliśmy sobie o Dockerze, a tu nagle okazuje się, że już go nie potrzebujemy? Nie do końca, ponieważ containerd jest projektem, który został wyizolowany z Dockera kilka lat temu i służy stricte jako środowisko uruchomieniowe dla platform kubernetesowych, podczas gdy Docker jest produktem, który może działać samodzielnie. Niemniej jednak podchodzenie obydwu rozwiązań jest wspólne.
Rancher jest rozwiązaniem na tyle uniwersalnym i przemyślanym, że możemy go zainstalować praktycznie na dowolnym klastrze, bez konieczności stosowania dedykowanych przez producenta rozwiązań. Jest to również ważne w kontekście tego, co napisałem wcześniej – Rancher jest systemem z jednej strony dostarczonym „w całości” i kompletnym, z drugiej strony mocno konfigurowalnym, jak się okazuje już od wyboru platformy instancyjnej. Wystarczy powiedzieć, że instalację platformy możemy przeprowadzić nawet na jednonodowym Kubernetesie wykorzystującym Dockera jako konteneryzator. Oczywiście instalacja taka będzie dosyć mocno ograniczona i niezalecana tam, gdzie zależy nam na stabilności i wydajności, niemniej jednak jest możliwa do przeprowadzenia.
Wspomnę też o tym, że praktycznie nie ogranicza nas wybór platformy sprzętowej czy wirtualnej. Środowisko zadziała nam równie dobrze, będąc zainstalowane lokalnie czy w chmurze. Sam proces instalacji Ranchera wymaga od nas nieco uwagi, ale jest relatywnie prosty i porównując go do instalacji czystego Kubernetesa, jest spójny i szybki. Zresztą, wsparcie zarówno ze strony społeczności, jak i samego producenta jest naprawdę duże i z roku na rok zainteresowanie tym produktem wzrasta.
Interfejs Ranchera
Rancher wprowadza pewnego rodzaju standard. Oferuje nam jednolity interfejs użytkownika, dzięki któremu możemy zarządzać klastrami poprzez GUI, umożliwia tworzenie nowych, w pełni zarządzalnych oraz oferuje relatywnie prosty sposób na podłączanie istniejących. W przypadku zewnętrznych klastrów konieczne jest zainstalowanie agenta. Czynność ta jest prosta, a sam Rancher dosyć dobrze poprowadzi nas przez cały proces, podpowiadając wprost polecenia, jakie trzeba na docelowym klastrze wykonać.
Jak napisałem, interfejs Ranchera jest spójny i dosyć prosty. Mamy tu do czynienia z klarownym rozmieszczeniem poszczególnych elementów. Począwszy od menu głównego, poprzez dodatkowe czynności jak pobranie pliku kubeconfig, dostęp do wbudowanego shella czy wybór namespace’u, na umieszczonych w centralnym miejscu pulpitu informacjach o zasobach klastra i eventach skończywszy.
Rancher posiada również wersję komercyjną zwaną Prime, której zakup da nam pełne wsparcie firmy SUSE.
Instalacja OpenShifta
Różnice pomiędzy platformami Rancher i OpenShift widać już podczas procesu instalacji. Nie mamy tu takiej swobody jak przy produkcie firmy SUSE, gdyż OpenShift nie dość, że wykorzystuje całe środowisko wirtualne, to jeszcze wymaga od nas użycia specjalnie przygotowanych systemów RHEL CoreOS lub w przypadku OKD Fedora CoreOS. Dodatkowo konieczne jest dostarczenie odpowiedniej liczby wirtualek z wymaganymi zasobami. Sam proces instalacji jest relatywnie prosty i może odbywać się na kilka różnych sposobów, z których najbardziej podstawowym jest przekazanie przygotowanych wcześniej plików konfiguracyjnych podczas bootowania systemu, a następnie wykonanie serii poleceń.
Instalację OpenShifta możemy również przeprowadzić nieco bardziej automatycznie na jednej z supportowanych platform wirtualizacyjnych, jak chociażby VMWare czy OpenStack, pozwalając, aby instalator wykonał za nas większość pracy.
Interfejs OpenShifta
Podobnie jak w przypadku Ranchera, interfejs OpenShifta jest prosty i spójny. Zauważymy oczywiście spore różnice w rozmieszczeniu poszczególnych elementów interfejsu, ale podobnie jak u konkurenta jest on dosyć przejrzysty i intuicyjny.
Graficzne interfejsy użytkownika zazwyczaj nie są tym, co administratorzy lubią najbardziej. Podobnie jak w Rancherze, wszystko możemy wykonać tutaj przy pomocy wiersza poleceń. Niemniej jednak nie da się dyskutować z faktem, iż w wielu sytuacjach korzystanie z GUI jest zwyczajnie prostsze i oszczędza sporo czasu. Wykonując typowe czynności administracyjne, często prościej jest skorzystać z CLI. Jednak gdy dochodzimy do momentu, w którym musimy utworzyć nowe polityki sieciowe, przeanalizować dostępy czy nawet monitorować zasoby naszego klastra, okazuje się, że GUI jest przydatnym narzędziem. W obu przypadkach są one proste, przemyślane i w gruncie rzeczy poza różnicami w układzie oraz funkcjach, są bardzo podobne.
Zarządzanie dostępem
Zarówno jedna, jak i druga platforma oferuje nam klasyczny RBAC, czyli oparty na rolach system weryfikacji dostępu, rozszerzając w ten sposób to, co daje nam Kubernetes. Przypomnijmy, kontrola dostępu w Kubernetesie jest domyślnie włączona od wersji 1.8. Jednak korzystanie z niej nie jest szczególnie wygodne. Obie platformy w podobny sposób upraszczają zarządzanie bezpieczeństwem. Role możemy przydzielać zarówno do użytkowników, jak i do grup, a uprawnienia przyznawać na poziomie klastra, przestrzeni nazw czy w przypadku Ranchera – projektu.
Rancher daje nam kolejny poziom uporządkowania naszych aplikacji, wprowadzając pojęcie projektu. Projekt jest niczym innym jak nadrzędnym folderem, w którym znajdują się namespace’y. Musimy jednak pamiętać, że pojęcie projektu zostało wprowadzone przez Ranchera i nie jest on natywnym obiektem Kubernetesa. W związku z tym przydzielając użytkownikom uprawnienia na tym poziomie, robimy to wyłącznie na platformie Rancher i będziemy mogli z nich skorzystać jedynie poprzez GUI lub autoryzując się w klastrze za pośrednictwem API Ranchera. Pojęcie projektu obecne jest także w OpenShifcie, ale w tym przypadku jest to nic innego jak klasyczny namespace. Może to być trochę mylące, zwłaszcza przesiadając się z jednej platformy na drugą czy operując w obydwu systemach jednocześnie.
Podłączenie do kontrolera domeny lub do zewnętrznego dostawcy poświadczeń jest zazwyczaj jedną z pierwszych rzeczy, jakie robimy, instalując w firmie nowe oprogramowanie, które rzecz jasna taką możliwość posiada. Jeżeli chodzi o mechanizm zewnętrznego uwierzytelnienia, to jest to coś, czego w Kubernetesie brakuje. Na platformie Rancher skonfigurować możemy jednego lub wielu dostawców poświadczeń. Może to być FeeeIPA, LDAP bądź jakikolwiek z popularnych protokołów. Całą operację jesteśmy w stanie przeprowadzić z poziomu konsoli GUI. Podłączenie Ranchera do zewnętrznego serwera uwierzytelniającego jest zresztą warunkiem koniecznym, aby w pełni wykorzystać dobrodziejstwo RBAC-a, gdyż pewnych rzeczy z lokalnymi użytkownikami zwyczajnie nie będziemy w stanie zrobić.
Co umożliwia OpenShift?
OpenShift pozwala nam na nieco więcej. Dostawców poświadczeń również tutaj może być wielu i o ile częściowo operację tę możemy wykonać z GUI, to pewne rzeczy, jak podłączenie platformy do serwera LDAP, będziemy w stanie wykonać wyłącznie z poziomu CLI, korzystając z dostarczonych przez Red Hat aplikacji. Oczywiście nie jest to żaden problem, gdyż operację taką wykonujemy zazwyczaj tylko raz i nigdy więcej do tego nie wracamy. Obie platformy pozwalają na niezależne od konfiguracji dostawcy poświadczeń tworzenie użytkowników i grup. Niemniej odnoszę wrażenie, że OpenShift jest nieco bardziej elastyczny w tej kwestii.
Dlaczego w ogóle temat autoryzacji i kontroli dostępu jest tak ważny? Bezpieczeństwo jest jednym z kluczowych zagadnień w każdej firmie. Systemy komputerowe rozrastają się w zastraszającym tempie i często zapanowanie nad nimi jest zadaniem mocno karkołomnym. Dodając do tego zalecaną zasadę ograniczonego dostępu do zasobów i często dużą rotację pracowników w firmach, chcemy, aby nasze systemy były pewne i bezpieczne w każdej sytuacji. Obie platformy oferują rozwiązania, które znacznie ułatwiają kontrolę dostępu i panowanie nad uprawnieniami, jak również połączenie z istniejącymi, zewnętrznymi systemami uwierzytelniania.
Bezpieczeństwo kontenerów, czyli nie tylko dostęp
Kontynuując niejako poprzedni wątek, chciałbym, abyśmy zatrzymali się nieco dłużej na szeroko pojętej tematyce bezpieczeństwa kontenerów. Po co w ogóle zabezpieczać kontenery? Czy nie wystarczy, że odpowiednio skonfigurujemy nasze środowisko, podłączymy do LDAP-a, utworzymy grupy, dodamy im odpowiedni poziom dostępu, no i rzecz jasna zabezpieczymy dostęp do naszych nodów? No nie do końca. Weźmy pod uwagę kilka kwestii.
Po pierwsze nigdy nie możemy być pewni w stu procentach naszego środowiska. Dzieje się tak chociażby z tego względu na to, że zazwyczaj jest ono konfigurowane i zarządzane przez różne osoby i pomimo największych wysiłków zdarzają się różnice w podejściu do niektórych zagadnień, niedopatrzenia czy nawet niewiedza skutkująca powstawaniem luk w systemie. Czasami problem dotyczy braku aktualizacji najbezpieczniejszych, jak by się mogło wydawać, komponentów.
Po drugie bezpieczeństwo sieciowe. Infrastruktura sieciowa w dużej firmie zazwyczaj przypomina pajęczynę, w której setki czy tysiące systemów są ze sobą mniej lub bardziej połączone. Nawet jeżeli jesteśmy w stanie monitorować każde połączenie i wychwytywać potencjalne problemy, to każde dodatkowe zabezpieczenie jest tutaj na wagę złota.
Po trzecie nie zawsze korzystamy z własnych aplikacji, które są tworzone w jednolity i kontrolowany sposób. Niejednokrotnie jesteśmy uzależnieni od zewnętrznych dostawców oprogramowania, którzy, powiedzmy sobie szczerze, nie zawsze są chętni do pełnej współpracy z nami w kwestiach bezpieczeństwa rozwijanych przez nich aplikacji. Często potencjalne problemy są zwyczajnie ignorowane. Weźmy na przykład aplikację kontenerową, która wymaga, aby ją uruchamiać z prawami roota. Liczba potencjalnych problemów i luk wynikających z takiego podejścia jest wręcz przytłaczająca.
Kubernetes i jego zabezpieczenia
To nie tak, że Kubernetes jest zupełnie pozbawiony zabezpieczeń czy narzędzi, dzięki którym poziom bezpieczeństwa możemy zwiększyć, ale jest ich relatywnie mało. Mamy tutaj obiekt o nazwie NetworkPolicy, który służy jako pewnego rodzaju firewall umożliwiający blokowanie ruchu pomiędzy podami czy przestrzeniami nazw, ale pisanie polityk nie należy do rzeczy prostych. Ktoś, kto chociaż raz tej sztuki próbował, doceni dobrodziejstwo kreatorów, w jakie są wyposażone nasze platformy. Kreatory nie są idealne i do większych projektów warto mimo wszystko zainteresować się zewnętrznymi narzędziami, które w sposób przejrzysty pozwalają takie polityki generować, niemniej jednak ułatwienie jest i tak bardzo duże.
NeuVector
Chciałbym jednak wspomnieć o jeszcze jednym narzędziu, które nie jest co prawda integralną częścią żadnej z platform, ale które w niesamowity wręcz sposób zwiększa poziom bezpieczeństwa naszego orkiestratora. Narzędziem tym jest NeuVector, czyli wywodzące się ze stajni SUSE kompleksowe rozwiązanie zwiększające bezpieczeństwo klastrów Kubernetes, zaczynając od zabezpieczenia strony sieciowej, poprzez skanowanie podatności nodów i kontenerów, na analizie procesów CI/CD kończąc.
Trudno przejść obok NeuVectora obojętnie, patrząc na ogrom zastosowań i funkcjonalności oraz na to, że chyba nie ma w tym momencie na rynku narzędzia, które równie kompleksowo zajmowałoby się tematem bezpieczeństwa. NeuVector wywodzi się od producenta Ranchera, jednak jego zastosowanie nie ogranicza się jedynie do tejże platformy. Jest bowiem w pełni kompatybilny z Kubernetesem, a co za tym idzie, możliwy jest również do zastosowania w OpenShifcie. Dokładnie tak, mimo że platformy te stanowią dla siebie pewnego rodzaju konkurencję, to bezpieczeństwo jest bezsprzecznie priorytetem, który musimy wziąć pod uwagę.
Aplikacje
Zarówno jedna, jak i druga platforma oferuje nam pełen zestaw gotowych do zainstalowania aplikacji z często predefiniowanymi ustawieniami. Dzięki nim możemy, korzystając między innymi z możliwości pełnej integracji z platformą, wyposażyć nasze środowisko w całą gamę programów narzędziowych znacznie wzbogacających jej funkcjonalność, ale nie tylko. Wśród kategorii mamy również bazy danych, repozytoria, serwery www i ogrom innych narzędzi, z każdej praktycznie dziedziny. Zresztą idea instalacji dodatkowego oprogramowania jest obecna w Kubernetesie praktycznie od początku. Zazwyczaj opiera się a operatorach. Te z kolei wykorzystują Custom Resource Definitions. Kubernetes, jak już powiedzieliśmy, jest oprogramowaniem dosyć ubogim i aby doprowadzić go do stanu, w jakim będzie mógł być uznany za w pełni zarządzalną platformę konteneryzacyjną, będziemy musieli prędzej czy później skorzystać z dobrodziejstw CRD.
Platformy, które omawiamy, mają budowę modułową. Oznacza to, że funkcje, jakie nam oferują, są same w sobie zazwyczaj kontenerami opartymi właśnie na CRD. Wiadomo jednak, że nigdy nie jest tak dobrze, żeby nie mogło być lepiej. Dlatego też funkcje, jakimi platformy dysponują, możemy znacząco rozszerzyć, instalując dodatkowe moduły.
Podejście Ranchera
Rancher oferuje nam podejście oparte na najpopularniejszym chyba w tej chwili managerze pakietów, jakim jest Helm Chart.
Podejście to jest dosyć uniwersalne. Zresztą aplikacje, które instalujemy samodzielnie z Helm Chartów, niekoniecznie poprzez interfejs webowy, również pojawiają nam się w panelu Apps. Nie ma tutaj również ograniczenia jeśli chodzi o repozytoria. Mamy naturalnie te oficjalne, które zawierają aplikacje sprawdzone i w pełni kompatybilne z naszą platformą. Dodatkowo mamy te posiadające opcję pełnej integracji z Rancherem w postaci dodatkowego menu czy zintegrowanej funkcji logowania. Tak działa między innymi wspomniany wcześniej NeuVector. Nic nie stoi na przeszkodzie, abyśmy dodali swoje własne repozytoria.
Jak powiedziałem wcześniej, Rancher jest platformą otwartą o bardzo dużych możliwościach personalizacji i konfiguracji. Podejście, jakie oferuje nam SUSE w swoim produkcie, jest dobre, ale nie pozbawione błędów. Przede wszystkim bezpieczeństwo, które mimo wszystko stoi na relatywnie niskim poziomie i bez dodatkowego oprogramowania kontrolującego i monitorującego nasze zasoby jesteśmy właściwie bezbronni. No, może trochę przesadzam, bo nie jest aż tak źle, w końcu aplikacje, które oferuje nam Rancher w oficjalnych repozytoriach, są w jakiś sposób sprawdzone i bezpieczne.
Jednak ponieważ stopień skomplikowania dzisiejszych aplikacji, wynikający przede wszystkim z ilości użytych w nich komponentów, często na licencji open source, czyli praktycznie zupełnie pozbawionych kontroli, jest olbrzymi, żeby nie powiedzieć gigantyczny, nie możemy czuć się bezpiecznie w żadnym momencie. Niemniej jednak podejście, jakie oferuje Rancher, jest mi bardzo bliskie. Zwłaszcza ze względu na swoją otwartość i możliwość konfiguracji. Właściwie każdą z aplikacji możemy zmodyfikować do własnych potrzeb już na etapie instalacji, każdą też możemy zmienić i usunąć.
Podejście OpenShifta
OpenShift idzie w tym temacie nieco dalej. Oferuje bowiem oficjalne repozytoria, w których aplikacje są bardziej kontrolowane. Ponieważ Red Hat dostarcza nam rozwiązanie kompletne i supportowane, również aplikacje dostępne w ramach subskrypcji powinny być pewne i nie budzić wątpliwości. To nie znaczy oczywiście, że OpenShift wymusza na nas instalację jedynie słusznego oprogramowania. Jest to w dalszym ciągu platforma konteneryzacyjna, która pozwala na bardzo dużo i nikt nam nie zabroni korzystać z takiego oprogramowania, z jakiego chcemy. Niemniej jednak warto zastanowić się nieco dłużej, czy aby na pewno chcemy to zrobić. Nie mamy wtedy również gwarancji poprawnej integracji z platformą. Tak, integracja oprogramowania z OpenShiftem również istnieje, chociaż w nieco mniejszym stopniu niż w przypadku Ranchera.
CLI czy GUI?
Konteneryzacja stworzona została z myślą o mikroserwisach. Z poziomu CLI Kubernetesa możemy w pełni kontrolować, co, gdzie i jak zostało zainstalowane. Mamy dostęp do logów, eventów oraz oczywiście do wszystkich obiektów, z jakich składa się aplikacja. Nie ma tutaj nic odkrywczego. Jednak jedną z zalet platform, jakie omawiamy, jest GUI. Graficzny interfejs użytkownika daje nam pełną kontrolę nad wdrożeniami, które posiadamy bądź zamierzamy zrealizować wraz z ich zależnościami w postaci wszelkiej maści obiektów, które się na nie składają. Podejścia obu systemów są bardzo podobne, różnią się co prawda lokalizacją niektórych elementów i naturalnie samym interfejsem, ale tak naprawdę nie ma tutaj nic niezwykłego i dostęp do poszczególnych funkcji jest dosyć prosty i intuicyjny.
Dlaczego w ogóle o tym piszę, skoro powiedzieliśmy sobie wcześniej, że GUI jako takie często jest nielubiane przez administratorów i omijane szerokim łukiem? W końcu wszystko można zrobić z CLI. To prawda, ale jedno podejście nie wyklucza drugiego. GUI jest niezwykle przydatne w zarządzaniu dużymi klastrami, gdzie nie dość, że musimy się przebić przez dużą ilość namespace’ów, deploymentów czy PV-ek, to jeszcze musimy to zrobić dosyć szybko i bez wątpliwości. Korzystamy z platform, w których graficzny interfejs użytkownika nie stanowi dodatku, a jest ich integralną częścią i warto z niego korzystać.
Zarządzanie wdrożeniami
Zarówno Rancher jak i OpenShift oferują nam dosyć dobrze zaprojektowane narzędzia do zarządzania wdrożeniami. Możemy kontrolować właściwie wszystkie podstawowe obiekty Kubernetesa, począwszy od samych wdrożeń, poprzez dodatkowe elementy jak serwisy, sekrety czy zewnętrzny storage, na CRD-kach i operatorach skończywszy. Możemy to robić zarówno poprzez formatki edycji parametrów, jak i przez edycję definicji czy manifestów zawartych w plikach yaml. Dla większości obiektów dostępne są też kreatory umożliwiające szybkie i proste ich tworzenie, a następnie podejrzenie i edycję, a nawet zaimportowanie kompletnego pliku.
Przy większych wdrożeniach rzadko będziemy z kreatorów korzystać, bazując bardziej na Helm Chartach bądź nawet gotowych yamlach, wykorzystując również dobrodziejstwo, jakim są procesy CI/CD. Powiemy o tym więcej nieco później. Nie ulega wątpliwości, że możliwość podejrzenia konfiguracji, jaką wdrożymy w bardziej przyjazny sposób, niż analiza pliku yaml, jest przydatna. Zwłaszcza podczas testów czy zmiany parametrów aplikacji.
Monitoring
Aplikacje to też monitoring i tutaj także nasze orkiestratory dają nam niezbędne narzędzia. Oczywiście trudno się tu doszukiwać możliwości, jakie oferuje chociażby Prometheus czy Grafana, które to naturalnie możemy zainstalować, korzystając z oficjalnego repozytorium i predefiniowanych konfiguracji. Jednak do codziennej pracy w zupełności wystarczy. Monitorować możemy zresztą nie tylko aplikacje, ale i wykorzystanie zasobów samego klastra czy wykorzystanie sieci.
Obsługa sieci
Natywnie Kubernetes nie obsługuje routowalnych sieci i nie dostarcza nam gotowego rozwiązania sieciowego. Stąd potrzeba zainstalowania dodatkowego pluginu w postaci chociażby Calico czy Flannel. Zarówno Rancher jak i OpenShift wyręczają nas z tego obowiązku w nieco inny sposób. Podczas konfiguracji klastra na platformie Rancher będziemy mieli możliwość wyboru pluginu sieciowego. Rancher dostarcza predefiniowane opcje, takie jak Canal, Calico, Flannel, Weave czy Cilium, chociaż nic nie stoi na przeszkodzie, abyśmy skorzystali z jeszcze innej. W przypadku opcji sugerowanych cała konfiguracja odbywa się praktycznie automatycznie i bez naszego udziału, chyba że bardzo nam na tym zależy. Wówczas możemy taką instalację dostosować, definiując chociażby zakres adresów IP, wielkość MTU czy polityki sieciowe.
OpenShift obsługuje sieci za pomocą rozwiązania sieciowego o nazwie OVN Kubernets, ale, co ciekawe, nie zamyka się na inne rozwiązania, jak wspomniane wyżej pluginy CNI. Obie platformy oferują rozwiązania dosyć dobrze przygotowane i jeśli nie zależy nam na zaawansowanej konfiguracji, która jak najbardziej możliwa również w rozwiązaniu Red Hata, to otrzymujemy predefiniowaną i gotową do działania sieć bez konieczności ingerencji w ustawienia. Dodatkowo dostajemy możliwość korzystania z polityk sieciowych, o czym wspomniałem już wcześniej.
Continuous Integration / Continuous Delivery, czyli czym jest GitOps?
W skrócie GitOps to nowoczesne podejście do zarządzania infrastrukturą i aplikacjami przy pomocy deklaratywnego kodu, łączące w sobie praktyki DevOps i wykorzystujące repozytoria Git jako system kontroli źródła. Trudno sobie wyobrazić nowoczesny system, który przynajmniej w części nie został zautomatyzowany. GitOps łączy w sobie to, co najlepsze, umożliwiając zarządzanie zarówno infrastrukturą, która opisana jest w formie kodu (Infrastructure as Code, IaC) jak i aplikacjami, które wdrażamy na przykład poprzez Helm Charty.
To właśnie Helm Charty stanowią bazę dla systemu Fleet, oferowanego niejako w pakiecie i zintegrowanego z Rancherem. Jest to autorskie rozwiązanie SUSE i mimo że dosyć hermetyczne i stosowane praktycznie jedynie w Rancherze, jest relatywnie proste do opanowania. Przy tym jest potężne i wszechstronne oraz umożliwia zarządzanie środowiskiem wieloklastrowym. Niezależnie od źródła, z jakiego korzystamy – czy to będą czyste pliki yaml, czy skrypty Kustomize, to i tak wszystkie zasoby są dynamicznie przekształcane w wykresy Helm, który służy jako silnik do wdrażania wszystkich zasobów w klastrze zarządzanym przez Ranchera.
Argo CD
OpenShift stosuje nieco inne podejście, wykorzystując zewnętrzną aplikację, jaką jest Argo CD jako deklaratywnego silnika GitOps, z którą jednak dosyć mocno się integruje. Argo CD umożliwia przepływ pracy GitOps, nawet w wieloklastrowej infrastrukturze OpenShift. Korzystając z niego, możemy spójnie konfigurować i wdrażać infrastrukturę oraz aplikacje oparte na Kubernetes w klastrach i cyklach rozwoju.
Rozwiązanie oferowane przez Red Hata nieco bardziej do mnie przemawia, głównie ze względu na to, że jest mniej hermetyczne i zamknięte. Właściwie może być stosowane niezależnie od platformy. Argo CD jest narzędziem otwartoźródłowym, posiadającym bogatą społeczność z naprawdę dużą bazą wiedzy. Ale GitOps to pewnego rodzaju podejście, w którym nie jesteśmy zobligowani do używania jednego tylko słusznego podejścia. W związku z tym swoboda, jaką mamy, jest naprawdę duża. Co nie zmienia jednak faktu, że poczucie pewności związane z wykorzystywaniem preinstalowanego czy nawet oficjalnie wspieranego przez producenta rozwiązania, jest nie bez znaczenia.
Rancher vs. OpenShift — co wybrać?
Artykuł w swoim założeniu nie miał porównywać ze sobą Ranchera i OpenShifta, a raczej przybliżyć nieco obydwa rozwiązania i, bazując na podstawie, jaką stanowi Kubernetes, pokazać różne podejścia twórców do niektórych tematów. Wielu rzeczy w ogóle nie poruszyliśmy. Nie powiedzieliśmy chociażby o aktualizacjach, możliwościach konfiguracji, dostosowania instalacji do własnych wymagań czy integracji z platformami wirtualizacyjnymi i wykorzystaniu zewnętrznego storage’u. Jednak ze względu na ogrom funkcjonalności, jakimi obie platformy dysponują, trudno byłoby poruszyć wszystkie te aspekty w ramach jednego materiału.
Zarówno Rancher, jak i OpenShift to kompleksowe platformy do zarządzania klastrami Kubernetes, ale opierające się na zupełnie innym modelu. Chociaż patrząc na oba rozwiązania, trudno oprzeć się wrażeniu, że, przynajmniej na pierwszy rzut oka, są do siebie bardzo podobne. W gruncie rzeczy ich przeznaczeniem jest zarządzanie klastrami Kubernetes, a główne różnice polegają na tym, o czym napisałem już we wstępie: Rancher to menedżer klastrów, umożliwiający nie tylko tworzenie swoich własnych, opartych na architekturze RKE, RKE2 czy k3s, ale też dołączanie zewnętrznych, które już posiadamy i zarządzanie nimi. OpenShift natomiast to kompletna platforma kontenerowa oparta na Kubernetesie, która poza dodatkowymi narzędziami, zwiększa poziom bezpieczeństwa, wprowadzając chociażby nieco bardziej rygorystyczne zasady uruchamiania i działania kontenerów. Obie platformy posiadają szereg preinstalowanych oraz cały zestaw dostępnych i wstępnie skonfigurowanych narzędzi, sprawiających, że administracja jest dużo prostsza niż w przypadku klasycznego Kubernetesa.
Wymagania
Jeżeli posiadamy w infrastrukturze firmowej produkty Red Hata i jesteśmy z tą firmą mocno związani, również licencyjnie, a dodatkowo nie posiadamy zewnętrznych klastrów, którymi chcemy zarządzać, to OpenShift jest tutaj rozwiązaniem idealnym. Musimy jednak pamiętać, że wymagania sprzętowe są w tym przypadku znacząco większe. Chociażby z tego powodu, że OpenShift wymaga całych maszyn wirtualnych o określonych parametrach, na których instalowany jest CoreOS, stanowiący podstawę OpenShifta. Nie ma tutaj praktycznie żadnej możliwości negocjacji. Otrzymujemy w zamian system kompletny zarówno pod względem funkcjonalnym, jak i wydajnościowym.
Rancher w tym względzie różni się diametralnie – możemy go zainstalować na praktycznie dowolnej nowoczesnej dystrybucji Linuksa. Oczywiście i w tym przypadku istnieją określone wymagania co do wydajności. Dla instalacji opartych o RKE/RKE2 będą one znacznie wyższe niż przypadku tych opartych o Dockera, jednak będą one i tak mniej rygorystyczne niż w przypadku produktu firmy Red Hat.
Licencje
Musimy również wspomnieć o licencjach. Rancher jest produktem open source, posiadającym swój supportowany odpowiednik w postaci Ranchera Prime. OpenShift natomiast jest w pełni komercyjnym rozwiązaniem, dostępnym również w wersji community pod postacią OKD. Różnica niby niewielka, ale sugeruje trochę inne podejście chociażby do wypuszczania nowych wersji oprogramowania, a co za tym idzie instalowania uaktualnień.
Rancher Prime jest produktem w pełni supportowanym, opartym na wersji darmowej, co może sugerować, iż poza kilkoma dodatkowymi funkcjami, jakie obecne są w wersji płatnej, produkty te są ze sobą praktycznie całkowicie zgodne. Takiej pewności nie mamy niestety w przypadku produktu Red Hata i o ile można podejrzewać, że pod względem funkcjonalnym OpenShift i OKD w tych samych wersjach będą ze sobą w większości kwestii niemal identyczne, to już na starcie możemy zauważyć różnicę na przykład w postaci CoreOS-u. Dla OKD jest on zbudowany na bazie otwartoźródłowej i supportowanej niemal głównie przez społeczność Fedory, podczas gdy w OpenShifcie rdzeń stanowi komercyjny Red Hat Enterprise.
Ostateczna decyzja
Jak napisałem wcześniej – odpowiedź na pytanie, który system wybrać, jest trudna. Powinniśmy podejść do tematu od strony posiadanych i wykorzystywanych zasobów sprzętowych oraz software’u, jaki wykorzystujemy lub wykorzystywać będziemy. Jeżeli większość lub przynajmniej duża część posiadanego oprogramowania brandowana jest marką Red Hat, posiadamy licencje i wsparcie tejże firmy w wielu obszarach, wówczas śmiało możemy iść w rozwiązanie OpenShift.
Jeżeli natomiast ważna jest dla nas pewna otwartość i podejście open source, a przy tym posiadamy klastry Kubernetes, którymi chcemy zarządzać w jednej, scentralizowanej konsoli lub planujemy takie klastry dodawać w przyszłości, wówczas Rancher może stać się rozwiązaniem skrojonym dla nas na miarę.
Jedno jest pewne: zarówno Rancher, jak i OpenShift, przenoszą Kubernetesa na znacznie wyższy poziom, oferując środowiska praktycznie kompletne, bez konieczności mozolnej pracy polegającej na wyszukiwaniu i konsolidacji narzędzi, w które klasyczny Kubernetes, w swojej podstawowej formie nie jest wyposażony. Porównywanie platform oferujących podobne funkcjonalności, ale bądź co bądź zupełnie różnych, rzadko kiedy ma sens. Dodatkowo dużą rolę odgrywają tutaj nasze preferencje czy budżet, a także ogólna znajomość tematu i produktów danej firmy.
