Konteneryzacja IT dla laika: Kubernetes, Rancher i nie tylko, czyli jak wykonać skok

Większość organizacji zaakceptowała platformy wirtualizacyjne jako podstawę dla swoich usług IT. Oznacza to, że coraz rzadziej widzimy fizyczne serwery (bare-metal), których zasoby nie są poddawane wirtualizacji. Jednakże, rozwój usług chmurowych oraz rosnące użycie kontenerów i mikroserwisów w ostatnim dziesięcioleciu spowodowały silna presję na rozwój środowisk kontenerowych.

Autorami tekstu są Jarosław Biniek i Ziemowit Buczyński z SUSE Polska 

Konteneryzacja vs wirtualizacja

Przy wielu zaletach wirtualizacji, ma ona też swoje wady i ograniczenia. Poniższy diagram pokazuje podstawową różnicę w obu podejściach:

Łatwo dostrzec, że aplikacje (mikroserwisy) uruchamiane w kontenerach nie są obciążone każdorazowym uruchomieniem systemu operacyjnego, a co za tym idzie mogą być uruchamiane w przeciągu kilku sekund lub nawet ułamków sekund. W porównaniu do typowego czasu uruchomienia wirtualnej maszyny mierzonego w minutach daje to zupełnie nowe możliwości (np. skalowanie ad hoc, czy migracja na żądanie).

Jednakże, konteneryzacja wymaga również odpowiedniego przygotowania środowiska pod kątem zarządzania. Tu z pomocą przychodzi Kubernetes.

Docker, Kubernetes, Rancher…

O ile w obszarze  konteneryzacji standardem de facto jest Docker, o tyle w obszarze zarządzania kontenerami dominuje Kubernetes. Około 80% organizacji używających kontenerów deklaruje użycie Kubernetesa do zarządzania. Jednakże nawet Kubernetes ma swoje ograniczenia i skupia się na zarządzaniu poszczególnymi klastrami. Dla organizacji, które potrzebują więcej niż jednego klastra kontenerowego został stworzony Rancher.

Kiedy możemy potrzebować Ranchera? Naturalnym miejscem wykorzystania Ranchera jest organizacja posiadająca rozbudowane środowisko kontenerowe, gdzie duży wysiłek administracyjny jest wkładany w utrzymanie spójności wykorzystywanych klastrów kontenerowych. Mniej oczywiste wydaje się skorzystanie z Ranchera w organizacjach o dużo mniejszych potrzebach w zakresie konteneryzacji, ale warto rozważyć scenariusz, gdzie w chmurze tworzymy alternatywę dla klastra uruchomionego we własnym centrum przetwarzania.

Powody wdrożenia takiego scenariusza mogą być rozmaite:

• optymalizacja kosztów poprzez migrację do chmury,
• stworzenie łatwego w skalowaniu, zapasowego centrum przetwarzania danych (fizycznego lub w chmurze),
• separacja pomiędzy usługami publicznymi i wewnętrznymi przy zachowaniu centralnego zarządzania.

We wszystkich powyższych przypadkach Rancher może ułatwić zarówno samo wdrożenie, jak i późniejsze zarządzanie.

Powyższy diagram pokazuje zależności pomiędzy poszczególnymi komponentami kontenerowego krajobrazu.

Jakie kroki trzeba wykonać?

Bardzo często słyszy się o „wysokim progu wejścia” do konteneryzacji. Nowa wiedza, inna filozofia, odmienne słownictwo, zupełnie nowe narzędzia… To tylko niektóre z wyzwań przed jakimi stoi organizacja przymierzająca się do wdrożenia usług opartych na mikroserwisach. Aby ułatwić to przejście prezentujemy poniżej kilka kroków, które należy wykonać.

Platforma sprzętowa

Na początku trzeba zadać sobie pytanie, czy chcemy

• skorzystać z szerokiej oferty usług chmurowych,
• utrzymywać własną infrastrukturę sieciową,
• czy wreszcie postawić na model hybrydowy.

W pierwszym przypadku odpada nam problem inwestycji sprzętowych, a większość dostawców usług w chmurze oferuje również gotową infrastrukturę kontenerową. W przypadku drugim i trzecim musimy zakupić odpowiedni sprzęt. Dokładne wyliczenie potrzeb sprzętowych wymaga analizy konkretnych przypadków, ale minimalny zestaw produkcyjny obejmujący jeden klaster Kubernetesa powinien zawierać przynajmniej dwa węzły zarządzające i dwa węzły robocze. W przypadku wirtualizacji powinny być one rozrzucone na co najmniej dwa fizyczne serwery. Należy pamiętać, że oparcie usług na dwóch węzłach roboczych powoduje duże komplikacje wydajnościowe w przypadku awarii jednego z węzłów.

Wirtualizacja (opcjonalna)

Wszystkie rodzaje węzłów (robocze, zarządzające i Ranchera) można  instalować zarówno na maszynach fizycznych, jak i wirtualnych. Oba warianty są wspierane przez środowiska kontenerowe, ale patrząc na rysunek z poprzedniej strony należy pamiętać o dodatkowym narzucie na obsługę dwóch systemów operacyjnych „w drodze” od aplikacji do sprzętu. O ile w zastosowaniach produkcyjnych, o wysokich wymaganiach wydajnościowych, stosuje się przede wszystkim serwery fizyczne, to w środowisku deweloperskim lub akceptacyjnym zastosowanie serwerów wirtualnych jest jak najbardziej uzasadnione. Decyzja o wyborze konkretnego wirtualizatora powinna być podjęta po sprawdzeniu wsparcia oferowanego przez dostawcę  systemu operacyjnego.

Platforma kontenerowa

Jak zostało napisane na wstępie, istnieje szeroka gama platform kontenerowych i warto poświęcić chwilę na analizę potrzeb, aby zaoszczędzić sobie wysiłku związanego z ręcznym konfigurowaniem usług, które mogą być zautomatyzowane. W chwili pisania tego dokumentu certyfikowanych było 67 dystrybucji i 48 platform hostingowych Kubernetesa. Pełna lista certyfikowanych platform kontenerowych znajduje się na stronie CNCF (https://www.cncf.io/certification/software-conformance/).

Rancher – instalator, który „robi różnicę”

Jeśli planujemy posiadanie więcej niż jednego klastra Kubernetesa (bez względu na dystrybucję) to warto rozważyć wybór Ranchera, który znakomicie upraszcza instalację i późniejsze zarządzenie klastrami Kubernetesa.

Do instalacji nowych klastrów jest wykorzystywana certyfikowana dystrybucja RKE (Rancher Kubernetes Engine), ale Rancher potrafi zarządzać również dowolną istniejącą instalacją certyfikowanego Kubernetesa. Ilustracja obok pokazuje to na przykładzie klastrów RKE i EKS.

Na zakończenie podajemy w tabeli informacje używanej tutaj terminologii. Zainteresowanych rozwiązaniami Ranchera zapraszamy do kontaktu z SUSE w Polsce, tel. 225375020, e-mail: infolinia@suse.com.