Witam, nazywam się Dmitry Krasnov. Od ponad pięciu lat administruję klastrami Kubernetes i buduję złożone architektury mikroserwisowe. Na początku tego roku uruchomiliśmy usługę zarządzania klastrami Kubernetes w oparciu o Containerum. Korzystając z okazji, opowiem Ci, czym jest Kubernetes i czym różni się integracja z dostawcą od open source.
Na początek, co to jest? . Jest to system do zarządzania kontenerami na dużej liczbie hostów. Nawiasem mówiąc, z języka greckiego tłumaczy się to jako „pilot” lub „sternik”. Pierwotnie opracowany przez Google, a następnie przekazany jako wkład technologiczny na rzecz Cloud Native Computing Foundation, międzynarodowej organizacji non-profit zrzeszającej wiodących na świecie programistów, użytkowników końcowych i dostawców technologii kontenerowych.
Zarządzaj dużą liczbą kontenerów
Teraz zastanówmy się, jakie to są pojemniki. Jest to aplikacja wraz z całym jej środowiskiem - głównie bibliotekami, od których zależy działanie programu. Wszystko to jest spakowane w archiwach i przedstawione w formie obrazu, który można uruchomić niezależnie od systemu operacyjnego, przetestować i nie tylko. Ale jest problem - zarządzanie kontenerami na dużej liczbie hostów jest bardzo trudne. Dlatego powstał Kubernetes.
Obraz kontenera reprezentuje aplikację wraz z jej zależnościami. Aplikacja, jej zależności oraz obraz systemu plików systemu operacyjnego znajdują się w różnych częściach obrazu, tzw. warstwach. Warstwy można ponownie wykorzystać w różnych pojemnikach. Na przykład wszystkie aplikacje w firmie mogą korzystać z warstwy podstawowej Ubuntu. Podczas uruchamiania kontenerów nie ma potrzeby przechowywania wielu kopii pojedynczej warstwy bazowej na hoście. Pozwala to zoptymalizować przechowywanie i dostarczanie obrazów.
Kiedy chcemy uruchomić aplikację z kontenera, niezbędne warstwy nakładają się na siebie i powstaje system plików nakładek. Na wierzchu umieszczona jest warstwa rejestrująca, która jest usuwana po zatrzymaniu się pojemnika. Dzięki temu po uruchomieniu kontenera aplikacja będzie zawsze mieć to samo środowisko, którego nie można zmienić. Gwarantuje to odtwarzalność środowiska w różnych systemach operacyjnych hosta. Niezależnie od tego, czy jest to Ubuntu, czy CentOS, środowisko zawsze będzie takie samo. Dodatkowo kontener jest izolowany od hosta za pomocą mechanizmów wbudowanych w jądro Linuksa. Aplikacje w kontenerze nie widzą plików, procesów hosta i kontenerów sąsiednich. Ta izolacja aplikacji od systemu operacyjnego hosta zapewnia dodatkową warstwę bezpieczeństwa.
Dostępnych jest wiele narzędzi do zarządzania kontenerami na hoście. Najpopularniejszym z nich jest Docker. Pozwala zapewnić pełny cykl życia kontenerów. Działa to jednak tylko na jednym hoście. Jeśli musisz zarządzać kontenerami na wielu hostach, Docker może zmienić życie inżynierów w piekło. Dlatego powstał Kubernetes.
Zapotrzebowanie na Kubernetes wynika właśnie z możliwości zarządzania grupami kontenerów na wielu hostach jako pewnego rodzaju pojedynczą jednostką. Popularność systemu daje możliwość budowania DevOps czy Development Operations, w których Kubernetes służy do obsługi procesów tego właśnie DevOps.
Rysunek 1. Schematyczne przedstawienie działania Kubernetesa
Pełna automatyzacja
DevOps to w zasadzie automatyzacja procesu rozwoju. Z grubsza rzecz biorąc, programiści piszą kod, który jest przesyłany do repozytorium. Następnie kod ten można automatycznie zebrać od razu do kontenera ze wszystkimi bibliotekami, przetestować i „wdrożyć” do kolejnego etapu – Stagingu, a potem od razu do Produkcji.
Razem z Kubernetesem DevOps pozwala zautomatyzować ten proces tak, aby odbywał się on praktycznie bez udziału samych programistów. Dzięki temu kompilacja jest znacznie szybsza, ponieważ programista nie musi tego robić na swoim komputerze - po prostu pisze fragment kodu, wypycha kod do repozytorium, po czym uruchamiany jest potok, który może obejmować proces budowania, testowania i wdrażania. Dzieje się tak przy każdym zatwierdzeniu, więc testowanie odbywa się w sposób ciągły.
Jednocześnie zastosowanie kontenera pozwala mieć pewność, że całe środowisko tego programu zostanie wypuszczone do produkcji dokładnie w takiej formie, w jakiej zostało przetestowane. Oznacza to, że nie będzie problemów typu „niektóre wersje były w teście, inne w produkcji, ale kiedy je zainstalowaliśmy, wszystko upadło”. A skoro dzisiaj mamy trend w kierunku architektury mikroserwisowej, gdzie zamiast jednej ogromnej aplikacji są setki małych, do ręcznego administrowania nimi potrzebna będzie ogromna kadra pracowników. Dlatego używamy Kubernetesa.
Plusy, plusy, plusy
Jeśli mówimy o zaletach Kubernetesa jako platformy, to ma ona istotne zalety z punktu widzenia zarządzania architekturą mikroserwisową.
- Zarządzanie wieloma replikami. Najważniejszą rzeczą jest zarządzanie kontenerami na wielu hostach. Co ważniejsze, zarządzaj wieloma replikami aplikacji w kontenerach jako pojedynczą jednostką. Dzięki temu inżynierowie nie muszą martwić się o każdy kontener z osobna. Jeśli jeden z kontenerów ulegnie awarii, Kubernetes to zobaczy i zrestartuje go ponownie.
- Sieć klastrowa. Kubernetes posiada także tzw. sieć klastrową z własną przestrzenią adresową. Dzięki temu każdy pod ma swój własny adres. Subpod rozumiany jest jako minimalna jednostka strukturalna klastra, w której bezpośrednio zwodowane są kontenery. Ponadto Kubernetes posiada funkcjonalność łączącą moduł równoważenia obciążenia i wykrywanie usług. Dzięki temu możesz pozbyć się ręcznego zarządzania adresami IP i przekazać to zadanie Kubernetesowi. Automatyczne kontrole stanu pomogą wykryć problemy i przekierować ruch do działających podów.
- Zarządzanie konfiguracją. W przypadku zarządzania dużą liczbą aplikacji zarządzanie konfiguracją aplikacji staje się trudne. W tym celu Kubernetes posiada specjalne zasoby ConfigMap. Umożliwiają centralne przechowywanie konfiguracji i udostępnianie ich zasobnikom podczas uruchamiania aplikacji. Mechanizm ten pozwala nam zagwarantować spójność konfiguracji w co najmniej dziesięciu lub stu replikach aplikacji.
- Trwałe woluminy. Kontenery są z natury niezmienne i gdy kontener zostanie zatrzymany, wszystkie dane zapisane w systemie plików zostaną zniszczone. Ale niektóre aplikacje przechowują dane bezpośrednio na dysku. Aby rozwiązać ten problem, Kubernetes posiada funkcję zarządzania pamięcią dyskową - Woluminy trwałe. Mechanizm ten wykorzystuje zewnętrzną pamięć masową danych i może przenosić trwałą pamięć, blok lub plik, do kontenerów. Rozwiązanie to umożliwia przechowywanie danych oddzielnie od pracowników, co pozwala na ich uratowanie w przypadku awarii tych samych pracowników.
- Moduł równoważenia obciążenia. Mimo że w Kubernetesie zarządzamy abstrakcyjnymi jednostkami, takimi jak Deployment, StatefulSet itp., ostatecznie kontenery działają na zwykłych maszynach wirtualnych lub serwerach sprzętowych. Nie są idealne i w każdej chwili mogą spaść. Kubernetes to zobaczy i przekieruje ruch wewnętrzny do innych replik. Ale co zrobić z ruchem przychodzącym z zewnątrz? Jeśli po prostu skierujesz ruch do jednego z procesów roboczych, w przypadku jego awarii usługa stanie się niedostępna. Aby rozwiązać ten problem, Kubernetes ma usługi takie jak Load Balancer. Mają na celu automatyczną konfigurację zewnętrznego modułu równoważącego chmurę dla wszystkich pracowników w klastrze. Ten zewnętrzny balanser kieruje ruch zewnętrzny do pracowników i sam monitoruje ich status. Jeśli jeden lub więcej pracowników stanie się niedostępnych, ruch zostanie przekierowany do innych. Pozwala to na tworzenie usług o wysokiej dostępności przy użyciu Kubernetes.
Kubernetes działa najlepiej, gdy działają architektury mikrousługowe. Można wdrożyć system w architekturze klasycznej, jednak nie ma to sensu. Jeśli aplikacja nie może działać na wielu replikach, jaka to różnica – w Kubernetesie czy nie?
Otwarte oprogramowanie Kubernetes
Kubernetes typu open source to świetna rzecz: zainstalowałem go i działa. Możesz go wdrożyć na własnych serwerach sprzętowych, na własnej infrastrukturze, zainstalować mastery i workery, na których będą działać wszystkie aplikacje. A co najważniejsze, wszystko to jest bezpłatne. Istnieją jednak niuanse.
- Pierwszym z nich jest zapotrzebowanie na wiedzę i doświadczenie administratorów i inżynierów, którzy to wszystko będą wdrażać i wspierać. Ponieważ klient otrzymuje pełną swobodę działania w klastrze, sam ponosi odpowiedzialność za funkcjonowanie klastra. A tutaj bardzo łatwo wszystko zepsuć.
- Po drugie, brak integracji. Jeśli uruchomisz Kubernetes bez popularnej platformy wirtualizacyjnej, nie uzyskasz wszystkich korzyści programu. Na przykład korzystanie z usług woluminów trwałych i równoważenia obciążenia.
Rysunek 2. Architektura k8s
Kubernetes od dostawcy
Integracja z dostawcą usług w chmurze zapewnia dwie możliwości:
- Po pierwsze, wystarczy kliknąć przycisk „Utwórz klaster”, a klaster będzie już skonfigurowany i gotowy do użycia.
- Po drugie, sprzedawca sam instaluje klaster i konfiguruje integrację z chmurą.
Jak to się tutaj dzieje. Inżynier uruchamiający klaster określa, ilu pracowników potrzebuje i z jakimi parametrami (np. 5 pracowników, każdy z 10 procesorami, 16 GB RAM i powiedzmy 100 GB dysku). Po czym uzyskuje dostęp do już utworzonego klastra. W tym przypadku pracownicy, na których uruchamiane jest obciążenie, w całości przechodzą na Klienta, natomiast cała płaszczyzna zarządzania pozostaje w gestii dostawcy (o ile usługa świadczona jest w modelu usługi zarządzanej).
Jednak ten schemat ma swoje wady. Ze względu na to, że płaszczyzna zarządzania pozostaje po stronie dostawcy, sprzedawca nie daje pełnego dostępu do klienta, a to ogranicza elastyczność pracy z Kubernetesem. Czasami zdarza się, że klient chce dodać do Kubernetesa jakąś konkretną funkcjonalność, np. uwierzytelnianie poprzez LDAP, ale konfiguracja płaszczyzny zarządzania na to nie pozwala.
Rysunek 3. Przykład klastra Kubernetes od dostawcy chmury
Co wybrać: open source czy dostawca
Czy Kubernetes jest oprogramowaniem typu open source czy specyficznym dla dostawcy? Jeśli weźmiemy Kubernetesa typu open source, to użytkownik zrobi z nim, co chce. Istnieje jednak duża szansa, że strzelisz sobie w stopę. Z dostawcą jest trudniej, bo wszystko jest przemyślane i skonfigurowane pod firmę. Największą wadą open source Kubernetes jest zapotrzebowanie na specjalistów. Dzięki opcji dostawcy firma zostaje uwolniona od tego bólu głowy, ale będzie musiała zdecydować, czy płacić swoim specjalistom, czy dostawcy.
Cóż, zalety są oczywiste, wady są również znane. Jedno jest niezmienne: Kubernetes rozwiązuje mnóstwo problemów automatyzując zarządzanie wieloma kontenerami. I który wybrać, open source czy dostawca - każdy podejmuje własną decyzję.
Artykuł przygotował Dmitry Krasnov, wiodący architekt usługi Containerum dostawcy #CloudMTS
Źródło: www.habr.com