Après avoir déployé votre Mendix Lors de l'installation d'une application sur Kubernetes, le trafic reçu peut changer de manière imprévisible. Comment faire en sorte que votre application reste réactive à tout moment ?

C'est là que la mise à l'échelle entre en jeu. Vous souhaitez que votre cluster gère la charge avec élégance, qu'il s'agisse d'un pic de trafic ou simplement d'une utilisation régulière. Mendix for Private Cloud facilite cela en ajustant dynamiquement le nombre de pods en fonction de la demande. Dans notre offre Connected, vous pouvez le faire manuellement à partir du portail des développeurs ou en activant Horizontal Pod Autoscaler directement dans le cluster Kubernetes. Plutôt cool, non ?

Dans ce blog, vous apprendrez comment implémenter la mise à l'échelle automatique pour un Mendix application basée sur une métrique personnalisée spécifique à l'application. Nous utiliserons une combinaison d'Autoscaler de pods horizontaux et d'Autoscaler de clusters. Mais attendez, il y a plus ? Oui, un joli tableau de bord Grafana accompagnement sur mesure. pour Mendix pour le Cloud Privé pour visualiser tout cela pendant que cela se passe en temps réel !

Mise à l’échelle automatique dans Kubernetes : qu’est-ce que cela inclut ?

Pour commencer, examinons de plus près l'utilisation du terme « autoscaling » dans Kubernetes. Dans Kubernetes, plusieurs éléments sont appelés « autoscaling », notamment :

• Autoscaler horizontal à pods (HPA) – ajuste le nombre de répliques d’une application.
• Autoscaler vertical à pods (VPA)) – ajuste les demandes de ressources et les limites d'un conteneur. Veuillez noter que VPA n'est pas une stratégie de mise à l'échelle automatique recommandée dans le contexte de Mendix et est fortement déconseillé.
• Autoscaler de cluster (CA) – ajuste le nombre de nœuds d’un cluster.

Mendix for Private Cloud prend en charge tous les éléments ci-dessus, mais ils répondent tous à des cas d'utilisation très différents et utilisent des concepts et des mécanismes différents.

Explorons les stratégies pour une mise à l’échelle efficace.

Une stratégie de mise à l’échelle

Comment obtenir un nombre optimal de répliques pour une demande donnée ? Ne serait-il pas formidable de disposer d'un indicateur numérique de la demande que votre application subit actuellement ?

Pour la mise à l’échelle, une métrique appropriée est une mesure qui représente la charge actuelle de l’application.
Voici quelques exemples de mesures de mise à l’échelle appropriées :

• Le nombre de requêtes reçues par seconde par chaque réplique.
• L'utilisation du processeur et/ou de la mémoire des processus des applications.

(REMARQUE : comme le Mendix L'environnement d'exécution est basé sur Java, qui pré-alloue la mémoire et ne la libère généralement jamais. Les métriques basées sur la mémoire ne doivent pas être utilisées pour la mise à l'échelle automatique.)

La clé ici est de trouver une valeur métrique optimale (appelons-la la valeur cible) où l'application n'est ni sur- ni sous-utilisée. Malheureusement, c'est plus facile à dire qu'à faire puisque chaque application se comporte différemment.

Par exemple, si vous spécifiez une utilisation maximale de 80 % du processeur, le contrôleur HPA ajoutera un pod dès que l'utilisation moyenne de tous les pods de cet ensemble de réplicas atteindra 80 % ou plus. Un facteur important ici est de savoir si vous avez ou non correctement configuré les demandes de ressources et les limites du pod. Notre stratégie de mise à l'échelle devrait alors ressembler à ceci :

• Si la valeur observée est inférieure à la valeur cible (c'est-à-dire que l'application est sous-utilisée), le nombre de répliques doit être réduit afin que chaque réplique bénéficie d'une utilisation plus élevée. Cela entraînera une augmentation de la valeur de la métrique et se rapprochera de la valeur cible.
• Si la valeur observée est supérieure à la valeur cible (c'est-à-dire que l'application est surutilisée), le nombre de répliques doit être augmenté afin que chaque réplique reçoive une part plus petite de la charge totale, ce qui entraîne une diminution de la valeur métrique et un rapprochement vers la valeur cible.

Principes de base des demandes et des limites de ressources

Kubernetes vous permet de spécifier la quantité de CPU/RAM dont un seul Pod a besoin et comment restreindre l'utilisation de ces ressources pour un Pod donné. Mendix pour le Cloud privé, cela se configure facilement via notre Portail des Développeurs ou, pour les clients utilisant notre offre autonome, par éditer le MendixCR objet.

Unités de mémoire

• Les unités de mémoire sont généralement représentées en octets, mais pour plus de simplicité, Kubernetes vous permet d'utiliser des formats plus lisibles par l'homme tels que les mégaoctets (Mo) ou les gigaoctets (Go).
• Vous pouvez utiliser les suffixes suivants pour représenter les unités de mémoire :
  • « Mi » pour mébioctets (2^20 octets)
  • « Gi » pour gibioctets (2^30 octets)
  • « M » pour mégaoctets
  • « G » pour gigaoctets

Unités centrales

• Les unités CPU dans Kubernetes sont mesurées en « millicores », qui sont des fractions d'un cœur de processeur.
• 1 cœur de processeur équivaut à 1000 XNUMX millicœurs.
• Vous pouvez spécifier les demandes et les limites du processeur en utilisant le suffixe « m » pour indiquer les millicœurs.

Exemples

• 100 m représente 100 millicœurs, soit 0.1 cœur de processeur.
• 500 m représente 500 millicœurs, soit 0.5 cœur de processeur.

Le CPU est une unité absolue, ce qui signifie qu'un CPU est le même quel que soit le nombre de cœurs d'un nœud.

Notre Mendix le déploiement de l'application est configuré avec les valeurs de modèle de petite taille suivantes :

• Demande CPU de 100 m
• Demande de mémoire de 512Mi

Simulation de mise à l'échelle automatique

Notre objectif avec cet article est de :

• Simuler la croissance du trafic reçu par un Mendix application hébergée dans un cluster Kubernetes.
• Configurez Horizontal Pod Autoscaler pour faire évoluer le nombre de Mendix répliques d'applications en direct Mendix Environnement Kubernetes exécuté dans Mendix pour le mode connecté au Cloud privé.
• Configurez Cluster Autoscaler pour mettre à l'échelle le nombre de nœuds de cluster pour allouer les nouvelles répliques du Mendix .

Dans cet exemple d'environnement, j'hébergerai mon Mendix cluster dans Azure AKS. Pour les autres types de cluster Mx4PC pris en charge, suivez la méthode recommandée par votre fournisseur pour configurer la fonctionnalité CA.

Pour plus de détails sur la façon de déployer un Mendix application, vous pouvez consulter ce guide : https://docs.mendix.com/developerportal/deploy

Avant de commencer, il est judicieux de revoir certaines conditions préalables. Avez-vous :

• Autoscaler horizontal de pod activé dans votre Mendix environnement?
• Activation de Cluster Autoscaler ?
• Serveur de métriques Kubernetes installé dans votre cluster ?

Configuration de l'autoscaler horizontal de pods

Activons HPA et définissons la métrique sur un seuil d'utilisation du processeur de 80 % :

# kubectl -n mendix-app autoscale mendixapp blogapp1-master --cpu-percent=80 --min=1 --max=3
horizontalpodautoscaler.autoscaling/blogapp1 autoscaled

Configuration de Cluster Autoscaler (CA)

Vous pouvez activer CA depuis la ligne de commande ou de Portail AzureJe vais définir le nombre maximal de nœuds à 3 pour cet exemple :

Générer du trafic !

Dans la vidéo suivante, vous pouvez voir en haut à gauche que je génère du trafic directement dans le Mendix application en envoyant 1000 connexions simultanées pendant deux minutes. J'utilise cet outil à l'intérieur d'une nacelle temporaire, mais il y en a beaucoup d'autres qui peuvent faire la même chose !

Vue de l'autoscaler horizontal de pods à partir du cluster Kubernetes

Explorons à quoi ressemble la même séquence dans notre tableau de bord Grafana :

Vue du pod horizontal Autoscaler depuis le tableau de bord Grafana

Une fois que nous commençons à envoyer 1000 requêtes simultanées à la Mendix application, nous observons ce qui suit :

1. Utilisation du processeur pour le blogapp1-master l'application va de 8 m à plus de 100 m (écran en haut à droite).
2. Le Autoscaler de pod horizontal commence à mettre à l'échelle les pods.
3. Deux autres pods sont créés.
4. L'un des pods est désormais en attente et ne peut pas être déployé. Il n'y a pas assez d'espace dans l'un ou l'autre des nœuds existants pour allouer un pod supplémentaire.
5. Après quelques minutes, le Autoscaler de cluster déclenche et crée un nouveau nœud dans le cluster (écran en bas à droite)
6. Le En Attente Le pod est maintenant déployé.

Exploration du délai de mise à l'échelle automatique

Terminons en comprenant comment tout cela est lié :

1. Temps de réaction de l'autoscaler horizontal Pod.
   • Par défaut, L'utilisation du processeur et de la mémoire des pods est récupérée par kubelet toutes les 10 secondes.
   • Chaque minute, le serveur de mesures regroupera ces mesures et les exposer au reste de l'API Kubernetes.
   • Par défaut, le L'autoscaler horizontal de pods vérifie les métriques des pods toutes les 15 secondes.
   • Dans le pire des cas, l'Autoscaler Horizontal Pod peut prendre jusqu'à 1 minute et demie pour déclencher la mise à l'échelle automatique (c'est-à-dire 10 s + 60 s + 15 s).
2. Temps de réaction du Cluster Autoscaler.
   • Le Cluster Autoscaler vérifie les pods non planifiés dans le cluster toutes les 10 secondes.
   • L'ensemble du processus devrait prendre environ 30 secondes sur des clusters comportant 100 nœuds ou moins et jusqu'à 30 pods chacun.
3. Temps de provisionnement du nœud.
   • Ensuite, il y a le temps de provisionnement des nœuds, qui dépend principalement du fournisseur de cloud.
   • Il est assez courant qu’une nouvelle ressource de calcul soit provisionnée en 3 à 5 minutes.
4. Mendix Heure de création du pod.
   • À partir de Mendix L'exécution ne devrait généralement pas prendre plus de 30 secondes.

Dans le pire des cas, le retard total pourrait atteindre 7 minutes. Pas mal, non ? Cependant, pouvez-vous gérer une augmentation soudaine du trafic pendant 7 minutes avant d'obtenir plus de pods ?

Existe-t-il des moyens de régler la mise à l'échelle automatique pour réduire le temps de mise à l'échelle en minutes ?

Essayez d’ajuster certaines de ces valeurs par défaut :

• Le temps de rafraîchissement par défaut pour HPA qui est contrôlé par le période de synchronisation-de-pod-autoscaler-horizontale (par défaut 15 secondes).
• L'intervalle de récupération des métriques dans le serveur de métriques, qui est contrôlé par le indicateur de résolution métrique (par défaut 60 secondes).
• Le temps de réaction du cluster autoscaler aux pods non attribués, qui est contrôlé par le indicateur d'intervalle d'analyse (par défaut 10 secondes).

Mots de clôture

La mise à l'échelle et la gestion de la croissance des clusters Kubernetes peuvent sembler une tâche ardue au début, mais avec les bonnes stratégies et en tirant parti des fonctionnalités fournies par Mendix pour le Cloud privé, vous êtes bien équipé pour naviguer dans ce voyage passionnant. La clé réside dans la recherche du juste milieu entre l'ajout de nœuds supplémentaires et l'optimisation de ceux dont vous disposez.

Un dernier mot aux sages –  Mendix les applications ont tendance à être relativement gourmandes en bases de données par rapport aux conteneurs d'applications, alors assurez-vous également de mettre à l'échelle (automatiquement) votre base de données.

Bonne mise à l'échelle !