Share via

Veelgestelde vragen over veelvoorkomende problemen bij het uitvoeren of schalen van grote AKS-clusters

  • Artikel

In dit artikel vindt u antwoorden op veelgestelde vragen over veelvoorkomende problemen die kunnen optreden wanneer u grote clusters uitvoert of schaalt in Microsoft Azure Kubernetes Service (AKS). Een groot cluster is een cluster dat wordt uitgevoerd op een schaal van meer dan 500 knooppunten.

Ik krijg een fout 'quotum overschreden' tijdens het maken, omhoog schalen of upgraden

U kunt dit probleem oplossen door een ondersteuningsaanvraag te maken in het abonnement waarin u probeert te maken, te schalen of te upgraden en een quotum aan te vragen voor het bijbehorende resourcetype. Zie regionale rekenquota voor meer informatie.

Ik krijg de fout 'insufficientSubnetSize' wanneer ik een AKS-cluster implementeer dat gebruikmaakt van geavanceerde netwerken

Deze fout geeft aan dat een subnet dat wordt gebruikt voor een cluster geen beschikbare IP-adressen meer heeft in de CIDR voor een geslaagde resourcetoewijzing. Dit probleem kan optreden tijdens upgrades, scale-outs of het maken van knooppuntgroepen. Dit probleem treedt op omdat het aantal gratis IP-adressen in het subnet kleiner is dan het resultaat van de volgende formule:

aantal aangevraagde knooppunten * waarde van knooppuntgroep --max-pod

Vereisten

Oplossing

Omdat u het CIDR-bereik van een bestaand subnet niet kunt bijwerken, moet u gemachtigd zijn om een nieuw subnet te maken om dit probleem op te lossen. Volg deze stappen:

  1. Bouw een nieuw subnet opnieuw op met een groter CIDR-bereik dat voldoende is voor operationele doelen.

  2. Creatie een nieuw subnet met een nieuw niet-overlappend bereik.

  3. Creatie een nieuwe knooppuntgroep in het nieuwe subnet.

  4. Verwijder pods uit de oude knooppuntgroep die zich in het oude subnet bevindt dat wordt vervangen.

  5. Verwijder het oude subnet en de oude knooppuntgroep.

Ik heb sporadische verbindingsfouten vanwege uitputting van de SNAT-poort

Voor clusters die op relatief grote schaal worden uitgevoerd (meer dan 500 knooppunten), raden we u aan de AKS Managed Network Address Translation (NAT)-gateway te gebruiken voor een grotere schaalbaarheid. Azure NAT Gateway staat maximaal 64.512 uitgaande UDP- en TCP-verkeersstromen per IP-adres toe en maximaal 16 IP-adressen.

Als u geen beheerde NAT gebruikt, raadpleegt u Problemen met SNAT-uitputting (Source Network Address Translation) en verbindingstime-outs oplossen om problemen met SNAT-poortuitputting te begrijpen en op te lossen.

Ik kan niet omhoog schalen naar 5000 knooppunten met behulp van de Azure Portal

Gebruik de Azure CLI om omhoog te schalen naar maximaal 5000 knooppunten door de volgende stappen uit te voeren:

  1. Creatie een minimum aantal knooppuntgroepen in het cluster (omdat de maximale knooppuntgroeplimiet 1000 is) door de volgende opdracht uit te voeren:

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

  2. Schaal de knooppuntgroepen één voor één omhoog. Stel idealiter vijf minuten slaaptijd in tussen opeenvolgende scale-ups van 1000. Voer de volgende opdracht uit:

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

Mijn upgrade wordt uitgevoerd, maar deze is traag

In de standaardconfiguratie worden AKS-pieken tijdens een upgrade uitgevoerd door de volgende acties uit te voeren:

  • Eén nieuw knooppunt maken.
  • De knooppuntgroep met één knooppunt schalen boven het gewenste aantal knooppunten.

Voor de maximale piekspanningsinstellingen betekent een standaardwaarde van één knooppunt dat AKS één nieuw knooppunt maakt voordat de bestaande toepassingen worden leeggemaakt en een knooppunt met een eerdere versie wordt vervangen. Met dit extra knooppunt kan AKS werkbelastingsonderbreking minimaliseren.

Wanneer u clusters met veel knooppunten bijwerkt, kan het enkele uren duren voordat het hele cluster is bijgewerkt als u de standaardwaarde van max-surgegebruikt. U kunt de max-surge eigenschap per knooppuntgroep aanpassen om een afweging mogelijk te maken tussen upgradesnelheid en upgradeonderbreking. Door de maximale piekwaarde te verhogen, kunt u het upgradeproces sneller voltooien. Een grote waarde voor maximale piek kan echter ook onderbrekingen veroorzaken tijdens het upgradeproces.

Voer de volgende opdracht uit om de maximale piekspanning voor een bestaande knooppuntgroep te verhogen of aan te passen:

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

Mijn upgrade bereikt de quotumlimiet (5000 cluster)

Zie Regionale vCPU-quota verhogen om dit probleem op te lossen.

Mijn interne service maken op meer dan 750 knooppunten is traag of mislukt vanwege een time-outfout

Standard Load Balancer back-endpoolupdates (SLB) zijn een bekend prestatieknelpunt. We werken aan een nieuwe mogelijkheid waarmee sneller services en SLB op schaal kunnen worden gemaakt. Als u ons uw feedback over dit probleem wilt sturen, raadpleegt u Azure Kubernetes-ondersteuning voor load balancer met op IP gebaseerde back-endpool.

Oplossing

U wordt aangeraden het cluster omlaag te schalen naar minder dan 750 knooppunten en vervolgens een interne load balancer voor het cluster te maken. Als u een interne load balancer wilt maken, maakt u een LoadBalancer servicetype en azure-load-balancer-internal aantekeningen volgens de volgende voorbeeldprocedure.

Stap 1: een interne load balancer Creatie

Als u een interne load balancer wilt maken, maakt u een servicemanifest met de naam internal-lb.yaml en dat het LoadBalancer servicetype en de azure-load-balancer-internal aantekening bevat, zoals wordt weergegeven in het volgende voorbeeld:

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

Stap 2: de interne load balancer implementeren

Implementeer de interne load balancer met behulp van de kubectl apply opdracht en geef de naam van uw YAML-manifest op, zoals wordt weergegeven in het volgende voorbeeld:

kubectl apply -f internal-lb.yaml

Nadat uw cluster is gemaakt, kunt u ook een interne load balancer inrichten (volgens deze procedure) en een interne service met gelijke taakverdeling laten uitvoeren. Als u dit doet, kunt u meer services op schaal toevoegen aan de load balancer.

Het maken van een SLB-service op schaal duurt uren

Updates van SLB-back-endpools zijn een bekend prestatieknelpunt. We werken aan een nieuwe functie waarmee u services met gelijke taakverdeling op schaal kunt uitvoeren met aanzienlijk snellere prestaties voor het maken, bijwerken en verwijderen van bewerkingen. Zie Azure Kubernetes-ondersteuning voor load balancer met ip-back-endpool om ons uw feedback te sturen.

Disclaimerinformatie van derden

De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Feedback-community van Azure.