Dela via

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

  • Artikel

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 överskreds" när jag skapade, skalade upp eller uppgraderade

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 när du uppgraderar, skalar ut eller skapar 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. Följ de här stegen:

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

  2. Skapa ett nytt undernät som har ett nytt icke-överlappande intervall.

  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 (fler än 500 noder) rekommenderar vi att du använder NAT-gatewayen (AKS Managed Network Address Translation) för större 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 (source network address translation) och timeouter för anslutning 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

Min uppgradering körs, men den är långsam

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 överspänning 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

Det är också viktigt att tänka på hur dina distributionsinställningar kan fördröja slutförandet av uppgraderingen eller skalningsåtgärden:

  • Virtuella datorer i SKU-serien B-serien stöds inte av AKS i systemnodpoolen och de kan uppleva låga prestanda under och efter uppdateringar.
  • Kontrollera distributionens PDB-resursinställningar för att säkerställa att de är korrekta för en lyckad uppgradering. Mer information finns i metodtips för AKS-arbetsbelastningar.

Dricks

Om du vill få mer information om det här beteendet kan du visa felinformation på sidan Aktivitetslogg i Azure Portal eller granska resursloggarna i klustret.

Min uppgradering når gränsen på 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

Uppdateringar av SLB-serverdelspoolen (Standard Load Balancer) ä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. Information om hur du skickar feedback om det här problemet finns i 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. Skapa en intern lastbalanserare genom att skapa 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 anteckningen azure-load-balancer-internal , enligt 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å DITT YAML-manifest, som du ser i följande exempel:

kubectl apply -f internal-lb.yaml

När klustret har skapats kan du även 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.