Aby w pełni opanować Kubernetes, trzeba znać różne sposoby skalowania zasobów klastra: poprzez , jest to jedno z głównych zadań Kubernetesa. Udostępniliśmy ogólny przegląd mechanizmów automatycznego skalowania w poziomie i w pionie oraz zmiany rozmiaru klastrów, a także zalecenia dotyczące skutecznego korzystania z nich.
artykuł przetłumaczone przez zespół, który zaimplementował autoskalowanie w .
Dlaczego warto myśleć o skalowaniu
- narzędzie do zarządzania zasobami i orkiestracji. Oczywiście miło jest majstrować przy ciekawych funkcjach wdrażania, monitorowania i zarządzania podami (pod to grupa kontenerów uruchamianych w odpowiedzi na żądanie).
Warto jednak zastanowić się także nad następującymi kwestiami:
- Jak skalować moduły i aplikacje?
- Jak zapewnić sprawność i efektywność kontenerów?
- Jak reagować na ciągłe zmiany w kodzie i obciążenia użytkowników?
Konfigurowanie klastrów Kubernetes w celu zrównoważenia zasobów i wydajności może być wyzwaniem i wymaga specjalistycznej wiedzy na temat wewnętrznego działania Kubernetes. Obciążenie aplikacji lub usług może zmieniać się w ciągu dnia lub nawet w ciągu godziny, dlatego równoważenie najlepiej traktować jako proces ciągły.
Poziomy autoskalowania Kubernetes
Efektywne autoskalowanie wymaga koordynacji pomiędzy dwoma poziomami:
- Poziom podów, w tym poziomy (automatyczne skalowanie podów w poziomie, HPA) i automatyczne skalowanie w pionie (automatyczne skalowanie pionowych podów, VPA). To skaluje dostępne zasoby dla Twoich kontenerów.
- Poziom klastra zarządzany przez narzędzie Cluster Autoscaler (CA), które zwiększa lub zmniejsza liczbę węzłów w klastrze.
Moduł poziomego autoskalera (HPA).
Jak sama nazwa wskazuje, HPA skaluje liczbę replik strąków. Większość devopsów wykorzystuje obciążenie procesora i pamięci jako wyzwalacze zmiany liczby replik. Istnieje jednak możliwość skalowania systemu w oparciu o ich lub .
Schemat operacyjny wysokiego poziomu HPA:
- HPA stale sprawdza wartości metryczne określone podczas instalacji w domyślnym odstępie 30 sekund.
- HPA próbuje zwiększyć liczbę modułów, jeśli zostanie osiągnięty określony próg.
- HPA aktualizuje liczbę replik w kontrolerze wdrażania/replikacji.
- Następnie kontroler wdrażania/replikacji wdraża wszelkie niezbędne dodatkowe moduły.
HPA rozpoczyna proces wdrażania modułu po osiągnięciu progu metryki
Korzystając z HPA, należy wziąć pod uwagę następujące kwestie:
- Domyślny interwał sprawdzania HPA wynosi 30 sekund. Jest ustawiony przez flagę okres synchronizacji poziomego pod-automatycznego skalowania w menedżerze kontrolerów.
- Domyślny błąd względny wynosi 10%.
- Po ostatnim zwiększeniu liczby modułów HPA spodziewa się stabilizacji wskaźników w ciągu trzech minut. Ten interwał jest ustawiany przez flagę poziome opóźnienie-automatycznego skalowania-upscalera.
- Po ostatnim zmniejszeniu liczby modułów HPA czeka pięć minut na ustabilizowanie się. Ten interwał jest ustawiany przez flagę opóźnienie-w dół-skalowania poziomego pod-autoskalera.
- HPA działa najlepiej z obiektami wdrożeniowymi, a nie z kontrolerami replikacji. Automatyczne skalowanie w poziomie jest niezgodne z aktualizacją kroczącą, która bezpośrednio manipuluje kontrolerami replikacji. W przypadku wdrożenia liczba replik zależy bezpośrednio od obiektów wdrożenia.
Automatyczne skalowanie w pionie podów
Automatyczne skalowanie pionowe (VPA) przydziela więcej (lub mniej) czasu procesora lub pamięci istniejącym podom. Nadaje się do zasobników stanowych i bezstanowych, ale jest przeznaczony głównie do usług stanowych. Można jednak zastosować VPA również w przypadku modułów bezstanowych, jeśli konieczne jest automatyczne dostosowanie ilości początkowo przydzielonych zasobów.
VPA reaguje również na zdarzenia OOM (brak pamięci). Zmiana czasu procesora i pamięci wymaga ponownego uruchomienia zasobników. Po ponownym uruchomieniu VPA przestrzega budżetu alokacyjnego (), aby zagwarantować minimalną wymaganą liczbę modułów.
Możesz ustawić minimalne i maksymalne zasoby dla każdego modułu. W ten sposób możesz ograniczyć maksymalną ilość przydzielonej pamięci do 8 GB. Jest to przydatne, jeśli bieżące węzły zdecydowanie nie mogą przydzielić więcej niż 8 GB pamięci na kontener. Szczegółowe dane techniczne i mechanizm działania opisano w .
Dodatkowo VPA posiada ciekawą funkcję rekomendacji (VPA Recommender). Monitoruje wykorzystanie zasobów i zdarzenia OOM wszystkich modułów, aby zaproponować nowe wartości pamięci i czasu procesora w oparciu o inteligentny algorytm oparty na danych historycznych. Istnieje również interfejs API, który pobiera uchwyt pod i zwraca sugerowane wartości zasobów.
Warto zauważyć, że narzędzie rekomendujące VPA nie śledzi „limitu” zasobów. Może to spowodować, że moduł zmonopolizuje zasoby w obrębie węzłów. Lepiej ustawić limit na poziomie przestrzeni nazw, aby uniknąć ogromnego zużycia pamięci lub procesora.
Schemat działania VPA wysokiego poziomu:
- VPA stale sprawdza wartości metryczne określone podczas instalacji w domyślnym odstępie 10 sekund.
- Jeśli określony próg zostanie osiągnięty, VPA podejmie próbę zmiany przydzielonej ilości zasobów.
- Umowa VPA aktualizuje liczbę zasobów w kontrolerze wdrażania/replikacji.
- Po ponownym uruchomieniu modułów wszystkie nowe zasoby zostaną zastosowane do utworzonych instancji.
VPA dodaje wymaganą ilość zasobów
Korzystając z VPA, należy pamiętać o następujących kwestiach:
- Skalowanie wymaga obowiązkowego ponownego uruchomienia zasobnika. Jest to konieczne, aby uniknąć niestabilnej pracy po dokonaniu zmian. Aby zapewnić niezawodność, moduły są uruchamiane ponownie i dystrybuowane pomiędzy węzłami w oparciu o nowo przydzielone zasoby.
- VPA i HPA nie są jeszcze ze sobą kompatybilne i nie mogą działać na tych samych kapsułach. Jeśli używasz obu mechanizmów skalowania w tym samym klastrze, upewnij się, że Twoje ustawienia uniemożliwiają ich aktywację na tych samych obiektach.
- VPA dostraja żądania kontenerów dotyczące zasobów w oparciu wyłącznie o przeszłe i obecne wykorzystanie. Nie określa limitów wykorzystania zasobów. Mogą wystąpić problemy z tym, że aplikacje nie działają poprawnie i zaczynają przejmować coraz więcej zasobów, co doprowadzi do wyłączenia tego poda przez Kubernetesa.
- VPA jest wciąż na wczesnym etapie rozwoju. Należy być przygotowanym na to, że w najbliższej przyszłości system może ulec pewnym zmianom. Możesz przeczytać o и . Tym samym w planach jest wdrożenie wspólnego działania VPA i HPA, a także wdrożenie modułów wraz z polityką ich pionowego autoskalowania (np. specjalna etykieta „wymaga VPA”).
Automatyczne skalowanie klastra Kubernetes
Cluster Autoscaler (CA) zmienia liczbę węzłów na podstawie liczby oczekujących zasobników. System okresowo sprawdza, czy nie ma oczekujących modułów i zwiększa rozmiar klastra, jeśli potrzeba więcej zasobów i klaster nie przekracza ustalonych limitów. Urząd certyfikacji komunikuje się z dostawcą usług w chmurze, żąda od niego dodatkowych węzłów lub zwalnia nieużywane. Pierwsza ogólnodostępna wersja CA została wprowadzona w Kubernetes 1.8.
Schemat wysokiego poziomu działania SA:
- Urząd certyfikacji sprawdza oczekujące moduły w domyślnym odstępie 10 sekund.
- Jeśli co najmniej jeden pod jest w stanie gotowości, ponieważ klaster nie ma wystarczającej ilości zasobów, aby je przydzielić, podejmuje próbę udostępnienia co najmniej jednego dodatkowego węzła.
- Gdy dostawca usług w chmurze przydziela wymagany węzeł, przyłącza się on do klastra i jest gotowy do obsługi zasobników.
- Harmonogram Kubernetes dystrybuuje oczekujące zasobniki do nowego węzła. Jeżeli po tym czasie niektóre moduły nadal będą znajdować się w stanie oczekiwania, proces zostanie powtórzony i do klastra dodane zostaną nowe węzły.
Automatyczne udostępnianie węzłów klastra w chmurze
Korzystając z urzędu certyfikacji, rozważ następujące kwestie:
- CA zapewnia, że wszystkie pody w klastrze mają miejsce do działania, niezależnie od obciążenia procesora. Stara się także upewnić, że w klastrze nie ma niepotrzebnych węzłów.
- CA rejestruje potrzebę skalowania po około 30 sekundach.
- Gdy węzeł nie jest już potrzebny, urząd certyfikacji domyślnie czeka 10 minut przed skalowaniem systemu.
- System autoskalowania ma koncepcję ekspanderów. Są to różne strategie wyboru grupy węzłów, do których zostaną dodane nowe węzły.
- Korzystaj z tej opcji odpowiedzialnie klaster-autoskaler.kubernetes.io/safe-to-evict (true). Jeśli zainstalujesz wiele podów lub jeśli wiele z nich będzie rozproszonych po wszystkich węzłach, w dużej mierze utracisz możliwość skalowania klastra.
- Stosowanie aby zapobiec usuwaniu podów, co mogłoby spowodować całkowitą awarię części aplikacji.
Jak autoskalery Kubernetes współdziałają ze sobą
Aby uzyskać idealną harmonię, autoskalowanie powinno zostać zastosowane zarówno na poziomie podu (HPA/VPA), jak i na poziomie klastra. Oddziałują ze sobą stosunkowo prosto:
- HPA lub VPA aktualizują repliki podów lub zasoby przydzielone do istniejących zasobników.
- Jeśli nie ma wystarczającej liczby węzłów do planowanego skalowania, urząd certyfikacji zauważa obecność podów w stanie oczekiwania.
- Urząd certyfikacji przydziela nowe węzły.
- Moduły są dystrybuowane do nowych węzłów.
Współpracujący system skalowania w poziomie Kubernetes
Typowe błędy w autoskalowaniu Kubernetesa
Istnieje kilka typowych problemów, na które napotykają deweloperzy próbujący wdrożyć automatyczne skalowanie.
HPA i VPA zależą od wskaźników i niektórych danych historycznych. Jeśli przydzielone zostaną niewystarczające zasoby, moduły zostaną zminimalizowane i nie będą mogły generować metryk. W takim przypadku autoskalowanie nigdy nie nastąpi.
Sama operacja skalowania jest wrażliwa na czas. Zależy nam na szybkim skalowaniu modułów i klastra – zanim użytkownicy zauważą jakiekolwiek problemy lub awarie. Należy zatem uwzględnić średni czas skalowania dla podów i klastra.
Idealny scenariusz – 4 minuty:
- 30 sekund. Aktualizacja wskaźników docelowych: 30–60 sekund.
- 30 sekund. HPA sprawdza wartości metryczne: 30 sekund.
- Mniej niż 2 sekundy. Pody są tworzone i przechodzą w stan oczekiwania: 1 sekunda.
- Mniej niż 2 sekundy. CA widzi oczekujące moduły i wysyła wywołania do węzłów udostępniania: 1 sekunda.
- 3 minuty. Dostawca chmury przydziela węzły. K8s czeka, aż będą gotowe: do 10 minut (w zależności od kilku czynników).
Najgorszy scenariusz (bardziej realistyczny) – 12 minut:
- 30 sekund. Zaktualizuj wskaźniki docelowe.
- 30 sekund. HPA sprawdza wartości metryki.
- Mniej niż 2 sekundy. Pody zostaną utworzone i przejdą w stan gotowości.
- Mniej niż 2 sekundy. Urząd certyfikacji widzi oczekujące moduły i wykonuje wywołania w celu udostępnienia węzłów.
- 10 minut. Dostawca chmury przydziela węzły. K8 czekają, aż będą gotowe. Czas oczekiwania zależy od kilku czynników, takich jak opóźnienie dostawcy, opóźnienie systemu operacyjnego i narzędzia pomocy technicznej.
Nie myl mechanizmów skalowania dostawców usług chmurowych z naszym urzędem certyfikacji. Ten ostatni działa w klastrze Kubernetes, podczas gdy silnik dostawcy chmury działa na zasadzie dystrybucji węzłów. Nie wie, co się dzieje z Twoimi kapsułami lub aplikacją. Systemy te działają równolegle.
Jak zarządzać skalowaniem w Kubernetesie
- Kubernetes to narzędzie do zarządzania i orkiestracji zasobów. Operacje zarządzania podami i zasobami klastra są kluczowym kamieniem milowym w doskonaleniu Kubernetes.
- Zrozum logikę skalowalności podów z uwzględnieniem HPA i VPA.
- CA należy stosować tylko wtedy, gdy dobrze rozumiesz potrzeby swoich kapsuł i pojemników.
- Aby optymalnie skonfigurować klaster, należy zrozumieć, w jaki sposób różne systemy skalowania współpracują ze sobą.
- Szacując czas skalowania, należy mieć na uwadze najgorszy i najlepszy scenariusz.
Źródło: www.habr.com