Aby w pełni zrozumieć Kubernetes, należy znać różne metody skalowania zasobów klastrów: według , to jedno z głównych zadań Kubernetes. Przygotowaliśmy podsumowanie mechanizmów automatycznego skalowania poziomego i pionowego oraz zmiany rozmiaru klastrów, a także wskazówki, jak skutecznie je wykorzystać.
Artykuł przetłumaczył zespół, który wdrożył automatyczne skalowanie w .
Dlaczego warto pomyśleć o skalowaniu
— narzędzie do zarządzania zasobami i orkiestracji. Oczywiście dobrze jest pobawić się wspaniałymi funkcjami wdrażania, monitorowania i zarządzania podami (moduł pod — grupa kontenerów uruchamianych w odpowiedzi na żądanie).
Należy jednak także rozważyć takie kwestie, jak:
- Jak skalować moduły i aplikacje?
- Jak utrzymać kontenery w działającym i efektywnym stanie?
- Jak reagować na ciągłe zmiany w kodzie i obciążeniach od użytkowników?
Konfiguracja klastrów Kubernetes do równoważenia zasobów i wydajności może być skomplikowanym zadaniem, wymaga to eksperckiej wiedzy na temat wewnętrznego działania Kubernetes. Obciążenie aplikacji lub usług może się zmieniać w ciągu dnia lub nawet jednego godziny, dlatego równoważenie najlepiej postrzegać jako proces ciągły.
Poziomy automatycznego skalowania Kubernetes
Efektywne automatyczne skalowanie wymaga koordynacji między dwoma poziomami:
- Poziom podów, obejmujący automatyczne skalowanie poziome (Horizontal Pod Autoscaler, HPA) i pionowe (Vertical Pod Autoscaler, VPA). To skalowanie istniejących zasobów dla twoich kontenerów.
- Poziom klastra, zarządzany przez system automatycznego skalowania klastra (Cluster Autoscaler, CA), zwiększa lub zmniejsza liczbę węzłów w klastrze.
Moduł automatycznego skalowania poziomego (HPA)
Jak wskazuje nazwa, HPA skaluje liczbę replik podów. Jako wyzwalacze do zmiany liczby replik, większość devopsów wykorzystuje obciążenie procesora i pamięci. Można jednak skalować system na podstawie , ich lub nawet .
Wysokopoziomowy schemat działania HPA:
- HPA nieprzerwanie sprawdza wartości metryk określonych podczas instalacji, co 30 sekund.
- HPA dąży do zwiększenia liczby modułów, jeśli osiągnięty zostanie ustalony próg.
- HPA aktualizuje liczbę replik w obrębie kontrolera wdrożenia/rekonstrukcji.
- Kontroler wdrożenia/rekonstrukcji następnie wdraża wszystkie potrzebne dodatkowe moduły.
HPA uruchamia proces wdrażania modułów przy osiągnięciu progu wartości metryk.
Podczas korzystania z HPA należy pamiętać o następujących rzeczach:
- Domyślny interwał sprawdzania HPA wynosi 30 sekund. Jest ustawiany flagą. horizontal-pod-autoscaler-sync-period w menedżerze kontrolera.
- Domyślna względna dokładność wynosi 10%.
- Po ostatnim zwiększeniu liczby modułów HPA czeka na stabilizację metryk przez trzy minuty. Ten interwał jest ustawiany flagą. horizontal-pod-autoscaler-upscale-delay.
- Po ostatnim zmniejszeniu liczby modułów HPA czeka na stabilizację przez pięć minut. Ten interwał jest ustawiany flagą. horizontal-pod-autoscaler-downscale-delay.
- HPA najlepiej działa z obiektami wdrożeniowymi, a nie z kontrolerami replikacji. Poziome automatyczne skalowanie jest niekompatybilne z aktualizacją w trybie rolling update, która bezpośrednio manipuluje kontrolerami replikacji. Podczas wdrażania liczba replik zależy bezpośrednio od obiektów wdrożeniowych.
Poziome automatyczne skalowanie podów
Poziome automatyczne skalowanie (VPA) przydziela więcej (lub mniej) czasu procesora lub pamięci dla istniejących podów. Nadaje się do podów stanowych (stateful) lub bezstanowych (stateless), ale głównie jest przeznaczone dla usług stateful. Można jednak zastosować VPA również do modułów bezstanowych, jeśli potrzebujesz automatycznie dostosować ilość początkowo przydzielonych zasobów.
VPA reaguje również na zdarzenia OOM (out of memory, brak pamięci). Aby zmienić czas procesora i ilość pamięci, konieczne jest ponowne uruchomienie podów. Przy ponownym uruchamianiu VPA przestrzega budżetu dystrybucji (), aby zapewnić minimalną wymaganą liczbę modułów.
Możesz ustawić minimalną i maksymalną ilość zasobów dla każdego modułu. Można w ten sposób ograniczyć maksymalną ilość przydzielonej pamięci do 8 GB. Jest to przydatne, jeśli bieżące węzły nie mogą przydzielić więcej niż 8 GB pamięci na kontener. Szczegółowe specyfikacje oraz zasady działania opisane są w .
Ponadto VPA ma interesującą funkcję rekomendacji (VPA Recommender). Śledzi ona użycie zasobów oraz zdarzenia OOM wszystkich modułów, aby zaproponować nowe wartości pamięci i czasu procesora na podstawie inteligentnego algorytmu uwzględniającego historyczne metryki. Jest również interfejs API, który przyjmuje identyfikator pod i zwraca proponowane wartości zasobów.
Warto zaznaczyć, że VPA Recommender nie monitoruje „limitów” zasobów. Może to doprowadzić do tego, że moduł monopolizuje zasoby w obrębie węzłów. Lepiej ustawić limit na poziomie przestrzeni nazw, aby uniknąć ogromnego zużycia pamięci lub czasu procesora.
Schemat działania VPA na wysokim poziomie:
- VPA nieustannie sprawdza wartości metryk zadanych przy instalacji w domyślnym interwale 10 sekund.
- Jeśli osiągnięto zadany próg, VPA próbuje zmienić przydzieloną ilość zasobów.
- VPA aktualizuje ilość zasobów w obrębie kontrolera wdrożenia/replikacji.
- Podczas ponownego uruchamiania modułów wszystkie nowe zasoby są stosowane do utworzonych instancji.
VPA dodaje wymaganą ilość zasobów
Weź pod uwagę następujące aspekty korzystając z VPA:
- Skalowanie wymaga obowiązkowego ponownego uruchomienia pod'a. Jest to konieczne, aby uniknąć niestabilnej pracy po wprowadzeniu zmian. Dla niezawodności moduły ponownie uruchamiają się i są rozdzielane pomiędzy węzłami w oparciu o nowe przydzielone zasoby.
- VPA i HPA są na razie ze sobą niekompatybilne i nie mogą działać na tych samych pod'ach. Jeśli stosujesz oba mechanizmy skalowania w tej samej klastrze, upewnij się, że ustawienia nie pozwolą im na aktywację na tych samych obiektach.
- VPA dostosowuje zapytania kontenerów do zasobów, opierając się tylko na ich wcześniejszym i bieżącym wykorzystaniu. Nie ustala limitów wykorzystania zasobów. Mogą wystąpić problemy z nieprawidłowym działaniem aplikacji, które zaczynają zajmować coraz więcej zasobów, co doprowadzi do wyłączenia tego poda przez Kubernetes.
- VPA jest wciąż w wczesnej fazie rozwoju. Bądź przygotowany, że w najbliższym czasie system może ulec pewnym zmianom. Można poczytać o i . W planach jest wdrożenie współpracy VPA i HPA, a także uruchomienie modułów z polityką pionowego automatycznego skalowania dla nich (na przykład specjalna etykieta 'requires VPA').
Automatyczne skalowanie klastra Kubernetes
Automatyczne skalowanie klastra (Cluster Autoscaler, CA) zmienia liczbę węzłów w zależności od liczby oczekujących modułów pod. System okresowo sprawdza obecność oczekujących modułów — i zwiększa rozmiar klastra, jeśli potrzebne są dodatkowe zasoby i jeśli klaster nie przekracza ustalonych limitów. CA współdziała z dostawcą usług chmurowych, zamawiając dodatkowe węzły lub zwalniając nieużywane. Pierwsza publiczna wersja CA została opublikowana w Kubernetes 1.8.
Ogólna schemat pracy CA:
- CA sprawdza obecność modułów w stanie oczekiwania co 10 sekund.
- Jeśli jeden lub kilka modułów znajduje się w stanie oczekiwania z powodu niewystarczającej liczby dostępnych zasobów w klastrze, podejmuje próbę uruchomienia jednego lub kilku dodatkowych węzłów.
- Gdy dostawca usług chmurowych przydzieli wymagany węzeł, dołącza on do klastra i jest gotowy do obsługi modułów pod.
- Planista Kubernetes rozdziela oczekujące moduły na nowy węzeł. Jeśli po tym niektóre moduły nadal pozostają w stanie oczekiwania, proces powtarza się — i do klastra dodawane są nowe węzły.
Automatyczne przydzielanie węzłów klastra w chmurze
Weź pod uwagę następujące kwestie przy używaniu CA:
- CA zapewnia, że wszystkie moduły w klastrze mają miejsce do uruchomienia, niezależnie od obciążenia procesora. Ponadto stara się zagwarantować, że w klastrze nie ma niepotrzebnych węzłów.
- CA rejestruje potrzebę skalowania w ciągu około 30 sekund.
- Po tym, jak węzeł staje się niepotrzebny, CA domyślnie oczekuje 10 minut przed skalowaniem systemu.
- W systemie automatycznego skalowania istnieją pojęcia rozszerzeń (expanders). To różne strategie do wyboru grupy węzłów, do której zostaną dodane nowe zasoby.
- Odpowiedzialnie zastosuj opcję cluster-autoscaler.kubernetes.io/safe-to-evict (true). Jeśli ustawi się wiele pod’ów lub jeśli wiele z nich będzie rozmieszczonych na wszystkich węzłach, w dużej mierze utraci się zdolność do zmniejszenia skali klastra.
- Użyj , aby zapobiec usunięciu pod’ów, co mogłoby spowodować całkowite awarie części aplikacji.
Jak systemy automatycznego skalowania Kubernetes współdziałają ze sobą
Dla idealnej harmonii należy zastosować automatyczne skalowanie zarówno na poziomie pod’ów (HPA/VPA), jak i na poziomie klastra. Relatywnie łatwo współdziałają ze sobą:
- HPA lub VPA aktualizują repliki pod’ów lub zasoby przydzielone dla istniejących pod’ów.
- Jeśli do planowanego skalowania brakuje węzłów, CA zauważa obecność pod’ów w stanie oczekiwania.
- CA przydziela nowe węzły.
- Moduły są rozdzielane po nowych węzłach.
Zintegrowany system skalowania Kubernetes
Typowe błędy w automatycznym skalowaniu Kubernetes
Istnieje kilka typowych problemów, z którymi DevOps napotykają, próbując zastosować automatyczne skalowanie.
HPA i VPA zależą od metryk i niektórych danych historycznych. Jeśli przydzielono niewystarczające zasoby, moduły zostaną skompresowane i nie będą w stanie generować metryk. W takim przypadku automatyczne skalowanie nigdy nie zajdzie.
Sama operacja skalowania jest wrażliwa na czas. Chcemy, aby moduły i klaster były skalowane szybko — zanim użytkownicy zauważą jakiekolwiek problemy i awarie. Dlatego należy wziąć pod uwagę średni czas skalowania pod’ów i klastra.
Idealny scenariusz to 4 minuty:
- 30 sekund. Aktualizacja docelowych metryk: 30−60 sekund.
- 30 sekund. HPA sprawdza wartości metryk: 30 sekund.
- Mniej niż 2 sekundy. Moduły pod są tworzone i przechodzą w stan oczekiwania: 1 sekunda.
- Mniej niż 2 sekundy. CA widzi oczekujące moduły i wysyła wezwania do przygotowania węzłów: 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 (bardziej realistyczny) scenariusz — 12 minut:
- 30 sekund. Aktualizacja docelowych metryk.
- 30 sekund. HPA sprawdza wartości metryk.
- Mniej niż 2 sekundy. Moduły pod zostały stworzone i przechodzą w stan oczekiwania.
- Mniej niż 2 sekundy. CA widzi oczekujące moduły i wysyła wywołania do przygotowania węzłów.
- 10 minut. Dostawca chmury przydziela węzły. K8s czeka, aż będą gotowe. Czas oczekiwania zależy od kilku czynników, takich jak opóźnienie dostawcy, opóźnienie systemu operacyjnego oraz działanie narzędzi pomocniczych.
Nie myl mechanizmów skalowania dostawców chmury z naszym CA. Ten ostatni działa wewnątrz klastra Kubernetes, podczas gdy mechanizm dostawcy chmury działa na podstawie rozdzielania węzłów. Nie wie, co się dzieje z Twoimi pod'ami lub aplikacją. Te systemy działają równolegle.
Jak zarządzać skalowaniem w Kubernetes
- Kubernetes to narzędzie do zarządzania zasobami i orkiestracji. Operacje zarządzania pod'ami i zasobami klastra to kluczowa kwestia w opanowaniu Kubernetes.
- Poznaj logikę skalowalności pod'ów z uwzględnieniem HPA i VPA.
- CA warto używać tylko jeśli dobrze rozumiesz potrzeby swoich pod'ów i kontenerów.
- Aby optymalnie skonfigurować klaster, musisz zrozumieć, jak różne systemy skalowania współpracują ze sobą.
- Oceniając czas skalowania, pamiętaj o najgorszym i najlepszym scenariuszu.
Źródło: habr.com
