Podczas tworzenia klastra Kubernetes pojawia się wiele pytań: jak wiele węzłów roboczych skonfigurować i jakiego typu? Co lepiej dla klastra on-premise: zakupić kilka wydajnych serwerów czy wykorzystać dziesięć starych maszyn w swoim centrum danych? A w chmurze lepiej wziąć osiem jednordzeniowych instancji czy dwie czterordzeniowe?
Odpowiedzi na te pytania znajdują się w artykule w tłumaczeniu zespołu .
Pojemność klastra
Ogólnie rzecz biorąc, klaster Kubernetes można uznać za duży „superwęzeł”. Jego całkowita moc obliczeniowa to suma mocy wszystkich węzłów składowych.
Istnieje kilka sposobów, aby osiągnąć pożądaną docelową pojemność klastra. Na przykład potrzebujemy klastra z całkowitą pojemnością 8 rdzeni procesora i 32 GB pamięci RAM, ponieważ zestaw aplikacji wymaga takiej ilości zasobów. Wówczas można skonfigurować dwa węzły po 16 GB pamięci lub cztery węzły po 8 GB pamięci, dwa czterordzeniowe procesory lub cztery dwurdzeniowe.
Oto tylko dwa możliwe sposoby stworzenia klastra:
Obie opcje dają klaster o tej samej pojemności, ale w konfiguracji poniżej zainstalowano cztery mniejsze węzły, a w konfiguracji powyżej — dwa większe.
Która opcja jest lepsza?
Aby odpowiedzieć na to pytanie, rozważmy zalety obu opcji. Zebraliśmy je w tabeli.
Kilka dużych węzłów
Wiele małych węzłów
Łatwiejsze zarządzanie klastrem (jeśli jest on on-premise)
Płynne automatyczne skalowanie
Tańsze (jeśli on-premise)
Cena niewiele się różni (w chmurze)
Można uruchamiać zasobożerne aplikacje
Pełna replikacja
Zasoby są wykorzystywane efektywniej (mniejsze obciążenie na demony systemowe)
Wyższa odporność klastra na awarie
Zauważ, że mówimy tylko o węzłach roboczych. Wybór liczby i rozmiaru węzłów głównych to zupełnie inny temat.
Zatem omówmy szczegółowo każdy punkt z tabeli.
Pierwsza opcja: kilka dużych węzłów
Najbardziej ekstremalna opcja — jeden węzeł roboczy na całą pojemność klastra. W powyższym przykładzie byłby to jeden węzeł roboczy z 16 rdzeniami CPU i 16 GB pamięci RAM.
Zalety
Zaleta nr 1. Łatwiejsze zarządzanie
Łatwiej jest zarządzać wieloma maszynami niż całym parkiem. Szybciej wdrażać aktualizacje i poprawki, łatwiej synchronizować. Ilość awarii w liczbach bezwzględnych również jest mniejsza.
Zauważ, że wszystko, co powiedziano powyżej, odnosi się do własnego sprzętu, własnych serwerów, a nie do instancji w chmurze.
W chmurze sytuacja jest inna. Zarządzaniem zajmuje się dostawca usług chmurowych. W ten sposób zarządzanie dziesięcioma węzłami w chmurze niewiele różni się od zarządzania jednym węzłem.
Routing ruchu i rozkładanie obciążenia między podami w chmurze : przychodzący z internetu ruch jest kierowany na główny load balancer, który kieruje ruch na port jednego z węzłów (usługa NodePort udostępnia port w zakresie 30000-32767 w każdym węźle klastra). Reguły ustalone przez kube-proxy przekierowują ruch z węzła do poda. Oto jak to wygląda dla dziesięciu podów w dwóch węzłach:
Zaleta nr 2. Mniejsze koszty na węzeł
Mocna maszyna jest droższa, ale wzrost ceny nie musi być liniowy. Innymi słowy, jeden dziesięciordzeniowy serwer z 10 GB pamięci zazwyczaj kosztuje mniej niż dziesięć jedno rdzeniowych z tą samą ilością pamięci.
Ale pamiętaj, że ta zasada zwykle nie działa w chmurze. W obecnych schematach cenowych wszystkich głównych dostawców chmur ceny rosną liniowo z zwiększeniem pojemności.
W związku z tym w chmurze zazwyczaj nie da się zaoszczędzić na bardziej wydajnych serwerach.
Zaleta nr 3. Można uruchamiać zasobożerne aplikacje
Niektóre aplikacje wymagają mocnych serwerów w klastrze. Na przykład, jeśli system uczenia maszynowego wymaga 8 GB pamięci, nie będziesz mógł uruchomić go na węzłach po 1 GB, a jedynie przy obecności co najmniej jednego dużego węzła roboczego.
Minusy
Wada nr 1. Wiele podów na węzeł
Jeśli to samo zadanie jest realizowane na mniejszej liczbie węzłów, to na każdym z nich będzie oczywiście więcej podów.
Może to stać się problemem.
Powodem jest to, że każdy moduł wprowadza pewne narzuty na środowisko uruchomieniowe kontenera (na przykład Docker), a także kubelet i cAdvisor.
Na przykład kubelet regularnie sondował wszystkie kontenery na węźle pod kątem żywotności - im więcej kontenerów, tym więcej pracy dla kubelet.
CAdvisor zbiera statystyki wykorzystania zasobów wszystkich kontenerów na węźle, a kubelet regularnie żąda tych informacji i udostępnia je przez API. Znowu, im więcej kontenerów, tym więcej pracy zarówno dla cAdvisor, jak i kubelet.
Jeśli liczba modułów wzrośnie, może to spowolnić system, a nawet podważyć jego niezawodność.
W repozytorium Kubernetes niektórzy , że węzły skaczą między statusami Ready/NotReady, ponieważ regularne kontrole kubelet wszystkich kontenerów na węźle zajmują zbyt dużo czasu.
Z tego powodu Kubernetes . W zależności od wydajności węzła możesz uruchomić więcej podów na węzeł, ale trudno przewidzieć, czy pojawią się problemy, czy wszystko będzie działać dobrze. Warto przetestować działanie z wyprzedzeniem.
Minus № 2. Ograniczenie na replikację
Zbyt mała liczba węzłów ogranicza efektywny stopień replikacji aplikacji. Na przykład, jeśli masz aplikację o wysokiej dostępności z pięcioma replikami, ale tylko dwa węzły, to efektywny stopień replikacji aplikacji zmniejsza się do dwóch.
Pięć replik można rozłożyć tylko na dwa węzły, a jeśli jeden z nich przestaje działać, natychmiast wyłącza kilka replik.
Jeśli masz pięć węzłów lub więcej, każda replika będzie działać na osobnym węźle, a awaria jednego węzła usunie maksymalnie jedną replikę.
W ten sposób wymagania dotyczące wysokiej dostępności mogą wymagać posiadania określonej minimalnej liczby węzłów w klastrze.
Minus № 3. Gorsze konsekwencje awarii
Przy małej liczbie węzłów każda awaria niesie poważniejsze konsekwencje. Na przykład, jeśli masz tylko dwa węzły, a jeden z nich przestaje działać, natychmiast znika połowa twoich modułów.
Oczywiście Kubernetes przeniesie obciążenie z uszkodzonego węzła na inne. Ale jeśli ich jest mało, to może zabraknąć wolnej pojemności. W rezultacie część twoich aplikacji stanie się niedostępna, dopóki nie uruchomisz uszkodzonego węzła.
W ten sposób im więcej węzłów — tym mniejsze skutki awarii sprzętowych.
Minus № 4. Większe kroki automatycznego skalowania
W Kubernetes działa system automatycznego skalowania klastra dla infrastruktury chmurowej, co pozwala na automatyczne dodawanie lub usuwanie węzłów w zależności od bieżących potrzeb. W przypadku dużych węzłów automatyczne skalowanie staje się bardziej gwałtowne i nieporęczne. Na przykład, w przypadku dwóch węzłów, dodanie dodatkowego węzła zwiększy pojemność klastra o 50%. I będziesz musiał zapłacić za te zasoby, nawet jeśli nie są Ci potrzebne.
Dlatego jeśli planujesz korzystać z automatycznego skalowania klastra, to im mniejsze węzły — tym bardziej elastyczne i oszczędne skalowanie uzyskasz.
Teraz przyjrzyjmy się zaletom i wadom dużej liczby małych węzłów.
Druga opcja: wiele małych węzłów
Zalety tego podejścia zasadniczo wynikają z wad przeciwnego wariantu z kilkoma dużymi węzłami.
Zalety
Zaleta nr 1. Mniejsze skutki awarii
Im więcej węzłów, tym mniej pod’ów na każdym węźle. Na przykład, jeśli masz sto modułów na dziesięciu węzłach, to na każdym węźle będzie średnio po dziesięć modułów.
W związku z tym, jeśli jeden z węzłów ulegnie awarii, tracisz tylko 10% obciążenia roboczego. Istnieje prawdopodobieństwo, że dotknięte zostaną tylko nieliczne replikaty, a aplikacje w ogóle pozostaną w działaniu.
Ponadto, na pozostałych węzłach prawdopodobnie wystarczy wolnych zasobów dla obciążenia roboczego uszkodzonego węzła, więc Kubernetes może swobodnie zaplanować na nowo pod’y, a Twoje aplikacje stosunkowo szybko powrócą do działania.
Zaleta nr 2. Dobra replikacja
Jeśli węzłów jest wystarczająco dużo, to scheduler Kubernetes może przydzielić wszystkim replikom różne węzły. W ten sposób, w przypadku awarii węzła, dotknięta zostanie tylko jedna replikacja, a aplikacja pozostanie dostępna.
Minusy
Wada nr 1. Trudniejsze zarządzanie
Zarządzanie dużą liczbą węzłów jest trudniejsze. Na przykład każdy węzeł Kubernetes musi komunikować się ze wszystkimi innymi, to znaczy liczba połączeń rośnie kwadratowo, i wszystkie te połączenia trzeba śledzić.
Kontroler węzłów w menedżerze kontrolerów Kubernetes regularnie przeszukuje wszystkie węzły w klastrze w celu sprawdzenia ich stanu — im więcej węzłów, tym większe obciążenie dla kontrolera.
Obciążenie wzrasta również na bazie danych etcd — każdy kubelet i kube-proxy wywołują dla etcd (przez API), któremu etcd ma transmitować aktualizacje obiektu.
Ogólnie każdy węzeł roboczy nakłada dodatkowe obciążenie na komponenty systemowe głównych węzłów.
Oficjalnie Kubernetes wspiera klastry z . Jednak w praktyce już 500 węzłów .
Aby zarządzać dużą liczbą węzłów roboczych, należy wybierać bardziej wydajne główne węzły. Na przykład kube-up odpowiedni rozmiar VM dla głównego węzła w zależności od liczby węzłów roboczych. To znaczy, im więcej węzłów roboczych, tym wydajniejsze powinny być główne węzły.
W celu rozwiązania tych specyficznych problemów istnieją specjalne rozwiązania, takie jak . Ten system pozwala obejść ograniczenia i budować klastry z ogromną liczbą węzłów roboczych.
Minus nr 2. Większe koszty ogólne
Na każdym węźle roboczym Kubernetes uruchamia zestaw demonów systemowych — należą do nich środowisko uruchomieniowe kontenerów (np. Docker), kube-proxy i kubelet, w tym cAdvisor. W sumie zużywają określoną, stałą ilość zasobów.
Jeśli masz wiele małych węzłów, udział tych kosztów ogólnych na każdym węźle jest większy. Na przykład wyobraź sobie, że wszystkie demony systemowe jednego węzła razem zużywają 0,1 rdzenia CPU i 0,1 GB pamięci. Jeśli masz jeden dziesięcio-rdzeniowy węzeł z 10 GB pamięci, demony zużywają 1% pojemności klastra. Z drugiej strony, na dziesięciu jedno-rdzeniowych węzłach po 1 GB pamięci demony zabierają 10% pojemności klastra.
Tak więc, im mniej węzłów, tym efektywniej wykorzystywana jest infrastruktura.
Minus nr 3. Nieefektywne wykorzystanie zasobów
Na małych węzłach może powstać sytuacja, w której pozostałe fragmenty zasobów są zbyt małe, aby przydzielić im jakiekolwiek obciążenie robocze, dlatego pozostają nieużywane.
Na przykład każdy pod wymaga 0,75 GB pamięci. Jeśli masz dziesięć węzłów, a na każdym 1 GB pamięci, można uruchomić dziesięć pod’ów — w końcu na każdym węźle pozostanie 0,25 GB niewykorzystanej pamięci.
To oznacza, że 25% pamięci całego klastra jest marnowane.
Na dużym węźle z 10 GB pamięci możesz uruchomić 13 takich modułów — i pozostanie tylko jeden niewykorzystany fragment 0,25 GB.
W takim przypadku marnuje się tylko 2,5% pamięci.
W ten sposób zasoby są efektywniej wykorzystywane na dużych węzłach.
Kilka dużych węzłów czy wiele małych?
Co więc jest lepsze: kilka dużych węzłów w klastrze czy wiele małych? Jak zawsze, nie ma jednoznacznej odpowiedzi. Wiele zależy od rodzaju aplikacji.
Na przykład, jeśli aplikacja wymaga 10 GB pamięci, wybór dużych węzłów jest oczywisty. Jeśli jednak aplikacja wymaga dziesięciokrotnej replikacji dla wysokiej dostępności, nie warto ryzykować, umieszczając repliki na tylko dwóch węzłach — w klastrze powinno być co najmniej dziesięć węzłów.
W sytuacjach pośrednich podejmij decyzję na podstawie zalet i wad każdego rozwiązania. Być może niektóre argumenty są bardziej aktualne w twojej sytuacji niż inne.
Nie ma również konieczności, aby wszystkie węzły miały ten sam rozmiar. Nic nie stoi na przeszkodzie, aby eksperymentować najpierw z węzłami o tym samym rozmiarze, a potem dodać do nich węzły o innym rozmiarze, łącząc je w klastrze. Węzły robocze klastra Kubernetes mogą być całkowicie heterogeniczne. Można więc spróbować połączyć zalety obu podejść.
Nie ma jednego uniwersalnego przepisu, każda sytuacja ma swoje niuanse, a tylko produkcja pokaże prawdę.
Tłumaczenie przygotowane przez zespół platformy chmurowej .
Jeszcze o Kubernetes: .
Źródło: habr.com
