Podczas tworzenia klastra Kubernetes mogą pojawić się pytania: ile węzłów roboczych skonfigurować i jakiego typu? Co jest lepsze dla klastra lokalnego: kupić kilka wydajnych serwerów czy wykorzystać kilkanaście starych maszyn w swoim centrum danych? Czy lepiej wziąć w chmurze osiem instancji jednordzeniowych czy dwie czterordzeniowe?
Odpowiedzi na te pytania znajdują się w artykule. w tłumaczeniu polecenia .
Pojemność klastra
Ogólnie klaster Kubernetes można traktować jako duży „superwęzeł”. Jego całkowita moc obliczeniowa jest sumą mocy wszystkich jego węzłów składowych.
Istnieje kilka sposobów osiągnięcia pożądanej docelowej pojemności klastra. Na przykład potrzebujemy klastra o łącznej pojemności 8 rdzeni procesorów i 32 GB RAM-u, ponieważ zestaw aplikacji wymaga tak wielu zasobów. Można wtedy zainstalować dwa węzły z 16 GB pamięci lub cztery węzły z 8 GB pamięci, dwa procesory czterordzeniowe lub cztery dwurdzeniowe.
Oto tylko dwa możliwe sposoby utworzenia klastra:
Obie opcje tworzą klaster o tej samej pojemności, ale dolna konfiguracja ma cztery mniejsze węzły, a górna konfiguracja ma dwa większe węzły.
Która opcja jest lepsza?
Aby odpowiedzieć na to pytanie, przyjrzyjmy się zaletom obu opcji. Zestawiliśmy je w tabeli.
Kilka dużych węzłów
Wiele małych węzłów
Łatwiejsze zarządzanie klastrem (jeśli jest on lokalny)
Płynne automatyczne skalowanie
Taniej (jeśli lokalnie)
Cena jest trochę inna (w chmurze)
Może uruchamiać aplikacje wymagające dużej ilości zasobów
Pełna replikacja
Zasoby są wykorzystywane wydajniej (mniejsze obciążenie demonów systemowych
Wyższa tolerancja na błędy klastra
Należy pamiętać, że mówimy tylko o węzłach roboczych. Wybór liczby i wielkości głównych węzłów to zupełnie inny temat.
Omówmy więc każdy punkt z tabeli bardziej szczegółowo.
Pierwsza opcja: kilka dużych węzłów
Najbardziej ekstremalną opcją jest jeden węzeł roboczy na całą pojemność klastra. W powyższym przykładzie byłby to pojedynczy węzeł roboczy z 16 rdzeniami procesora i 16 GB pamięci RAM.
Plusy
Plus nr 1. Łatwiejsze zarządzanie
Łatwiej zarządzać kilkoma maszynami niż całą flotą. Szybsze jest wdrażanie aktualizacji i poprawek oraz łatwiejsza synchronizacja. Mniejsza jest także liczba awarii w liczbach bezwzględnych.
Należy pamiętać, że wszystkie powyższe dotyczą sprzętu, serwerów, a nie instancji w chmurze.
Inaczej jest w chmurze. Tam zarządzaniem zajmuje się dostawca usług chmurowych. Zatem zarządzanie dziesięcioma węzłami w chmurze niewiele różni się od zarządzania jednym węzłem.
Routing ruchu i dystrybucja obciążenia pomiędzy podami w chmurze : ruch przychodzący z Internetu kierowany jest do głównego modułu równoważenia obciążenia, który przekazuje ruch na port jednego z węzłów (usługa NodePort ustawia port w zakresie 30000-32767 w każdym węźle klastra). Reguły ustawione 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: Mniejszy koszt na węzeł
Mocny samochód jest droższy, ale wzrost ceny nie musi być liniowy. Innymi słowy, jeden dziesięciordzeniowy serwer z 10 GB pamięci jest zwykle tańszy niż dziesięć jednordzeniowych serwerów z taką samą ilością pamięci.
Należy jednak pamiętać, że ta zasada zwykle nie działa w usługach w chmurze. W obecnych systemach cenowych wszystkich głównych dostawców usług w chmurze ceny rosną liniowo wraz ze wzrostem wydajności.
Dlatego w chmurze zwykle nie można oszczędzać na mocniejszych serwerach.
Zaleta nr 3: Możesz uruchamiać aplikacje wymagające dużych zasobów
Niektóre aplikacje wymagają wydajnych serwerów w klastrze. Na przykład, jeśli system uczenia maszynowego wymaga 8 GB pamięci, nie będzie można go uruchomić na węzłach 1 GB, ale tylko z co najmniej jednym dużym węzłem roboczym.
Wady
Wada nr 1. Wiele podów na węzeł
Jeśli to samo zadanie zostanie wykonane na mniejszej liczbie węzłów, to każdy z nich będzie naturalnie miał więcej podów.
To może być problem.
Powodem jest to, że każdy moduł wprowadza pewne obciążenie do środowiska wykonawczego kontenera (np. Docker), a także kubelet i cAdvisor.
Na przykład kubelet regularnie sprawdza wszystkie kontenery w węźle pod kątem przetrwania — im więcej kontenerów, tym więcej pracy musi wykonać kubelet.
CADvisor zbiera statystyki wykorzystania zasobów dla wszystkich kontenerów w węźle, a kubelet regularnie odpytuje te informacje i udostępnia je za pośrednictwem interfejsu API. Ponownie, więcej kontenerów oznacza więcej pracy zarówno dla cAdvisora, jak i kubeleta.
Zwiększenie liczby modułów może spowolnić system, a nawet obniżyć jego niezawodność.
W repozytorium Kubernetes niektóre że węzły przeskakują między stanami Gotowy/NieGotowy, ponieważ regularne sprawdzanie kubelet wszystkich kontenerów w węźle trwa zbyt długo.
Z tego powodu Kubernetes . W zależności od wydajności węzła można uruchomić więcej podów na węzeł, ale trudno przewidzieć, czy wystąpią problemy i czy wszystko będzie działać poprawnie. Warto wcześniej przetestować działanie.
Wada nr 2. Ograniczenie replikacji
Zbyt mała liczba węzłów ogranicza efektywny zakres replikacji aplikacji. Na przykład, jeśli masz aplikację o wysokiej dostępności z pięcioma replikami, ale tylko dwoma węzłami, efektywny stopień replikacji aplikacji zmniejsza się do dwóch.
Pięć replik można rozmieścić tylko w dwóch węzłach, a jeśli jeden z nich ulegnie awarii, wiele replik zostanie usuniętych jednocześnie.
Jeśli masz co najmniej pięć węzłów, każda replika będzie działać w oddzielnym węźle, a awaria jednego węzła spowoduje usunięcie co najwyżej jednej repliki.
Dlatego wymagania dotyczące wysokiej dostępności mogą wymagać określonej minimalnej liczby węzłów w klastrze.
Wada nr 3. Gorsze konsekwencje niepowodzenia
Przy małej liczbie węzłów każda awaria ma poważniejsze konsekwencje. Na przykład, jeśli masz tylko dwa węzły i jeden z nich ulegnie awarii, połowa modułów natychmiast zniknie.
Oczywiście Kubernetes przeprowadzi migrację obciążenia z uszkodzonego węzła do innych. Ale jeśli jest ich niewiele, może nie być wystarczającej ilości wolnego miejsca. W rezultacie niektóre aplikacje będą niedostępne, dopóki nie przywołasz uszkodzonego węzła.
Zatem im więcej węzłów, tym mniejszy wpływ awarii sprzętu.
Wada nr 4: Więcej kroków automatycznego skalowania
Kubernetes posiada system automatycznego skalowania klastrów dla infrastruktury chmurowej, który pozwala na automatyczne dodawanie lub usuwanie węzłów w zależności od bieżących potrzeb. W przypadku większych 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 natychmiast zwiększy pojemność klastra o 50%. Będziesz musiał zapłacić za te zasoby, nawet jeśli ich nie potrzebujesz.
Zatem, jeśli planujesz używać automatycznego skalowania klastrów, im mniejsze węzły, tym bardziej elastyczne i ekonomiczne skalowanie uzyskasz.
Przyjrzyjmy się teraz 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 odwrotnej opcji z kilkoma dużymi węzłami.
Plusy
Zaleta nr 1: Mniejszy wpływ awarii
Im więcej węzłów, tym mniej podów w każdym węźle. Na przykład, jeśli masz sto modułów na dziesięć węzłów, wówczas każdy węzeł będzie miał średnio dziesięć modułów.
W ten sposób, jeśli jeden z węzłów ulegnie awarii, stracisz tylko 10% obciążenia. Istnieje prawdopodobieństwo, że problem dotyczy tylko niewielkiej liczby replik i cała aplikacja będzie nadal działać.
Ponadto pozostałe węzły prawdopodobnie będą miały wystarczającą ilość wolnych zasobów, aby obsłużyć obciążenie uszkodzonego węzła, dzięki czemu Kubernetes będzie mógł swobodnie zmieniać harmonogram podów, a Twoje aplikacje stosunkowo szybko powrócą do stanu funkcjonalnego.
Zaleta nr 2: Dobra replikacja
Jeśli jest wystarczająca liczba węzłów, harmonogram Kubernetes może przypisać różne węzły do wszystkich replik. W ten sposób, jeśli węzeł ulegnie awarii, będzie to miało wpływ tylko na jedną replikę, a aplikacja pozostanie dostępna.
Wady
Wada nr 1. Trudny do kontrolowania
Zarządzanie dużą liczbą węzłów jest trudniejsze. Przykładowo każdy węzeł Kubernetesa musi komunikować się ze wszystkimi pozostałymi, czyli liczba połączeń rośnie kwadratowo i wszystkie te połączenia trzeba śledzić.
Kontroler węzła w Kubernetes Controller Manager regularnie przegląda wszystkie węzły w klastrze, aby sprawdzić ich stan — im więcej węzłów, tym większe obciążenie kontrolera.
Rośnie także obciążenie bazy danych etcd - każde wywołanie kubelet i kube-proxy for etcd (poprzez API), do którego etcd powinien rozgłaszać aktualizacje obiektów.
Ogólnie rzecz biorąc, każdy węzeł roboczy nakłada dodatkowe obciążenie na komponenty systemu węzłów głównych.
Kubernetes oficjalnie obsługuje klastry za pomocą . Jednak w praktyce jest już 500 węzłów .
Aby zarządzać dużą liczbą węzłów roboczych, należy wybrać mocniejsze węzły główne. Na przykład kube-up prawidłowy rozmiar maszyny wirtualnej dla węzła głównego w zależności od liczby węzłów roboczych. Oznacza to, że im więcej węzłów roboczych, tym bardziej produktywne powinny być węzły główne.
Aby rozwiązać te specyficzne problemy, istnieją specjalne rozwiązania, takie jak . System ten pozwala ominąć ograniczenia i budować klastry z ogromną liczbą węzłów roboczych.
Wada nr 2: Wyższe koszty ogólne.
Na każdym węźle roboczym Kubernetes uruchamia zestaw demonów systemowych - obejmują one środowisko wykonawcze kontenerów (takie jak Docker), kube-proxy i kubelet, w tym cAdvisor. Razem zużywają określoną ilość zasobów.
Jeśli masz wiele małych węzłów, udział tego narzutu w każdym węźle jest większy. Załóżmy na przykład, że wszystkie demony systemowe w jednym węźle używają łącznie 0,1 rdzeni procesora i 0,1 GB pamięci. Jeśli masz jeden dziesięciordzeniowy węzeł z 10 GB pamięci, demony zużywają 1% pojemności klastra. Natomiast na dziesięciu jednordzeniowych węzłach z 1 GB pamięci demony zajmą 10% pojemności klastra.
Zatem im mniej węzłów, tym efektywniej wykorzystywana jest infrastruktura.
Wada nr 3. Nieefektywne wykorzystanie zasobów
W przypadku małych węzłów może się zdarzyć, że pozostałe fragmenty zasobów będą zbyt małe, aby przypisać do nich jakiekolwiek obciążenie, w związku z czym pozostaną niewykorzystane.
Na przykład każdy moduł wymaga 0,75 GB pamięci. Jeśli masz dziesięć węzłów, każdy z 1 GB pamięci, możesz uruchomić dziesięć podów, pozostawiając każdemu węzłowi 0,25 GB niewykorzystanej pamięci.
Oznacza to, że marnuje się 25% pamięci całego klastra.
Na dużym węźle posiadającym 10 GB pamięci można uruchomić 13 takich modułów – a niewykorzystany zostanie tylko jeden fragment o wielkości 0,25 GB.
W tym przypadku marnuje się tylko 2,5% pamięci.
Dzięki temu zasoby są wykorzystywane bardziej optymalnie na większych 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, oczywistym wyborem są większe węzły. A jeśli aplikacja wymaga dziesięciokrotnej replikacji w celu zapewnienia wysokiej dostępności, nie warto ryzykować umieszczania replik tylko na dwóch węzłach – w klastrze musi znajdować się minimum dziesięć węzłów.
W sytuacjach pośrednich dokonaj wyboru w oparciu o zalety i wady każdej opcji. Być może niektóre argumenty są bardziej adekwatne do Twojej sytuacji niż inne.
I wcale nie jest konieczne, aby wszystkie węzły były tego samego rozmiaru. Nic nie stoi na przeszkodzie, aby najpierw poeksperymentować z węzłami o tej samej wielkości, a następnie dodać do nich węzły o innej wielkości, łącząc je w klaster. Węzły robocze w klastrze Kubernetes mogą być całkowicie heterogeniczne. Można więc spróbować połączyć zalety obu podejść.
Nie ma jednej recepty, a każda sytuacja ma swoje niuanse i dopiero produkcja pokaże prawdę.
Tłumaczenie przygotowane przez zespół platformy chmurowej .
Więcej o Kubernetesie: .
Źródło: www.habr.com