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

Uwaga

Ten artykuł koncentruje się na ogólnych najlepszych rozwiązaniach dotyczących dużych obciążeń. Aby uzyskać najlepsze praktyki specyficzne dla małych do średnich obciążeń, zobacz Najlepsze praktyki dotyczące wydajności i skalowania dla małych i średnich obciążeń w 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.

Należy pamiętać, że duży jest względnym terminem. Platforma Kubernetes ma zakres skalowania wielowymiarowego, a zakres skalowania dla twojego obciążenia zależy od zasobów, których używasz. Na przykład klaster ze 100 węzłami i tysiącami podó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 skali płaszczyzny sterowania Kubernetes jest szybkość i opóźnienie żądań HTTP serwera API, ponieważ odzwierciedla to poziom obciążenia na płaszczyźnie sterowania.

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

  • Skalowanie węzłów.
  • Skalowalność płaszczyzny sterowania AKS i Kubernetes.
  • Najlepsze praktyki dotyczące klienta Kubernetes, w tym odroczenie, obserwacje i stronicowanie.
  • Azure limity ograniczania przepustowości interfejsu API i platformy.
  • Ograniczenia funkcji.
  • Najlepsze rozwiązania dotyczące sieci.

Skalowanie 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 węzłów:

  • Podczas uruchamiania dużych klastrów AKS, używaj autoskalera klastra lub automatycznego zarządzania węzłami, kiedy tylko to możliwe, aby zapewnić dynamiczne skalowanie węzłów na podstawie zapotrzebowania na zasoby obliczeniowe.
  • 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 być przeprowadzane z dwu- do pięciominutowym odstępem pomiędzy kolejnymi skalowaniami w górę, aby zapobiec ograniczaniu interfejsu API Azure. Aby uzyskać więcej informacji, zobacz API Management: zasady buforowania i ograniczania przepustowości.
  • W przypadku pul węzłów systemowych użyj jednostki SKU Standard_D16ds_v5 lub równoważnej jednostki SKU maszyny wirtualnej z efemerycznymi dyskami systemu operacyjnego, aby zapewnić odpowiednie 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.

Skalowalność płaszczyzny kontrolnej AKS i Kubernetes

Na platformie Kubernetes wszystkie obiekty uruchomione w klastrze są zarządzane przez płaszczyznę sterowania zarządzaną 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 oferuje skalowanie wielowymiarowe, gdzie każdy typ zasobu reprezentuje wymiar, a nie wszystkie zasoby mają ten sam koszt. Na przykład Sekrety są często obserwowane przez wiele kontrolerów i podów, z których każde powoduje początkowe wywołanie LIST w celu zsynchronizowania stanu. Ponieważ sekrety są zwykle duże i często aktualizowane, nakładają większe obciążenie na płaszczyznę sterowania niż rzadziej obserwowane zasoby.

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, jak dużą szybkość zmian zasobników (mutacje zasobników na sekundę) może obsługiwać plan zarządzania.

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

Ważne

Użyj warstwy Standard lub Premium dla obciążeń produkcyjnych lub na skalę masową. Usługa AKS automatycznie skaluje w górę płaszczyznę sterowania platformy Kubernetes w celu obsługi następujących limitów skalowania:

  • Do 5 000 węzłów na klaster AKS
  • 200 000 podów na klaster usługi AKS (z nakładką 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 o 5000 węzłów, skaluj w przyrostach 500–1000 węzłów. AKS automatycznie skaluje płaszczyznę sterowania, ale nie odbywa się to natychmiastowo.

Aby sprawdzić, czy płaszczyzna sterowania została powiększona, poszukaj configmap large-cluster-control-plane-scaling-status.

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

Rozważania dotyczące zakresu skalowania i płaszczyzny sterowania Kubernetes

Klienci kubernetes to składniki aplikacji, takie jak operatory lub agenci monitorowania, które działają w klastrze i komunikują się z serwerem kube-apiserver w celu odczytu lub modyfikowania zasobów. Ważne jest, aby zoptymalizować zachowanie tych klientów w celu zmniejszenia obciążenia, które umieszczają na serwerze kube-apiserver i płaszczyźnie sterowania Kubernetes.

Liczba żądań aktywnie przetwarzanych przez serwer interfejsu API w danym momencie jest określana przez --max-requests-inflight i --max-mutating-requests-inflight flagi. Usługa AKS używa wartości domyślnych 400 i 200 żądań dla tych flag, co umożliwia wysłanie łącznie 600 żądań w danym momencie. W miarę skalowania serwera API zwiększamy również równoczesne żądania.

Dwa typy obiektów Kubernetes, PriorityLevelConfiguration i FlowSchema (APF) określają, jak serwer interfejsu API dzieli łączną pojemność żądań między typy żądań. Usługa AKS używa konfiguracji domyślnej.

Każda konfiguracja PriorityLevelConfiguration ma przypisany udział w całkowitej liczbie dozwolonych żądań. Aby wyświetlić obiekty PriorityLevelConfiguration w klastrze i ich przydzielone udziały żądań, uruchom następujące polecenie.

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

FlowSchema mapuje żądania do serwera API na PriorityLevelConfiguration. Jeśli wiele obiektów FlowSchema pasuje do żądania, serwer interfejsu API wybiera ten z najniższym zgodnym pierwszeństwem.

Mapowanie FlowSchemas do PriorityLevelConfigurations można wyświetlić używając tej komendy.

kubectl get flowschemas

Aby sprawdzić, czy jakiekolwiek żądania są odrzucane z powodu APF, uruchom następujące polecenie:

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Najlepsze rozwiązania dotyczące klienta Kubernetes

Wywołania LIST złożone przez niezoptymalizowanych klientów są często jednym z największych czynników ograniczających skalowalność klastra. 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 rozmiarze odpowiedzi. Te wskazówki dotyczą tego, czy klient wystawia niewielką liczbę żądań LIST dla dużych obiektów, czy dużą liczbę żądań LIST dla mniejszych obiektów.

Korzystanie z informatorów

  • Jeśli kod musi zachować zaktualizowaną listę obiektów w pamięci, użycie informatora z biblioteki client-go zapewni korzyści związane z obserwowaniem zmian w zasobach na podstawie zdarzeń zamiast sondowania pod kątem zmian. Jest to najlepsze podejście, aby uniknąć niezoptymalizowanych i powtarzających się list.

Korzystanie z pamięci podręcznej serwera interfejsu API

  • Użyj polecenia resourceVersion=0 , aby zwrócić wyniki z pamięci podręcznej serwera interfejsu API. Może to uniemożliwić pobieranie obiektów z etcd, zmniejszając obciążenie etcd, ale nie obsługuje stronicowania.

    /api/v1/namespaces/default/pods?resourceVersion=0

Wydajne użycie interfejsu API platformy Kubernetes

  • Zaleca się używanie argumentu "watch" zawsze, gdy jest to możliwe. Bez argumentów domyślne zachowanie polega na wyświetlaniu listy obiektów. Zapoznaj się z poniższym przykładem.

    /api/v1/namespaces/default/pods?watch=true

    Użyj zegarka z ustawieniem na najnowszą znaną wartość resourceVersion, otrzymaną z poprzedniej listy lub zegarka. Ta funkcja jest obsługiwana automatycznie w języku client-go. Sprawdź jednak, czy używasz klienta Kubernetes w innych językach.

    /api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>

  • Jeśli kontrolery lub operatory muszą używać wywołań LIST, należy unikać sondowania zasobów w całym klastrze bez selektorów etykiet lub pól, zwłaszcza w dużych klastrach. W poniższych przykładach przedstawiono zoptymalizowane i niezoptymalizowane wywołania LIST.

    Lista zoptymalizowana:

    /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running

    Niezoptymalizowana lista:

    /api/v1/pods

  • Użyj stronicowania , aby zmniejszyć rozmiar odpowiedzi LIST, jeśli klient musi pobrać dane z etcd. W poniższym przykładzie użyto argumentu limitu, aby ograniczyć odpowiedź do 100 obiektów.

    /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100

    Jeśli chcesz, aby lista kontynuowała zwracanie wszystkich obiektów zasobników w powyższym przykładzie, użyj argumentu continue z limitem.

    /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>

    Jeśli narzędzie kubectl jest używane, --chunk-size argument można zastosować bezpośrednio do stronicowania odpowiedzi.

    kubectl get pods -n default --chunk-size=100

  • Jeśli kontrolery lub operatorzy używają aktualizacji dzierżawy w wyborach liderów, upewnij się, że są odporne na przejściowe problemy z łącznością, dostrajając leaseDuration, renewDeadlinei retryPeriod które są optymalne dla obciążeń. W przypadku kontrolerów Kubernetes korzystających z wyboru lidera przez client-go użyj następującej formuły:

    lease_duration > renew_deadline > retry_period

Daemonsety

  • Istnieje znacząca różnica między pojedynczym kontrolerem wyświetlającym obiekty a DaemonSet uruchomionym na każdym węźle. Jeśli wiele wystąpień aplikacji klienckiej okresowo wyświetla dużą liczbę obiektów, rozwiązanie nie będzie skalować się dobrze w dużych klastrach.

  • W klastrach z tysiącami węzłów utworzenie nowego elementu DaemonSet, zaktualizowanie elementu DaemonSet lub zwiększenie liczby węzłów może spowodować duże obciążenie umieszczone na płaszczyźnie sterowania. Jeśli pody DaemonSet wysyłają kosztowne żądania do serwera API podczas uruchamiania, mogą powodować wysokie zużycie zasobów na płaszczyźnie sterowania z powodu dużej liczby równoczesnych żądań.

  • Użyj strategii RollingUpdate, aby stopniowo wdrażać nowe pody DaemonSet. Po zaktualizowaniu szablonu DaemonSet kontroler zastępuje stare zasobniki nowymi w kontrolowany sposób. Jeśli strategia aktualizacji stopniowej nie jest jawnie skonfigurowana, platforma Kubernetes będzie domyślnie tworzyć aktualizację RollingUpdate z wartością maxUnavailable jako 1, maxSurge jako 0 i minReadySeconds jako 0s. Zapoznaj się z poniższym przykładem.

      minReadySeconds: 30
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1

  • Strategia RollingUpdate ma zastosowanie tylko do istniejących zasobników DaemonSet. Nie ogranicza to wpływu dodawania nowych węzłów, co powoduje utworzenie dodatkowych podów DaemonSet, ani wdrożenia całkowicie nowych DaemonSetów.

  • Aby zapobiec równoczesnym żądaniom LIST do serwera API podczas uruchamiania po skalowaniu węzła lub wdrożeniach nowych DaemonSet, zaimplementuj opóźnienie startu w punkcie wejścia kontenera i skonfiguruj odpowiednie wykładnicze wycofywanie i polityki ponawiania prób dla odpowiedzi 5xx lub 429, aby zapobiec powtarzaniu dużych żądań LIST.

      spec:
    template:
      spec:
        containers:
        - name: my-daemonset-container
          image: <image>
          command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]

Uwaga

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.

optymalizacje etcd

  • Zachowaj rozmiar ogólny itpd mały i nie używaj etcd jako bazy danych ogólnego przeznaczenia. Usługa AKS domyślnie zapewnia 8 GB miejsca do magazynowania etcd, ale większe bazy danych etcd zwiększają czas defragmentacji, co może prowadzić do problemów z wydajnością odczytu i zapisu. Większe bazy danych etcd mogą również zwiększyć prawdopodobieństwo wystąpienia problemów z niezawodnością serwera API i etcd, jeśli niezoptymalizowany klient często pobiera dużą liczbę obiektów z etcd. Jeśli rozmiar bazy danych etcd przekracza 2 GB, rozważ użycie technik redukcji rozmiaru obiektu wymienionych poniżej.
  • Aby zmniejszyć rozmiary specyfikacji podu, przenieś zmienne środowiskowe ze specyfikacji podu do ConfigMap.
  • Podziel duże sekrety lub ConfigMapy na mniejsze, bardziej łatwe do zarządzania części.
  • Przechowuj tajne informacje w Azure Key Vault zamiast Kubernetes Secrets, gdy to możliwe, aby zmniejszyć liczbę tajnych informacji przechowywanych w etcd.
  • Czyszczenie nieużywanych obiektów
    • Usuń przestarzałe zadania (Jobs) i ukończone Pody. Użyj wartości ttlSecondsAfterFinished w obszarze Zadania, aby gotowe obiekty zostały usunięte automatycznie.
    • Upewnij się, że kontrolery ustawiają właściwość ownerReferences. Dzięki temu funkcja garbage collection w Kubernetes automatycznie usuwa zależne obiekty, gdy usuwany jest zasób nadrzędny.
    • Ogranicz historię CronJob, ustawiając wartość successfulJobsHistoryLimit i failedJobsHistoryLimit, aby zachować tylko niewielką liczbę ukończonych rekordów zadań.
    • Zmniejsz historię wdrożeń. Stare zestawy replik są również przechowywane jako obiekty interfejsu API. Wartość domyślna to 10.
  • Zmniejsz historię poprawek programu Helm za pomocą argumentu --history-max . W dużych klastrach zachowaj je poniżej 5.

Monitorowanie metryk i dzienników płaszczyzny sterowania AKS

Monitorowanie wskaźników płaszczyzny sterowania w dużych klastrach AKS jest kluczowe dla zapewnienia stabilności i wydajności obciążeń Kubernetes. Te metryki zapewniają wgląd w kondycję i zachowanie krytycznych składników, takich jak serwer API, etcd, menedżer kontrolera i harmonogram. W środowiskach na dużą skalę, w których często występują zmagania o zasoby i wysokie wolumeny wywołań API, monitorowanie metryk płaszczyzny sterowania pomaga identyfikować wąskie gardła, wykrywać anomalie i optymalizować użycie zasobów. Analizując te metryki, operatorzy mogą aktywnie rozwiązywać problemy, takie jak opóźnienie serwera interfejsu API, duża liczba obiektów etcd, czy nadmierne zużycie zasobów płaszczyzny sterowania, zapewniając wydajne działanie klastra i minimalizując przestoje.

Azure Monitor oferuje kompleksowe metryki i dzienniki dotyczące kondycji płaszczyzny sterowania za pośrednictwem Azure Managed Prometheus i diagnostyczne ustawienia.

Kluczowe metryki platformy płaszczyzny sterowania

Usługa AKS udostępnia następujące metryki platformy w Azure Monitor na potrzeby monitorowania serwera API i stanu etcd. Te metryki są dostępne bez włączania zarządzanego rozwiązania Prometheus i można je wyświetlić bezpośrednio w portalu Azure w obszarze Metrics dla klastra usługi AKS.

Metryki serwera API:

Wskaźnik Opis
apiserver_cpu_usage_percentage Maksymalny procent użycia CPU (na podstawie bieżącego limitu) używany przez zasobnik serwera API we wszystkich wystąpieniach.
apiserver_memory_usage_percentage Maksymalna wartość procentowa pamięci (na podstawie bieżącego limitu) używana przez pod serwera interfejsu API we wszystkich instancjach.
apiserver_current_inflight_requests (wersja zapoznawcza) Maksymalna liczba aktualnie aktywnych żądań w locie na serwerze interfejsu API dla każdego rodzaju żądania.

Metryki etcd:

Wskaźnik Opis
etcd_cpu_usage_percentage Maksymalny procentowy udział CPU (na podstawie aktualnego limitu) wykorzystywany przez zasobnik etcd w różnych instancjach.
etcd_memory_usage_percentage Maksymalny procent pamięci (na podstawie bieżącego limitu) używany przez pod etcd we wszystkich wystąpieniach.
etcd_database_usage_percentage Maksymalne wykorzystanie bazy danych etcd we wszystkich wystąpieniach. Uważnie monitoruj, aby uniknąć przekroczenia limitu przestrzeni magazynowej etcd.

Konsekwentne monitorowanie apiserver_cpu_usage_percentage i apiserver_memory_usage_percentage w celu wykrycia ciśnienia zasobów na serwerze interfejsu API. Jeśli etcd_database_usage_percentage stale przekracza 50%, zapoznaj się z sekcją Optymalizacje etcd , aby zmniejszyć rozmiar bazy danych. Aby uzyskać pełną listę dostępnych metryk, zobacz Dokumentację danych monitorowania usługi AKS.

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:

  • Usługa AKS obsługuje domyślne skalowanie do 5000 węzłów dla wszystkich klastrów Standard Tier / LTS. Usługa AKS skaluje płaszczyznę sterowania klastra podczas działania, opierając się na rozmiarze klastra i wykorzystaniu zasobów serwera interfejsu API. Jeśli nie możesz skalować w górę do obsługiwanego limitu, włącz metryki płaszczyzny sterowania (wersja zapoznawcza) przy użyciu zarządzanej usługi Azure Monitor dla Prometheusa, aby monitorować płaszczyznę sterowania. Aby ułatwić rozwiązywanie problemów ze skalowaniem wydajności lub niezawodności, zobacz następujące zasoby:

    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 zgłoszenie do działu wsparcia.

  • 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ć przychodząca/wychodząca, nie będą dostępne w metrykach platformy Azure Monitor po zwiększeniu skali płaszczyzny sterowania.

  • 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 Zatrzymaj i uruchom klaster AKS.

Ograniczenia działania interfejsu API i 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. W Azure ograniczanie odbywa się na dwóch poziomach. Azure Resource Manager (ARM) ogranicza żądania dotyczące subskrypcji i dzierżawy. Jeśli żądanie mieści się w granicach limitów dla subskrypcji i dzierżawcy, 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 ograniczeniami w Azure Kubernetes Service (AKS)

Azure limity interfejsu API są zwykle definiowane na poziomie kombinacji subskrypcji i regionu. Na przykład wszyscy klienci w ramach subskrypcji w danym regionie dzielą się limitami API dla poszczególnych interfejsów API Azure, takich jak interfejsy API PUT dla zestawów skalowania maszyn wirtualnych (Virtual Machine Scale Sets). Każdy klaster usługi AKS ma kilku klientów zarządzanych przez AKS, takich jak dostawca usług w chmurze lub autoskaler klastra, a także klientów zarządzanych przez użytkownika, takich jak Datadog lub Prometheus wdrażany samodzielnie, które wywołują interfejsy API Azure. W przypadku uruchamiania wielu klastrów AKS w ramach jednej subskrypcji w danym regionie, wszystkie klienty należące do usługi AKS i klienty należące do klientów, działające w klastrach, mają wspólny zestaw limitów 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 rozwiązują problemy z wydajnością i zarządzaniem zasobami. 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, identyfikowania głównej przyczyny i uzyskiwania zaleceń dotyczących rozwiązywania problemów.
  • Podziel swoje klastry na różne subskrypcje lub regiony: Jeśli masz dużą liczbę klastrów i pul węzłów korzystających z Virtual Machine Scale Sets, możesz podzielić je na różne subskrypcje lub na różne regiony w ramach tej samej subskrypcji. Większość limitów interfejsu API 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 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.

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:

  • Użyj zarządzanego NAT dla ruchu wychodzącego klastra, z co najmniej dwoma publicznymi adresami IP w bramie NAT. Aby uzyskać więcej informacji, zobacz Tworzenie zarządzanej bramy NAT dla klastra AKS.

  • Jeśli używasz Azure usługa Load Balancer w warstwie Standardowa, użyj co najmniej 2 wychodzących publicznych adresów IP. Podczas planowania dużych klastrów należy również rozważyć limity reguł zaplecza usługi LoadBalancer. Standardowe Load Balancery Azure w warstwie Standard obsługują maksymalnie 10 000 konfiguracji adresów IP zaplecza na adres IP frontend. Każda usługa typu LoadBalancer tworzy jedną regułę równoważenia obciążenia na każdy udostępniony port i kojarzy wszystkie węzły klastra z pulą zaplecza modułu równoważenia obciążenia. Na przykład uwidacznianie 5 portów dla pojedynczej usługi spowoduje osiągnięcie tego limitu w 2000 węzłach.

    1 service * 5 ports * 2000 nodes = 10000 backend IP configurations

  • Użyj Azure CNI Overlay, aby skalować do 200 000 podów i 5000 węzłów na klaster. Aby uzyskać więcej informacji, zobacz Konfigurowanie sieci nakładki Azure CNI w usłudze AKS.

  • Jeśli aplikacja wymaga bezpośredniej komunikacji między zasobnikami w klastrach, użyj sieci Azure CNI z dynamiczną alokacją adresów IP i skaluj do 50 000 zasobników aplikacji na klaster, przy użyciu jednego routowalnego adresu IP na zasobnik. Aby uzyskać więcej informacji, zobacz Konfigurowanie Azure sieci CNI na potrzeby dynamicznej alokacji adresów IP w usłudze AKS.

  • W przypadku korzystania z wewnętrznych usług Kubernetes za wewnętrznym modułem równoważenia obciążenia zalecamy utworzenie wewnętrznego modułu równoważenia obciążenia lub usługi poniżej skali 750 węzłów w celu uzyskania optymalnej wydajności skalowania i elastyczności modułu równoważenia obciążenia.

  • program Azure Network Policy Manager (NPM) obsługuje tylko maksymalnie 250 węzłów. Jeśli chcesz wymusić zasady sieci dla większych klastrów, rozważ użycie Azure CNI obsługiwanej przez cilium, która łączy niezawodną płaszczyznę sterowania Azure CNI z płaszczyzną danych Cilium w celu zapewnienia wysokiej wydajności sieci i zabezpieczeń.

  • Włącz usługę LocalDNS w pulach węzłów, aby zmniejszyć opóźnienie rozpoznawania nazw DNS i odciążyć scentralizowane zasobniki CoreDNS. W dużych klastrach z dużą liczbą zapytań DNS scentralizowane rozpoznawanie DNS może stać się wąskim gardłem. LocalDNS wdraża serwer proxy DNS jako usługę na każdym węźle, co pozwala na lokalne rozwiązywanie zapytań, eliminując obciążenie tabeli i przełączając połączenia na protokół TCP, aby uniknąć sytuacji wyścigowych. Usługa LocalDNS obsługuje również obsługę nieaktualnych buforowanych odpowiedzi, gdy nadrzędny serwer DNS jest niedostępny, co zwiększa odporność obciążenia podczas przejściowych awarii. Aby uzyskać więcej informacji, zobacz Rozpoznawanie nazw DNS w usłudze AKS.

Zagadnienia i najlepsze rozwiązania dotyczące uaktualniania klastra

  • Gdy klaster osiągnie limit 5000 węzłów, uaktualnienia klastra są blokowane. Ten limit uniemożliwia uaktualnienie, ponieważ nie ma dostępnej pojemności węzła do wykonywania aktualizacji stopniowych 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 częstotliwości zmian węzłów i zminimalizuje obciążenie płaszczyzny sterowania.
  • Przy uaktualnianiu klastrów zawierających ponad 500 węzłów zaleca się użycie konfiguracji maksymalnego wzrostu 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 maksymalnych ustawień przyrostu, proces uaktualniania zostanie ukończony szybciej, ale mogą wystąpić zakłócenia podczas procesu uaktualniania. Aby uzyskać więcej informacji, zobacz Dostosowywanie modernizacji przełączania węzłów.
  • Aby uzyskać więcej informacji na temat uaktualniania klastra, zobacz temat Uaktualnianie klastra AKS.
  • Last updated on