🥇Kubernetes: open source kontra wersja od dostawcy

Cześć, nazywam się Dmitrij Krasnow. Od ponad pięciu lat zajmuję się administracją klastrów Kubernetes oraz budową złożonych architektur mikroserwisów. Na początku tego roku uruchomiliśmy usługę zarządzania klastrami Kubernetes opartą na Containerum. Korzystając z okazji, opowiem, czym właściwie jest ten Kubernetes i czym różni się integracja z dostawcą od open source.

Na początek, co to jest Kubernetes. To system do zarządzania kontenerami na dużej liczbie hostów. Z greckiego zresztą tłumaczy się jako „pilot” lub „sternik”. Został pierwotnie opracowany przez Google, a następnie przekazany do Cloud Native Computing Foundation, międzynarodowej organizacji non-profit, która łączy czołowych światowych deweloperów, użytkowników końcowych oraz dostawców technologii kontenerowych.

Zarządzać dużą liczbą kontenerów

Teraz zobaczmy, co to właściwie są te kontenery. To aplikacja wraz z całym jej środowiskiem – głównie bibliotekami, od których zależy działanie programu. Wszystko to jest spakowane w archiwa i przedstawione w postaci obrazu, który można uruchamiać niezależnie od systemu operacyjnego, testować i nie tylko. Ale jest problem — zarządzanie kontenerami na dużej liczbie hostów jest bardzo trudne. Dlatego stworzono Kubernetes.

Obraz kontenera to aplikacja plus jej zależności. Aplikacja, jej zależności oraz obraz systemu plików OS znajdują się w różnych częściach obrazu, tak zwanych warstwach. Warstwy mogą być ponownie używane dla różnych kontenerów. Na przykład, dla wszystkich aplikacji w firmie może być używana podstawowa warstwa Ubuntu. Przy uruchamianiu kontenerów nie ma potrzeby przechowywania na hoście wielu kopii tej samej podstawowej warstwy. To pozwala zoptymalizować przechowywanie i dostarczanie obrazów.

Kiedy chcemy uruchomić aplikację z kontenera, potrzebne warstwy nakładają się na siebie, tworząc nakładkowy system plików. Na górze nakładana jest warstwa do zapisu, która przy zatrzymaniu kontenera jest usuwana. Gwarantuje to, że przy uruchomieniu kontenera aplikacja zawsze będzie miała to samo środowisko, które nie może być zmienione. To zapewnia reprodukowalność środowiska na różnych systemach operacyjnych hosta. Niezależnie od tego, czy to Ubuntu, czy CentOS, — środowisko zawsze będzie takie samo. Ponadto kontener jest izolowany od hosta za pomocą wbudowanych w jądro Linux mechanizmów. Aplikacje w kontenerze nie widzą plików ani procesów hosta i sąsiednich kontenerów. Tego rodzaju izolacja aplikacji od systemu operacyjnego hosta zapewnia dodatkową warstwę bezpieczeństwa.

Na hoście istnieje wiele narzędzi do zarządzania kontenerami. Najpopularniejszym z nich jest Docker. Umożliwia on zapewnienie pełnego cyklu życia kontenerów. Jednak działa tylko na jednym hoście. W przypadku konieczności zarządzania kontenerami na wielu hostach, Docker może zmienić życie inżynierów w piekło. Dlatego powstał Kubernetes.

Zapotrzebowanie na Kubernetes wynika z możliwości zarządzania grupami kontenerów na wielu hostach jako pewnymi jednolitymi bytami. Popularność systemu zapewnia możliwość budowy DevOps lub Development Operations, w których Kubernetes używany jest do uruchamiania procesów tegoż DevOps.

Rysunek 1. Schematyczne przedstawienie zasady działania Kubernetes

Pełna automatyzacja

DevOps w zasadzie reprezentuje automatyzację procesu rozwoju. Mówiąc prosto, programiści piszą kod, który jest przesyłany do repozytorium. Następnie ten kod może być automatycznie kompilowany od razu w kontenerze z wszystkimi bibliotekami, testowany i "wdrażany" na kolejnym etapie – Staging, a następnie od razu na Production.

Wraz z Kubernetes, DevOps umożliwia automatyzację tego procesu, dzięki czemu przebiega on praktycznie bez udziału samych programistów. Dzięki temu znacznie przyspiesza się budowa, ponieważ programista nie musi zajmować się tym na swoim komputerze — po prostu pisze fragment kodu, wrzuca kod do repozytorium, po czym uruchamia się pipeline, który może obejmować proces budowy, testowania, wdrażania. Tak dzieje się z każdym commitem, dlatego testowanie przebiega nieprzerwanie.

Użycie kontenera zapewnia, że całe środowisko tej aplikacji wejdzie do produkcji dokładnie w takiej formie, w jakiej zostało przetestowane. To znaczy, że nie pojawią się problemy w stylu "na teście były inne wersje, w produkcji – inne, a po wdrożeniu – wszystko padło". A ponieważ dzisiaj mamy trend na architekturę mikroserwisową, przy której zamiast jednej ogromnej aplikacji mamy setki małych, do wykonywania ich administracji ręcznie potrzebny będzie ogromny zespół pracowników. Dlatego właśnie korzystamy z Kubernetes.

Zalety, zalety, zalety

Jeśli mówimy o zaletach Kubernetes jako platformy, ma on znaczące plusy z perspektywy zarządzania architekturą mikroserwisową.

Zarządzanie wieloma replikami. Najważniejsze — to zarządzanie kontenerami na wielu hostach. I co istotniejsze — zarządzanie wieloma replikami aplikacji w kontenerach jako jedną całością. Dzięki temu inżynierowie nie muszą martwić się o każdy pojedynczy kontener. Jeśli jeden z kontenerów upadnie, Kubernetes to zauważy i ponownie go uruchomi.
Sieć klastra. Kubernetes posiada również tak zwaną sieć klastra z własną przestrzenią adresową. Dzięki temu każdy pod ma swój adres. Pod to najmniejsza jednostka strukturalna klastra, w której bezpośrednio uruchamiane są kontenery. Poza tym, Kubernetes dysponuje funkcjonalnością, która łączy w sobie balansowanie obciążenia i Odkrywanie Usług. To pozwala uniknąć ręcznego zarządzania adresami IP i powierza to zadanie Kubernetes. Automatyczne health checki pomogą wykrywać problemy i przekierować ruch na działające pody.
Zarządzanie konfiguracjami. Zarządzanie konfiguracją aplikacji staje się trudne, gdy mamy do czynienia z dużą liczbą aplikacji. W Kubernetes istnieją specjalne zasoby ConfigMap, które pozwalają na centralne przechowywanie konfiguracji i wstawianie ich do podów przy uruchamianiu aplikacji. Taki mechanizm zapewnia spójność konfiguracji zarówno w dziesięciu, jak i w setkach replik aplikacji.
Objętości trwałe. Kontenery są z natury niemutowalne, a po zatrzymaniu kontenera wszystkie dane zapisane w systemie plików zostaną utracone. Jednak niektóre aplikacje przechowują dane bezpośrednio na dysku. Aby rozwiązać ten problem, Kubernetes wprowadza funkcję zarządzania przechowywaniem danych — Objętości trwałe. Mechanizm ten wykorzystuje zewnętrzne przechowywanie danych, umożliwia przekazywanie trwałego magazynu, blokowego lub plikowego do kontenerów. Takie rozwiązanie pozwala na przechowywanie danych oddzielnie od węzłów roboczych, co chroni je w przypadku awarii tych węzłów.
Load Balancer. Chociaż w Kubernetes zarządzamy abstrakcyjnymi encjami, takimi jak Deployment, StatefulSet itp., ostatecznie kontenery uruchamiają się na zwykłych maszynach wirtualnych lub fizycznych serwerach. Nie są one idealne i mogą zawieść w każdej chwili. Kubernetes to zauważy i przekieruje wewnętrzny ruch do innych replik. Ale co z ruchem, który przychodzi z zewnątrz? Jeśli po prostu skierujemy ruch na jeden z węzłów roboczych, co się stanie, jeśli on zawiedzie? Usługa stanie się niedostępna. Aby rozwiązać ten problem, Kubernetes ma usługi typu Load Balancer. Są one zaprojektowane do automatycznego konfigurowania zewnętrznego balansu obciążenia dla wszystkich węzłów roboczych w klastrze. Ten zewnętrzny balancer kieruje ruch zewnętrzny do węzłów roboczych i sam monitoruje ich status. Jeśli jeden lub więcej węzłów roboczych stanie się niedostępnych, ruch jest przekierowywany do innych. Umożliwia to tworzenie usług o wysokiej dostępności przy użyciu Kubernetes.

Kubernetes najlepiej sprawdza się w uruchamianiu architektur mikroserwisowych. Wprowadzanie systemu w klasyczną architekturę jest możliwe, ale bez sensu. Jeśli aplikacja nie może działać w kilku replikach, to jaka jest różnica – w Kubernetes czy nie?

Open source Kubernetes

Open source Kubernetes – to świetna rzecz: instalujesz i działa. Można go uruchomić na własnych serwerach, na swojej infrastrukturze, postawić mastera i workerów, na których będą uruchamiane wszystkie aplikacje. A co najważniejsze – wszystko to jest darmowe. Jednak są pewne niuanse.

Pierwszy – wymagania dotyczące wiedzy i doświadczenia administratorów oraz inżynierów, którzy będą to wszystko wdrażać i utrzymywać. Ponieważ klient otrzymuje pełną swobodę działania w klastrze, ponosi odpowiedzialność za jego działanie. A zepsuć to jest bardzo prosto.
Drugi – brak integracji. Jeśli uruchamiasz Kubernetes, nie mając jakiejś popularnej platformy wirtualizacji, nie uzyskasz wszystkich korzyści tego programu. Takich jak wykorzystanie Persistent Volumes i usług Load balancer.

Rysunek 2. Architektura k8s

Kubernetes od dostawcy

Integracja z dostawcą chmurowym daje dwie możliwości:

Po pierwsze, użytkownik może po prostu kliknąć przycisk „utwórz klaster” i otrzymać już skonfigurowany i gotowy do pracy klaster.
Po drugie, dostawca sam instaluje klaster i konfiguruje integrację z chmurą.

Jak to wygląda u nas. Inżynier, który uruchamia klaster, wskazuje, ile potrzebuje workerów i z jakimi parametrami (na przykład 5 workerów, każdy z 10 CPU, 16 GB RAM i powiedzmy 100 GB dysku). Następnie uzyskuje dostęp do już utworzonego klastra. Przy tym, workery, na których uruchamiana jest obciążenie, całkowicie przechodzą na własność klienta, jednak cały management plane pozostaje w gestii dostawcy (w przypadku, gdy usługa jest świadczona w modelu managed service).

Jednak taki schemat ma swoje wady. Z tego powodu, że management plane pozostaje u dostawcy, ten nie daje pełnego dostępu klientowi, co obniża elastyczność pracy z Kubernetes. Czasami klient chce dołączyć do Kubernetes jakąś specyficzną funkcjonalność, na przykład autoryzację przez LDAP, jednak konfiguracja management plane tego nie umożliwia.

Rysunek 3. Przykład klastra Kubernetes od dostawcy chmurowego

Co wybrać: open source czy dostawcę

A zatem, open source Kubernetes czy wersja od dostawcy? W przypadku open source Kubernetes użytkownik może robić, co chce. Jednak istnieje duże ryzyko, że sam sobie zaszkodzi. Z wersją od dostawcy jest to trudniejsze, ponieważ wszystko jest dokładnie przemyślane i skonfigurowane przez firmę. Największą wadą open source Kubernetes jest zapotrzebowanie na specjalistów. W przypadku wersji od dostawcy firma nie musi się tym przejmować, ale będzie musiała zdecydować: płacić swoim specjalistom czy dostawcy.

Cóż, zalety są oczywiste, wady również są znane. Jedno pozostaje niezmienne: Kubernetes rozwiązuje wiele problemów, automatyzując zarządzanie wieloma kontenerami. A którą wersję wybrać, open source czy dostawcy, każdy decyduje sam.