vue d’ensemble de la mise à l’échelle Azure Kubernetes Service (AKS) : HPA, VPA, Mise à l’échelle automatique du cluster et KEDA

Lorsque vous exécutez des applications dans Azure Kubernetes Service (AKS), vous pouvez mettre à l’échelle des pods, des ressources de pod, des nœuds ou des charges de travail pilotées par les événements pour correspondre aux modifications de la demande. AKS prend en charge la mise à l’échelle manuelle, l’autoscaler horizontal de pods (HPA), l’autoscaler vertical de pods (VPA), Cluster Autoscaler, Kubernetes Event-driven Autoscaling (KEDA), l’approvisionnement automatique des nœuds et la mise à l’échelle en rafale avec Azure Container Instances (ACI).

Choisir la méthode de mise à l’échelle appropriée

Quand utiliser chaque méthode de mise à l’échelle

• Utilisez HPA lorsque votre charge de travail peut exécuter plusieurs réplicas identiques et que la demande varie en fonction du processeur, de la mémoire ou du taux de requête.
• Utilisez VPA lorsque votre charge de travail ne peut pas être mise à l’échelle horizontalement (non parallélisable) ou que vous devez effectuer des demandes de ressources de taille appropriée pour une meilleure planification.
• Utilisez Cluster Autoscaler lorsque vous disposez de pools de nœuds prédéfinis et devez ajouter ou supprimer des nœuds en fonction de la demande de pods en attente.
• Utilisez NAP lorsque vous souhaitez sélectionner automatiquement la référence SKU de machine virtuelle et l’approvisionnement de nœuds sans configurer manuellement les pools de nœuds.
• Utilisez KEDA lorsque la mise à l’échelle doit répondre aux événements externes (files d’attente, flux, messages) ou vous avez besoin d’une fonctionnalité de mise à l’échelle à zéro.
• Utilisez la mise à l’échelle en rafale ACI lorsque vous avez besoin d’une expansion rapide de la capacité pour les charges de travail Linux sans attendre l’approvisionnement de machines virtuelles (généralement 2 à 5 minutes).

Recommandation rapide

Pour la plupart des charges de travail de production, commencez par AKS Automatic, qui préconfigure NAP, VPA et KEDA. Dans AKS Standard, vous activez et configurez ces fonctionnalités explicitement.

Mettre à l’échelle des pods ou des nœuds manuellement

Vous pouvez redimensionner manuellement le nombre de réplicas de pod et de nœuds pour tester comment votre application réagit aux changements dans les ressources disponibles ou pour maintenir un niveau de capacité fixe. Pour effectuer une mise à l’échelle manuelle, définissez le nombre de réplicas ou de nœuds requis. Kubernetes crée ou supprime ensuite des pods, tandis qu’AKS ajoute ou supprime des nœuds du pool de nœuds applicable.

Lorsque vous effectuez un scale-down de nœuds, AKS appelle l'API de calcul Azure appropriée pour le type de calcul du cluster. Pour les clusters basés sur Virtual Machine Scale Sets, l’API Virtual Machine Scale Sets détermine les nœuds à supprimer. Pour plus d’informations, consultez la FAQ sur Virtual Machine Scale Sets.

Pour commencer, consultez :

• Mettre manuellement à l’échelle les nœuds d’un cluster AKS
• kubectl scale

Autoscaler de pods horizontaux

Utilisez HPA lorsque votre charge de travail peut être exécutée sur plusieurs réplicas identiques et que la demande varie. La mise à l’échelle s’effectue en fonction du CPU ou de la mémoire, des métriques d’application (requêtes par seconde, latence) ou des métriques externes de file d’attente et d’arriéré. Lorsque les répliques risquent de dépasser la capacité existante des nœuds, utilisez la fonctionnalité NAP préconfigurée dans AKS Automatic ou configurez Cluster Autoscaler ou NAP dans AKS Standard.

N’utilisez pas HPA et VPA sur les mêmes métriques de processeur ou de mémoire. Pour utiliser les deux autoscalers, utilisez VPA en mode recommandation ou configurez HPA pour utiliser des métriques personnalisées distinctes.

En savoir plus : Quand dois-je utiliser la mise à l’échelle automatique des pods horizontaux (HPA) dans Kubernetes ?

Voir aussi : Utiliser Vertical Pod Autoscaler dans AKS pour ajuster correctement les demandes de processeur et de mémoire des pods.

Autoscaler de pods verticaux

Vertical Pod Autoscaler analyse l’utilisation du processeur et de la mémoire des pods et recommande ou applique les demandes de ressources appropriées. Utilisez VPA pour ajuster correctement la taille des charges de travail qui ne peuvent pas être mises à l’échelle efficacement en ajoutant des répliques, ou pour améliorer l’ordonnancement et l’utilisation des ressources.

Selon son mode de mise à jour, VPA peut appliquer des recommandations lors de la création des pods, soit expulser et recréer des pods avec des demandes de ressources mises à jour. Passez en revue les exigences de disponibilité de la charge de travail avant d’autoriser l’application automatique des modifications par VPA.

Pour commencer, consultez Utiliser Vertical Pod Autoscaler dans AKS.

Autoscaler de cluster

Cluster Autoscaler ajuste le nombre de nœuds dans un groupe de nœuds en fonction des besoins de planification des pods. Il ajoute des nœuds lorsque les pods ne peuvent pas être programmés en raison d’une capacité insuffisante des nœuds et supprime les nœuds sous-utilisés lorsque leurs charges de travail peuvent s’exécuter ailleurs.

Cluster Autoscaler est couramment utilisé avec HPA. HPA ajuste le nombre de répliques de pods en fonction de la charge de travail, tandis que Cluster Autoscaler ajuste la capacité des nœuds pour accueillir ces pods.

Pour commencer, consultez Utiliser l’autoscaler de cluster dans AKS.

Événements de scale-out

Si un pool de nœuds n’a pas suffisamment de ressources de calcul pour un pod, le pod reste en attente. Lorsque Cluster Autoscaler détecte des pods qui ne peuvent pas être programmés en raison des contraintes de ressources du pool de nœuds, il augmente le nombre de nœuds dans ce pool de nœuds. Kubernetes planifie les pods en attente une fois les nouveaux nœuds approvisionnés et prêts.

L’approvisionnement de nœuds basés sur des machines virtuelles peut prendre plusieurs minutes. Pour les charges de travail avec une demande en rafale soudaine, envisagez d’utiliser des nœuds virtuels et des Azure Container Instances.

Événements de scale-in

Cluster AutoScaler surveille les nœuds pour la sous-utilisation et détermine si leurs pods peuvent s’exécuter sur d’autres nœuds. Lorsqu’un nœud n’est plus nécessaire, Kubernetes replanifie ses pods et AKS supprime le nœud du pool de nœuds.

Les opérations de mise à l’échelle peuvent perturber les charges de travail à mesure que les pods se déplacent entre les nœuds. Déployez plusieurs réplicas de pod et configurez des mécanismes de haute disponibilité appropriés pour minimiser les interruptions.

Mise à l’échelle automatique basée sur les événements Kubernetes

La mise à l’échelle automatique basée sur les événements Kubernetes (KEDA) est un composant open source qui met à l’échelle les charges de travail en fonction des événements. KEDA étend Kubernetes avec des ressources personnalisées, notamment ScaledObject, qui décrivent comment une charge de travail doit répondre à une source d’événement ou à une métrique.

KEDA est utile pour les charges de travail qui traitent des files d’attente, des flux, des messages ou d’autres backlogs d’événements. Il peut ramener à zéro les charges de travail prises en charge lorsqu’aucun événement n’est disponible, et augmenter le nombre de répliques à mesure que la file d’attente s’allonge.

Ne combinez pas un KEDA ScaledObject avec un HPA distinct pour la même charge de travail. KEDA crée et utilise un HPA en interne, de sorte que les autoscalers se concurrencent les uns avec les autres.

Pour commencer, consultez la vue d’ensemble du module complémentaire KEDA.

Auto-approvisionnement des nœuds

L’approvisionnement automatique des nœuds (NAP) s’appuie sur le projet open source Karpenter pour approvisionner et gérer les nœuds en fonction des besoins des pods en attente. NAP sélectionne une référence SKU de machine virtuelle appropriée et une quantité de nœuds pour répondre à la demande de charge de travail en temps réel.

NAP commence par un ensemble autorisé de références SKU de machine virtuelle et sélectionne la capacité des charges de travail en attente. Vous pouvez définir des limites de ressources et des préférences de planification pour contrôler la façon dont elle provisionne des nœuds et distribue les charges de travail.

Mise à l’échelle et protections du plan de contrôle

AKS met automatiquement à l’échelle les composants du plan de contrôle en fonction de la taille du cluster et de l’utilisation des ressources du serveur d’API. Ces recommandations s’appliquent à AKS Automatic et à AKS Standard. Utilisez le niveau tarifaire Standard ou Premium pour les charges de travail de production ou à grande échelle.

Kubernetes présente une plage de mise à l’échelle multidimensionnelle dans laquelle chaque type de ressource impose des exigences différentes au plan de contrôle. Par exemple, les secrets sont souvent surveillés par plusieurs contrôleurs et pods qui effectuent un appel initial LIST, ce qui crée une charge sur le plan de contrôle plus importante que celle générée par des ressources surveillées moins fréquemment. Une mise à l’échelle importante dans une dimension peut réduire la capacité dans d’autres. Par exemple, le fait d’exécuter des centaines de milliers de pods peut réduire le taux de mutation des pods pris en charge par le plan de contrôle. Pour obtenir des recommandations, consultez les meilleures pratiques des clients Kubernetes pour les clusters AKS à grande échelle.

Pour vérifier si le plan de contrôle est monté en charge, inspectez la ConfigMap large-cluster-control-plane-scaling-status :

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

La présence de ce ConfigMap confirme qu’AKS effectue un scale-up du plan de contrôle.

Protections du plan de contrôle

Si la mise à l’échelle automatique du serveur d’API ne la stabilise pas sous une charge élevée, AKS peut déployer une protection de serveur d’API managée. Cette protection de dernier recours limite les demandes des clients non système pour empêcher le plan de contrôle de ne pas répondre. Les appels au serveur d’API critiques pour le système provenant de composants tels que kubelet continuent de fonctionner.

Pour déterminer si la protection du serveur d’API managée a été appliquée, vérifiez les aks-managed-apiserver-guardFlowSchema points suivants :PriorityLevelConfiguration

kubectl get flowschemas
kubectl get prioritylevelconfigurations

La protection est active lorsque aks-managed-apiserver-guard apparaît dans les sorties des deux commandes.

Si ces ressources sont présentes, consultez le guide de résolution des problèmes du serveur d’API et etcd pour obtenir des conseils d’atténuation.

Intégration à Azure Container Instances (ACI)

Vous pouvez intégrer AKS à Azure Container Instances pour gérer les augmentations rapides de la demande. La mise à l’échelle automatique des pods peut créer plus de réplicas que le pool de nœuds existant, tandis que l’approvisionnement de nœuds basés sur des machines virtuelles supplémentaires peut prendre plusieurs minutes. ACI fournit une capacité de calcul sans nécessiter de nœuds de machine virtuelle supplémentaires.

Les nœuds virtuels (nœuds Kubernetes virtuels soutenus par ACI) prennent en charge les pods et nœuds Linux et nécessitent un cluster AKS qui utilise Azure mise en réseau CNI. Ils ne prennent pas en charge certains scénarios courants, notamment les plages d’adresses IP autorisées par le serveur d’API, les volumes persistants et les revendications de volume persistant, IPv6 et les identités managées attachées aux nœuds virtuels. Consultez les limitations des nœuds virtuels avant d’utiliser la mise à l’échelle en rafale avec ACI.

Le composant nœuds virtuels AKS est basé sur Virtual Kubelet et présente ACI en tant que nœud Kubernetes virtuel. Kubernetes peut planifier des pods éligibles via le nœud virtuel pour qu’ils s’exécutent en tant qu’instances de conteneur ACI au lieu d’être directement sur des nœuds de machine virtuelle AKS.

Les nœuds virtuels utilisent un autre sous-réseau dans le même réseau virtuel que le cluster AKS. Cette configuration fournit une connectivité réseau privée entre AKS et ACI tout en permettant à ACI d’agir comme une extension logique du cluster.

Contenu connexe

Utilisez les ressources suivantes pour implémenter la méthode de mise à l’échelle qui correspond à votre charge de travail :

• Mise à l’échelle des pods ou des nœuds
• Quand dois-je utiliser la mise à l’échelle automatique des pods horizontaux (HPA) dans Kubernetes ?
• Utiliser Vertical Pod Autoscaler dans AKS
• Utiliser la mise à l’échelle automatique du cluster dans AKS
• Utiliser le module complémentaire KEDA
• Utiliser le provisionnement automatique des nœuds
• Créer des nœuds virtuels avec Azure Container Instances

Pour plus d’informations sur les principaux concepts Kubernetes et AKS, consultez :

• Concepts de base d’AKS
• Accès et identité
• Sécurité
• Réseaux virtuels
• Stockage