L’autoscaling dans AKS

Aujourd’hui nous allons parler montée en charge dans Kubernetes grâce à l’horizontal pod autoscaler ! Nous verrons comment configurer cet autoscaling dans AKS 🙂

Le scaling consiste à augmenter ou diminuer le nombre d’instances d’une application. Cela permet par exemple de résister à un pic de charge si votre service est fortement sollicité par moments et très peu le reste du temps. On peut configurer grâce à Kubernetes l’upscale et le downscale pour s’adapter en temps réel aux besoins de nos utilisateurs.

Montée en charge manuelle

Avant de rentrer dans le vif du sujet, petite précision sur le scaling manuel : la commande kubectl scale vous permet de modifier instantanément le nombre d’instances dont vous souhaitez disposer pour exécuter votre application.

kubectl scale --replicas=5 deployment/myApp

Montée en charge automatique

Préparation du projet

Je vais ici créer un projet de type Application Web basée sur le Framework .Net Core 3.0, la dernière version stable en date.

Petite custom sur le site, quelle folie 🙂

Le Dockerfile que j’ai laissé tel quel :

Le code de l’application est disponible ici !

Préparation du cluster

Je provisionne un AKS avec le monitoring activé, comme expliqué ici et je vais utiliser une container registry pour déployer mon app comme expliqué dans ce tuto.

Si je vais sur mon cluster dans le portail Azure, on voit un nouvel onglet nommé déploiements pour le moment en préversion.

Le portail me propose un yaml pour activer la fonctionnalité, je vais donc en profiter pour la tester 🙂

J’applique mon yaml grâce à un kubectl create.

Et j’ai désormais accès à cet onglet, nous y reviendrons.

Autre fonctionnalité intéressante : la visualisation live des logs sur mes instances / pods / nodes instanciés :

Idem, nous y reviendrons.

Déploiement de mon application

Voici le yaml que j’ai écrit pour mon application :

L’élément qui va nous intéresser aujourd’hui est “ressources” avec la définition des propriétés requests et limits.

Requests, c’est ce que le pod est garanti d’avoir à sa disposition pour fonctionner. Ici mon container aura donc 100m de CPU et 15Mi de RAM.

Limits en revanche c’est une sécurité sur la consommation de ressources du container. Il ne pourra pas utiliser plus de 500m de CPU et 512Mi de RAM. Si il va au-delà, le pod sera détruit.

Les valeurs de CPU sont définis en milli-cores. Si vous avez besoin de deux VCPU il faudra indiquer 2000m. La notation “2” sera équivalente.

Pour la mémoire, les valeurs sont exprimées en bytes. Voir ce lien pour connaitre les différentes possibilités.

Déployons mon application :

Dans le dashboard, accessible via :

az aks browse --resource-group aks --name myAKSCluster

Je constate que mon déploiement s’est bien passé.

Dans services je peux obtenir l’url pour accéder à mon application :

Et valider que tout est OK.

Ajoutons de l’HPA

La commande kubectl autoscale crée un objet HorizontalPodAutoscaler (HPA) qui cible une ressource spécifiée et la fait évoluer si nécessaire. Le HPA ajuste périodiquement le nombre d’instances dupliquées de l’objectif de scaling de façon à respecter la valeur d’utilisation moyenne du processeur que vous spécifiez.

Après l’exécution de la commande kubectl autoscale, l’objet HorizontalPodAutoscaler est créé et commence à cibler l’application. En cas de modification de la charge, cet objet augmente ou réduit le nombre d’instances dupliquées de l’application.

https://cloud.google.com/kubernetes-engine/docs/how-to/scaling-apps?hl=fr#autoscaling-deployments

Ici, je vais demander un HPA sur mon application aspwebsitenetcore. Je lui indique de scaler entre 2 et 10 réplicas. L’upscale se fera si le pourcentage CPU consommé dépasse les 10% de ce qui est alloué, ici c’est donc 10% de 500millicores de CPU.

kubectl autoscale deployment aspwebsitenetcore --max 10 --min 2 --cpu-percent 10

Précision : La commande kubectl get hpa me permet d’afficher mes differents scaling mis en place sur mon cluster k8s.

Je constate qu’après la mise en place de mon HPA, j’ai désormais deux pods d’opérationnel ! Les appels vers mon site web seront automatiquement répartis vers ces deux pods via le loadbalancer de mon service.

Si je rééxecute un get hpa, je visualise dans la colonne targets ou ce situent mes conteneurs par rapport à la limite qu’on leur a fixée :

Dans mon live d’évènement je remarque également ce scaling qui s’est effectué :

Si je me place au niveau des conteneurs idem :

L’onglet intégrité rassemble des informations sur l’état de santé de mon cluster, je vous conseille d’aller y jeter un œil également :

Stress Test

Maintenant, je vais stresser un peu mon application et simuler un fort trafic sur mon site. En toute logique, l’autoscaling configuré pour mon cluster AKS doit intervenir et mon nombre de pods devraient se dupliquer. Pour ce faire j’écrit un batch qui fait un appel curl à mon site dans une boucle infinie.

Et je lance une dizaine d’instance de ce batch :

Assez rapidement, des événements m’informent du scale up :

J’ai maintenant 5 pods d’actif :

Puis 6 :

Mon site en tout cas est toujours fonctionnel :

Quand je stoppe le load, je vais constater l’inverse et voir progressivement mon nombre de pods diminuer :

Jusqu’à revenir à ma situation initiale :

Nous en avons finis avec cette façon de faire, je peux supprimer l’autoscaling de mon AKS grâce à la commande delete hpa [nom_hpa] :

Un autoscale déployé via un YAML

Et oui, il est possible de configurer un scaling via une description yaml comme celle-ci :

Je précise toujours sur quel déploiement je veux positionner mon scaling, un nombre de pod min et max et une condition ici représentée par “targetAverageValue” sur la consommation mémoire de mes conteneurs. Ici la montée en charge sera toujours entre 2 et 10 pods et le scale se fera si on dépasse les 32Mi de mémoire.

J’applique mon yaml :

Je relance mon batch :

Et de la même façon je vais voir rapidement mon nombre de pod augmenter. La valeur de RAM que j’ai positionnée pour activer le scaling étant assez faible, ça va vite.

Jusqu’à atteindre les 10 pods :

Que je retrouve bien sur mon dashboard :

De la même manière en stoppant la sollicitation du site le nombre de pods diminuera progressivement…

Et c’est tout pour aujourd’hui … Mais c’est déjà pas mal ! Nous avons :

• Préparer le scaling automatique pour notre application en définissant des requests et limits.
• Mis en place un autoscaling sur la charge CPU avec kubectl dans notre cluster AKS
• Configuré un HPA sur l’empreinte mémoire avec un yaml.

J’espère que ça vous a plu 🙂 A bientôt !

Thomas