Podczas tworzenia klastra Kubernetes mogą pojawić się pytania: ile węzłów roboczych powinienem skonfigurować i jakiego typu? Co jest lepsze dla klastra lokalnego: zakup kilku wydajnych serwerów czy użycie kilkunastu starych maszyn w centrum danych? A w chmurze, czy lepiej jest wziąć osiem instancji jednordzeniowych czy dwie czterordzeniowe?
Odpowiedzi na te pytania znajdziesz w artykule w tłumaczeniu zespołu .
Pojemność klastra
Ogólnie rzecz biorąc, klaster Kubernetes można postrzegać jako duży „superwęzeł”. Jego całkowita moc obliczeniowa jest sumą mocy wszystkich jego składowych węzłów.
Istnieje kilka sposobów na osiągnięcie pożądanej docelowej pojemności klastra. Na przykład potrzebujemy klastra o łącznej pojemności 8 rdzeni procesora i 32 GB pamięci RAM, ponieważ zestaw aplikacji wymaga takiej ilości zasobów. Następnie możemy 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 procesory dwurdzeniowe.
Oto dwa możliwe sposoby utworzenia klastra:
Obie opcje zapewniają klaster o takiej 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. Podsumowaliśmy je w tabeli.
Kilka dużych węzłów
Dużo małych węzłów
Łatwiejsze zarządzanie klastrem (jeśli jest on lokalny)
Płynne automatyczne skalowanie
Tańsze (jeśli na miejscu)
Cena nie różni się znacząco (w chmurze)
Możesz uruchamiać aplikacje intensywnie wykorzystujące zasoby
Pełna replikacja
Zasoby są wykorzystywane wydajniej (mniejsze obciążenie demonów systemowych)
Większa tolerancja błędów klastra
Należy zauważyć, że mówimy tylko o węzłach roboczych. Wybór liczby i rozmiaru węzłów głównych to zupełnie inny temat.
Omówmy zatem szczegółowo każdy punkt z tabeli.
Opcja 1: Kilka dużych węzłów
Najbardziej ekstremalną opcją jest jeden węzeł roboczy dla całej pojemności klastra. W powyższym przykładzie byłby to jeden węzeł roboczy z 16 rdzeniami CPU i 16 GB pamięci RAM.
Plusy
Plus #1. Łatwiejsze do kontrolowania
Łatwiej zarządzać kilkoma maszynami niż całą flotą. Szybciej wdrażać aktualizacje i poprawki, łatwiej synchronizować. Liczba awarii w liczbach bezwzględnych jest również niższa.
Należy pamiętać, że powyższe informacje dotyczą Twojego własnego sprzętu i serwerów, a nie instancji w chmurze.
W chmurze sytuacja jest inna. Tam zarządzaniem zajmuje się dostawca usług w chmurze. Tak więc zarządzanie dziesięcioma węzłami w chmurze nie różni się wiele od zarządzania jednym węzłem.
Trasowanie ruchu i równoważenie obciążenia między kontenerami w chmurze : ruch pochodzący z Internetu jest kierowany do głównego modułu równoważenia obciążenia, który kieruje ruch do portu na jednym z węzłów (usługa NodePort ustawia port w zakresie 30000-32767 na każdym węźle klastra). Reguły ustawione przez kube-proxy przekierowują ruch z węzła do zasobnika. Tak to wygląda dla dziesięciu zasobników na dwóch węzłach:
Plus nr 2: Niższy koszt na węzeł
Mocniejsza maszyna jest droższa, ale wzrost ceny nie jest koniecznie liniowy. Innymi słowy, jeden dziesięciordzeniowy serwer z 10 GB pamięci jest zazwyczaj tańszy niż dziesięć jednordzeniowych serwerów z taką samą ilością pamięci.
Należy jednak pamiętać, że ta zasada zwykle nie dotyczy usług w chmurze. W obecnych schematach cenowych wszystkich głównych dostawców chmury ceny rosną liniowo wraz z pojemnością.
Dlatego w przypadku chmury zazwyczaj nie da się zaoszczędzić na wydajniejszych serwerach.
Zaleta nr 3: Możesz uruchamiać aplikacje intensywnie wykorzystujące zasoby
Niektóre aplikacje wymagają wydajnych serwerów w klastrze. Na przykład, jeśli system uczenia maszynowego wymaga 8 GB pamięci, nie będziesz w stanie uruchomić go na węzłach 1 GB, ale tylko jeśli masz co najmniej jeden duży węzeł roboczy.
Wady
Wady nr 1: Zbyt wiele kontenerów na węzeł
Jeśli to samo zadanie jest wykonywane na mniejszej liczbie węzłów, to każdy z nich będzie miał więcej kontenerów.
To może być problem.
Powodem jest to, że każdy kontener wprowadza pewne obciążenie do środowiska wykonawczego kontenera (np. Dockera), a także kubelet i cAdvisor.
Na przykład kubelet regularnie sprawdza wszystkie kontenery na węźle pod kątem przeżywalności — im więcej kontenerów, tym więcej pracy musi wykonać kubelet.
CAdvisor zbiera statystyki wykorzystania zasobów ze wszystkich kontenerów na węźle, a kubelet regularnie wysyła zapytania do tych informacji i udostępnia je za pośrednictwem interfejsu API. Ponownie, im więcej kontenerów, tym więcej pracy zarówno dla cAdvisor, jak i kubelet.
Jeżeli liczba modułów wzrośnie, może to spowolnić działanie systemu, a nawet obniżyć jego niezawodność.
Niektóre z nich znajdują się w repozytorium Kubernetes , że węzły przeskakują między statusami Gotowy/Niegotowy, ponieważ regularne sprawdzanie przez kubelet wszystkich kontenerów na węźle zajmuje 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ć pracę z wyprzedzeniem.
Minus #2. Ograniczenie replikacji
Zbyt mała liczba węzłów ogranicza efektywny stopień replikacji aplikacji. Na przykład, jeśli masz wysoce dostępną aplikację z pięcioma replikami, ale tylko dwoma węzłami, efektywny stopień replikacji aplikacji jest zredukowany do dwóch.
Pięć replik można rozmieścić tylko na dwóch węzłach. Jeśli jedna z nich ulegnie awarii, natychmiast zostanie przerwanych kilka replik.
Jeśli masz pięć lub więcej węzłów, każda replika będzie działać na osobnym węźle, a awaria pojedynczego węzła spowoduje usunięcie co najwyżej jednej repliki.
Dlatego wymagania wysokiej dostępności mogą wiązać się z koniecznością stosowania określonej minimalnej liczby węzłów w klastrze.
Minus #3. Gorsze konsekwencje porażki
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 twoich modułów zniknie od razu.
Oczywiście, Kubernetes przeniesie obciążenie z uszkodzonego węzła do innych węzłów. Ale jeśli jest ich niewiele, może nie być wystarczającej ilości wolnej pojemności. W rezultacie niektóre z Twoich aplikacji będą niedostępne, dopóki nie przywrócisz uszkodzonego węzła.
Im więcej węzłów, tym mniejszy wpływ mają awarie sprzętu.
Minus #4. Więcej kroków automatycznego skalowania
Kubernetes ma system automatycznego skalowania klastra dla infrastruktury chmury, który umożliwia automatyczne dodawanie lub usuwanie węzłów w oparciu o bieżące potrzeby. W przypadku większych węzłów automatyczne skalowanie staje się bardziej nagłe i nieporęczne. Na przykład na dwóch węzłach dodanie dodatkowego węzła zwiększy pojemność klastra o 50% naraz. I będziesz musiał zapłacić za te zasoby, nawet jeśli ich nie potrzebujesz.
Jeśli więc planujesz korzystać z automatycznego skalowania klastra, im mniejsze węzły, tym bardziej elastyczne i ekonomiczne będzie skalowanie.
Przyjrzyjmy się teraz zaletom i wadom posiadania dużej liczby małych węzłów.
Opcja 2: Wiele małych węzłów
Zalety tego podejścia w zasadzie wynikają z wad odwrotnej opcji z wieloma dużymi węzłami.
Plusy
Zaleta nr 1: Mniejszy wpływ awarii
Im więcej węzłów, tym mniej podów na każdym węźle. Na przykład, jeśli masz sto podów na dziesięciu węzłach, każdy węzeł będzie miał średnio dziesięć podów.
Jeśli więc jeden węzeł ulegnie awarii, stracisz tylko 10% swojego obciążenia. Istnieje prawdopodobieństwo, że tylko niewielka liczba replik zostanie dotknięta, a Twoje aplikacje jako całość pozostaną operacyjne.
Ponadto pozostałe węzły będą prawdopodobnie dysponować wystarczającą ilością wolnej mocy obliczeniowej, aby obsłużyć obciążenie uszkodzonego węzła, dzięki czemu Kubernetes będzie mógł swobodnie zmieniać harmonogram zadań kontenerów, a Twoje aplikacje zostaną przywrócone do działania stosunkowo szybko.
Plus #2: Dobra replikacja
Jeśli jest wystarczająco dużo węzłów, harmonogram Kubernetes może przypisać wszystkie repliki do różnych węzłów. W ten sposób, jeśli węzeł ulegnie awarii, dotyczy to tylko jednej repliki, a aplikacja pozostaje dostępna.
Wady
Minus nr 1: Trudniejszy do kontrolowania
Zarządzanie dużą liczbą węzłów jest trudniejsze. Na przykład każdy węzeł Kubernetes musi komunikować się ze wszystkimi innymi, co oznacza, że liczba połączeń rośnie kwadratowo, a wszystkie te połączenia muszą być śledzone.
Kontroler węzłów w menedżerze kontrolerów Kubernetes regularnie sprawdza stan wszystkich węzłów w klastrze — im więcej węzłów, tym większe obciążenie kontrolera.
Obciążenie bazy danych etcd również rośnie - każde wywołanie kubelet i kube-proxy dla etcd (poprzez API), do którego etcd powinno rozgłaszać aktualizacje obiektów.
Ogólnie rzecz biorąc, każdy węzeł roboczy dodatkowo obciąża elementy systemu węzłów głównych.
Kubernetes oficjalnie obsługuje klastry z . W praktyce jednak węzłów jest już 500 .
Aby zarządzać dużą liczbą węzłów roboczych, należy wybrać bardziej wydajne 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 konkretne problemy, istnieją specjalne rozwiązania, takie jak: System ten umożliwia ominięcie ograniczeń i budowę klastrów składających się z ogromnej liczby węzłów roboczych.
Wady nr 2: Więcej kosztów ogólnych
Na każdym węźle roboczym Kubernetes uruchamia zestaw demonów systemowych — należą do nich środowisko wykonawcze kontenera (takie jak Docker), kube-proxy i kubelet, w tym cAdvisor — które łącznie zużywają ustaloną ilość zasobów.
Jeśli masz wiele małych węzłów, udział tego narzutu na każdym węźle jest większy. Na przykład wyobraź sobie, że wszystkie demony systemowe na jednym węźle łącznie używają 0,1 rdzenia 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. Z drugiej strony, na dziesięciu jednordzeniowych węzłach z 1 GB pamięci, demony zajmą 10% pojemności klastra.
Im mniej węzłów, tym bardziej efektywnie wykorzystywana jest infrastruktura.
Minus 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ć im jakiekolwiek obciążenie, w związku z czym pozostaną niewykorzystane.
Na przykład każdy pod 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 — to pozostawi każdemu węzłowi 0,25 GB niewykorzystanej pamięci.
Oznacza to, że 25% pamięci całego klastra jest marnowane.
Na dużym węźle z 10 GB pamięci można uruchomić 13 takich modułów i nadal mieć do dyspozycji tylko jeden niewykorzystany blok o wielkości 0,25 GB.
W tym przypadku marnowane jest tylko 2,5% pamięci.
Dzięki temu zasoby są wykorzystywane bardziej optymalnie na dużych węzłach.
Kilka dużych węzłów czy wiele małych?
Więc co jest lepsze: kilka dużych węzłów w klastrze czy wiele małych? Jak zawsze, nie ma jasnej odpowiedzi. Wiele zależy od rodzaju aplikacji.
Na przykład, jeśli aplikacja wymaga 10 GB pamięci, duże węzły są oczywistym wyborem. Ale jeśli aplikacja wymaga XNUMX-krotnej replikacji dla wysokiej dostępności, prawdopodobnie nie warto ryzykować umieszczania replik tylko na dwóch węzłach — klaster powinien mieć co najmniej dziesięć węzłów.
W sytuacjach pośrednich dokonaj wyboru na podstawie zalet i wad każdej opcji. Być może niektóre argumenty są bardziej istotne w Twojej sytuacji niż inne.
I wcale nie jest konieczne, aby wszystkie węzły miały ten sam rozmiar. Nic nie stoi na przeszkodzie, aby najpierw poeksperymentować z węzłami o jednym rozmiarze, a następnie 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żesz więc spróbować połączyć zalety obu podejść.
Nie ma jednego przepisu, każda sytuacja ma swoje niuanse i tylko produkcja pokaże prawdę.
Tłumaczenie przygotowane przez zespół platformy chmurowej .
Więcej o Kubernetes: .
Źródło: www.habr.com
