Delen via

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 op meer dan 500 knooppuntschaal wordt uitgevoerd.

Ik krijg de foutmelding 'quotum overschreden' tijdens het maken, omhoog schalen of upgraden

Als u dit probleem wilt oplossen, maakt u een ondersteuningsaanvraag in het abonnement waarin u probeert te maken, schalen of upgraden en vraagt u een quotum aan voor het bijbehorende resourcetype. Zie regionale rekenquota voor meer informatie.

Ik krijg de foutmelding '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 ip-adressen meer heeft binnen de CIDR voor een geslaagde resourcetoewijzing. Dit probleem kan optreden tijdens upgrades, uitschalen of het maken van een knooppuntgroep. 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

Voorwaarden

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 vervolgens deze stappen:

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

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

  3. Maak 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 ondervind sporadische uitgaande connectiviteitsfouten vanwege SNAT-poortuitputting

Voor clusters die op relatief grote schaal worden uitgevoerd (meer dan 500 knooppunten), raden we u aan om de NAT-gateway (Managed Network Address Translation) van AKS te gebruiken voor een grotere schaalbaarheid. Azure NAT Gateway biedt maximaal 64.512 uitgaande UDP- en TCP-verkeerstromen per IP-adres 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 Azure Portal

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

  1. Maak een minimum aantal knooppuntgroepen in het cluster (omdat de maximale limiet voor knooppuntgroepen 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 schaalaanpassingen van 1000. Voer de volgende opdracht uit:

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

Mijn upgrade wordt uitgevoerd, maar het is traag

In de standaardconfiguratie neemt AKS toe tijdens een upgrade door de volgende acties uit te voeren:

  • Er wordt één nieuw knooppunt gemaakt.
  • Het schalen van de knooppuntgroep buiten het gewenste aantal knooppunten met één knooppunt.

Voor de maximale piekinstellingen 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 werkbelastingonderbreking minimaliseren.

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

Voer de volgende opdracht uit om de maximale piek 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

Het is ook belangrijk om na te gaan hoe uw implementatie-instellingen de voltooiing van de upgrade- of schaalbewerking kunnen vertragen:

  • Vm's uit de SKU-serie B-serie worden niet ondersteund door AKS in de systeemknooppuntpool en kunnen tijdens en na updates lage prestaties ervaren.
  • Controleer de PDB-resource-instellingen van uw implementatie om ervoor te zorgen dat deze correct zijn voor een geslaagde upgrade. Zie best practices voor AKS-workloads voor meer informatie.

Tip

Als u meer inzicht wilt krijgen in dit gedrag, kunt u foutdetails bekijken op de pagina Activiteitenlogboek in Azure Portal of de resourcelogboeken in uw cluster bekijken.

Mijn upgrade bereikt de quotumlimiet (5.000 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

SLB-updates (Standard Load Balancer) voor back-endpools zijn een bekend knelpunt voor prestaties. We werken aan een nieuwe mogelijkheid waarmee u sneller services en SLB op schaal kunt maken. Als u ons feedback wilt sturen over dit probleem, raadpleegt u De ondersteuning van Azure Kubernetes voor load balancer met een back-endpool op basis van IP.

Oplossing

Het is raadzaam om 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 maken

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 uitvoeren. Hierdoor kunt u meer services toevoegen aan de load balancer op schaal.

Het maken van de SLB-service op schaal duurt uren om uit te voeren

SLB-back-endpoolupdates zijn een bekend knelpunt voor prestaties. We werken aan een nieuwe mogelijkheid waarmee u services met gelijke taakverdeling op schaal kunt uitvoeren met aanzienlijk snellere prestaties voor het maken, bijwerken en verwijderen van bewerkingen. Als u ons uw feedback wilt sturen, raadpleegt u de ondersteuning van Azure Kubernetes voor load balancer met een back-endpool op basis van IP.

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 Azure-feedbackcommunity.