429 Fouten bij 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 AKS-clusters (Microsoft Azure Kubernetes Service) 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 oproepvolumes zorgen ervoor dat Azure uw abonnement beperkt
Een Kubernetes-cluster in Azure (met of zonder AKS) dat regelmatig omhoog of omlaag wordt geschaald, of waarvoor automatische schaalaanpassing van clusters wordt gebruikt, kan leiden tot een groot aantal HTTP-aanroepen. Dit aanroepvolume kan leiden tot een fout omdat het het toegewezen quotum voor uw Azure-abonnement overschrijdt.
Zie Voor meer informatie over deze fouten het beperken van Azure Resource Manager-aanvragen en het oplossen van problemen met API-beperkingsfouten. Voor informatie over het analyseren en identificeren van de oorzaak van deze fouten en het verkrijgen van aanbevelingen om deze op te lossen, raadpleegt u Analyseren en identificeren van fouten met behulp van AKS Diagnose en Problemen oplossen.
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-beperkings-/429-fouten en ondersteuning bieden 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 merkt dat de diagnostische beperking voor cluster automatisch schalen is gedetecteerd, meldt beperking die wordt veroorzaakt door de automatische schaalaanpassing van clusters, kunt u proberen om het scaninterval voor automatische schaalaanpassing te verhogen om het aantal aanroepen naar virtuele-machineschaalsets (VMSS) van de automatische schaalaanpassing van clusters te verminderen.
Oplossing 3: Configureer toepassingen van derden opnieuw om minder aanroepen te doen
Wanneer u filtert op gebruikersagenten in de diagnose Aanvraagsnelheid en beperkingsgegevens weergeven, wijzigt u de instellingen van deze toepassingen om de frequentie van get-aanroepen te verminderen als u toepassingen van derden (zoals bewakingstoepassingen) vindt die een overmatig aantal GET-aanvragen maken. 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. Zo delen alle clusters en clients in sub één en de regio VS - oost een limiet voor de GET-API voor virtuele-machineschaalsets. Daarom kunt u nieuwe AKS-clusters in een nieuwe regio verplaatsen of schalen en de blokkering opheffen voor azure-API-beperking. 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 op abonnementsniveau 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-diagnoses en problemen 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 Azure Portal en selecteer Problemen vaststellen en oplossen in het linkernavigatievenster om AKS-problemen te openen. Zoek en open beperking van Azure-resourceaanvragen, waar u een rapport met een reeks diagnostische gegevens kunt ophalen. Deze diagnostische gegevens kunnen aangeven of het cluster een aanvraagsnelheidbeperking (429 antwoorden) van Azure Resource Manager (ARM) of Resource Provider (RP) heeft ervaren en waar de beperking vandaan komt. Bijvoorbeeld:
Aanvraagfrequentiebeperking is gedetecteerd voor uw cluster: deze diagnose biedt enkele algemene aanbevelingen als beperking is gedetecteerd in het huidige AKS-cluster.
Beperking van cluster automatisch schalen is gedetecteerd: deze diagnose wordt weergegeven als beperking is gedetecteerd en afkomstig is van de automatische schaalaanpassing van clusters.
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 clusters naar virtuele-machineschaalsets te verminderen. Deze methode kan een negatieve latentie beïnvloeden voor de tijd die nodig is om omhoog te schalen, omdat de automatische schaalaanpassing van clusters langer wacht voordat azure Compute Resource Provider (CRP) wordt aangeroepen voor een nieuwe virtuele machine.
- Zorg ervoor dat het cluster een minimale Kubernetes-versie van 1.18 heeft. Kubernetes versie 1.18 en nieuwere versies verwerken de aanvraagsnelheid beter wanneer er 429 beperkingsreacties worden ontvangen. We raden u ten zeerste aan binnen ondersteunde Kubernetes-versies te blijven om beveiligingspatches te ontvangen.
Beperking - Azure Resource Manager: in deze diagnose ziet u 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.
Aanvraagsnelheid en beperkingsgegevens 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 van
management.azure.com
; alles 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 client-IP-adres dat de vertraagde aanvragen heeft verzonden.
- Host: De host waar HTTP-status 429-antwoorden zijn gedetecteerd. Azure Resource Manager-beperkingen zijn afkomstig van
Aanvraagbeperking kan worden veroorzaakt door een combinatie van een cluster in dit abonnement, niet alleen de aanvraagsnelheid voor dit cluster.
Voorbeeld 1: Beperking van automatische schaalaanpassing van clusters
In dit voorbeeld gaat het om het analyseren van beperking die wordt veroorzaakt door de automatische schaalaanpassing van clusters.
Als u merkt dat de beperking van cluster automatisch schalen is gedetecteerd in AKS diagnose en oplossing van bekende problemen>, beschikbaarheid en prestaties>van Azure Resource Request Throttling, wordt aangegeven 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 diagnostische gegevens van Azure Resource Manager .
U vindt het aantal ARM-aanvragen in dezelfde periode.
U kunt de aanvraagsnelheid weergeven en de diagnostische gegevens voor beperkingen controleren om de details van de beperking te vinden. Selecteer 429s per gebruikersagent in de vervolgkeuzelijst Filter selecteren en u kunt zien dat aanvragen voor automatische schaalaanpassing van 15:00 tot 16:00 worden beperkt.
U kunt ook het totale aantal vertraagde aanvragen voor de automatische schaalaanpassing van clusters en andere gebruikersagenten vinden.
U kunt ook beperkingen filteren op bewerkingen. In dit geval wordt de verwijderingsbewerking voor VMSS-VM's 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 bij 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 details van de beperking bekijken in de diagnose Aanvraagsnelheid weergeven en diagnostische gegevens beperken. Selecteer 429's per gebruikersagent in de vervolgkeuzelijst Filter selecteren en u kunt zien dat aanvragen van cloudproviders zijn beperkt van 03:00 tot 06:00 uur.
U kunt ook filteren op bewerkingen om erachter te komen dat de vertraagde bewerking 'Network/loadBalancers/read' is.
U kunt de op IP gebaseerde Load Balancer van de AKS-previewfunctie 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 Azure-feedbackcommunity.