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.

aks - L'autoscaling dans AKS

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.

1 1024x712 - L'autoscaling dans AKS

Petite custom sur le site, quelle folie 🙂

2 1024x695 - L'autoscaling dans AKS

Le Dockerfile que j’ai laissé tel quel :

3 - L'autoscaling dans AKS

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.

5 1024x147 - L'autoscaling dans AKS

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

6 1024x436 - L'autoscaling dans AKS

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

7 - L'autoscaling dans AKS

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

8 - L'autoscaling dans AKS

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

9 1024x369 - L'autoscaling dans AKS

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

10 1024x583 - L'autoscaling dans AKS

Idem, nous y reviendrons.

Déploiement de mon application

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

11 - L'autoscaling dans AKS

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 :

12 - L'autoscaling dans AKS

Dans le dashboard, accessible via :

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

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

13 1024x498 - L'autoscaling dans AKS

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

14 1024x213 - L'autoscaling dans AKS

Et valider que tout est OK.

15 1024x214 - L'autoscaling dans AKS

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

17 1024x110 - L'autoscaling dans AKS

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.

18 1024x176 - L'autoscaling dans AKS

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 :

19 1024x99 - L'autoscaling dans AKS

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

20 1024x690 - L'autoscaling dans AKS

Si je me place au niveau des conteneurs idem :

21 1024x661 - L'autoscaling dans AKS

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 :

22 1024x495 - L'autoscaling dans AKS

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.

25 - L'autoscaling dans AKS

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

26 1024x621 - L'autoscaling dans AKS

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

27 1024x476 - L'autoscaling dans AKS

J’ai maintenant 5 pods d’actif :

28 - L'autoscaling dans AKS
31 1024x487 - L'autoscaling dans AKS
29 1024x245 - L'autoscaling dans AKS

Puis 6 :

30 1024x247 - L'autoscaling dans AKS

Mon site en tout cas est toujours fonctionnel :

33 1024x220 - L'autoscaling dans AKS

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

34 - L'autoscaling dans AKS

Jusqu’à revenir à ma situation initiale :

35 1024x77 - L'autoscaling dans AKS
36 - L'autoscaling dans AKS

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] :

37 - L'autoscaling dans AKS

Un autoscale déployé via un YAML

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

38 - L'autoscaling dans AKS

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 :

39 - L'autoscaling dans AKS

Je relance mon batch :

41 1024x616 - L'autoscaling dans AKS

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.

43 1024x595 - L'autoscaling dans AKS

Jusqu’à atteindre les 10 pods :

45 1024x621 - L'autoscaling dans AKS

Que je retrouve bien sur mon dashboard :

46 1024x591 - L'autoscaling dans AKS
47 1024x155 - L'autoscaling dans AKS

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

Une réponse sur “L’autoscaling dans AKS”

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *