Omówienie skalowania automatycznego klastra w usłudze Azure Kubernetes Service (AKS)

Aby nadążyć za wymaganiami aplikacji w usłudze Azure Kubernetes Service (AKS), może być konieczne dostosowanie liczby węzłów, które uruchamiają obciążenia. Składnik automatycznego skalowania klastra obserwuje pody w klastrze, których nie można zaplanować z powodu ograniczeń zasobowych. Gdy narzędzie do automatycznego skalowania klastra wykryje nieplanowane zasobniki, skaluje w górę liczbę węzłów w puli węzłów, aby zaspokoić zapotrzebowanie aplikacji. Regularnie sprawdza również węzły, które nie mają żadnych zaplanowanych zasobników, i w razie potrzeby zmniejsza liczbę węzłów.

Ten artykuł pomaga zrozumieć, jak działa narzędzie do automatycznego skalowania klastra w usłudze AKS. Zawiera również wskazówki, najlepsze praktyki i kwestie do rozważenia przy konfigurowaniu narzędzia do automatycznego skalowania klastra dla obciążeń usługi AKS. Jeśli chcesz włączyć, wyłączyć lub zaktualizować automatyczne skalowanie klastra dla obciążeń usługi AKS, zobacz Używanie narzędzia do automatycznego skalowania klastra w usłudze AKS.

Informacje o autoskalatorze klastra

Klastry często wymagają sposobu automatycznego skalowania w celu dostosowania się do zmieniających się wymagań aplikacji, takich jak między dni roboczymi a wieczorami lub weekendami. Klastry usługi AKS mogą być skalowane w następujący sposób:

• Narzędzie do automatycznego skalowania klastra okresowo sprawdza zasobniki, których nie można umieścić na węzłach z powodu ograniczeń zasobów. Następnie klaster automatycznie zwiększa liczbę węzłów. Skalowanie ręczne jest wyłączone w przypadku korzystania z narzędzia do automatycznego skalowania klastra. Aby uzyskać więcej informacji, zobacz Jak działa skalowanie w górę?.
• Narzędzie Horizontal Pod Autoscaler używa serwera Metrics w klastrze Kubernetes do monitorowania zapotrzebowania na zasoby podów. Jeśli aplikacja potrzebuje większej ilości zasobów, liczba zasobników zostanie automatycznie zwiększona, aby zaspokoić zapotrzebowanie.
• Narzędzie Pionowe Automatyczne Skalowanie Zasobników automatycznie ustawia żądania zasobów i limity na kontenerach dla każdego typu obciążenia na podstawie wcześniejszego użycia, aby upewnić się, że zasobniki są umieszczane na węzłach z wymaganymi zasobami procesora CPU i pamięci.

Typowym rozwiązaniem jest włączenie autoskalowania klastra dla węzłów oraz skalowania pionowego lub poziomego zasobników. Po włączeniu automatycznego skalowania klastra stosuje określone reguły skalowania, gdy rozmiar puli węzłów jest niższy niż minimalna liczba węzłów, aż do osiągnięcia maksymalnej liczby węzłów. Narzędzie do automatycznego skalowania klastra czeka, aż nowy węzeł będzie potrzebny w puli węzłów lub aż węzeł będzie można bezpiecznie usunąć z obecnej puli węzłów. Aby uzyskać więcej informacji, zobacz Jak działa skalowanie w dół?

Najlepsze rozwiązania i zagadnienia

• Podczas implementowania stref dostępności za pomocą narzędzia do automatycznego skalowania klastra zalecamy użycie pojedynczej puli węzłów dla każdej strefy. Można ustawić parametr --balance-similar-node-groups na True, aby zachować zrównoważony rozkład węzłów między strefami dla obciążeń podczas operacjach zwiększania skali. Jeśli takie podejście nie jest zaimplementowane, operacje skalowania w dół mogą zakłócać równowagę węzłów między strefami.
• W przypadku klastrów z ponad 400 węzłami zalecamy użycie warstwy Azure CNI lub nakładki usługi Azure CNI.
• Aby efektywnie uruchamiać obciążenia współbieżnie zarówno w pulach węzłów typu spot, jak i w stałych węzłach, rozważ użycie rozszerzeń priorytetu. Takie podejście umożliwia planowanie zasobników na podstawie priorytetu puli węzłów.
• Zachowaj ostrożność podczas przypisywania żądań CPU/pamięci na podach. Narzędzie do automatycznego skalowania klastra skalowany w górę bazując na oczekujących zasobnikach, a nie na obciążeniu CPU/pamięci na węzłach.
• W przypadku klastrów, które jednocześnie obsługują zarówno długotrwałe obciążenia, takie jak aplikacje internetowe, jak i obciążenia zadań krótkotrwałych/intensywnych, zalecamy ich rozdzielenie na odrębne pule węzłów za pomocą reguł koligacji/rozszerzeń lub użycie PodDisruptionBudgetu, aby zapobiec niepotrzebnemu opróżnianiu węzłów lub zmniejszaniu skali operacji. Określenie adnotacji cluster-autoscaler.kubernetes.io/safe-to-evict: "false" w specyfikacji zasobnika uniemożliwi również eksmitowanie zasobników. Użyj tej adnotacji z ostrożnością, ponieważ może to spowodować, że narzędzie do automatycznego skalowania klastra napotka problemy podczas opróżniania węzła z uruchomionym zasobnikem zawierającym tę adnotację.
• W puli węzłów z włączoną funkcją automatycznego skalowania zmniejszaj liczbę węzłów przez usunięcie obciążeń, zamiast ręcznie zmieniać minimalną/maksymalną liczebność węzłów w puli. Może to być problematyczne, jeśli pula węzłów jest już w maksymalnej pojemności lub jeśli istnieją aktywne obciążenia uruchomione w węzłach, potencjalnie powodując nieoczekiwane zachowanie przez narzędzie do automatycznego skalowania klastra.
• Węzły nie są skalowane w górę, jeśli zasobniki mają wartość PriorityClass mniejszą niż -10. Priorytet -10 jest zarezerwowany dla podów z nadmiernymi zasobami. Aby uzyskać więcej informacji, zobacz Using the cluster autoscaler with Pod Priority and Preemption (Używanie narzędzia do automatycznego skalowania klastra z priorytetem zasobnika i wywłaszczeniem).
• Nie łącz innych mechanizmów skalowania automatycznego węzłów, takich jak autoskalatory zestawu skalowania maszyn wirtualnych, z funkcją automatycznego skalowania klastra.
• Automatyczne skalowanie klastra może nie być w stanie zmniejszać skali, w przypadku, gdy pody nie mogą być przenoszone, na przykład w następujących sytuacjach:
  • Bezpośrednio utworzony zasobnik nie jest wspierany przez obiekt kontrolera, taki jak Deployment lub ReplicaSet.
  • Budżet zaburzenia poda (PDB), który jest zbyt restrykcyjny i nie pozwala na spadek liczby podów poniżej określonego progu.
  • Zasobnik używa selektorów węzłów lub anty-koligacji, których nie można przestrzegać, jeśli jest to zaplanowane w innym węźle. Aby uzyskać więcej informacji, zobacz What types of pods can prevent the cluster autoscaler from removing a node? (Jakie typy zasobników mogą uniemożliwić automatyczne skalowanie klastra przed usunięciem węzła?).

Ważne

Nie wprowadzaj zmian w poszczególnych węzłach w pulach węzłów skalowanych automatycznie. Wszystkie węzły w tej samej grupie węzłów powinny mieć jednolitą pojemność, etykiety, tainty i pody systemowe działające na nich.

• Narzędzie do automatycznego skalowania klastra nie jest odpowiedzialne za wymuszanie "maksymalnej liczby węzłów" w puli węzłów klastra niezależnie od kwestii związanych z planowaniem podów. Jeśli jakikolwiek aktor niezwiązany z automatycznym skalowaniem klastra ustawia liczbę pul węzłów na wartość przekraczającą skonfigurowane maksimum dla automatycznego skalowania klastra, autoskalowanie klastra nie usuwa automatycznie węzłów. Zachowanie skalowania automatycznego klastra w dół pozostaje ograniczone do usuwania nie w pełni wykorzystanych węzłów. Jedynym celem konfiguracji maksymalnej liczby węzłów w klastrze jest ustalenie górnej granicy dla operacji skalowania w górę. Nie ma to żadnego wpływu na zagadnienia dotyczące skalowania w dół.

Profil skalowania automatycznego klastra

Profil narzędzia do automatycznego skalowania klastra to zestaw parametrów, które kontrolują zachowanie narzędzia do automatycznego skalowania klastra. Profil automatycznego skalowania klastra można skonfigurować podczas tworzenia klastra lub aktualizowania istniejącego klastra.

Optymalizowanie profilu skalowania automatycznego klastra

Ustawienia profilu automatycznego skalowania klastra należy dostosować zgodnie z konkretnymi scenariuszami obciążenia, a jednocześnie rozważyć kompromisy między wydajnością a kosztami. Ta sekcja zawiera przykłady, które pokazują te kompromisy.

Należy pamiętać, że ustawienia profilu automatycznego skalowania klastra są stosowane na poziomie całego klastra i dotyczą wszystkich pul węzłów z włączoną funkcją automatycznego skalowania. Wszelkie akcje skalowania, które mają miejsce w jednej puli węzłów, mogą mieć wpływ na zachowanie skalowania automatycznego innych pul węzłów, co może prowadzić do nieoczekiwanych wyników. Upewnij się, że stosujesz spójne i zsynchronizowane konfiguracje profilów we wszystkich odpowiednich pulach węzłów, aby upewnić się, że uzyskasz żądane wyniki.

Przykład 1. Optymalizowanie pod kątem wydajności

W przypadku klastrów obsługujących znaczne i zwiększone obciążenia z głównym naciskiem na wydajność zalecamy zwiększenie scan-interval i zmniejszenie wartości scale-down-utilization-threshold. Te ustawienia pozwalają połączyć wiele operacji skalowania w jedno wywołanie, optymalizując czas skalowania i wykorzystanie przydziałów odczytu/zapisu jednostek obliczeniowych. Pomaga również ograniczyć ryzyko szybkiego skalowania operacji w dół na nie w pełni wykorzystanych węzłach, zwiększając wydajność planowania zasobników. Ponadto zwiększ wartość ok-total-unready-counti max-total-unready-percentage.

W przypadku klastrów z zasobnikami demononset zalecamy ustawienie wartości ignore-daemonsets-utilizationtrue, co skutecznie ignoruje wykorzystanie węzłów przez zasobniki demononset i minimalizuje niepotrzebne operacje skalowania w dół. Zobacz profil dla obciążeń wybuchowych

Przykład 2. Optymalizowanie pod kątem kosztów

Jeśli chcesz mieć profil zoptymalizowany pod kątem kosztów, zalecamy ustawienie następujących konfiguracji parametrów:

• Zmniejsz scale-down-unneeded-time wartość, która określa czas, przez jaki węzeł powinien być niepotrzebny, zanim zakwalifikuje się do skalowania w dół.
• Zmniejsz wartość scale-down-delay-after-add, czyli czas oczekiwania po dodaniu węzła przed rozważeniem go pod kątem skalowania w dół.
• Zwiększ scale-down-utilization-threshold, który jest progiem wykorzystania do usuwania węzłów.
• Zwiększ max-empty-bulk-delete, maksymalną liczbę węzłów, które można usunąć w jednym wywołaniu.
• Ustaw skip-nodes-with-local-storage wartość false.
• Zwiększ ok-total-unready-count i max-total-unready-percentage.

Typowe problemy i zalecenia dotyczące ograniczania ryzyka

Wyświetlaj niepowodzenia skalowania oraz zdarzenia, które nie zostały zapoczątkowane, za pomocą interfejsu wiersza polecenia lub portalu.

Nie uruchamianie operacji skalowania w górę

Typowe przyczyny	Zalecenia dotyczące ograniczania ryzyka
Konflikty koligacji węzłów PersistentVolume, które mogą wystąpić podczas korzystania z automatycznego skalera klastra w środowisku z wieloma strefami dostępności, lub gdy strefa zasobnika lub trwałego woluminu różni się od strefy węzła.	Użyj jednej puli węzłów na strefę dostępności i włącz --balance-similar-node-groups. Można również ustawić volumeBindingMode pole na WaitForFirstConsumer w specyfikacji podu, aby zapobiec powiązaniu woluminu z węzłem do momentu utworzenia podu przy użyciu woluminu.
Taints i Tolerations/Konflikty koligacji węzła	Oceń zabrudzenia przypisane do węzłów i przejrzyj tolerancje zdefiniowane w podach. W razie potrzeby wprowadź zmiany w zanieczyszczeniach i tolerancjach, aby upewnić się, że pody mogą być efektywnie zaplanowane na węzłach.

Niepowodzenia operacji skalowania w górę

Typowe przyczyny	Zalecenia dotyczące ograniczania ryzyka
Wyczerpanie adresów IP w podsieci	Dodaj kolejną podsieć w tej samej sieci wirtualnej i dodaj kolejną pulę węzłów do nowej podsieci.
Wyczerpanie limitu przydziału rdzeni	Zatwierdzony limit przydziału rdzeni został wyczerpany. Zażądaj zwiększenia limitu przydziału. Narzędzie do automatycznego skalowania klastra wprowadza stan wycofywania wykładniczego w ramach określonej grupy węzłów, gdy wystąpi wiele nieudanych prób skalowania w górę.
Maksymalny rozmiar puli węzłów	Zwiększ maksymalną liczbę węzłów w puli węzłów lub utwórz nową pulę węzłów.
Żądania/wywołania przekraczają limit szybkości	Zobacz błędy 429 Zbyt wiele żądań.

Niepowodzenia operacji zmniejszania skali

Typowe przyczyny	Zalecenia dotyczące ograniczania ryzyka
Pod blokujący opróżnianie węzła/Nie można usunąć poda	• Wyświetl typy zasobników, które mogą zapobiegać skalowaniu w dół. • W przypadku zasobników korzystających z magazynu lokalnego, takiego jak hostPath i emptyDir, ustaw flagę profilu automatycznego skalowania klastra na skip-nodes-with-local-storagefalse. • W specyfikacji poda ustaw adnotację cluster-autoscaler.kubernetes.io/safe-to-evict na true. • Sprawdź plik PDB, ponieważ może być restrykcyjny.
Minimalny rozmiar puli węzłów	Zmniejsz minimalny rozmiar puli węzłów.
Żądania/wywołania przekraczają limit szybkości	Zobacz błędy 429 Zbyt wiele żądań.
Zablokowane operacje zapisu	Nie wprowadzaj żadnych zmian w w pełni zarządzanej grupie zasobów usługi AKS (zobacz zasady pomocy technicznej usługi AKS). Usuń lub zresetuj wszystkie blokady zasobów, które zostały wcześniej zastosowane do grupy zasobów.

Inne problemy

Typowe przyczyny	Zalecenia dotyczące ograniczania ryzyka
GrupaNiezgodnaZMapąKonfiguracjiPriorytetów	Upewnij się, że wszystkie grupy węzłów wymagające automatycznego skalowania zostaną dodane do pliku konfiguracyjnego ekspandera.

Pula węzłów w wycofywaniu

Pula węzłów w trybie odstąpienia została wprowadzona w wersji 0.6.2 i powoduje, że narzędzie Cluster Autoscaler odstępuje od skalowania puli węzłów po awarii.

W zależności od tego, jak długo występują błędy operacji skalowania, wykonanie kolejnej próby może potrwać do 30 minut. Stan wycofywania puli węzłów można zresetować, wyłączając i ponownie włączając skalowanie automatyczne.