Partage via

Options de mise à l’échelle des applications dans AKS (Azure Kubernetes Service)

  • Article

Quand vous exécutez des applications dans Azure Kubernetes Service (AKS), vous pouvez avoir besoin d’augmenter ou de diminuer la quantité de ressources de calcul. Lorsque vous changez le nombre des instances d’application qui vous avez, il vous faudra peut-être changer le nombre de nœuds Kubernetes sous-jacent. Par ailleurs, vous pourriez avoir besoin d’approvisionner un grand nombre d’autres instances d’application.

Cet article présente les principaux concepts de mise à l’échelle des applications AKS, notamment la mise à l’échelle manuelle des pods ou des nœuds, l’utilisation de la mise à l’échelle automatique des pods horizontaux, l’utilisation de la mise à l’échelle automatique de cluster et l’intégration à Azure Container Instances (ACI).

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

Vous pouvez mettre à l’échelle des réplicas, des pods et des nœuds manuellement pour tester la façon dont votre application répond à une modification au niveau des ressources disponibles et de l’état. Mettre à l’échelle manuellement les ressources vous permet de définir une quantité donnée de ressources à utiliser pour maintenir un coût fixe, par exemple le nombre de nœuds. Pour mettre à l’échelle manuellement, vous définissez le nombre de réplicas ou de nœuds. L’API Kubernetes planifie ensuite la création de pods supplémentaires ou le drainage de nœuds en fonction du nombre de réplicas ou de nœuds.

Lors d’un scale-down des nœuds, l’API Kubernetes appelle l’API de calcul Azure appropriée liée au type de calcul utilisé par votre cluster. Par exemple, pour les clusters basés sur Virtual Machine Scale Sets, l’API Virtual Machine Scale Sets détermine les nœuds à supprimer. Pour en savoir plus sur la façon dont les nœuds sont sélectionnés pour la suppression lors d’un scale-down, consultez les Questions fréquentes (FAQ) sur VMSS.

Pour bien commencer avec la mise à l’échelle manuelle des nœuds, consultez Mettre à l’échelle manuellement des nœuds dans un cluster AKS. Pour mettre à l’échelle manuellement le nombre de pods, consultez Commande kubectl scale.

Autoscaler de pods élastique

Kubernetes utilise la mise à l’échelle automatique horizontale de pods pour superviser la demande en ressources et adapter automatiquement le nombre de pods. Par défaut, le HPA vérifie l’API Metrics toutes les 15 secondes pour toute modification requise du nombre de réplicas et l’API Metrics récupère les données de Kubelet toutes les 60 secondes. Le HPA est donc mis à jour toutes les 60 secondes. Lorsque des modifications sont nécessaires, le nombre de réplicas est augmenté ou diminué en conséquence. HPA fonctionne avec les clusters AKS qui ont déployé le serveur de métriques pour Kubernetes version 1.8 et ultérieures.

Mise à l’échelle de pods élastique Kubernetes

Lorsque vous configurez le HPA pour un déploiement donné, vous définissez le nombre minimal et maximal de réplicas qui peuvent s’exécuter. Vous précisez également la métrique à surveiller et sur laquelle baser vos décisions de mise à l’échelle, par exemple l’utilisation du processeur.

Pour vous familiariser avec l’autoscaler de pods élastique dans AKS, consultez Mettre à l’échelle des pods dans AKS.

Ralentissement des événements de mise à l’échelle

Étant donné que le HPA est mis à jour toutes les 60 secondes, les événements de mise à l’échelle précédents peuvent ne pas être totalement terminés avant la vérification suivante. Ce comportement peut pousser le HPA à modifier le nombre de réplicas avant même que l’événement de mise à l’échelle précédent ait pu recevoir la charge de travail de l’application, et que les demandes en ressources soient ajustées en conséquence.

Pour réduire le nombre d’événements de concurrence, une valeur de délai est définie. Cette valeur précise la durée pendant laquelle le HPA doit attendre, entre la fin d’un événement de mise à l’échelle et le déclenchement d’un autre événement de mise à l’échelle. Ce comportement permet au nouveau nombre de réplicas d’être pris en compte, et à l’API de métriques de refléter la charge de travail distribuée. Il n’y a aucun délai pour les événements de scale-up à partir de Kubernetes 1.12. Toutefois, le délai standard des événements de scale-down est de 5 minutes.

Autoscaler de cluster

Pour répondre aux demandes changeantes de pods, la mise à l’échelle automatique de cluster Kubernetes ajuste le nombre de nœuds en fonction des ressources de calcul demandées dans le pool de nœuds. Par défaut, l’autoscaler de cluster vérifie le serveur d’API de métriques toutes les 10 secondes à la recherche de toute modification à apporter au nombre de nœuds. Si l’autoscaler de cluster détermine qu’un changement est nécessaire, le nombre de nœuds de votre cluster AKS augmente ou diminue selon le cas. L’autoscaler de cluster fonctionne avec les clusters AKS avec RBAC Kubernetes qui exécutent Kubernetes versions 1.10.x ou ultérieures.

Autoscaler de cluster Kubernetes

La mise à l’échelle automatique de cluster est généralement utilisé parallèlement à la mise à l’échelle automatique horizontale de pods. Lorsqu’ils sont combinés, l’autoscaler de pod horizontal augmente ou diminue le nombre de pods en fonction de la demande des applications, tandis que l’autoscaler de cluster ajuste le nombre de nœuds pour exécuter davantage de pods.

Pour vous familiariser avec la mise à l’échelle automatique de cluster dans AKS, consultez mise à l’échelle automatique de cluster sur AKS.

Événements de scale-out

Si les ressources de calcul d’un nœud sont insuffisantes pour l’exécution d’un pod demandé, ce pod ne peut pas avancer dans le processus de planification. Le pod ne peut pas démarrer, sauf si davantage de ressources de calcul sont disponibles dans le pool de nœuds.

Lorsque l’autoscaler de cluster remarque que des pods ne sont pas panifiables en raison de contraintes liées aux ressources du pool de nœuds, le nombre de nœuds à l’intérieur de ce pool est augmenté pour fournir les ressources de calcul supplémentaires. Lorsque les nœuds sont correctement déployés et utilisables au sein du pool de nœuds, les pods sont alors planifiés pour s’exécuter sur eux.

Si votre application doit rapidement se mettre à l'échelle, il est possible que certains pods restent en état d’attente de planification, jusqu’à ce que les nœuds supplémentaires déployés par l’autoscaler de cluster puissent accepter les pods planifiés. Pour les applications qui présentent des demandes de croissance extrêmement forte et rapide, vous pouvez mettre à l’échelle au moyen de nœuds virtuels et de Azure Container Instances.

Événements de scale-in

L’autoscaler de cluster surveille également le statut de planification des pods pour les nœuds qui n’ont pas reçu récemment de nouvelles demandes de planification. Ce scénario indique que le pool de nœuds détient plus de ressources de calcul que nécessaire et que le nombre de nœuds peut être réduit. Par défaut, les nœuds qui atteignent le seuil pour lequel ils ne sont plus nécessaire pendant 10 minutes a une suppression programmé. Lorsque cette situation se produit, les pods sont planifiés pour s’exécuter sur d’autres nœuds au sein du pool de nœuds tandis que l’autoscaler de cluster réduit le nombre de nœuds.

Vos applications peuvent rencontrer quelques perturbations au moment où les pods sont planifiés sur des nœuds différents et que l’autoscaler de cluster diminue le nombre de nœuds. Pour limiter ces perturbations, évitez les applications qui utilisent une seule instance de pod.

Kubernetes Event-driven Autoscaling (KEDA)

Kubernetes Event-driven Autoscaling (KEDA) est un composant open source de mise à l’échelle automatique pilotée par les événements pour les charges de travail. Les charges de travail sont mises à l’échelle de manière dynamique en fonction du nombre d’événements reçus. KEDA étend Kubernetes avec une définition de ressource personnalisée (CRD, Custom Resource Definition), appelée ScaledObject, qui décrit la façon dont les applications doivent être mises à l’échelle en réponse à un trafic spécifique.

La mise à l’échelle KEDA est utile dans les scénarios où les charges de travail reçoivent des pics de trafic ou gèrent des volumes élevés de données. KEDA est différent d’Horizontal Pod Autoscaler. En effet, KEDA est piloté par les événements et effectue une mise à l’échelle en fonction du nombre d’événements, tandis que HPA est piloté par des métriques et est basé sur l’utilisation des ressources (par exemple, le processeur et la mémoire).

Pour commencer à utiliser le module complémentaire KEDA dans AKS, consultez la vue d’ensemble de KEDA.

Intégration à Azure Container Instances (ACI)

Pour faire évoluer rapidement votre cluster AKS, vous pouvez intégrer Azure Container Instances (ACI). Kubernetes dispose de composants intégrés pour mettre à l’échelle le nombre de réplicas et de nœuds. Toutefois, si votre application doit rapidement s’adapter, l’la mise à l’échelle automatique horizontale de pods peut planifier plus de pods que la quantité pouvant être fournie par les ressources de calcul existantes dans le pool de nœuds. S’il est configuré, ce scénario oblige l’autoscaler de cluster à déployer davantage de nœuds dans le pool de nœuds, mais quelques minutes peuvent être nécessaires pour que ces nœuds soient correctement approvisionnés et permettent au planificateur Kubernetes d’y exécuter des pods.

Mise à l'échelle rapide de Kubernetes sur ACI

ACI vous permet de déployer rapidement des instances de conteneur sans surcharge d’infrastructure supplémentaire. Lorsque vous vous connectez à AKS, ACI devient une extension logique et sécurisée de votre cluster AKS. Le composant nœuds virtuels, qui est basé sur virtual Kubelet, est installé dans votre cluster AKS qui présente ACI comme un nœud Kubernetes virtuel. Kubernetes peut alors planifier les pods s’exécutant en tant qu’instances ACI via des nœuds virtuels, et non en tant que pods sur des nœuds de machine virtuelle, directement dans votre cluster AKS.

Votre application n’a besoin d’aucune modifications pour utiliser les nœuds virtuels. Vos déploiements peuvent mettre à l’échelle dans AKS et ACI, et sans aucun délai car la mise à l’échelle automatique de cluster déploie les nouveaux nœuds dans votre cluster AKS.

Les nœuds virtuels sont déployés sur un autre sous-réseau dans le même réseau virtuel que votre cluster AKS. Cette configuration de réseau virtuel sécurise le trafic entre ACI et AKS. À l’instar d’un cluster AKS, une instance ACI est une ressource de calcul logique, sécurisée, isolée des autres utilisateurs.

Étapes suivantes

Pour bien commencer la mise à l’échelle des applications, consultez les ressources suivantes :

Pour plus d’informations sur les concepts fondamentaux de Kubernetes et d’AKS, consultez les articles suivants :