Przyp. tłum.: ten materiał z projektu edukacyjnego — odpowiedź na popularne pytanie podczas projektowania infrastruktury opartej na Kubernetesie. Mamy nadzieję, że wystarczająco szczegółowe opisy zalet i wad każdej z opcji pomogą w podjęciu optymalnej decyzji także w Twoim projekcie.
TL;DR: ten sam zestaw obciążeń roboczych można uruchomić na kilku dużych klastrach (na każdy klaster przypada dużo obciążeń) lub na wielu małych (z niewielką liczbą obciążeń w każdym klastrze).
Poniżej znajduje się tabela oceniająca zalety i wady każdego podejścia:
Podczas wykorzystania KuberneTESa jako platformy do uruchamiania aplikacji często pojawia się kilka podstawowych pytań dotyczących szczegółów konfiguracji klastrów:
- Ile klastrów użyć?
- Jak duże mają być?
- Co powinien zawierać każdy klaster?
W tym artykule postaram się odpowiedzieć na te pytania, analizując zalety i wady każdego podejścia.
Formułowanie pytania
Jako twórca oprogramowania prawdopodobnie równolegle rozwijasz i uruchamiasz wiele aplikacji.
Ponadto wiele egzemplarzy tych aplikacji na pewno działa w różnych środowiskach — na przykład mogą to być dev, test i prod.
W rezultacie otrzymujemy całą matrycę aplikacji i środowisk:
Aplikacje i środowiska
W powyższym przykładzie przedstawiono 3 aplikacje i 3 środowiska, co daje łącznie 9 możliwych wariantów.
Każdy egzemplarz aplikacji stanowi samodzielną jednostkę wdrożeniową, z którą można pracować niezależnie od innych.
Zauważ, że egzemplarz aplikacji może składać się z wielu elementów, takich jak frontend, backend, baza danych itp. W przypadku aplikacji mikroserwisowej egzemplarz będzie obejmował wszystkie mikroserwisy.
W rezultacie użytkownicy Kubernetesa mają kilka pytań:
- Czy warto umieszczać wszystkie egzemplarze aplikacji w jednym klastrze?
- Czy warto zakładać osobny klaster dla każdego egzemplarza aplikacji?
- A może lepiej skorzystać z kombinacji powyższych podejść?
Wszystkie te opcje są jak najbardziej wykonalne, ponieważ Kubernetes to elastyczny system, który nie ogranicza użytkowników w możliwościach.
Oto kilka możliwych dróg:
- jeden duży wspólny klaster;
- wiele małych, wyspecjalizowanych klastrów;
- jeden klaster dla każdej aplikacji;
- jeden klaster dla każdego środowiska.
Jak pokazano poniżej, pierwsze dwa podejścia znajdują się na przeciwległych końcach skali opcji:
Od kilku dużych klastrów (po lewej) do wielu małych (po prawej)
Ogólnie przyjmuje się, że jeden klaster jest "większy" od drugiego, jeśli ma więcej węzłów i podów. Na przykład klaster z 10 węzłami i 100 podami jest większy od klastra z 1 węzłem i 10 podami.
Cóż, zacznijmy!
1. Jeden duży wspólny klaster
Pierwsza opcja — umieścić wszystkie obciążenia robocze w jednym klastrze:
Jeden duży klaster
W ramach tego podejścia klaster wykorzystywany jest jako uniwersalna platforma infrastrukturalna — wszystko, co potrzebne, po prostu wdrażasz w istniejącym klastrze Kubernetes.
Kubernetes pozwala logicznie oddzielić części klastra od siebie, dzięki czemu dla każdego egzemplarza aplikacji można używać własnej przestrzeni nazw.
Przyjrzyjmy się zaletom i wadom tego podejścia.
+ Efektywne wykorzystanie zasobów
W przypadku jednego klastra wymagana jest tylko jedna kopia wszystkich zasobów potrzebnych do uruchomienia klastra Kubernetes i zarządzania nim.
Na przykład dotyczy to węzłów głównych. Zazwyczaj na każdy klaster Kubernetes przypada 3 węzły główne, więc dla jednego jedynego klastra ich liczba pozostanie taka sama (dla porównania, 10 klastrów będzie potrzebować 30 węzłów głównych).
Powyższa subtelność odnosi się również do innych usług działających w skali całego klastra, takich jak load balancery, kontrolery Ingress, systemy autoryzacji, logowania i monitorowania.
W jednym klastrze wszystkie te usługi można wykorzystać od razu dla wszystkich obciążeń roboczych (nie trzeba tworzyć ich kopii, jak w przypadku wielu klastrów).
+ Taniej
W związku z powyższym, mniejsza liczba klastrów zwykle kosztuje mniej, ponieważ nie ma wydatków na nadmiarowe zasoby.
Dotyczy to szczególnie węzłów głównych, które mogą kosztować znaczną sumę bez względu na sposób lokalizacji (na miejscu lub w chmurze).
Niektóre zarządzane usługi Kubernetes, takie jak lub , zapewniają warstwę zarządzającą za darmo. W tym przypadku kwestie kosztowe są mniej palące.
Istnieją również usługi zarządzane, pobierające stałą opłatę za działanie każdego klastra Kubernetes (na przykład, ).
+ Efektywne zarządzanie
Zarządzanie jednym klastrem jest prostsze niż wieloma.
Zarządzanie może obejmować następujące zadania:
- aktualizacja wersji Kubernetes;
- konfiguracja potoku CI/CD;
- instalacja wtyczki CNI;
- konfiguracja systemu uwierzytelniania użytkowników;
- instalacja kontrolera dostępu;
i wiele innych…
W przypadku jednego klastra wszystkie te czynności trzeba wykonać tylko raz.
W przypadku wielu klastrów operacje te będą musiały być powtarzane wielokrotnie, co prawdopodobnie wymaga jakiejś automatyzacji procesów i narzędzi, aby zapewnić systematyczność i jednolitość procesu.
A teraz kilka słów o wadach.
− Pojedynczy punkt awarii
W przypadku awarii jednego klastra natychmiast przestaną działać wszystkie wszystkie obciążenia robocze!
Istnieje wiele scenariuszy, kiedy coś może pójść nie tak:
- aktualizacja Kubernetes powoduje nieoczekiwane efekty uboczne;
- komponent klastra (na przykład, wtyczka CNI) zaczyna działać inaczej niż oczekiwano;
- jeden z komponentów klastra jest źle skonfigurowany;
- usterka w infrastrukturze bazowej.
Taki incydent może wyrządzić poważne szkody wszystkim obciążeniom roboczym umieszczonym w wspólnym klastrze.
− Brak silnej izolacji
Praca w wspólnym klastrze oznacza, że aplikacje współdzielą zasoby sprzętowe, możliwości sieciowe i system operacyjny na węzłach klastra.
W pewnym sensie dwa kontenery z dwoma różnymi aplikacjami działającymi na tym samym węźle są podobne do dwóch procesów działających na tej samej maszynie pod kontrolą tego samego jądra OS.
Kontenery Linux zapewniają pewną formę izolacji, ale nie jest ona tak silna, jak ta, którą zapewniają na przykład maszyny wirtualne. W istocie proces w kontenerze to ten sam proces uruchomiony w systemie operacyjnym hosta.
Może to stanowić problem z punktu widzenia bezpieczeństwa: taka organizacja teoretycznie pozwala niepowiązanym aplikacjom wchodzić ze sobą w interakcje (umyślnie lub przypadkowo).
Ponadto wszystkie obciążenia robocze w klastrze Kubernetes współdzielą niektóre wspólne usługi klastra, takie jak — pozwala to aplikacjom znajdować usługi innych aplikacji w klastrze.
Wszystkie powyższe punkty mogą mieć różne znaczenie w zależności od wymagań dotyczących bezpieczeństwa aplikacji.
Kubernetes dostarcza różne narzędzia do zapobiegania problemom w systemie bezpieczeństwa, takie jak i . Jednak ich poprawna konfiguracja wymaga pewnego doświadczenia, ponadto nie są w stanie zamknąć absolutnie wszystkich luk w bezpieczeństwie.
Ważne jest, aby zawsze pamiętać, że Kubernetes został pierwotnie zaprojektowany do współdzielenia, a nie do izolacji i bezpieczeństwa.
− Brak surowej multi-tenancy
Biorąc pod uwagę liczne wspólne zasoby w klastrze Kubernetes, istnieje wiele sposobów, w jakie różne aplikacje mogą "deptać sobie po piętach".
Na przykład aplikacja może zmonopolizować jakiś wspólny zasób (tak jak procesor czy pamięć) i pozbawić inne aplikacje działające na tym samym węźle dostępu do niego.
Kubernetes zapewnia różne mechanizmy kontrolowania takiego zachowania, takie jak (zob. także artykuł „” — przyp. tłum.), i . Jednak, podobnie jak w przypadku bezpieczeństwa, ich konfiguracja jest dość skomplikowana i nie mogą one zapobiec absolutnie wszystkim nieprzewidzianym skutkom ubocznym.
− Duża liczba użytkowników
W przypadku pojedynczego klastra konieczne jest udostępnienie go wielu osobom. Im więcej osób, tym większe ryzyko, że coś "zepsują".
W obrębie klastra można kontrolować, kto i co może robić za pomocą (zob. artykuł „” — przyp. tłum.). Choć nie przeszkodzi to użytkownikom w "zepsuciu" czegoś w ramach swojej odpowiedzialności.
− Klastry nie mogą rosnąć w nieskończoność
Klaster, który jest używany do wszystkich obciążeń roboczych, prawdopodobnie będzie dość duży (pod względem liczby węzłów i podów).
Jednak pojawia się inny problem: klastry w Kubernetes nie mogą rosnąć w nieskończoność.
Istnieje teoretyczny limit rozmiaru klastra. W Kubernetes wynosi on około .
Jednak w rzeczywistości problemy mogą rozpocząć się znacznie wcześniej — na przykład już przy .
Chodzi o to, że duże klastry wywierają wysokie obciążenie na warstwę zarządzającą Kubernetes. Innymi słowy, aby utrzymać klaster w dobrym stanie i efektywnie wykorzystywać zasoby, konieczna jest staranna konfiguracja.
Problem ten jest omawiany w odpowiednim artykule na oryginalnym blogu zatytułowanym „».
Ale przyjrzyjmy się przeciwstawnemu podejściu: wiele małych klastrów.
2. Wiele małych, wyspecjalizowanych klastrów
W tym podejściu używasz oddzielnego klastra dla każdego wdrażanego elementu:
Wiele małych klastrów
Dla celów tego artykułu przez wdrażany element rozumie się instancję aplikacji — na przykład wersję dev oddzielnej aplikacji.
W tej strategii Kubernetes jest używany jako wyspecjalizowane środowisko wykonawcze dla pojedynczych instancji aplikacji.
Przyjrzyjmy się zaletom i wadom tego podejścia.
+ Ograniczony „promień eksplozji”
Przy „uszkodzeniu” klastra negatywne konsekwencje ograniczają się jedynie do tych obciążeń roboczych, które zostały wdrożone w tym klastrze. Wszystkie inne obciążenia pozostają nietknięte.
+ Izolacja
Obciążenia robocze ulokowane w indywidualnych klastrach nie mają wspólnych zasobów, takich jak procesor, pamięć, system operacyjny, sieć czy inne usługi.
W rezultacie uzyskujemy silną izolację między niezwiązanymi aplikacjami, co może pozytywnie wpływać na ich bezpieczeństwo.
+ Niewielka liczba użytkowników
Biorąc pod uwagę, że w każdym klastrze znajduje się jedynie ograniczony zestaw obciążeń roboczych, liczba użytkowników mających do niego dostęp jest zmniejszona.
Im mniej osób ma dostęp do klastra, tym mniejsze ryzyko, że coś się „zepsuje”.
Przyjrzyjmy się wadom.
− Nieefektywne wykorzystanie zasobów
Jak wspomniano wcześniej, każdy klaster Kubernetes wymaga określonej ilości zasobów zarządzających: węzłów master, komponentów warstwy kontrolnej, rozwiązań do monitorowania i rejestrowania.
W przypadku dużej liczby małych klastrów konieczne jest przeznaczenie większej części zasobów na zarządzanie.
− Wysokie koszty
Nieefektywne wykorzystanie zasobów automatycznie prowadzi do wysokich wydatków.
Na przykład, posiadanie 30 węzłów zamiast trzech przy tej samej mocy obliczeniowej na pewno wpłynie na koszty.
− Trudności w administracji
Administracja wieloma klastrami Kubernetes jest znacznie bardziej skomplikowana niż praca z jednym.
Na przykład, konieczne będzie skonfigurowanie uwierzytelniania i autoryzacji dla każdego klastra. Aktualizacja wersji Kubernetes również będzie musiała być przeprowadzana wielokrotnie.
Prawdopodobnie będziesz musiał zastosować automatyzację, aby zwiększyć efektywność tych wszystkich zadań.
Teraz przyjrzyjmy się mniej ekstremalnym scenariuszom.
3. Jeden klaster na każdą aplikację
W ramach tego podejścia tworzysz oddzielny klaster dla wszystkich instancji konkretnej aplikacji:
Klaster na aplikację
Taki kierunek można traktować jako uogólnienie zasady „oddzielny klaster na zespół”, ponieważ zazwyczaj zespół inżynierów zajmuje się rozwojem jednej lub kilku aplikacji.
Przyjrzyjmy się zaletom i wadom tego podejścia.
+ Klaster można dostosować do aplikacji
Jeśli aplikacja ma szczególne potrzeby, można je zrealizować w klastrze, nie wpływając na inne klastry.
Takie potrzeby mogą obejmować workerów z GPU, określone wtyczki CNI, service mesh lub inną usługę.
Każdy klaster można dostosować do aplikacji, która w nim działa, aby zawierał tylko to, co jest niezbędne.
− Różne środowiska w jednym klastrze
Wadą tego podejścia jest to, że instancje aplikacji z różnych środowisk współistnieją w jednym klastrze.
Na przykład, wersja prod aplikacji działa w tym samym klastrze, co wersja dev. Oznacza to również, że deweloperzy prowadzą swoją działalność w tym samym klastrze, w którym funkcjonuje wersja produkcyjna aplikacji.
Jeśli w wyniku działań deweloperów lub błędów wersji dev w klastrze wystąpi awaria, istnieje potencjalne ryzyko, że również wersja prod zostanie dotknięta — ogromna wada tego podejścia.
No i w końcu, ostatni scenariusz na naszej liście.
4. Jeden klaster na każde środowisko
Ten scenariusz przewiduje przydzielenie oddzielnego klastra na każde środowisko:
Jeden klaster na środowisko
Na przykład, możesz mieć klastry dev, test i prod, w których uruchomisz wszystkie instancje aplikacji przeznaczone dla konkretnego środowiska.
Oto zalety i wady tego podejścia.
+ Izolacja środowiska prod
W ramach tego podejścia wszystkie środowiska są od siebie izolowane. Jednak w praktyce jest to szczególnie ważne dla środowiska produkcyjnego.
Produkcje aplikacji nie są teraz zależne od tego, co dzieje się w innych klastrach i środowiskach.
W ten sposób, jeśli w klastrze deweloperskim nagle pojawi się problem, wersje produkcyjne aplikacji będą nadal działać, jakby nic się nie wydarzyło.
+ Klaster można dostosować do środowiska
Każdy klaster można dostosować do jego środowiska. Na przykład można:
- zainstalować w klastrze deweloperskim narzędzia do programowania i debugowania;
- zainstalować frameworki testowe i narzędzia w klastrze test;
- użytkować mocniejsze sprzęty i kanały sieciowe w klastrze prod.
Pozwala to zwiększyć efektywność zarówno podczas rozwoju, jak i eksploatacji aplikacji.
+ Ograniczenie dostępu do klastra produkcyjnego
Potrzeba pracy z klastrem produkcyjnym bezpośrednio pojawia się rzadko, więc można znacznie ograniczyć krąg osób, które mają do niego dostęp.
Można pójść nawet dalej i całkowicie pozbawić ludzi dostępu do tego klastra, a wszystkie wdrożenia realizować za pomocą zautomatyzowanego narzędzia CI/CD. Takie podejście znacznie ograniczy ryzyko błędów ludzkich właśnie tam, gdzie jest to najbardziej aktualne.
A teraz kilka słów o wadach.
− Brak izolacji między aplikacjami
Główną wadą tego podejścia jest brak izolacji sprzętowej i zasobowej między aplikacjami.
Niezwiązane aplikacje wspólnie korzystają z zasobów klastra: systemowego jądra, procesora, pamięci i innych usług.
Jak już wspomniano, może to być potencjalnie niebezpieczne.
− Niemożność lokalizacji zależności aplikacji
Jeśli aplikacja ma szczególne wymagania, muszą one być spełnione we wszystkich klastrach.
Na przykład, jeśli aplikacja wymaga GPU, to każdy klaster musi mieć przynajmniej jednego workera z GPU (nawet jeśli jest on używany tylko przez tę aplikację).
W rezultacie ryzykujemy wyższe koszty i nieefektywne wykorzystanie zasobów.
Podsumowanie
Przy posiadaniu określonego zestawu aplikacji można je umieścić w kilku dużych klastrach lub w wielu małych.
W artykule omówiono zalety i wady różnych podejść, począwszy od jednego globalnego klastra, aż po kilka małych i wyspecjalizowanych:
- jeden dużych wspólny klaster;
- wiele małych, wyspecjalizowanych klastrów;
- jeden klaster dla każdej aplikacji;
- jeden klaster dla każdego środowiska.
Jakie podejście wybrać?
Jak zwykle, odpowiedź zależy od scenariusza użycia: należy rozważyć zalety i wady różnych podejść i wybrać najbardziej optymalne rozwiązanie.
Jednak wybór nie ogranicza się do powyższych przykładów — można wykorzystać dowolne ich kombinacje!
Na przykład, można zorganizować po dwa klastry dla każdego zespołu: klaster do rozwoju (w którym będą środowiska dev i test) i klaster do production (gdzie znajduje się środowisko produkcyjne).
Opierając się na informacjach z tego artykułu, będziesz mógł odpowiednio zoptymalizować zalety i wady pod konkretny scenariusz. Powodzenia!
P.S.
Przeczytaj także na naszym blogu:
- «»;
- «»;
- «»;
- «».
Źródło: habr.com
