Meilleures pratiques concernant le niveau de performance et la mise à l’échelle des charges de travail volumineuses dans Azure Kubernetes Service (AKS)

Lorsque vous déployez et gérez des clusters dans AKS, vous pouvez utiliser les meilleures pratiques suivantes pour optimiser le niveau de performance et la mise à l’échelle.

N’oubliez pas que volumineux est un terme relatif. Kubernetes a une enveloppe de mise à l’échelle multidimensionnelle et l’enveloppe de mise à l’échelle de votre charge de travail dépend des ressources que vous utilisez. Par exemple, un cluster avec 100 nœuds et des milliers de pods ou de CRD peut être considéré comme volumineux. Un cluster de 1 000 nœuds avec 1 000 pods et plusieurs autres ressources peut être considéré comme petit selon la perspective du plan de contrôle. Le meilleur signal de mise à l’échelle d’un plan de contrôle Kubernetes est le taux de réussite et la latence des requêtes HTTP du serveur d’API, car il s’agit d’un proxy pour la quantité de charge sur le plan de contrôle.

Cet article porte sur les points suivants :

Scalabilité du plan de contrôle Kubernetes et d’AKS

Dans AKS, un cluster se compose d’un ensemble de nœuds (machines virtuelles ou physiques) qui exécutent des agents Kubernetes et qui sont managés par le plan de contrôle Kubernetes hébergé par AKS. Alors qu’AKS optimise le plan de contrôle Kubernetes et ses composants pour la scalabilité et le niveau de performance, il est toujours lié par les limites du projet en amont.

Kubernetes a une enveloppe d’échelle multidimensionnelle avec chaque type de ressource représentant une dimension. Toutes les ressources ne sont pas les mêmes. Par exemple, les espions sont généralement définis sur des secrets. Ces secrets entraînent des appels de liste à kube-apiserver qui ajoutent des coûts et une charge disproportionnée plus élevée au plan de contrôle par rapport aux ressources sans espions.

Le plan de contrôle gère toute la mise à l’échelle des ressources dans le cluster. Par conséquent, plus vous mettez à l’échelle le cluster dans une dimension donnée, moins vous pouvez effectuer de mise à l’échelle dans d’autres dimensions. Par exemple, l’exécution de centaines de milliers de pods dans un cluster AKS a un impact sur la quantité d’attrition des pods (mutations de pods par seconde) que le plan de contrôle peut prendre en charge.

La taille de l’enveloppe est proportionnelle à la taille du plan de contrôle Kubernetes. AKS prend en charge trois niveaux de plan de contrôle dans le cadre de la référence SKU de base : Gratuit, Standard et Premium. Pour plus d’informations, consultez l’article Niveaux tarifaires Gratuit, Standard et Premium pour la gestion des clusters AKS.

Dans la plupart des cas, le dépassement du seuil de limite de mise à l’échelle entraîne une dégradation du niveau de performance, mais ne provoque pas le basculement immédiat du cluster. Pour gérer la charge sur le plan de contrôle Kubernetes, envisagez de mettre à l’échelle des lots allant jusqu’à 10 à 20 % de la mise à l’échelle actuelle. Par exemple, pour un cluster de 5 000 nœuds, effectuez une mise à l’échelle par incréments de 500 à 1 000 nœuds. AKS met automatiquement à l’échelle votre plan de contrôle, mais cette mise à l’échelle automatique ne se produit pas instantanément.

Vous pouvez tirer parti de l’API Priority and Fairness (APF) pour limiter des clients et des types de requêtes spécifiques, puis protéger ainsi le plan de contrôle en cas d’attrition et de charge élevées.

Clients Kubernetes

Les clients Kubernetes sont les clients d’applications, tels que les opérateurs ou les agents de surveillance, déployés dans le cluster Kubernetes qui doivent communiquer avec le serveur kube-api pour effectuer des opérations de lecture ou de mutation. Il est important d’optimiser le comportement de ces clients pour réduire la charge qu’ils ajoutent au serveur kube-api et au plan de contrôle Kubernetes.

Vous pouvez analyser le trafic du serveur d’API et le comportement du client via les journaux d’audit Kube. Si vous souhaitez en savoir plus, veuillez consultez la rubrique Résoudre les problèmes du plan de contrôle Kubernetes.

Les requêtes LIST peuvent être coûteuses. Lorsque vous travaillez avec des listes qui peuvent avoir plus de quelque milliers de petits objets ou plus de quelques centaines d’objets volumineux, vous devez prendre en compte les instructions suivantes :

• Prenez en compte le nombre d’objets (CR) que vous prévoyez d’exister éventuellement lors de la définition d’un nouveau type de ressource (CRD).
• La charge sur etcd et sur le serveur d’API repose principalement sur le nombre d’objets qui existent, et non sur le nombre d’objets retournés. Même si vous utilisez un sélecteur de champ pour filtrer la liste, puis récupérer uniquement un petit nombre de résultats, ces instructions s’appliquent toujours. La seule exception est la récupération d’un seul objet par metadata.name.
• Évitez les appels LIST répétés si possible si votre code doit conserver une liste mise à jour d’objets en mémoire. Au lieu de cela, nous vous recommandons d’utiliser les classes d’informateurs fournies dans la plupart des bibliothèques Kubernetes. Les informateurs combinent automatiquement les fonctionnalités LIST et WATCH pour gérer efficacement une collection en mémoire.
• Déterminez si vous avez besoin d’une cohérence forte si les informateurs ne répondent pas à vos besoins. Avez-vous besoin de voir les données les plus récentes, jusqu’au moment exact où vous avez émis la requête ? Sinon, définissez ResourceVersion=0. Ainsi, le cache du serveur d’API traite votre requête au lieu d’etcd.
• Si vous ne pouvez pas utiliser d’informateurs ou le cache du serveur d’API, lisez les grandes listes par blocs.
• Évitez de constituer des listes plus souvent que nécessaire. Si vous ne pouvez pas utiliser d’informateurs, tenez compte de la fréquence à laquelle votre application répertorie les ressources. Une fois que vous avez lu le dernier objet d’une liste volumineuse, n’interrogez pas immédiatement de nouveau la même liste. Vous devriez attendre un certain temps à la place.
• Prenez en compte le nombre d’instances en cours d’exécution de votre application cliente. Il y a une grande différence entre avoir un seul contrôleur répertoriant des objets et avoir des pods sur chaque nœud faisant la même chose. Si vous envisagez d’avoir plusieurs instances de votre application cliente répertoriant régulièrement un grand nombre d’objets, votre solution ne sera pas mise à l’échelle vers des clusters volumineux.

Limitation de l’API Azure et de la plateforme

La charge sur une application cloud peut varier au fil du temps, selon des facteurs tels que le nombre d’utilisateurs actifs ou les types d’activités effectués par les utilisateurs. Si les exigences de traitement du système dépassent la capacité des ressources disponibles, le système peut être surchargé et subir un niveau de performance médiocre et des défaillances.

Pour gérer différentes tailles de charge dans une application cloud, vous pouvez autoriser l’application à utiliser des ressources jusqu’à une limite spécifiée, puis les limiter lorsque la limite est atteinte. Sur Azure, la limitation se produit à deux niveaux. Azure Resource Manager (ARM) limite les requêtes pour l’abonnement et le tenant. Si la requête se trouve sous les limites de limitation pour l’abonnement et le tenant, ARM achemine la requête vers le fournisseur de ressources. Le fournisseur de ressources applique alors des limites de limitation adaptées à ses opérations. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Requêtes de limitations ARM.

Gérer la limitation dans AKS

Les limites d’API Azure sont généralement définies au niveau d’une combinaison de région d’abonnement. Par exemple, tous les clients au sein d’un abonnement dans une région donnée partagent des limites d’API pour une API Azure donnée, comme les API PUT Virtual Machine Scale Sets. Chaque cluster AKS a plusieurs clients appartenant à AKS, tels que le fournisseur de cloud ou le système de mise à l’échelle automatique de cluster, ou les clients appartenant au client, tels que Datadog ou Prometheus auto-hébergé, qui appellent des API Azure. Lors de l’exécution de plusieurs clusters AKS dans un abonnement dans une région donnée, tous les clients appartenant à AKS et appartenant au client au sein des clusters partagent un ensemble commun de limites d’API. Par conséquent, le nombre de clusters que vous pouvez déployer dans une région d’abonnement varie en fonction du nombre de clients déployés, de leurs modèles d’appel et de l’échelle globale et de l’élasticité des clusters.

Gardez à l’esprit les considérations ci-dessus. Les clients sont généralement en mesure de déployer entre 20 et 40 clusters de petite à moyenne échelle par région d’abonnement. Vous pouvez agrandir votre échelle d’abonnement à l’aide des meilleures pratiques suivantes :

Mettez toujours à niveau vos clusters Kubernetes vers la dernière version. Les versions plus récentes contiennent de nombreuses améliorations qui résolvent les problèmes de niveau de performance et de limitation. Si vous utilisez une version mise à niveau de Kubernetes et que vous voyez toujours la limitation en raison de la charge réelle ou du nombre de clients dans l’abonnement, vous pouvez essayer les options suivantes :

• Analyser les erreurs à l’aide d’AKS Diagnose and Solve Problems (Diagnostiquer et résoudre les problèmes) : vous pouvez utiliser AKS Diagnose and Solve Problems pour analyser les erreurs, identifier la cause racine, puis obtenir des recommandations de résolution.
  • Augmenter l’intervalle d’analyse de mise à l’échelle automatique du cluster : si les rapports de diagnostic montrent qu’une limitation de mise à l’échelle automatique du cluster a été détectée, vous pouvez augmenter l’intervalle d’analyse pour réduire le nombre d’appels à Virtual Machine Scale Sets depuis Cluster Autoscaler.
  • Reconfigurer les applications tierces pour effectuer moins d’appels : si vous effectuez un filtrage par agents utilisateurs dans le diagnostic Afficher le taux de requêtes et les détails de limitation et voyez qu’une application tierce, telle qu’une application de surveillance, crée un grand nombre de requêtes GET, vous pouvez modifier les paramètres de ces applications pour réduire la fréquence des appels GET. Assurez-vous que les clients d’application utilisent un backoff exponentiel lors de l’appel d’API Azure.
• Fractionner vos clusters en plusieurs abonnements ou régions : si vous avez un grand nombre de clusters et de pools de nœuds qui utilisent Virtual Machine Scale Sets, vous pouvez les fractionner en plusieurs abonnements ou régions au sein du même abonnement. La plupart des limites d’API Azure sont partagées au niveau de l’abonnement-de la région. Vous pouvez donc déplacer ou mettre à l’échelle vos clusters vers plusieurs abonnements ou régions pour être débloqué sur la limitation des API Azure. Cette option est particulièrement utile si vous attendez que vos clusters aient une activité élevée. Il n’existe aucune directive générique pour ces limites. Si vous souhaitez obtenir une aide spécifiques, vous pouvez créer un ticket de support.

Limites des fonctionnalités

À mesure que vous mettez à l’échelle vos clusters AKS vers des points d’échelle plus importants, gardez à l’esprit les limitations des fonctionnalités suivantes :

• AKS prend en charge le scale-up jusqu’à 5 000 nœuds par défaut pour tous les clusters de niveau Standard/LTS. AKS met à l’échelle le plan de contrôle de votre cluster au moment de l’exécution en fonction de la taille du cluster et de l’utilisation des ressources du serveur d’API. Si vous ne pouvez pas effectuer un scale-up jusqu’à la limite prise en charge, activez les métriques du plan de contrôle (préversion) avec le service managé Azure Monitor pour Prometheus afin de surveiller le plan de contrôle. Pour résoudre les problèmes de performances ou de fiabilité de la mise à l’échelle, consultez les ressources suivantes :
  • Guide de résolution des problèmes d’AKS à l’échelle
  • Résoudre les problèmes du plan de contrôle Kubernetes

• Azure Network Policy Manager (Azure npm) prend uniquement en charge jusqu’à 250 nœuds.
• Certaines métriques de nœud AKS, notamment l’utilisation du disque de nœud, l’utilisation du processeur/mémoire du nœud et les entrées/sorties du réseau, ne seront pas accessibles dans les métriques de plateforme Azure Monitor une fois le scale-up du plan de contrôle terminé. Pour vérifier si votre plan de contrôle a fait l’objet d’un scale-up, recherchez le configmap « control-plane-scaling-status ».

kubectl describe configmap control-plane-scaling-status -n kube-system

• Vous ne pouvez pas utiliser la fonctionnalité Arrêter et démarrer avec les clusters qui ont plus de 100 nœuds. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Arrêter et démarrer un cluster AKS.

Mise en réseau

À mesure que vous mettez à l’échelle vos clusters AKS vers des points d’échelle plus importants, gardez à l’esprit les meilleures pratiques de mise en réseau suivantes :

• Utilisez NAT managé pour la sortie de cluster avec au moins deux adresses IP publiques sur la passerelle NAT. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Créer une passerelle NAT managée pour votre cluster AKS.
• Utilisez la superposition Azure CNI pour effectuer un scale-up jusqu’à 200 000 pods et 5 000 nœuds par cluster. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Configurer la mise en réseau de la superposition Azure CNI Overlay dans AKS.
• Si votre application a besoin d’une communication directe pod-à-pod entre clusters, utilisez Azure CNI avec l’allocation d’adresses IP dynamiques et mettez à l’échelle jusqu’à 50 000 pods d’application par cluster avec une adresse IP routable par pod. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Configurer la mise en réseau d’Azure CNI pour l’allocation d’adresses IP dynamiques dans AKS.
• Lorsque vous utilisez des services Kubernetes internes derrière un équilibreur de charge interne, nous recommandons de créer un équilibreur de charge interne ou un service inférieur à une échelle de 750 nœuds pour optimiser le niveau de performance de mise à l’échelle et l’élasticité de l’équilibreur de charge.
• Azure npm ne prend en charge que 250 nœuds au maximum. Si vous souhaitez appliquer des stratégies réseau pour les clusters plus volumineux, nous vous recommandons d’utiliser Azure CNI avec Cilium, qui combine le plan de contrôle robuste d’Azure CNI avec le plan de données Cilium pour fournir une mise en réseau et une sécurité hautes performances.

Mise à l’échelle du pool de nœuds

À mesure que vous mettez à l’échelle vos clusters AKS vers des points d’échelle plus volumineux, gardez à l’esprit les meilleures pratiques de mise en réseau suivantes :

• Pour les pools de nœuds système, utilisez la référence SKU Standard_D16ds_v5 ou une référence SKU de machine virtuelle de noyau/mémoire équivalente avec des disques de système d’exploitation éphémères pour fournir des ressources de calcul suffisantes pour les pods kube-system.
• Étant donné qu’AKS a une limite de 1 000 nœuds par pool de nœuds, nous vous recommandons de créer au moins cinq pools de nœuds d’utilisateurs pour mettre à l’échelle jusqu’à 5 000 nœuds.
• Lors de l’exécution de clusters AKS à l’échelle, utilisez l’autoscaler de cluster chaque fois que possible pour assurer une mise à l’échelle dynamique des pools de nœuds en fonction de la demande de ressources de calcul. Pour plus d’informations, consultez Mettre automatiquement à l’échelle un cluster AKS pour répondre aux demandes applicatives.
• Si vous mettez à l'échelle plus de 1 000 nœuds sans utiliser l’autoscaler de cluster, nous vous recommandons de le faire par lots de 500 à 700 nœuds maximum à la fois. Les opérations de mise à l’échelle doivent avoir une durée de veille de deux minutes à cinq minutes entre les opérations de scale-up pour empêcher les limitations des API Azure. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Gestion des API : stratégies de mise en cache et de limitation.

Considérations relatives à la mise à niveau du cluster et meilleures pratiques

• Lorsqu’un cluster atteint la limite de 5 000 nœuds, les mises à niveau du cluster sont bloquées. Cette limite empêche une mise à niveau, car il n’existe pas de capacité de nœud disponible pour effectuer des mises à jour propagées dans la limite de la propriété max surge. Si un cluster a atteint cette limite, nous vous recommandons d’effectuer un scale-down du cluster pour atteindre moins de 3 000 nœuds avant d’essayer une mise à niveau du cluster. Vous disposerez ainsi d’une capacité supplémentaire pour l’attrition des nœuds et réduirez la charge sur le plan de contrôle.
• Lors de la mise à niveau de clusters avec plus de 500 nœuds, il est recommandé d’utiliser une configuration de surtension maximale correspondant à 10-20 % de la capacité du pool de nœuds. AKS configure les mises à niveau avec une valeur par défaut de 10 % pour la surtension maximale. Vous pouvez personnaliser les paramètres max surge par pool de nœuds pour obtenir un compromis entre la vitesse de mise à niveau et l’interruption de la charge de travail. Lorsque vous augmentez les paramètres de surtension maximale, le processus de mise à niveau se termine plus rapidement, mais vous risquez de subir des interruptions pendant le processus de mise à niveau. Pour plus d’informations, consultez Personnaliser la mise à niveau de l’augmentation des nœuds.
• Pour plus d’informations sur la mise à jour de cluster, consultez Mettre à niveau un cluster AKS.