Vanliga problem när du kör eller skalar stora AKS-kluster – Vanliga frågor och svar

Den här artikeln besvarar vanliga frågor om vanliga problem som kan uppstå när du kör eller skalar stora kluster i Microsoft Azure Kubernetes Service (AKS). Ett stort kluster är ett kluster som körs i mer än en skala på 500 noder.

Jag får felet "kvoten har överskridits" när jag skapar, skalar upp eller uppgraderar

Lös problemet genom att skapa en supportbegäran i prenumerationen där du försöker skapa, skala eller uppgradera och begära en kvot för motsvarande resurstyp. Mer information finns i regionala beräkningskvoter.

Jag får felet "insufficientSubnetSize" när jag distribuerar ett AKS-kluster som använder avancerade nätverk

Det här felet anger att ett undernät som används för ett kluster inte längre har tillgängliga IP-adresser i sin CIDR för lyckad resurstilldelning. Det här problemet kan inträffa vid uppgraderingar, utskalningar eller skapande av nodpooler. Det här problemet beror på att antalet kostnadsfria IP-adresser i undernätet är mindre än resultatet av följande formel:

antal begärda noder * nodpoolsvärde --max-pod

Förutsättningar

Lösning

Eftersom du inte kan uppdatera ett befintligt undernäts CIDR-intervall måste du ha behörighet att skapa ett nytt undernät för att lösa problemet. Gör så här:

  1. Återskapa ett nytt undernät som har ett större CIDR-intervall som är tillräckligt för åtgärdsmål.

  2. Skapa ett nytt undernät som har ett nytt intervall som inte överlappar varandra.

  3. Skapa en ny nodpool i det nya undernätet.

  4. Töm poddar från den gamla nodpoolen som finns i det gamla undernätet som ska ersättas.

  5. Ta bort det gamla undernätet och den gamla nodpoolen.

Jag har sporadiska utgående anslutningsfel på grund av SNAT-portöverbelastning

För kluster som körs i relativt stor skala (mer än 500 noder) rekommenderar vi att du använder NAT-gatewayen (AKS Managed Network Address Translation) för bättre skalbarhet. Azure NAT Gateway tillåter upp till 64 512 utgående UDP- och TCP-trafikflöden per IP-adress och högst 16 IP-adresser.

Om du inte använder hanterad NAT kan du läsa Felsöka SNAT-överbelastning och tidsgränser för anslutningar för att förstå och lösa problem med SNAT-portöverbelastning.

Jag kan inte skala upp till 5 000 noder med hjälp av Azure Portal

Använd Azure CLI för att skala upp till högst 5 000 noder genom att följa dessa steg:

  1. Skapa ett minsta antal nodpooler i klustret (eftersom den maximala nodgränsen för nodpoolen är 1 000) genom att köra följande kommando:

    az aks nodepool add --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster
    
  2. Skala upp nodpoolerna en i taget. Vi rekommenderar att du ställer in fem minuters vilotid mellan på varandra följande uppskalningar på 1 000. Kör följande kommando:

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

Uppgraderingen körs, men den går långsamt

I sin standardkonfiguration ökar AKS under en uppgradering genom att vidta följande åtgärder:

  • Skapa en ny nod.
  • Skala nodpoolen bortom önskat antal noder med en nod.

För inställningarna för maximal ökning innebär ett standardvärde på en nod att AKS skapar en ny nod innan den tömmer befintliga program och ersätter en tidigare version av noden. Med den här extra noden kan AKS minimera arbetsbelastningsstörningar.

När du uppgraderar kluster som har många noder kan det ta flera timmar att uppgradera hela klustret om du använder standardvärdet max-surge. Du kan anpassa max-surge egenskapen per nodpool för att möjliggöra en kompromiss mellan uppgraderingshastighet och uppgraderingsavbrott. Genom att öka det maximala överspänningsvärdet gör du det möjligt för uppgraderingsprocessen att slutföras tidigare. Ett stort värde för maximal ökning kan dock också orsaka störningar under uppgraderingsprocessen.

Kör följande kommando för att öka eller anpassa den maximala ökningen för en befintlig nodpool:

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

Min uppgradering når kvoten (5 000 kluster)

Information om hur du löser det här problemet finns i Öka regionala vCPU-kvoter.

Det går inte att skapa min interna tjänst på fler än 750 noder på grund av ett timeout-fel

Standard Load Balancer (SLB) uppdateringar av serverdelspoolen är en känd flaskhals för prestanda. Vi arbetar med en ny funktion som gör det möjligt att snabbare skapa tjänster och SLB i stor skala. Om du vill skicka feedback om det här problemet kan du läsa Azure Kubernetes-stöd för lastbalanserare med IP-baserad serverdelspool.

Lösning

Vi rekommenderar att du skalar ned klustret till färre än 750 noder och sedan skapar en intern lastbalanserare för klustret. Om du vill skapa en intern lastbalanserare skapar du en LoadBalancer tjänsttyp och azure-load-balancer-internal en anteckning enligt följande exempelprocedur.

Steg 1: Skapa en intern lastbalanserare

Skapa en intern lastbalanserare genom att skapa ett tjänstmanifest med namnet internal-lb.yaml och som innehåller LoadBalancer tjänsttypen och kommentaren azure-load-balancer-internal , som du ser i följande exempel:

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

Steg 2: Distribuera den interna lastbalanseraren

Distribuera den interna lastbalanseraren med hjälp kubectl apply av kommandot och ange namnet på YAML-manifestet enligt följande exempel:

kubectl apply -f internal-lb.yaml

När klustret har skapats kan du också etablera en intern lastbalanserare (enligt den här proceduren) och hålla en intern lastbalanserad tjänst igång. På så sätt kan du lägga till fler tjänster i lastbalanseraren i stor skala.

Det tar timmar att skapa SLB-tjänsten i stor skala

Uppdateringar av SLB-serverdelspoolen är en känd flaskhals för prestanda. Vi arbetar med en ny funktion som gör att du kan köra belastningsutjämningstjänster i stor skala med betydligt snabbare prestanda för att skapa, uppdatera och ta bort åtgärder. Information om hur du skickar feedback finns i Azure Kubernetes-stöd för lastbalanserare med IP-baserad serverdelspool.

Ansvarsfriskrivning för information från tredje part

De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.