Fouten met 429 te veel aanvragen

In dit artikel wordt beschreven hoe u fouten kunt oplossen die worden veroorzaakt door fouten met '429 Te veel aanvragen' in uw Microsoft Azure Kubernetes Service (AKS)-clusters (of clusters die gebruikmaken van een andere Kubernetes-implementatie in Azure).

Symptomen

U ontvangt fouten die lijken op de volgende tekst:

Service heeft een fout geretourneerd.

Status=429

Code="OperationNotAllowed"

Message="De server heeft de aanvraag geweigerd omdat er te veel aanvragen zijn ontvangen voor dit abonnement."

Details=[{
"code":"TooManyRequests",
"message":"{
\"operationGroup\":\"HighCostGetVMScaleSet30Min\",
\"startTime\":\"2020-09-20T07:13:55.2177346+00:00\",
\"endTime\":\"2020-09-20T07:28:55.2177346+00:00\",
\"allowedRequestCount\":1800,
\"measuredRequestCount\":2208
}",
"target":"HighCostGetVMScaleSet30Min"
}]

InnerError={"internalErrorCode":"TooManyRequestsReceived"}"}

Oorzaak: Overmatige aanroepvolumes zorgen ervoor dat Azure uw abonnement beperkt

Een Kubernetes-cluster in Azure (met of zonder AKS) dat regelmatig omhoog of omlaag schaalt of gebruikmaakt van de automatische schaalaanpassing van het cluster, kan een groot aantal HTTP-aanroepen veroorzaken. Dit aanroepvolume kan leiden tot een fout, omdat het het toegewezen quotum voor uw Azure-abonnement overschrijdt.

Zie Azure Resource Manager-aanvragen beperken en Problemen met API-beperkingsfouten oplossen voor meer informatie over deze fouten. Zie Fouten analyseren en identificeren met behulp van AKS Problemen diagnosticeren en oplossen voor meer informatie over het analyseren en identificeren van de oorzaak van deze fouten en het verkrijgen van aanbevelingen om deze op te lossen.

Oplossing 1: Upgraden naar een latere versie van Kubernetes

Voer Kubernetes 1.18 uit. x of hoger. Deze versies bevatten veel verbeteringen die worden beschreven in AKS-beperking/429-fouten en Ondersteuning voor grote clusters zonder beperking. Als u echter nog steeds beperking ziet (vanwege de werkelijke belasting of het aantal clients in het abonnement), kunt u de volgende oplossingen proberen.

Oplossing 2: het scaninterval voor automatische schaalaanpassing verhogen

Als u de beperking van de diagnostische rapporten 'Beperking van automatische schaalaanpassing van clusters is gedetecteerd' vindt die wordt veroorzaakt door de automatische schaalaanpassing van het cluster, kunt u proberen het scaninterval voor automatische schaalaanpassing te verhogen om het aantal aanroepen naar VIRTUELE-machineschaalsets (VMSS) van de automatische schaalaanpassing van het cluster te verminderen.

Oplossing 3: Toepassingen van derden opnieuw configureren om minder aanroepen te doen

Wanneer u filtert op gebruikersagents in de diagnose 'Details van aanvraagsnelheid en beperking weergeven' en u toepassingen van derden (zoals bewakingstoepassingen) vindt die een te groot aantal GET-aanvragen doen, wijzigt u de instellingen van deze toepassingen om de frequentie van de GET-aanroepen te verminderen. Zorg er bovendien voor dat de toepassingsclients exponentieel uitstel gebruiken bij het aanroepen van Azure-API's.

Oplossing 4: Uw clusters splitsen in verschillende abonnementen of regio's

Als er talloze clusters en knooppuntgroepen zijn die gebruikmaken van virtuele-machineschaalsets, probeert u de clusters op te splitsen in verschillende abonnementen of regio's (binnen hetzelfde abonnement). De meeste Azure API-limieten zijn gedeelde limieten op abonnementsregioniveau. Alle clusters en clients in sub één en de regio VS - oost delen bijvoorbeeld een limiet voor de GET API voor virtuele-machineschaalsets. Daarom kunt u nieuwe AKS-clusters verplaatsen of schalen in een nieuwe regio en de blokkering van Azure API-beperking opheffen. Deze techniek helpt als u verwacht dat de clusters een hoge activiteit hebben (bijvoorbeeld als u een actieve automatische schaalaanpassing van clusters hebt). Het helpt ook als u veel klanten hebt (zoals Rancher, Terraform, enzovoort). Omdat alle clusters verschillen in hun elasticiteit en het aantal clients dat Azure-API's peilt, zijn er geen algemene richtlijnen voor het aantal clusters dat u per abonnementsregioniveau kunt uitvoeren. Voor specifieke richtlijnen kunt u een ondersteuningsticket maken.

Fouten analyseren en identificeren met behulp van AKS Problemen vaststellen en oplossen

Voor een AKS-cluster kunt u AKS Problemen diagnosticeren en oplossen gebruiken om de oorzaak van deze fouten te analyseren en te identificeren en aanbevelingen te krijgen om deze op te lossen. Navigeer naar uw cluster in de Azure Portal en selecteer Problemen vaststellen en oplossen in de linkernavigatiebalk om AKS Problemen vaststellen en oplossen te openen. Search en open Beperking van Azure-resourceaanvragen, waar u een rapport kunt ophalen met een reeks diagnostische gegevens. Deze diagnostische gegevens kunnen aangeven of het cluster een beperking van de aanvraagsnelheid (429 antwoorden) van Azure Resource Manager (ARM) of Resource Provider (RP) heeft ervaren en waar de beperking vandaan komt. Bijvoorbeeld:

• Beperking van aanvraagsnelheid is gedetecteerd voor uw cluster: deze diagnose biedt enkele algemene aanbevelingen als beperking is gedetecteerd in het huidige AKS-cluster.

• Beperking van automatische schaalaanpassing van clusters is gedetecteerd: deze diagnose wordt weergegeven als beperking is gedetecteerd en afkomstig is van de automatische schaalaanpassing van het cluster.

  Gebruik de volgende methoden om het aantal aanvragen van de automatische schaalaanpassing van clusters te verminderen:

  • Verhoog het scaninterval voor automatische schaalaanpassing om het aantal aanroepen van de automatische schaalaanpassing van het cluster naar virtuele-machineschaalsets te verminderen. Deze methode kan een negatieve latentie-invloed hebben op de tijd die nodig is om omhoog te schalen, omdat de automatische schaalaanpassing van het cluster langer wacht voordat de Azure Compute Resource Provider (CRP) wordt aangeroepen voor een nieuwe virtuele machine.
  • Zorg ervoor dat het cluster minimaal Kubernetes-versie 1.18 heeft. Kubernetes versie 1.18 en latere versies verwerken de back-off van aanvraagsnelheid beter wanneer 429 beperkingsreacties worden ontvangen. We raden u ten zeerste aan binnen ondersteunde Kubernetes-versies te blijven om beveiligingspatches te ontvangen.

• Beperking: Azure Resource Manager: deze diagnose toont het aantal vertraagde aanvragen in het opgegeven tijdsbereik in het AKS-cluster.

• Aanvraagsnelheid: Azure Resource Manager: deze diagnose toont het totale aantal aanvragen in het opgegeven tijdsbereik in het AKS-cluster.

• Details van aanvraagsnelheid en beperking weergeven: deze diagnose heeft meerdere diagrammen om de details van de beperking te bepalen, waaronder beperkte aanvragen en het totale aantal aanvragen. U kunt de resultaten ook filteren met behulp van de volgende dimensies:

  • Host: de host waar HTTP-status 429-antwoorden zijn gedetecteerd. Azure-Resource Manager beperkingen zijn afkomstig vanmanagement.azure.com; de rest is een resourceprovider met een lagere laag.
  • Gebruikersagent: aanvragen met een opgegeven gebruikersagent die zijn beperkt.
  • Bewerking: bewerkingen waarbij HTTP-status 429-antwoorden zijn gedetecteerd.
  • Client-IP: het IP-adres van de client dat de vertraagde aanvragen heeft verzonden.

Aanvraagbeperking kan worden veroorzaakt door een combinatie van een cluster in dit abonnement, niet alleen door de aanvraagsnelheid voor dit cluster.

Voorbeeld 1: Beperking van automatisch schalen van clusters

Dit voorbeeld gaat over het analyseren van beperking die wordt veroorzaakt door de automatische schaalaanpassing van clusters.

Als u merkt dat de beperking van automatische schaalaanpassing van clusters is gedetecteerd in AKS Problemen vaststellen en oplossen>bekende problemen, beschikbaarheid en prestaties>beperking van Azure-resourceaanvragen, geeft dit aan dat aanvragen die zijn uitgegeven door de automatische schaalaanpassing van het cluster zijn beperkt.

U vindt het aantal vertraagde aanvragen en wanneer de aanvragen worden beperkt in de diagnose Beperking - Azure Resource Manager.

U kunt het aantal arm-aanvragen in dezelfde periode vinden.

U kunt de diagnose Aanvraagsnelheid en beperkingsdetails weergeven controleren om de beperkingsdetails te vinden. Selecteer 429s per gebruikersagent in de vervolgkeuzelijst Filter selecteren en u ziet dat aanvragen voor automatische schaalaanpassing worden beperkt van 15:00 tot 16:00.

U kunt ook het totale aantal vertraagde aanvragen voor de automatische schaalaanpassing van het cluster en andere gebruikersagents vinden.

U kunt beperkingen ook filteren op bewerkingen. De vm-verwijderbewerking van VMSS wordt in dit geval beperkt.

U vindt het aantal vertraagde aanvragen en alle aanvragen gegroepeerd op bewerkingen.

Vervolgens kunt u de suggesties in de Aanbevolen actie volgen om de beperkingen te verminderen.

Voorbeeld 2: beperking van cloudproviders

Dit voorbeeld gaat over de beperkingen die worden veroorzaakt door de cloudprovider. Dit gebeurt vaak wanneer u resources in grotere clusters gebruikt, bijvoorbeeld het inrichten van een Azure Load Balancer in een cluster met meer dan 500 knooppunten.

Als u beperking in uw cluster vindt, kunt u de beperkingsdetails zien in de diagnose Aanvraagsnelheid en beperkingsdetails weergeven . Selecteer 429s per gebruikersagent in de vervolgkeuzelijst Filter selecteren . U ziet dat aanvragen van cloudproviders zijn beperkt van 03:00 tot 06:00.

U kunt ook filteren op bewerkingen om erachter te komen dat de vertraagde bewerking 'Network/loadBalancers/read' is.

U kunt de AKS Preview-functie Knooppunt IP-gebaseerde Load Balancer gebruiken om deze beperking te verminderen.

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.