Najlepsze rozwiązania dotyczące wydajności i skalowania dla małych i średnich obciążeń w usłudze Azure Kubernetes Service (AKS)

Podczas wdrażania i obsługi klastrów w usłudze AKS można użyć następujących najlepszych rozwiązań, aby ułatwić optymalizację wydajności i skalowania.

Z tego artykułu dowiesz się więcej o:

Skalowanie automatyczne aplikacji a skalowanie automatyczne infrastruktury

Skalowanie automatyczne aplikacji

Skalowanie automatyczne aplikacji jest przydatne podczas pracy z optymalizacją kosztów lub ograniczeniami infrastruktury. Dobrze skonfigurowany autoskalator utrzymuje wysoką dostępność aplikacji, jednocześnie minimalizując koszty. Płacisz tylko za zasoby wymagane do utrzymania dostępności, niezależnie od zapotrzebowania.

Jeśli na przykład istniejący węzeł ma miejsce, ale nie ma wystarczającej liczby adresów IP w podsieci, może być w stanie pominąć tworzenie nowego węzła i zamiast tego natychmiast uruchomić aplikację na nowym zasobniku.

Automatyczne poziome skalowanie Podów

Implementowanie skalowania automatycznego zasobników w poziomie jest przydatne w przypadku aplikacji ze stałym i przewidywalnym zapotrzebowaniem na zasoby. Narzędzie Horizontal Pod Autoscaler (HPA) dynamicznie skaluje liczbę replik zasobników, co skutecznie rozkłada obciążenie na wiele zasobników i węzłów. Ten mechanizm skalowania jest zazwyczaj najbardziej korzystny w przypadku aplikacji, które mogą być rozłożone na mniejsze, niezależne składniki, które mogą działać równolegle.

Narzędzie HPA domyślnie udostępnia metryki wykorzystania zasobów. Możesz również zintegrować metryki niestandardowe lub korzystać z narzędzi, takich jak rozwiązanie Kubernetes Event-Driven Autoscaler (KEDA) (wersja zapoznawcza). Te rozszerzenia umożliwiają hpa podejmowanie decyzji dotyczących skalowania na podstawie wielu perspektyw i kryteriów, zapewniając bardziej całościowy widok wydajności aplikacji. Jest to szczególnie przydatne w przypadku aplikacji o różnych złożonych wymaganiach dotyczących skalowania.

Automatyczne skalowanie pionowe Podów

Wdrożenie automatycznego skalowania zasobników w pionie jest przydatne w przypadku aplikacji z dynamicznymi i nieprzewidywalnymi wymaganiami dotyczącymi zasobów. Narzędzie Do automatycznego skalowania zasobników pionowych (VPA) umożliwia precyzyjne dostosowywanie żądań zasobów, w tym procesora CPU i pamięci, dla poszczególnych zasobników, co umożliwia dokładną kontrolę nad alokacją zasobów. Ten stopień szczegółowości minimalizuje straty zasobów i zwiększa ogólną wydajność wykorzystania klastra. VPA też usprawnia zarządzanie aplikacjami, automatyzując alokację zasobów, dzięki czemu zasoby są dostępne dla krytycznych zadań.

Skalowanie automatyczne infrastruktury

Skalowanie automatyczne klastra

Implementowanie skalowania automatycznego klastra jest przydatne, jeśli istniejące węzły nie mają wystarczającej pojemności, ponieważ ułatwia skalowanie w górę i aprowizowanie nowych węzłów.

Rozważając skalowanie automatyczne klastra, decyzja o tym, kiedy usunąć węzeł, wiąże się z kompromisem między optymalizacją wykorzystania zasobów a zapewnieniem dostępności zasobów. Wyeliminowanie nie w pełni używanych węzłów zwiększa wykorzystanie klastra, ale może spowodować, że nowe obciążenia muszą czekać na aprowizację zasobów przed ich wdrożeniem. Ważne jest, aby znaleźć równowagę między tymi dwoma czynnikami, które są zgodne z wymaganiami klastra i obciążenia i odpowiednio skonfigurować ustawienia profilu skalowania automatycznego klastra.

Ustawienia profilu automatycznego skalowania klastra są stosowane uniwersalnie do wszystkich pul węzłów z obsługą skalowania automatycznego w klastrze. Oznacza to, że wszelkie akcje skalowania występujące w jednej puli węzłów z obsługą skalowania automatycznego mogą mieć wpływ na zachowanie skalowania automatycznego w innej puli węzłów. Ważne jest, aby zastosować spójne i zsynchronizowane ustawienia profilu we wszystkich odpowiednich pulach węzłów, aby upewnić się, że narzędzie do automatycznego skalowania działa zgodnie z oczekiwaniami.

Overprovisioning

Nadmierne przydzielanie zasobów to strategia, która pomaga ograniczyć ryzyko nacisku aplikacji, zapewniając nadmiar łatwo dostępnych zasobów. Takie podejście jest szczególnie przydatne w przypadku aplikacji, które mają bardzo zmienne obciążenia i wzorce skalowania klastrów, które pokazują częste skalowanie w górę i skalowanie w dół.

Aby określić optymalną ilość nadmiernej aprowizacji, możesz użyć następującej formuły:

1-buffer/1+traffic

** Załóżmy, że chcesz uniknąć osiągnięcia 100% wykorzystania CPU w klastrze. Możesz wybrać bufor 30%, aby zachować margines bezpieczeństwa. Jeśli przewidujesz średni współczynnik wzrostu ruchu wynoszący 40%, możesz rozważyć przablekwrowanie o 50%, obliczone przy pomocy formuły:

1-30%/1+40%=50%

Efektywna metoda nadmiarowej aprowizacji obejmuje użycie pause pods. Zasobniki pauz to wdrożenia o niskim priorytecie, które można łatwo zastąpić wdrożeniami o wysokim priorytecie. Tworzy się pody o niskim priorytecie, które służą wyłącznie do rezerwowania przestrzeni bufora. Gdy zasobnik o wysokim priorytecie wymaga miejsca, zasobniki pauzy zostaną usunięte i przeplanowane na innym węźle lub nowym węźle, żeby pomieścić zasobnik o wysokim priorytecie.

Poniższy kod YAML przedstawia przykładowy manifest pauzy podu:

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi 

Skalowanie i wydajność węzłów

Wskazówki dotyczące najlepszych rozwiązań:

Uważnie monitoruj użycie zasobów i zasady planowania, aby zapewnić efektywne wykorzystanie węzłów.

Skalowanie węzłów umożliwia dynamiczne dostosowywanie liczby węzłów w klastrze na podstawie zapotrzebowania na obciążenia. Ważne jest, aby zrozumieć, że dodawanie większej liczby węzłów do klastra nie zawsze jest najlepszym rozwiązaniem do poprawy wydajności. Aby zapewnić optymalną wydajność, należy uważnie monitorować użycie zasobów i zasady planowania, aby zapewnić efektywne wykorzystanie węzłów.

Obrazy węzłów

Wskazówki dotyczące najlepszych rozwiązań:

Użyj najnowszej wersji obrazu węzła, aby upewnić się, że masz najnowsze poprawki zabezpieczeń i poprawki błędów.

Użycie najnowszej wersji obrazu węzła zapewnia najwyższą wydajność. Usługa AKS dostarcza ulepszenia wydajności w cotygodniowych wersjach obrazów. Najnowsze obrazy DaemonSet są buforowane na najnowszym obrazie VHD, co zapewnia mniejsze opóźnienia przy prowizjonowaniu węzłów i inicjalizacji. Spadek liczby aktualizacji może mieć negatywny wpływ na wydajność, dlatego ważne jest, aby uniknąć dużych przerw między wersjami.

Azure Linux

Host kontenera systemu Linux platformy Azure w usłudze AKS używa natywnego obrazu usługi AKS i udostępnia jedno miejsce do programowania w systemie Linux. Każdy pakiet jest kompilowany na podstawie źródła i weryfikowany, zapewniając, że usługi działają na sprawdzonych składnikach.

Azure Linux jest lekkie, zawiera tylko niezbędny zestaw pakietów do uruchamiania kontenerowych obciążeń roboczych. Zapewnia ograniczoną powierzchnię ataków i eliminuje stosowanie poprawek i konserwację niepotrzebnych pakietów. W warstwie podstawowej znajduje się jądro wzmocnione przez firmę Microsoft, dostosowane do optymalnej współpracy z platformą Azure. Ten obraz jest idealny dla obciążeń wrażliwych na wydajność i inżynierów platform i operatorów, którzy zarządzają flotami klastrów AKS.

Ubuntu 2204

Obraz Ubuntu 2204 jest domyślnym obrazem węzła dla usługi AKS. Jest to lekki i wydajny system operacyjny zoptymalizowany pod kątem uruchamiania konteneryzowanych obciążeń. Oznacza to, że może pomóc zmniejszyć użycie zasobów i zwiększyć ogólną wydajność. Obraz zawiera najnowsze poprawki zabezpieczeń i aktualizacje, które pomagają zapewnić ochronę obciążeń przed lukami w zabezpieczeniach.

Obraz ubuntu 2204 jest w pełni obsługiwany przez firmę Microsoft, Canonical i społeczność systemu Ubuntu oraz może pomóc w osiągnięciu lepszej wydajności i bezpieczeństwa dla konteneryzowanych obciążeń.

Maszyny wirtualne (VM)

Wskazówki dotyczące najlepszych rozwiązań:

Podczas wybierania maszyny wirtualnej upewnij się, że rozmiar i wydajność dysku systemu operacyjnego i jednostki SKU maszyny wirtualnej nie mają dużej rozbieżności. Rozbieżność rozmiaru lub wydajności może spowodować problemy z wydajnością i rywalizację o zasoby.

Wydajność aplikacji jest ściśle powiązana z jednostkami SKU maszyn wirtualnych używanymi w obciążeniach. Większe i bardziej wydajne maszyny wirtualne, ogólnie zapewniają lepszą wydajność. W przypadku obciążeń o znaczeniu krytycznym lub produktowym zalecamy używanie maszyn wirtualnych z co najmniej 8-rdzeniowym procesorem CPU. Maszyny wirtualne z nowszymi generacjami sprzętu, takimi jak v4 i v5, mogą również pomóc zwiększyć wydajność. Należy pamiętać, że opóźnienie tworzenia i skalowania może się różnić w zależności od używanych jednostek SKU maszyn wirtualnych.

Korzystanie z dedykowanych pul węzłów systemowych

W celu skalowania wydajności i niezawodności zalecamy użycie dedykowanej puli węzłów systemowych. Dzięki tej konfiguracji dedykowana pula węzłów systemu rezerwuje miejsce dla krytycznych zasobów systemowych, takich jak demony systemu operacyjnego. Obciążenie aplikacji może następnie działać w puli węzłów użytkownika, aby zwiększyć dostępność zasobów przydzielanych dla aplikacji. Ta konfiguracja pomaga również ograniczyć ryzyko konkurencji zasobów między systemem a aplikacją.

Tworzenie operacji

Przejrzyj rozszerzenia i dodatki, które zostały włączone podczas tworzenia aprowizacji. Rozszerzenia i dodatki mogą zwiększać opóźnienia w ogólnym czasie trwania operacji tworzenia. Jeśli nie potrzebujesz rozszerzenia lub dodatku, zalecamy usunięcie go w celu zwiększenia opóźnienia tworzenia.

Strefy dostępności umożliwiają również zapewnienie wyższego poziomu dostępności w celu ochrony przed potencjalnymi awariami sprzętowymi lub zdarzeniami planowanej konserwacji. Klastery usługi AKS dystrybuują zasoby w ramach logicznych sekcji podstawowej infrastruktury Azure. Strefy dostępności fizycznie oddzielają węzły od innych węzłów, aby zapewnić, że pojedynczy błąd nie ma wpływu na dostępność aplikacji. Strefy dostępności są dostępne tylko w niektórych regionach. Aby uzyskać więcej informacji, zobacz Strefy dostępności na platformie Azure.

Serwer interfejsu API usługi Kubernetes

Operacje LIST i WATCH

Platforma Kubernetes używa operacji LIST i WATCH do interakcji z serwerem interfejsu API Kubernetes i monitorowania informacji o zasobach klastra. Te operacje mają podstawowe znaczenie dla sposobu, w jaki platforma Kubernetes wykonuje zarządzanie zasobami.

Operacja LIST pobiera listę zasobów, które mieszczą się w określonych kryteriach, takich jak wszystkie zasobniki w określonej przestrzeni nazw lub wszystkich usługach w klastrze. Ta operacja jest przydatna, gdy chcesz zapoznać się z ogólnym przeglądem zasobów klastra lub operować na wielu zasobach jednocześnie.

Operacja LIST może pobierać duże ilości danych, szczególnie w dużych klastrach z wieloma zasobami. Należy pamiętać o tym, że wykonywanie nieograniczonych lub częstych wywołań LIST powoduje znaczne obciążenie serwera interfejsu API i może wydłużyć czasy odpowiedzi.

Operacja WATCH wykonuje monitorowanie zasobów w czasie rzeczywistym. Po skonfigurowaniu elementu WATCH w zasobie serwer interfejsu API wysyła aktualizacje za każdym razem, gdy wystąpią zmiany w tym zasobie. Jest to ważne w przypadku kontrolerów, takich jak kontroler ReplicaSet, który polega na funkcji WATCH do obsługi żądanego stanu zasobów.

Należy pamiętać o tym, że oglądanie zbyt wielu zasobów modyfikowalnych lub wykonywanie zbyt wielu współbieżnych żądań WATCH może przeciążyć serwer interfejsu API i spowodować nadmierne użycie zasobów.

Aby uniknąć potencjalnych problemów i zapewnić stabilność płaszczyzny sterowania platformy Kubernetes, możesz użyć następujących strategii:

Limity przydziałów zasobów

Zaimplementuj przydziały zasobów, aby ograniczyć liczbę zasobów, które mogą być wyświetlane lub obserwowane przez określonego użytkownika lub przestrzeń nazw, aby zapobiec nadmiernemu wywołaniu.

Priorytet i sprawiedliwość interfejsu API

Platforma Kubernetes wprowadziła koncepcję priorytetu interfejsu API i sprawiedliwości (APF), aby określić priorytety żądań interfejsu API i zarządzać nimi. Możesz użyć APF w Kubernetes, aby chronić serwer interfejsu API klastra i zmniejszyć liczbę odpowiedzi, które napotykają aplikacje klienckie.

Konfigurowanie interfejsu API przy użyciu parametrów PriorityLevelConfigurations i FlowSchemas umożliwia ustalanie priorytetów krytycznych żądań interfejsu API w przypadku mniej ważnych żądań. Dzięki temu kluczowe operacje nie będą cierpieć z powodu braku zasobów ani nie będą doświadczać opóźnień z powodu żądań o niższym priorytecie.

Optymalizowanie etykiet i selektorów

W przypadku korzystania z operacji LIST zoptymalizuj selektory etykiet, aby zawęzić zakres zasobów, które chcesz przeszukać, co zmniejszy ilość zwracanych danych i obciążenie serwera API.

W Kubernetes operacje TWORZENIA i AKTUALIZACJI odnoszą się do akcji, które zarządzają zasobami klastra oraz je modyfikują.

OPERACJE TWORZENIE i AKTUALIZACJA

Operacja CREATE tworzy nowe zasoby w klastrze Kubernetes, takie jak zasobniki, usługi, wdrożenia, mapy konfiguracji i wpisy tajne. Podczas operacji CREATE klient, taki jak kubectl lub kontroler, wysyła żądanie do serwera interfejsu API Kubernetes w celu utworzenia nowego zasobu. Serwer interfejsu API weryfikuje żądanie, zapewnia zgodność z dowolnymi zasadami kontrolera dostępu, a następnie tworzy zasób w żądanym stanie klastra.

Operacja UPDATE modyfikuje istniejące zasoby w klastrze Kubernetes, w tym zmiany specyfikacji zasobów, takie jak liczba replik, obrazy kontenerów, zmienne środowiskowe lub etykiety. Podczas operacji UPDATE klient wysyła żądanie do serwera interfejsu API w celu zaktualizowania istniejącego zasobu. Serwer interfejsu API weryfikuje żądanie, stosuje zmiany do definicji zasobu i aktualizuje zasób klastra.

Operacje CREATE i UPDATE mogą mieć wpływ na wydajność serwera interfejsu API Kubernetes w następujących warunkach:

• Wysoka współbieżność: gdy wielu użytkowników lub aplikacji tworzy współbieżne żądania CREATE lub UPDATE, może to prowadzić do wzrostu liczby żądań interfejsu API przychodzących na serwer w tym samym czasie. Może to obciążyć zdolność przetwarzania serwera interfejsu API i powodować problemy z wydajnością.
• Złożone definicje zasobów: definicje zasobów, które są nadmiernie złożone lub obejmują wiele zagnieżdżonych obiektów, mogą zwiększyć czas potrzebny serwerowi interfejsu API do weryfikowania i przetwarzania żądań CREATE i UPDATE, co może prowadzić do obniżenia wydajności.
• Sprawdzanie poprawności zasobów i kontroli dostępu: platforma Kubernetes wymusza różne zasady kontroli dostępu i sprawdzanie poprawności przychodzących żądań CREATE i UPDATE. Duże definicje zasobów, takie jak te z rozbudowanymi adnotacjami lub konfiguracjami, mogą wymagać więcej czasu przetwarzania.
• Kontrolery niestandardowe: kontrolery niestandardowe, które obserwują zmiany w zasobach, takich jak wdrożenia lub kontrolery StatefulSet, mogą generować znaczną liczbę aktualizacji podczas skalowania lub wprowadzania zmian. Te aktualizacje mogą obciążać zasoby serwera interfejsu API.

Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z serwerem API i etcd w AKS.

Wydajność płaszczyzny danych

Płaszczyzna danych Kubernetes jest odpowiedzialna za zarządzanie ruchem sieciowym między kontenerami a usługami. Problemy z płaszczyzną danych mogą prowadzić do powolnego czasu odpowiedzi, obniżonej wydajności i przestoju aplikacji. Ważne jest, aby uważnie monitorować i optymalizować konfiguracje płaszczyzny danych, takie jak opóźnienie sieci, alokacja zasobów, gęstość kontenerów i zasady sieci, aby zapewnić bezproblemowe i wydajne działanie konteneryzowanych aplikacji.

Typy magazynów

Usługa AKS zaleca i domyślnie używa efemerycznych dysków systemu operacyjnego. Efemeryczne dyski systemu operacyjnego są tworzone w lokalnym magazynie maszyny wirtualnej i, w przeciwieństwie do zarządzanych dysków systemu operacyjnego, nie są zapisywane w zdalnym magazynie Azure. Są one szybsze podczas odtwarzania obrazu systemu i mają krótsze czasy uruchamiania, co umożliwia szybsze operacje klastrów. Zapewniają także niższe opóźnienia odczytu i zapisu na dysku systemu operacyjnego węzłów agenta usługi AKS. Efemeryczne dyski systemu operacyjnego działają dobrze w przypadku obciążeń bezstanowych, w przypadku których aplikacje są odporne na awarie poszczególnych maszyn wirtualnych, ale nie czasu wdrożenia maszyny wirtualnej lub ponownego tworzenia poszczególnych wystąpień maszyn wirtualnych. Tylko niektóre jednostki SKU maszyn wirtualnych obsługują efemeryczne dyski systemu operacyjnego, dlatego należy upewnić się, że żądana generacja i rozmiar jednostki SKU są zgodne. Aby uzyskać więcej informacji, zobacz Efemeryczne dyski systemu operacyjnego w usłudze Azure Kubernetes Service (AKS).

Jeśli obciążenie nie może używać efemerycznych dysków systemu operacyjnego, usługa AKS domyślnie używa dysków systemu operacyjnego SSD w warstwie Premium. Jeśli dyski systemu operacyjnego Premium SSD nie są zgodne z obciążeniem, usługa AKS domyślnie korzysta z dysków Standard SSD. Obecnie jedynym innym dostępnym typem dysku systemu operacyjnego jest standardowy HDD. Aby uzyskać więcej informacji, zobacz Opcje magazynu w usłudze Azure Kubernetes Service (AKS).

Poniższa tabela zawiera podział sugerowanych przypadków użycia dla dysków systemu operacyjnego obsługiwanych w usłudze AKS:

Liczba operacji we/wy na sekundę i przepustowość

Operacje wejścia/wyjścia na sekundę (IOPS) odnoszą się do liczby operacji odczytu i zapisu, które dysk może wykonać w ciągu sekundy. Przepływność odnosi się do ilości danych, które można przesyłać w danym okresie.

Dyski systemu operacyjnego są odpowiedzialne za przechowywanie systemu operacyjnego i skojarzonych z nim plików, a maszyny wirtualne są odpowiedzialne za uruchamianie aplikacji. Podczas wybierania maszyny wirtualnej upewnij się, że rozmiar i wydajność dysku systemu operacyjnego i jednostki SKU maszyny wirtualnej nie mają dużej rozbieżności. Rozbieżność rozmiaru lub wydajności może spowodować problemy z wydajnością i rywalizację o zasoby. Jeśli na przykład dysk systemu operacyjnego jest znacznie mniejszy niż maszyny wirtualne, może ograniczyć ilość miejsca dostępnego dla danych aplikacji i spowodować, że system zabraknie miejsca na dysku. Jeśli dysk systemu operacyjnego ma niższą wydajność niż maszyny wirtualne, może stać się wąskim gardłem i ograniczyć ogólną wydajność systemu. Upewnij się, że rozmiar i wydajność są zrównoważone, aby zapewnić optymalną wydajność na platformie Kubernetes.

Poniższe kroki umożliwiają monitorowanie IOPS i mierników przepustowości na dyskach OS w Azure Portal.

1. Przejdź do Portalu Azure.
2. Wyszukaj Zestawy skalowania maszyn wirtualnych i wybierz swój zestaw skalowania maszyn wirtualnych.
3. W obszarze Monitorowanie wybierz pozycję Metryki.

Chwilowe dyski systemu operacyjnego mogą oferować dynamiczne IOPS i przepływność dla twojej aplikacji, natomiast dyski zarządzane mają ograniczone IOPS i przepływność. Aby uzyskać więcej informacji, zobacz Efemeryczny dysk systemu operacyjnego dla maszyn wirtualnych platformy Azure.

Usługa Azure Premium SSD w wersji 2 jest przeznaczona dla obciążeń intensywnie korzystających z operacji we/wy, które wymagają opóźnień dysku poniżej milisekundy oraz wysokiej liczby operacji we/wy (IOPS) i przepływności, przy niskich kosztach. Jest ona odpowiednia dla szerokiego zakresu obciążeń, takich jak SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, big data/analiza, gry i nie tylko. Ten typ dysku jest obecnie najlepszą opcją dostępną dla woluminów trwałych.

Planowanie Podów

Zasoby pamięci i procesora CPU przydzielone do maszyny wirtualnej mają bezpośredni wpływ na wydajność zasobników uruchomionych na maszynie wirtualnej. Po utworzeniu podu jest przypisywana pewna ilość pamięci i zasobów CPU, które są używane do uruchamiania aplikacji. Jeśli maszyna wirtualna nie ma wystarczającej ilości dostępnej pamięci lub zasobów procesora CPU, może to spowodować spowolnienie zasobników, a nawet awarię. Jeśli maszyna wirtualna ma za dużo dostępnej pamięci lub zasobów procesora, może to spowodować nieefektywne działanie zasobników, co prowadzi do marnowania zasobów i zwiększenia kosztów. Zalecamy monitorowanie łącznych żądań podów w ramach twoich obciążeń roboczych względem łącznych zasobów dostępnych do przydziału, aby zapewnić najlepszą przewidywalność i wydajność harmonogramowania. Można również ustawić maksymalne pody na węzeł w oparciu o planowanie pojemności przy użyciu --max-pods.