Typowe problemy podczas uruchamiania lub skalowania dużych klastrów AKS — często zadawane pytania

Ten artykuł zawiera odpowiedzi na często zadawane pytania dotyczące typowych problemów, które mogą wystąpić podczas uruchamiania lub skalowania dużych klastrów w usłudze Microsoft Azure Kubernetes Service (AKS). Duży klaster to dowolny klaster, który działa w skali większej niż 500 węzłów.

Podczas tworzenia, skalowania w górę lub uaktualniania występuje błąd "przekroczono limit przydziału"

Aby rozwiązać ten problem, utwórz wniosek o pomoc techniczną w subskrypcji, w której próbujesz utworzyć, skalować lub uaktualnić, i zażądać przydziału dla odpowiedniego typu zasobu. Aby uzyskać więcej informacji, zobacz regionalne przydziały obliczeniowe.

Podczas wdrażania klastra usługi AKS korzystającego z sieci zaawansowanej występuje błąd "insufficientSubnetSize"

Ten błąd wskazuje, że podsieć, która jest używana dla klastra, nie ma już dostępnych adresów IP w ramach trasy CIDR w celu pomyślnego przypisania zasobu. Ten problem może wystąpić podczas uaktualniania, skalowania w poziomie lub tworzenia puli węzłów. Ten problem występuje, ponieważ liczba bezpłatnych adresów IP w podsieci jest mniejsza niż wynik następującej formuły:

liczba żądanych węzłów * wartość puli --max-pod węzłów

Wymagania wstępne

• Aby skalować ponad 400 węzłów, należy użyć wtyczki sieciowej usługi Azure CNI.

• Aby ułatwić planowanie sieci wirtualnej i podsieci w celu uwzględnienia liczby wdrażanych węzłów i zasobników, zobacz planowanie adresów IP klastra. Aby zmniejszyć obciążenie związane z planowaniem podsieci lub ponownym utworzeniem klastra, które miałoby zostać utworzone z powodu wyczerpania adresów IP, zobacz Dynamiczna alokacja adresów IP.

Rozwiązanie

Ponieważ nie można zaktualizować zakresu CIDR istniejącej podsieci, musisz mieć uprawnienia do utworzenia nowej podsieci, aby rozwiązać ten problem. Wykonaj następujące czynności:

1. Ponownie skompiluj nową podsieć, która ma większy zakres CIDR, który jest wystarczający dla celów operacji.

2. Twórca nową podsieć, która ma nowy zakres, który nie nakłada się na siebie.

3. Twórca nową pulę węzłów w nowej podsieci.

4. Zasobniki opróżniania ze starej puli węzłów, która znajduje się w starej podsieci, która zostanie zamieniona.

5. Usuń starą podsieć i starą pulę węzłów.

Mam sporadyczne błędy łączności wychodzącej z powodu wyczerpania portów SNAT

W przypadku klastrów, które działają w stosunkowo dużej skali (ponad 500 węzłów), zalecamy użycie bramy NAT (Managed Network Address Translation) usługi AKS w celu zwiększenia skalowalności. Usługa Azure NAT Gateway umożliwia maksymalnie 64 512 wychodzących przepływów ruchu UDP i TCP na adres IP oraz maksymalnie 16 adresów IP.

Jeśli nie używasz zarządzanego translatora adresów sieciowych, zobacz Rozwiązywanie problemów z wyczerpaniem i przekroczeniem limitu czasu połączenia tłumaczenia źródłowego adresu sieciowego (SNAT ), aby zrozumieć i rozwiązać problemy z wyczerpaniem portów SNAT.

Nie mogę skalować do 5000 węzłów przy użyciu Azure Portal

Użyj interfejsu wiersza polecenia platformy Azure, aby skalować maksymalnie 5000 węzłów, wykonując następujące kroki:

1. Twórca minimalną liczbę pul węzłów w klastrze (ponieważ maksymalny limit węzłów puli węzłów wynosi 1000), uruchamiając następujące polecenie:

   az aks nodepool add --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster
   

2. Skaluj w górę pule węzłów pojedynczo. Najlepiej ustawić pięć minut czasu snu między kolejnymi skalowania w górę 1000. Uruchom następujące polecenie:

   az aks nodepool scale --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster
   

Moje uaktualnienie jest uruchomione, ale działa wolno

W domyślnej konfiguracji usługa AKS przeskakuje podczas uaktualniania, wykonując następujące akcje:

• Tworzenie jednego nowego węzła.
• Skalowanie puli węzłów poza żądaną liczbę węzłów o jeden węzeł.

W przypadku maksymalnych ustawień przepięcia wartość domyślna jednego węzła oznacza, że usługa AKS tworzy jeden nowy węzeł, zanim opróżni istniejące aplikacje i zastąpi węzeł o wcześniejszej wersji. Ten dodatkowy węzeł umożliwia usłudze AKS minimalizowanie zakłóceń obciążeń.

Uaktualnienie klastrów, które mają wiele węzłów, może potrwać kilka godzin, aby uaktualnić cały klaster, jeśli jest używana wartość domyślna max-surge. Możesz dostosować max-surge właściwość na pulę węzłów, aby włączyć kompromis między szybkością uaktualniania a przerwami w uaktualnianiu. Zwiększając maksymalną wartość przepięcia, można włączyć proces uaktualniania, aby zakończyć się wcześniej. Jednak duża wartość maksymalnego wzrostu może również powodować zakłócenia podczas procesu uaktualniania.

Uruchom następujące polecenie, aby zwiększyć lub dostosować maksymalny wzrost dla istniejącej puli węzłów:

az aks nodepool update --resource-group MyResourceGroup --name mynodepool --cluster-name MyManagedCluster --max-surge 5

Moje uaktualnienie osiąga limit przydziału (5000 klastrów)

Aby rozwiązać ten problem, zobacz Zwiększanie regionalnych przydziałów procesorów wirtualnych.

Tworzenie usługi wewnętrznej w ponad 750 węzłach działa wolno lub kończy się niepowodzeniem z powodu błędu przekroczenia limitu czasu

aktualizacje puli zaplecza usługa Load Balancer w warstwie Standardowa (SLB) są znanym wąskim gardłem wydajności. Pracujemy nad nową funkcją, która umożliwi szybsze tworzenie usług i SLB na dużą skalę. Aby wysłać nam swoją opinię na temat tego problemu, zobacz Obsługa usługi Azure Kubernetes dla modułu równoważenia obciążenia z pulą zaplecza opartą na protokole IP.

Rozwiązanie

Zalecamy skalowanie klastra w dół do mniej niż 750 węzłów, a następnie utworzenie wewnętrznego modułu równoważenia obciążenia dla klastra. Aby utworzyć wewnętrzny moduł równoważenia obciążenia, utwórz LoadBalancer typ usługi i azure-load-balancer-internal adnotację zgodnie z poniższą przykładową procedurą.

Krok 1. Twórca wewnętrznego modułu równoważenia obciążenia

Aby utworzyć wewnętrzny moduł równoważenia obciążenia, utwórz manifest usługi o nazwie internal-lb.yaml zawierający LoadBalancer typ usługi i azure-load-balancer-internal adnotację, jak pokazano w poniższym przykładzie:

apiVersion: v1
kind: Service
metadata:
  name: internal-app
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: internal-app

Krok 2. Wdrażanie wewnętrznego modułu równoważenia obciążenia

Wdróż wewnętrzny moduł równoważenia obciążenia przy użyciu kubectl apply polecenia i określ nazwę manifestu YAML, jak pokazano w poniższym przykładzie:

kubectl apply -f internal-lb.yaml

Po utworzeniu klastra można również aprowizować wewnętrzny moduł równoważenia obciążenia (zgodnie z tą procedurą) i zachować wewnętrzną usługę o zrównoważonym obciążeniu. Dzięki temu można dodać więcej usług do modułu równoważenia obciążenia na dużą skalę.

Tworzenie usługi SLB na dużą skalę trwa wiele godzin

Aktualizacje puli zaplecza SLB są znanym wąskim gardłem wydajności. Pracujemy nad nową funkcją, która umożliwi uruchamianie usług o zrównoważonym obciążeniu na dużą skalę ze znacznie szybszą wydajnością tworzenia, aktualizowania i usuwania operacji. Aby wysłać nam swoją opinię, zobacz Obsługa usługi Azure Kubernetes dla modułu równoważenia obciążenia z pulą zaplecza opartą na protokole IP.

Zastrzeżenie dotyczące innych firm

Produkty innych firm omówione w tym artykule są wytwarzane przez producentów niezależnych od firmy Microsoft. Firma Microsoft nie udziela żadnych gwarancji, dorozumianych ani żadnego innego rodzaju, w odniesieniu do wydajności lub niezawodności tych produktów.

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii platformy Azure.