429 Erreurs de requêtes trop nombreuses

Cet article explique comment résoudre les défaillances provoquées par des erreurs « 429 Trop de requêtes » sur vos clusters AKS (Microsoft Azure Kubernetes Service) (ou clusters qui utilisent une autre implémentation Kubernetes sur Azure).

Symptômes

Vous recevez des erreurs qui ressemblent au texte suivant :

Le service a retourné une erreur.

Status=429

Code="OperationNotAllowed »

Message="Le serveur a rejeté la demande, car trop de demandes ont été reçues pour cet 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"}"}

Cause : Les volumes d’appels excessifs entraînent la limitation de votre abonnement par Azure

Un cluster Kubernetes sur Azure (avec ou sans AKS) qui effectue un scale-up ou un scale-down fréquent, ou utilise l’autoscaler de cluster, peut provoquer un volume important d’appels HTTP. Ce volume d’appels peut entraîner un échec, car il dépasse le quota attribué pour votre abonnement Azure.

Pour plus d’informations sur ces erreurs, consultez Limitation des requêtes Azure Resource Manager et Résolution des erreurs de limitation d’API. Pour plus d’informations sur la façon d’analyser et d’identifier la cause de ces erreurs et d’obtenir des recommandations pour les résoudre, consultez Analyser et identifier les erreurs à l’aide du diagnostic et de la résolution des problèmes AKS.

Solution 1 : Mise à niveau vers une version ultérieure de Kubernetes

Exécutez Kubernetes 1.18. x ou version ultérieure. Ces versions contiennent de nombreuses améliorations décrites dans Les erreurs de limitation AKS/429 et Prise en charge des clusters volumineux sans limitation. Toutefois, si vous constatez toujours une limitation (en raison de la charge réelle ou du nombre de clients dans l’abonnement), vous pouvez essayer les solutions suivantes.

Solution 2 : Augmenter l’intervalle d’analyse du programme de mise à l’échelle automatique

Si vous constatez que les rapports de diagnostic « La limitation de mise à l’échelle automatique du cluster ont été détectés » signale une limitation causée par le programme de mise à l’échelle automatique du cluster, vous pouvez essayer d’augmenter l’intervalle d’analyse du programme de mise à l’échelle automatique pour réduire le nombre d’appels aux groupes de machines virtuelles identiques (VMSS) à partir de l’autoscaler de cluster.

Solution 3 : Reconfigurer les applications tierces pour effectuer moins d’appels

Lorsque vous filtrez par agents utilisateur dans le diagnostic « Afficher le taux de demandes et les détails de limitation », si vous trouvez des applications tierces (telles que des applications de surveillance) qui effectuent un nombre excessif de requêtes GET, modifiez les paramètres de ces applications pour réduire la fréquence des appels GET. En outre, assurez-vous que les clients d’application utilisent une interruption exponentielle lors de l’appel d’API Azure.

Solution 4 : Fractionner vos clusters en différents abonnements ou régions

S’il existe de nombreux clusters et pools de nœuds qui utilisent des groupes de machines virtuelles identiques, essayez de fractionner les clusters en différents abonnements ou régions (au sein du même abonnement). La plupart des limites de l’API Azure sont des limites partagées au niveau de la région de l’abonnement. Par exemple, tous les clusters et clients au sein du sous-un et de la région USA Est partagent une limite pour l’API GET des groupes de machines virtuelles identiques. Par conséquent, vous pouvez déplacer ou mettre à l’échelle de nouveaux clusters AKS dans une nouvelle région et obtenir un déblocage sur la limitation de l’API Azure. Cette technique est utile si vous vous attendez à ce que les clusters aient une activité élevée (par exemple, si vous avez un autoscaler de cluster actif). Il est également utile si vous avez de nombreux clients (tels que Rancher, Terraform, etc.). Étant donné que tous les clusters sont différents par leur élasticité et le nombre de clients interrogeant les API Azure, il n’existe aucune directive générique sur le nombre de clusters que vous pouvez exécuter par niveau région d’abonnement. Pour obtenir des conseils spécifiques, vous pouvez créer un ticket de support.

Analyser et identifier les erreurs à l’aide d’AKS Diagnostiquer et résoudre les problèmes

Pour un cluster AKS, vous pouvez utiliser AKS Diagnostiquer et résoudre les problèmes pour analyser et identifier la cause de ces erreurs et obtenir des recommandations pour les résoudre. Accédez à votre cluster dans le Portail Azure, puis sélectionnez Diagnostiquer et résoudre les problèmes dans le volet de navigation gauche pour ouvrir AKS Diagnostiquer et résoudre les problèmes. Recherche et ouvrez la limitation des demandes de ressources Azure, où vous pouvez obtenir un rapport avec une série de diagnostics. Ces diagnostics peuvent indiquer si le cluster a subi une limitation du taux de requêtes (429 réponses) d’Azure Resource Manager (ARM) ou de fournisseur de ressources (RP) et d’où provient la limitation. Par exemple :

  • Une limitation du taux de requête a été détectée pour votre cluster : ce diagnostic fournit des recommandations générales si une limitation a été détectée dans le cluster AKS actuel.

  • La limitation de mise à l’échelle automatique du cluster a été détectée : ce diagnostic s’affiche si la limitation a été détectée et provient de la mise à l’échelle automatique du cluster.

    Pour réduire le volume des demandes provenant de l’autoscaler de cluster, utilisez les méthodes suivantes :

    • Augmentez l’intervalle d’analyse du programme de mise à l’échelle automatique pour réduire le nombre d’appels de l’autoscaler de cluster vers des groupes de machines virtuelles identiques. Cette méthode peut avoir un impact négatif sur la latence sur le temps nécessaire au scale-up, car l’autoscaler de cluster attend plus longtemps avant d’appeler le fournisseur de ressources de calcul Azure (CRP) pour une nouvelle machine virtuelle.
    • Vérifiez que le cluster se trouve sur une version minimale de Kubernetes 1.18. Kubernetes version 1.18 et versions ultérieures gèrent mieux le taux d’interruption des requêtes lorsque des réponses de limitation 429 sont reçues. Nous vous recommandons vivement de rester dans les versions de Kubernetes prises en charge pour recevoir les correctifs de sécurité.
  • Limitation - Azure Resource Manager : ce diagnostic indique le nombre de demandes limitées dans l’intervalle de temps spécifié dans le cluster AKS.

  • Taux de demandes - Azure Resource Manager : ce diagnostic indique le nombre total de demandes dans l’intervalle de temps spécifié dans le cluster AKS.

  • Afficher le taux de requêtes et les détails de la limitation : ce diagnostic comporte plusieurs diagrammes pour déterminer les détails de la limitation, notamment les demandes limitées et le nombre total de demandes. Vous pouvez également filtrer les résultats à l’aide des dimensions suivantes :

    • Hôte : hôte où les réponses HTTP status 429 ont été détectées. Azure Resource Manager les limitations proviennent ; management.azure.comtout le reste est un fournisseur de ressources de couche inférieure.
    • Agent utilisateur : demandes avec un agent utilisateur spécifié qui ont été limitées.
    • Opération : opérations où des réponses HTTP status 429 ont été détectées.
    • Adresse IP du client : adresse IP du client qui a envoyé les demandes limitées.

La limitation des demandes peut être due à une combinaison de n’importe quel cluster de cet abonnement, et pas seulement au taux de requêtes pour ce cluster.

Exemple 1 : Limitation de la mise à l’échelle automatique de cluster

Cet exemple concerne l’analyse de la limitation provoquée par le générateur de mise à l’échelle automatique de cluster.

Si vous constatez que le diagnostic De limitation de mise à l’échelle automatique de cluster a été détecté dans Diagnostic et résolution des problèmes>AKS Problèmes connus, disponibilité et performances>Limitation des demandes de ressources Azure, cela indique que les demandes émises par le générateur automatique de mise à l’échelle du cluster ont été limitées.

Diagramme montrant la limitation des demandes de mise à l’échelle automatique de cluster détectée.

Vous trouverez le nombre de demandes limitées et le moment où elles sont limitées dans le diagnostic Limitation - Azure Resource Manager.

Diagramme montrant quand les demandes de mise à l’échelle automatique de cluster sont limitées.

Vous trouverez le nombre de toutes les requêtes ARM au cours de la même période.

Diagramme de toutes les requêtes ARM.

Vous pouvez case activée le diagnostic Afficher le taux de requêtes et limiter les détails pour rechercher les détails de la limitation. Sélectionnez 429s by User Agent dans la liste déroulante Sélectionner un filtre , et vous pouvez voir que les demandes de mise à l’échelle automatique sont limitées de 15 :00 à 16 :00.

Diagramme des limitations par agents utilisateur.

Vous pouvez également trouver le nombre total de demandes limitées pour le générateur de mise à l’échelle automatique du cluster et d’autres agents utilisateur.

Diagramme des limitations totales par agent utilisateur.

Vous pouvez également filtrer les limitations par opérations. L’opération de suppression de machine virtuelle VMSS est limitée dans ce cas.

Diagramme des limitations par opérations.

Vous trouverez le nombre de demandes limitées et toutes les demandes regroupées par opérations.

Diagramme des limitations totales par opérations.

Ensuite, vous pouvez suivre les suggestions de l’action recommandée pour réduire les limitations.

Diagramme montrant que la limitation des demandes de mise à l’échelle automatique de cluster est détectée.

Exemple 2 : Limitation du fournisseur de cloud

Cet exemple concerne les limitations provoquées par le fournisseur de cloud. Cela se produit souvent lors de l’exploitation de ressources dans des clusters plus volumineux, par exemple l’approvisionnement d’un Azure Load Balancer dans un cluster qui a plus de 500 nœuds.

Si vous constatez une limitation dans votre cluster, vous pouvez voir les détails de la limitation dans le diagnostic Afficher le taux de requêtes et les détails de la limitation . Sélectionnez 429s by User Agent (429s by User Agent ) dans la liste déroulante Sélectionner un filtre , et vous pouvez voir que les demandes du fournisseur de cloud ont été limitées de 03 :00 à 06 :00.

Diagramme montrant la détection d’une limitation.

Diagramme des limitations par agent utilisateur.

Vous pouvez également filtrer par opérations pour déterminer que l’opération limitée est « Network/loadBalancers/read ».

Diagramme des limitations par opération.

Vous pouvez utiliser la fonctionnalité de préversion AKS Load Balancer basée sur l’adresse IP du nœud pour réduire cette limitation.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.