Może masz środowisko bardziej statyczne, gdzie się niewiele dzieje i Twój klaster chodzi sobie na tych samych węzłach od jego utworzenia.
Może jednak masz możliwość jego skalowania przez zarządzanie liczbą i typem węzłów. Nawet jeśli nie teraz to jeśli tylko Twoja organizacja dowie się o możliwości sporych oszczędności z tego wynikających to temat może znaleźć się “na tapecie”.
To jak to jest z węzłami kastra w Kubernetesie? Jak nimi lepiej zarządzać? To dzisiejszy temat newslettera.
Jakie są typy węzłów?
Jeśli używasz Kubernetesa w chmurze jako usługi (EKS/AKS/GKE itp.) to sprawa jest prosta – możesz zarządzać tylko “zwykłymi” węzłami (workerami).
Przy samodzielnie tworzonym klastrze masz jeszcze cały Control Plane do zarządzania. Węzły, które go tworzą są super, ale to naprawdę super krytyczne. Od ich wydajności i dostępności zależy praca całego klastra oraz aplikacji na nim chodzących.
Na szczęście nawet dla dużych klastrów wystarczą trzy wydajne węzły. Rzadko stosuje się oddzielnie węzły na etcd i robi się to przy naprawdę dużych klastrach, aby podnieść poziom niezawodności całej platformy.
Więcej mniejszych czy mniej większych?
Najpierw Control Plane. Tu sprawa jest prosta – typ węzłów jest uzależniony od planowanej wielkości klastra. Ze względu na trochę złożony proces podmiany węzła Control Plane lepiej utworzyć je większe, aby uniknąć późniejszej operacji migracji.
Węzły workery to już inna historia.
Zacznę od przypadku szczególnego, czyli jeśli aplikacje na klastrze niezbyt dobrze skalują się horyzontalnie. Wówczas lepiej dobrać maszyny o większej liczbie zasobów (głównie CPU).
W pozostałych przypadkach reguła jest prosta:
Lepiej jest mieć więcej mniejszych węzłów niż mniej większych.
Dlaczego? Jest kilka powodów, a dwa najważniejsze z nich to:
- Większa stabilność – w przypadku awarii węzła jeśli ma on uruchomionych mniej kontenerów i tym samym ich ponowne uruchomienie na innych węzłach będzie szybsze oraz mniej zauważalne. Podobnie w przypadku “kontrolowanych awarii”, czyli aktualizacji wersji klastra, gdy węzły również są niedostępne (np. w trybie rolling update).
- Większa wydajność – kontenery to procesy, które działają na wspólnym kernelu linuksowym. Ten owszem, ma mechanizmy do zapewnienia im prywatności (namespaces), ale są jego części współdzielone przez nie wszystkie. Takim ważnym jest pagecache, który pośredniczy w odczytywaniu i zapisywaniu danych na dysk. Przy większej liczbie procesów (czyli większej liczbie kontenerów uruchomionych na większym węźle) to może tworzyć wąskie gardło i zmniejszać wydajność.
Tradycyjne autoskalowanie
Po co mielić puste powietrze lub cisnąć się na zbyt małej liczbie węzłów? Wtedy z pomocą przychodzi oficjalny projekt autoscaler.
Zareaguje on odpowiednio na potrzeby i zarządzi odpowiednią węzłami – zwiększy lub zmniejszy ich liczbę.
Jest tylko mały problemik – utworzy on węzły o jednym typie. To jest w większości wypadków ok, ale jeśli potrzebujesz dodatkowego węzła na zaledwie kilka podów to może utworzenia węzła mieszczącego ich kilka(naście) razy więcej nie być optymalne.
Do tego może te nowe pody mogą działać na węzłach typu spot – wtedy tradycyjny autoskaler może być niewystarczający. Ale na szczęście jest coś lepszego.
Mądrzejszy dobór węzłów z dodatkiem Karpenter
Tym czymś jest projekt Karpenter. Jest to bardziej inteligentny autoskaler, który zadba o lepszy dobór węzłów.
To dobra wiadomość, ale jest też zła. Póki co wspiera tylko AWS (oni go z resztą utworzyli) oraz Azure. Na resztę przyjdzie nam jeszcze poczekać.