Notatka. przeł.: ten materiał pochodzi z projektu edukacyjnego to odpowiedź na popularne pytanie przy projektowaniu infrastruktury opartej na Kubernetesie. Mamy nadzieję, że dość szczegółowe opisy zalet i wad każdej opcji pomogą Ci dokonać najlepszego wyboru dla Twojego projektu.
TL; DR: ten sam zestaw obciążeń można uruchomić w kilku dużych klastrach (każdy klaster będzie miał dużą liczbę obciążeń) lub na wielu małych (z małą liczbą obciążeń w każdym klastrze).
Poniżej znajduje się tabela oceniająca zalety i wady każdego podejścia:
Używając Kubernetesa jako platformy do uruchamiania aplikacji, często pojawia się kilka podstawowych pytań dotyczących zawiłości konfigurowania klastrów:
- Ile klastrów powinienem użyć?
- Jak duże mam je zrobić?
- Co powinien zawierać każdy klaster?
W tym artykule postaram się odpowiedzieć na wszystkie te pytania, analizując zalety i wady każdego podejścia.
Stwierdzenie pytania
Jako programista prawdopodobnie tworzysz i obsługujesz wiele aplikacji jednocześnie.
Ponadto wiele wystąpień tych aplikacji może działać w różnych środowiskach - na przykład mogą to być dev, test и szturchać.
Rezultatem jest cała matryca aplikacji i środowisk:
Aplikacje i środowiska
Powyższy przykład przedstawia 3 aplikacje i 3 środowiska, co daje w sumie 9 możliwych opcji.
Każda instancja aplikacji jest samodzielną jednostką wdrażania, z którą można pracować niezależnie od innych.
Uwaga! instancja aplikacji może składać się z wielu Składnikitakie jak frontend, backend, baza danych itp. W przypadku aplikacji mikrousługowej instancja będzie zawierać wszystkie mikrousługi.
W efekcie użytkownicy Kubernetesa mają kilka pytań:
- Czy wszystkie instancje aplikacji powinny zostać umieszczone w jednym klastrze?
- Czy warto mieć osobny klaster dla każdej instancji aplikacji?
- A może warto zastosować kombinację powyższych podejść?
Wszystkie te opcje są całkiem wykonalne, ponieważ Kubernetes jest systemem elastycznym, który nie ogranicza możliwości użytkownika.
Oto niektóre z możliwych sposobów:
- jeden duży wspólny klaster;
- wiele małych, wysoce wyspecjalizowanych klastrów;
- jeden klaster na aplikację;
- jeden klaster na środowisko.
Jak pokazano poniżej, dwa pierwsze podejścia znajdują się na przeciwległych krańcach skali opcji:
Od kilku dużych skupisk (po lewej) do wielu małych (po prawej)
Ogólnie rzecz biorąc, jeden klaster jest uważany za „większy” od drugiego, jeśli ma większą sumę węzłów i podów. Na przykład klaster z 10 węzłami i 100 zasobnikami jest większy niż klaster z 1 węzłem i 10 zasobnikami.
Cóż, zaczynajmy!
1. Jeden duży wspólny klaster
Pierwsza opcja polega na umieszczeniu wszystkich obciążeń w jednym klastrze:
Jedno wielkie skupisko
W tym podejściu klaster jest używany jako uniwersalny platforma infrastrukturalna — po prostu wdrażasz wszystko, czego potrzebujesz w istniejącym klastrze Kubernetes.
Kubernetes umożliwia logiczne oddzielenie od siebie części klastra, dzięki czemu każda instancja aplikacji może mieć własną przestrzeń nazw.
Przyjrzyjmy się zaletom i wadom tego podejścia.
+ Efektywne wykorzystanie zasobów
W przypadku pojedynczego klastra potrzebujesz tylko jednej kopii wszystkich zasobów potrzebnych do uruchomienia klastra Kubernetes i zarządzania nim.
Dotyczy to na przykład węzłów głównych. Zazwyczaj każdy klaster Kubernetes ma 3 węzły główne, więc w przypadku jednego klastra ich liczba pozostanie taka sama (dla porównania 10 klastrów będzie wymagało 30 węzłów głównych).
Powyższa subtelność dotyczy również innych usług działających w całym klastrze, takich jak moduły równoważenia obciążenia, kontrolery Ingress, systemy uwierzytelniania, logowania i monitorowania.
W jednym klastrze wszystkie te usługi można wykorzystać jednocześnie dla wszystkich obciążeń (nie ma konieczności tworzenia ich kopii, jak ma to miejsce w przypadku wielu klastrów).
+ Tani
Konsekwencją powyższego jest to, że mniejsza liczba klastrów jest zwykle tańsza, ponieważ nie ma kosztów ogólnych.
Dotyczy to zwłaszcza węzłów głównych, które mogą kosztować znaczną ilość pieniędzy niezależnie od sposobu ich hostowania (lokalnie lub w chmurze).
Niektóre zarządzane usługi Kubernetes, takie jak lub , udostępnij warstwę kontrolną za darmo. W tym przypadku kwestia kosztów jest mniej dotkliwa.
Istnieją również usługi zarządzane, które pobierają stałą opłatę za działanie każdego klastra Kubernetes (np. ).
+ Sprawna administracja
Zarządzanie jednym klastrem jest łatwiejsze niż zarządzanie kilkoma.
Administracja może obejmować następujące zadania:
- Aktualizacja wersji Kubernetes;
- utworzenie rurociągu CI/CD;
- instalacja wtyczki CNI;
- skonfigurowanie systemu uwierzytelniania użytkowników;
- instalacja kontrolera dostępu;
i wiele innych…
W przypadku jednego klastra będziesz musiał to wszystko zrobić tylko raz.
W przypadku wielu klastrów operacje będą musiały być powtarzane wiele razy, co prawdopodobnie będzie wymagało pewnej automatyzacji procesów i narzędzi, aby zapewnić spójność i spójność procesu.
A teraz kilka słów o wadach.
− Pojedynczy punkt awarii
W przypadku odmowy jedyny klaster natychmiast przestanie działać wszystko obciążenia!
Coś może pójść nie tak na wiele sposobów:
- aktualizacja Kubernetesa prowadzi do nieoczekiwanych skutków ubocznych;
- Komponent obejmujący cały klaster (na przykład wtyczka CNI) zaczyna nie działać zgodnie z oczekiwaniami;
- jeden z komponentów klastra nie jest poprawnie skonfigurowany;
- awaria podstawowej infrastruktury.
Jedno takie zdarzenie może spowodować poważne uszkodzenie wszystkich obciążeń hostowanych w udostępnionym klastrze.
− Brak sztywnej izolacji
Działanie we współdzielonym klastrze oznacza, że aplikacje współdzielą sprzęt, możliwości sieciowe i system operacyjny w węzłach klastra.
W pewnym sensie dwa kontenery z dwiema różnymi aplikacjami działającymi w tym samym węźle są jak dwa procesy działające na tej samej maszynie z tym samym jądrem systemu operacyjnego.
Kontenery Linuksa zapewniają pewną formę izolacji, ale nie jest ona tak silna, jak ta zapewniana przez, powiedzmy, maszyny wirtualne. Zasadniczo proces w kontenerze to ten sam proces działający w systemie operacyjnym hosta.
Może to stanowić kwestię bezpieczeństwa: takie rozwiązanie teoretycznie pozwala niepowiązanym aplikacjom komunikować się ze sobą (celowo lub przypadkowo).
Ponadto wszystkie obciążenia w klastrze Kubernetes korzystają z niektórych usług obejmujących cały klaster, takich jak - pozwala aplikacjom na wyszukiwanie Usług innych aplikacji w klastrze.
Wszystkie powyższe punkty mogą mieć różne znaczenie w zależności od wymagań bezpieczeństwa aplikacji.
Kubernetes zapewnia różne narzędzia zapobiegające problemom bezpieczeństwa, takim jak и . Jednak ich prawidłowe skonfigurowanie wymaga pewnego doświadczenia, ponadto nie są w stanie załatać absolutnie wszystkich luk w zabezpieczeniach.
Należy zawsze pamiętać, że Kubernetes został pierwotnie zaprojektowany dla dzielenie się, nie dla izolacja i bezpieczeństwo.
− Brak ścisłej wielodostępności
Biorąc pod uwagę obfitość współdzielonych zasobów w klastrze Kubernetes, istnieje wiele sposobów, w jakie różne aplikacje mogą sobie nawzajem pomagać.
Na przykład aplikacja może zmonopolizować współdzielony zasób (taki jak procesor lub pamięć) i odmówić dostępu do niego innym aplikacjom działającym w tym samym węźle.
Kubernetes zapewnia różne mechanizmy kontroli tego zachowania, takie jak (zobacz także artykuł „" - około. tłumacz.), и . Jednak podobnie jak w przypadku zabezpieczeń, ich konfiguracja jest dość nietrywialna i nie są w stanie zapobiec absolutnie wszystkim nieprzewidzianym skutkom ubocznym.
− Duża liczba użytkowników
W przypadku pojedynczego klastra trzeba udostępnić do niego dostęp wielu osobom. A im większa ich liczba, tym większe ryzyko, że coś „zniszczą”.
W ramach klastra możesz kontrolować, kto i co może robić (zobacz artykuł „" - około. tłumacz.). Nie przeszkodzi to jednak użytkownikom w „zepsuciu” czegoś w granicach swojego obszaru odpowiedzialności.
− Klastry nie mogą rosnąć w nieskończoność
Klaster używany do wszystkich obciążeń będzie prawdopodobnie dość duży (pod względem liczby węzłów i zasobników).
Ale tu pojawia się kolejny problem: klastry w Kubernetesie nie mogą rosnąć w nieskończoność.
Istnieje teoretyczna granica wielkości klastra. W Kubernetesie jest to około .
Jednak w prawdziwym życiu problemy mogą zacząć się znacznie wcześniej - na przykład po prostu .
Faktem jest, że duże klastry powodują duże obciążenie warstwy kontrolnej Kubernetes. Innymi słowy, utrzymanie sprawności klastra i jego wydajne działanie wymaga starannego dostrojenia.
Kwestię tę omówiono w powiązanym artykule na oryginalnym blogu zatytułowanym „".
Rozważmy jednak podejście odwrotne: wiele małych klastrów.
2. Wiele małych, wyspecjalizowanych klastrów
Dzięki takiemu podejściu używasz osobnego klastra dla każdego wdrażanego elementu:
Wiele małych skupisk
Na potrzeby tego artykułu, pod element rozkładany odnosi się do instancji aplikacji - na przykład wersji deweloperskiej osobnej aplikacji.
Ta strategia wykorzystuje Kubernetes jako specjalizację czas wykonania dla poszczególnych instancji aplikacji.
Przyjrzyjmy się zaletom i wadom tego podejścia.
+ Ograniczony „promień wybuchu”
W przypadku awarii klastra negatywne konsekwencje ograniczają się tylko do obciążeń, które zostały wdrożone w tym klastrze. Wszystkie inne obciążenia pozostają niezmienione.
+ Izolacja
Obciążenia hostowane w poszczególnych klastrach nie współdzielą zasobów, takich jak procesor, pamięć, system operacyjny, sieć ani inne usługi.
Rezultatem jest ścisła izolacja pomiędzy niepowiązanymi aplikacjami, co może być korzystne dla ich bezpieczeństwa.
+ Mała liczba użytkowników
Biorąc pod uwagę, że każdy klaster zawiera tylko ograniczony zestaw obciążeń, 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”.
Spójrzmy na wady.
− Nieefektywne wykorzystanie zasobów
Jak wspomniano wcześniej, każdy klaster Kubernetes wymaga określonego zestawu zasobów zarządczych: węzłów głównych, komponentów warstwy kontrolnej, rozwiązań do monitorowania i logowania.
W przypadku dużej liczby małych klastrów należy przeznaczyć na zarządzanie większą część zasobów.
− Drogie
Nieefektywne wykorzystanie zasobów automatycznie wiąże się z wysokimi kosztami.
Na przykład utrzymanie 30 węzłów głównych zamiast trzech o tej samej mocy obliczeniowej z pewnością wpłynie na koszty.
− Trudności w administracji
Zarządzanie wieloma klastrami Kubernetes jest znacznie trudniejsze niż zarządzanie tylko jednym.
Na przykład będziesz musiał skonfigurować uwierzytelnianie i autoryzację dla każdego klastra. Wersja Kubernetes również będzie wymagała kilkukrotnej aktualizacji.
Prawdopodobnie będziesz musiał zastosować automatyzację, aby wszystkie te zadania były bardziej wydajne.
Przyjrzyjmy się teraz mniej ekstremalnym scenariuszom.
3. Jeden klaster na aplikację
W tym podejściu tworzysz oddzielny klaster dla wszystkich instancji określonej aplikacji:
Klaster na aplikację
Ścieżkę tę można uznać za uogólnienie zasady „oddzielny klaster dla każdego zespołu”, ponieważ zwykle zespół inżynierów opracowuje jedną lub więcej aplikacji.
Przyjrzyjmy się zaletom i wadom tego podejścia.
+ Klaster można dostosować do aplikacji
Jeśli aplikacja ma specjalne potrzeby, można je wdrożyć w klastrze bez wpływu na inne klastry.
Takie potrzeby mogą obejmować pracowników GPU, niektóre wtyczki CNI, siatkę usług lub inną usługę.
Każdy klaster można dostosować do działającej w nim aplikacji tak, aby zawierał tylko to, co jest potrzebne.
− Różne środowiska w jednym klastrze
Wadą tego podejścia jest to, że instancje aplikacji z różnych środowisk współistnieją w tym samym klastrze.
Na przykład wersja prod aplikacji działa w tym samym klastrze, co wersja dev. Oznacza to również, że programiści działają w tym samym klastrze, w którym działa produkcyjna wersja aplikacji.
Jeśli w wyniku działań programistów lub błędów w wersji deweloperskiej nastąpi awaria w klastrze, wówczas wersja prod może potencjalnie ucierpieć – jest to ogromna wada tego podejścia.
I wreszcie ostatni scenariusz na naszej liście.
4. Jeden klaster na środowisko
Ten scenariusz zakłada przydzielenie oddzielnego klastra dla każdego środowiska:
Jeden klaster na środowisko
Możesz na przykład mieć klastry dev, test и szturchać, w którym uruchomisz wszystkie instancje aplikacji dedykowane dla konkretnego środowiska.
Oto zalety i wady tego podejścia.
+ Izolacja środowiska produkcyjnego
W ramach tego podejścia wszystkie środowiska są od siebie izolowane. Jednak w praktyce jest to szczególnie ważne w środowisku prod.
Wersje produkcyjne aplikacji są teraz niezależne od tego, co dzieje się w innych klastrach i środowiskach.
W ten sposób, jeśli nagle pojawi się problem w klastrze deweloperskim, wersje prod aplikacji będą nadal działać tak, jakby nic się nie stało.
+ Klaster można dostosować do otoczenia
Każdy klaster można dostosować do swojego otoczenia. Możesz na przykład:
- zainstaluj narzędzia do programowania i debugowania w klastrze deweloperskim;
- zainstaluj frameworki i narzędzia testowe w klastrze test;
- korzystać z wydajniejszych kanałów sprzętowych i sieciowych w klastrze szturchać.
Pozwala to na zwiększenie efektywności zarówno tworzenia aplikacji, jak i jej działania.
+ Ograniczenie dostępu do klastra produkcyjnego
Rzadko kiedy pojawia się konieczność bezpośredniej współpracy z klastrem prod, dlatego można znacząco ograniczyć krąg osób mających do niego dostęp.
Możesz pójść jeszcze dalej i całkowicie odmówić ludziom dostępu do tego klastra, a wszystkie wdrożenia wykonywać przy użyciu zautomatyzowanego narzędzia CI/CD. Takie podejście zminimalizuje ryzyko błędów ludzkich dokładnie tam, gdzie jest to najbardziej istotne.
A teraz kilka słów o wadach.
− Brak izolacji pomiędzy aplikacjami
Główną wadą tego podejścia jest brak izolacji sprzętu i zasobów pomiędzy aplikacjami.
Niepowiązane aplikacje współdzielą zasoby klastra: rdzeń systemu, procesor, pamięć i niektóre inne usługi.
Jak wspomniano, może to być potencjalnie niebezpieczne.
− Brak możliwości zlokalizowania zależności aplikacji
Jeśli aplikacja ma specjalne wymagania, muszą one być spełnione we wszystkich klastrach.
Na przykład, jeśli aplikacja wymaga procesora graficznego, każdy klaster musi zawierać co najmniej jednego pracownika z procesorem graficznym (nawet jeśli jest używany tylko przez tę aplikację).
W rezultacie ryzykujemy wyższe koszty i nieefektywne wykorzystanie zasobów.
wniosek
Jeśli masz określony zestaw aplikacji, można je umieścić w kilku dużych klastrach lub wielu małych.
W artykule omówiono zalety i wady różnych podejść, począwszy od jednego globalnego klastra po kilka małych i wysoce wyspecjalizowanych:
- jedno duże skupisko ogólne;
- wiele małych, wysoce wyspecjalizowanych klastrów;
- jeden klaster na aplikację;
- jeden klaster na środowisko.
Jakie podejście zatem wybrać?
Jak zawsze odpowiedź zależy od przypadku użycia: należy rozważyć zalety i wady różnych podejść i wybrać najbardziej optymalną opcję.
Jednak wybór nie ogranicza się do powyższych przykładów – możesz zastosować dowolną ich kombinację!
Na przykład możesz zorganizować kilka klastrów dla każdego zespołu: klaster deweloperski (w którym będą znajdować się środowiska dev и test) i klaster dla produkcja (gdzie będzie zlokalizowane środowisko produkcyjne).
Na podstawie informacji zawartych w tym artykule możesz odpowiednio zoptymalizować zalety i wady dla konkretnego scenariusza. Powodzenia!
PS
Przeczytaj także na naszym blogu:
- «";
- «";
- «";
- «".
Źródło: www.habr.com