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

  • Artykuł

Uwaga

Ten artykuł koncentruje się na ogólnych najlepszych rozwiązaniach dotyczących dużych obciążeń. Aby uzyskać najlepsze rozwiązania specyficzne dla małych i średnich obciążeń, zobacz Performance and scaling best practices for small to medium workloads in Azure Kubernetes Service (AKS) (Najlepsze rozwiązania dotyczące wydajności i skalowania dla małych i średnich obciążeń w usłudze Azure Kubernetes Service ).

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.

Należy pamiętać, że duży jest względnym terminem. Platforma Kubernetes ma kopertę skalowania wielowymiarowego, a koperta skalowania obciążenia zależy od używanych zasobów. Na przykład klaster z 100 węzłami i tysiącami zasobników lub crD może być uważany za duży. Klaster 1000 węzłów z 1000 zasobnikami i różnymi innymi zasobami może być uważany za mały z perspektywy płaszczyzny sterowania. Najlepszym sygnałem skalowania płaszczyzny sterowania kubernetes jest szybkość i opóźnienie żądań HTTP serwera interfejsu API, ponieważ jest to serwer proxy dla ilości obciążenia na płaszczyźnie sterowania.

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

  • Skalowalność płaszczyzny sterowania AKS i Kubernetes.
  • Najlepsze rozwiązania dotyczące klienta Kubernetes, w tym wycofywanie, zegarki i stronicowanie.
  • Limity ograniczania przepustowości interfejsu API i platformy platformy Azure.
  • Ograniczenia funkcji.
  • Najlepsze rozwiązania dotyczące skalowania sieci i puli węzłów.

Skalowalność płaszczyzny sterowania usług AKS i Kubernetes

W usłudze AKS klaster składa się z zestawu węzłów (maszyn fizycznych lub wirtualnych), które uruchamiają agentów platformy Kubernetes i są zarządzane przez płaszczyznę sterowania Kubernetes hostowaną przez usługę AKS. Usługa AKS optymalizuje płaszczyznę sterowania platformy Kubernetes i jej składniki pod kątem skalowalności i wydajności, ale nadal jest powiązana z limitami projektu nadrzędnego.

Platforma Kubernetes ma wielowymiarową kopertę skali z każdym typem zasobu reprezentującym wymiar. Nie wszystkie zasoby są podobne. Na przykład zegarki są często ustawiane na wpisach tajnych, co powoduje wywołania listy do serwera kube-apiserver, które dodają koszt i nieproporcjonalnie wyższe obciążenie płaszczyzny sterowania w porównaniu z zasobami bez zegarków.

Płaszczyzna sterowania zarządza wszystkimi skalowaniami zasobów w klastrze, dzięki czemu im więcej skalujesz klaster w danym wymiarze, tym mniej można skalować w innych wymiarach. Na przykład uruchamianie setek tysięcy zasobników w klastrze AKS wpływa na to, ile współczynnik zmian zasobników (mutacje zasobników na sekundę) może obsługiwać płaszczyzna sterowania.

Rozmiar koperty jest proporcjonalny do rozmiaru płaszczyzny sterowania Kubernetes. Usługa AKS obsługuje trzy warstwy płaszczyzny sterowania w ramach jednostki SKU Podstawowej: Bezpłatna, Standardowa i Premium. Aby uzyskać więcej informacji, zobacz Warstwy cenowe Bezpłatna, Standardowa i Premium na potrzeby zarządzania klastrem usługi AKS.

Ważne

Zdecydowanie zalecamy używanie warstwy Standardowa lub Premium dla obciążeń produkcyjnych lub na dużą skalę. Usługa AKS automatycznie skaluje w górę płaszczyznę sterowania platformy Kubernetes w celu obsługi następujących limitów skalowania:

  • Do 5000 węzłów na klaster usługi AKS
  • 200 000 zasobników na klaster usługi AKS (z nakładką usługi Azure CNI)

W większości przypadków przekroczenie progu limitu skalowania powoduje obniżenie wydajności, ale nie powoduje natychmiastowego przełączenie klastra w tryb failover. Aby zarządzać obciążeniem na płaszczyźnie sterowania platformy Kubernetes, rozważ skalowanie w partiach do 10–20% bieżącej skali. Na przykład w przypadku klastra 5000 węzłów skaluj w przyrostach 500–1000 węzłów. Usługa AKS automatycznie skaluje płaszczyznę sterowania, ale nie jest wykonywana natychmiast.

Możesz użyć priorytetu interfejsu API i sprawiedliwości (APF), aby ograniczyć określonych klientów i typy żądań w celu ochrony płaszczyzny sterowania podczas wysokiego współczynnika zmian i obciążenia.

Klienci kubernetes

Klienci kubernetes to klienci aplikacji, tacy jak operatorzy lub agenci monitorowania, wdrożony w klastrze Kubernetes, którzy muszą komunikować się z serwerem kube-api w celu wykonywania operacji odczytu lubmutacji. Ważne jest, aby zoptymalizować zachowanie tych klientów, aby zminimalizować obciążenie dodawane do serwera kube-api i płaszczyzny sterowania Kubernetes.

Możesz analizować ruch serwera interfejsu API i zachowanie klienta za pomocą dzienników inspekcji platformy Kube. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z płaszczyzną sterowania platformy Kubernetes.

Żądania LIST mogą być kosztowne. Podczas pracy z listami, które mogą zawierać więcej niż kilka tysięcy małych obiektów lub więcej niż kilkaset dużych obiektów, należy wziąć pod uwagę następujące wskazówki:

  • Podczas definiowania nowego typu zasobu (CRD) należy wziąć pod uwagę liczbę obiektów, które mają ostatecznie istnieć .
  • Obciążenie serwera etcd i interfejsu API opiera się głównie na liczbie obiektów, które istnieją, a nie na liczbie zwracanych obiektów. Nawet jeśli używasz selektora pól do filtrowania listy i pobierania tylko niewielkiej liczby wyników, te wytyczne nadal mają zastosowanie. Jedynym wyjątkiem jest pobieranie pojedynczego obiektu przez metadata.name.
  • Unikaj powtarzających się wywołań LIST, jeśli jest to możliwe , jeśli kod musi zachować zaktualizowaną listę obiektów w pamięci. Zamiast tego rozważ użycie klas informera dostępnych w większości bibliotek Kubernetes. Informatory automatycznie łączą funkcje LIST i WATCH, aby efektywnie obsługiwać kolekcję w pamięci.
  • Zastanów się, czy potrzebujesz silnej spójności , jeśli informatory nie spełniają Twoich potrzeb. Czy musisz zobaczyć najnowsze dane, aż do dokładnego momentu wystawienia zapytania? Jeśli nie, ustaw wartość ResourceVersion=0. Powoduje to, że pamięć podręczna serwera interfejsu API obsługuje żądanie zamiast itp.
  • Jeśli nie możesz używać informatorów ani pamięci podręcznej serwera interfejsu API, odczytaj duże listy we fragmentach.
  • Unikaj wyświetlania listy częściej niż jest to konieczne. Jeśli nie możesz używać informatorów, rozważ, jak często aplikacja wyświetla listę zasobów. Po przeczytaniu ostatniego obiektu na dużej liście nie wykonuj natychmiast ponownego wykonywania zapytań o tę samą listę. Zamiast tego należy czekać.
  • Rozważ liczbę uruchomionych wystąpień aplikacji klienckiej. Istnieje duża różnica między tym, że pojedynczy kontroler wyświetla obiekty, a zasobniki na każdym węźle robią to samo. Jeśli planujesz okresowe wyświetlanie wielu wystąpień aplikacji klienckiej z dużą liczbą obiektów, rozwiązanie nie będzie skalowane do dużych klastrów.

Ograniczanie interfejsu API i platformy platformy platformy azure

Obciążenie aplikacji w chmurze może się różnić w czasie na podstawie czynników, takich jak liczba aktywnych użytkowników lub typy akcji, które wykonują użytkownicy. Jeśli wymagania dotyczące przetwarzania systemu przekraczają pojemność dostępnych zasobów, system może zostać przeciążony i cierpi na niską wydajność i awarie.

Aby obsłużyć różne rozmiary obciążenia w aplikacji w chmurze, możesz zezwolić aplikacji na używanie zasobów do określonego limitu, a następnie ograniczać je po osiągnięciu limitu. Na platformie Azure ograniczanie odbywa się na dwóch poziomach. Usługa Azure Resource Manager (ARM) ogranicza żądania dotyczące subskrypcji i dzierżawy. Jeśli żądanie jest w ramach limitów ograniczania dla subskrypcji i dzierżawy, usługa ARM kieruje żądanie do dostawcy zasobów. Następnie dostawca zasobów stosuje limity ograniczania przepustowości dostosowane do jego operacji. Aby uzyskać więcej informacji, zobacz Żądania ograniczania przepustowości usługi ARM.

Zarządzanie ograniczaniem przepustowości w usłudze AKS

Limity interfejsu API platformy Azure są zwykle definiowane na poziomie kombinacji regionów subskrypcji. Na przykład wszyscy klienci w ramach subskrypcji w danym regionie współużytkują limity interfejsu API dla danego interfejsu API platformy Azure, takie jak interfejsy API PUT zestawów skalowania maszyn wirtualnych. Każdy klaster usługi AKS ma kilku klientów należących do usługi AKS, takich jak dostawca usług w chmurze lub narzędzie do automatycznego skalowania klastra lub klientów należących do klienta, takich jak Datadog lub self-hosted Prometheus, które wywołuje interfejsy API platformy Azure. W przypadku uruchamiania wielu klastrów usługi AKS w ramach subskrypcji w danym regionie wszystkie klientów należących do usługi AKS i klientów w klastrach mają wspólny zestaw limitów interfejsu API. W związku z tym liczba klastrów, które można wdrożyć w regionie subskrypcji, jest funkcją liczby wdrożonych klientów, ich wzorców wywołań oraz ogólnej skali i elastyczności klastrów.

Mając na uwadze powyższe zagadnienia, klienci zazwyczaj mogą wdrażać między 20–40 małych i średnich klastrów na średnią skalę na region subskrypcji. Skalowanie subskrypcji można zmaksymalizować, korzystając z następujących najlepszych rozwiązań:

Zawsze uaktualnij klastry Kubernetes do najnowszej wersji. Nowsze wersje zawierają wiele ulepszeń, które dotyczą problemów z wydajnością i ograniczaniem przepustowości. Jeśli używasz uaktualnionej wersji platformy Kubernetes i nadal widzisz ograniczanie przepustowości spowodowane rzeczywistym obciążeniem lub liczbą klientów w subskrypcji, możesz wypróbować następujące opcje:

  • Analizowanie błędów przy użyciu usługi AKS Diagnozowanie i rozwiązywanie problemów: możesz użyć usługi AKS Diagnozowanie i rozwiązywanie problemów w celu analizowania błędów, tożsamości głównej przyczyny i uzyskiwania zaleceń dotyczących rozwiązywania problemów.
    • Zwiększ interwał skanowania automatycznego skalowania klastra: jeśli raporty diagnostyczne pokazują, że wykryto ograniczanie skalowania automatycznego klastra, możesz zwiększyć interwał skanowania, aby zmniejszyć liczbę wywołań do zestawów skalowania maszyn wirtualnych z narzędzia skalowania automatycznego klastra.
    • Skonfiguruj ponownie aplikacje innych firm, aby wykonywać mniej wywołań: w przypadku filtrowania według agentów użytkowników w diagnostyce Wyświetl częstotliwość żądań i ograniczanie szczegółów oraz sprawdzenie, czy aplikacja innej firmy, taka jak aplikacja monitorowania, wykonuje dużą liczbę żądań GET, możesz zmienić ustawienia tych aplikacji, aby zmniejszyć częstotliwość wywołań GET. Upewnij się, że klienci aplikacji używają wycofywania wykładniczego podczas wywoływania interfejsów API platformy Azure.
  • Podziel klastry na różne subskrypcje lub regiony: jeśli masz dużą liczbę klastrów i pul węzłów korzystających z zestawów skalowania maszyn wirtualnych, możesz podzielić je na różne subskrypcje lub regiony w ramach tej samej subskrypcji. Większość limitów interfejsu API platformy Azure jest współużytkowana na poziomie regionu subskrypcji, dzięki czemu można przenosić lub skalować klastry do różnych subskrypcji lub regionów, aby odblokować ograniczanie interfejsu API platformy Azure. Ta opcja jest szczególnie przydatna, jeśli oczekujesz, że klastry będą miały wysoką aktywność. Nie ma ogólnych wytycznych dotyczących tych limitów. Jeśli potrzebujesz konkretnych wskazówek, możesz utworzyć bilet pomocy technicznej.

Ograniczenia funkcji

Podczas skalowania klastrów usługi AKS do większych punktów skalowania należy pamiętać o następujących ograniczeniach funkcji:

Uwaga

Podczas operacji skalowania płaszczyzny sterowania może wystąpić zwiększone opóźnienie serwera interfejsu API lub przekroczenie limitu czasu przez maksymalnie 15 minut. Jeśli nadal występują problemy ze skalowaniem do obsługiwanego limitu , otwórz bilet pomocy technicznej.

  • Menedżer usługi Azure Network Policy Manager (Azure npm) obsługuje tylko maksymalnie 250 węzłów.
  • Niektóre metryki węzłów usługi AKS, w tym użycie dysku węzła, użycie procesora CPU/pamięci węzła i sieć w poziomie, nie będą dostępne w metrykach platformy azure monitor po przeskalowanym poziomie płaszczyzny sterowania w górę. Aby sprawdzić, czy płaszczyzna sterowania została przeskalowana w górę, poszukaj mapy konfiguracji "control-plane-scaling-status"
kubectl describe configmap control-plane-scaling-status -n kube-system
  • Nie można używać funkcji Zatrzymywanie i uruchamianie z klastrami, które mają więcej niż 100 węzłów. Aby uzyskać więcej informacji, zobacz Zatrzymywanie i uruchamianie klastra usługi AKS.

Sieć

Podczas skalowania klastrów usługi AKS do większych punktów skalowania należy pamiętać o następujących najlepszych rozwiązaniach sieciowych:

Skalowanie puli węzłów

Podczas skalowania klastrów usługi AKS do większych punktów skalowania należy pamiętać o następujących najlepszych rozwiązaniach dotyczących skalowania puli węzłów:

  • W przypadku pul węzłów systemowych użyj jednostki SKU Standard_D16ds_v5 lub równoważnej jednostki SKU maszyny wirtualnej z efemerycznych dysków systemu operacyjnego, aby zapewnić wystarczające zasoby obliczeniowe dla zasobników kube-system.
  • Ponieważ usługa AKS ma limit 1000 węzłów na pulę węzłów, zalecamy utworzenie co najmniej pięciu pul węzłów użytkownika w celu skalowania do 5000 węzłów.
  • W przypadku uruchamiania klastrów usługi AKS na dużą skalę użyj narzędzia do automatycznego skalowania klastra zawsze, gdy jest to możliwe, aby zapewnić dynamiczne skalowanie pul węzłów na podstawie zapotrzebowania na zasoby obliczeniowe. Aby uzyskać więcej informacji, zobacz Automatyczne skalowanie klastra usługi AKS w celu spełnienia wymagań aplikacji.
  • Jeśli skalowanie przekracza 1000 węzłów i nie korzystasz z narzędzia do automatycznego skalowania klastra, zalecamy skalowanie w partiach 500–700 węzłów jednocześnie. Operacje skalowania powinny mieć od dwóch minut do pięciu minut między operacjami skalowania w górę, aby zapobiec ograniczaniu przepustowości interfejsu API platformy Azure. Aby uzyskać więcej informacji, zobacz USŁUGA API Management: Buforowanie i zasady ograniczania przepustowości.

Zagadnienia i najlepsze rozwiązania dotyczące uaktualniania klastra

  • Gdy klaster osiągnie limit 5000 węzłów, uaktualnienia klastra są blokowane. Te limity uniemożliwiają uaktualnienie, ponieważ nie ma dostępnej pojemności węzła do wykonywania aktualizacji stopniowego w ramach limitu właściwości maksymalnego wzrostu. Jeśli masz klaster w tym limicie, zalecamy skalowanie klastra w dół poniżej 3000 węzłów przed podjęciem próby uaktualnienia klastra. Zapewni to dodatkową pojemność dla współczynnika zmian węzłów i zminimalizowania obciążenia na płaszczyźnie sterowania.
  • Podczas uaktualniania klastrów z ponad 500 węzłami zaleca się użycie konfiguracji maksymalnej liczby skoków wynoszącej 10–20% pojemności puli węzłów. Usługa AKS konfiguruje uaktualnienia z wartością domyślną 10% dla maksymalnego wzrostu. Ustawienia maksymalnego wzrostu dla puli węzłów można dostosować, aby umożliwić kompromis między szybkością uaktualniania a zakłóceniami obciążenia. Po zwiększeniu ustawień maksymalnego wzrostu proces uaktualniania zostanie ukończony szybciej, ale może wystąpić zakłócenia w procesie uaktualniania. Aby uzyskać więcej informacji, zobacz Dostosowywanie uaktualniania skoków węzłów.
  • Aby uzyskać więcej informacji na temat uaktualniania klastra, zobacz Uaktualnianie klastra usługi AKS.