Container Service for Kubernetes:Use load-aware scheduling

Fonctionnement de la planification tenant compte de la charge

La planification tenant compte de la charge est un plugin du planificateur Container Service for Kubernetes (ACK), implémenté sur la base du framework de planification Kubernetes. La politique de planification native de Kubernetes place principalement les pods selon l'allocation des ressources. Le planificateur ACK détecte quant à lui la charge réelle des ressources de chaque nœud : il s'appuie sur les statistiques historiques de charge des nœuds, estime la charge du pod à planifier, puis place ce dernier sur un nœud moins chargé. Cette approche permet d'équilibrer la charge entre les nœuds et aide à prévenir les pannes d'application ou de nœud dues à la surcharge d'un nœud unique.

La planification tenant compte de la charge nécessite à la fois le composant kube-scheduler et le module complémentaire ack-koordinator. Le module complémentaire ack-koordinator collecte et rapporte l'utilisation des ressources des nœuds, tandis que le planificateur ACK utilise ces données pour noter et classer les nœuds, afin de sélectionner en priorité ceux qui sont les moins chargés. Pour plus de détails sur la conception du module complémentaire, consultez Architecture d'ack-koordinator.

Dans la figure ci-dessous, Requested représente la quantité de ressources demandées et Usage correspond à la quantité de ressources réellement utilisées. Seules les ressources effectivement consommées comptent comme charge réelle. Dans des conditions de nœud identiques, le planificateur ACK attribue le nouveau pod au nœud B, qui présente la charge la plus faible.

L'utilisation des nœuds évolue dynamiquement au fil du temps et en fonction de l'environnement du cluster, du trafic des charges de travail et du volume des requêtes. Pour réduire le risque que le cluster ne se déséquilibre à nouveau après la planification des pods, le module complémentaire ack-koordinator propose également une fonctionnalité de déplanification. Utilisez la planification tenant compte de la charge conjointement avec l'utilisation de la déplanification sensible aux points chauds pour équilibrer les charges des nœuds afin de maintenir l'équilibre des charges des nœuds dans le temps.

Politiques de planification

La planification tenant compte de la charge propose les politiques suivantes. Toutes deux s'appuient sur la statistique de charge agrégée des nœuds décrite dans la section précédente.

Prérequis

• Type de cluster — Seul un cluster ACK Pro managé est pris en charge. Pour la procédure, consultez Création d'un cluster ACK Pro.

• Module complémentaire ack-koordinator — Installez le module complémentaire ack-koordinator version 1.1.1-ack.1 ou ultérieure. Pour la procédure d'installation, consultez ack-koordinator (anciennement ack-slo-manager).

• Version du planificateur ACK — Le planificateur ACK doit satisfaire aux exigences de version correspondant à la version Kubernetes de votre cluster, comme indiqué dans le tableau suivant.

Ces versions sont nécessaires pour configurer la planification tenant compte de la charge via les paramètres de kube-scheduler. Certaines versions antérieures du planificateur ne prennent en charge que le protocole d'annotation de pod. Pour la matrice de compatibilité complète, consultez la section FAQ.

Facturation

L'installation et l'utilisation du module complémentaire ack-koordinator sont gratuites. Toutefois, des coûts peuvent être engagés dans les scénarios suivants :

• Ressources des nœuds de travail — ack-koordinator est un module complémentaire non managé qui consomme des ressources des nœuds de travail après son installation. Les demandes de ressources peuvent être configurées pour chaque module lors de l'installation.

• Métriques personnalisées — Par défaut, ack-koordinator expose des métriques de surveillance pour des fonctionnalités telles que le profilage des ressources et la planification granulaire au format Prometheus. Si vous sélectionnez Enable Prometheus monitoring metrics for ack-koordinator et utilisez Managed Service for Prometheus, ces métriques sont facturées en tant que métriques personnalisées. Les frais varient en fonction de facteurs tels que la taille du cluster et le nombre d'applications. Avant d'activer cette fonctionnalité, consultez Facturation des instances Prometheus pour comprendre l'offre gratuite et la tarification des métriques personnalisées. Pour surveiller et gérer votre utilisation des ressources, utilisez la requête d'utilisation.

Étape 1 : Activer la planification tenant compte de la charge

1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Components and Add-ons .

3. Recherchez kube-scheduler et cliquez sur Configuration.

4. Dans la boîte de dialogue des paramètres de kube-scheduler, configurez les paramètres décrits dans le tableau suivant et cliquez sur OK.

   Le tableau suivant décrit les principaux paramètres de la planification tenant compte de la charge. Pour la référence complète des paramètres et les versions du module complémentaire requises pour chacun d'eux, consultez kube-scheduler et .

   Paramètre	Type	Description	Valeurs valides	Valeur par défaut	Exemple
   loadAwareThreshold	Liste composée du nom de la ressource resourceName et du seuil threshold.	Seuil du type de ressource correspondant, utilisé par la politique de filtrage des nœuds.	resourceName : cpu et memory sont pris en charge. threshold : [0,100].	Vide, ce qui signifie que le filtrage des nœuds est désactivé.	resourceName: cpu et threshold: 80
   loadAwareResourceWeight	Liste composée du nom de la ressource resourceName et du poids resourceWeight.	Poids de notation du type de ressource correspondant, utilisé par la politique de notation des nœuds. Vous devez sélectionner Specifies whether to enable load-aware node scoring during pod scheduling.	resourceName : seuls cpu et memory sont pris en charge. resourceWeight : entier compris dans la plage [1,100].	cpu: 1 et memory: 1	resourceName: cpu et resourceWeight: 1
   loadAwareAggregatedUsageAggragationType	enum	Type d'agrégation de la statistique de charge. avg : valeur moyenne. p50 : 50e percentile, soit la médiane. p90, p95 et p99 : 90e, 95e et 99e percentiles.	avg, p50, p90, p95 et p99	avg	p90

   Important

   Si la mise à l'échelle automatique des nœuds est déjà activée pour les nœuds du cluster, un seuil de filtrage tenant compte de la charge peut déclencher une mise à l'échelle horizontale ascendante ou descendante inattendue. En effet, la mise à l'échelle automatique des nœuds procède à une mise à l'échelle ascendante en fonction de l'état d'attente des pods et à une mise à l'échelle descendante en fonction du niveau d'allocation du cluster. Pour utiliser conjointement la mise à l'échelle automatique des nœuds et le filtrage des nœuds tenant compte de la charge, ajustez la configuration pour qu'elle corresponde à la capacité et à l'utilisation de votre cluster, comme décrit dans Activation de la mise à l'échelle automatique des nœuds.

5. Dans le volet de navigation de gauche, cliquez sur Cluster Information. Sur la page qui s'affiche, cliquez sur l'onglet Basic Information et attendez que le cluster passe à l'état Running, ce qui indique que la planification tenant compte de la charge est activée.

Étape 2 : Vérifier la planification tenant compte de la charge

L'exemple suivant utilise un cluster composé de trois nœuds, chacun disposant de 4 cœurs et de 16 Go de mémoire. L'exemple commence par déséquilibrer les charges entre les nœuds, puis vérifie où les nouveaux pods sont planifiés.

1. Créez un fichier nommé stress-demo.yaml avec le contenu suivant.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: stress-demo
     namespace: default
     labels:
       app: stress-demo
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: stress-demo
     template:
       metadata:
         name: stress-demo
         labels:
           app: stress-demo
       spec:
         containers:
           - args:
               - '--vm'
               - '2'
               - '--vm-bytes'
               - '1600M'
               - '-c'
               - '2'
               - '--vm-hang'
               - '2'
             command:
               - stress
             image: polinux/stress
             imagePullPolicy: Always
             name: stress
             resources:
               limits:
                 cpu: '2'
                 memory: 4Gi
               requests:
                 cpu: '2'
                 memory: 4Gi
         restartPolicy: Always

2. Exécutez la commande kubectl suivante pour créer le pod. Le pod augmente la charge du nœud qui l'héberge.

   kubectl create -f stress-demo.yaml

   deployment.apps/stress-demo created

3. Exécutez la commande kubectl suivante pour vérifier l'état du pod jusqu'à ce qu'il soit en cours d'exécution.

   kubectl get pod -o wide

   NAME                           READY   STATUS    RESTARTS   AGE   IP           NODE                    NOMINATED NODE   READINESS GATES
   stress-demo-7fdd89cc6b-g****   1/1     Running   0          82s   10.XX.XX.112   cn-beijing.10.XX.XX.112   <none>           <none>

   stress-demo-7fdd89cc6b-g**** est planifié sur le nœud cn-beijing.10.XX.XX.112. Attendez environ 3 minutes que le pod termine son initialisation et que la charge du nœud ait augmenté.

4. Exécutez la commande kubectl suivante pour vérifier la charge de chaque nœud.

   kubectl top node

   NAME                    CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   cn-beijing.10.XX.XX.110   92m          2%     1158Mi          9%
   cn-beijing.10.XX.XX.111   77m          1%     1162Mi          9%
   cn-beijing.10.XX.XX.112   2105m        53%    3594Mi          28%

   cn-beijing.10.XX.XX.111 présente la charge la plus faible et le nœud cn-beijing.10.XX.XX.112 la charge la plus élevée. Les charges entre les nœuds du cluster sont désormais déséquilibrées.

5. Créez un fichier nommé nginx-with-loadaware.yaml avec le contenu suivant.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-with-loadaware
     namespace: default
     labels:
       app: nginx
   spec:
     replicas: 6
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         name: nginx
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx
           resources:
             limits:
               cpu: 500m
             requests:
               cpu: 500m

6. Exécutez la commande kubectl suivante pour créer les pods.

   kubectl create -f nginx-with-loadaware.yaml

   deployment/nginx-with-loadawre created

7. Exécutez la commande kubectl suivante pour afficher les détails de la planification des pods.

   kubectl get pods | grep nginx

   nginx-with-loadaware-5646666d56-2****   1/1     Running   0          18s   10.XX.XX.118   cn-beijing.10.XX.XX.110   <none>           <none>
   nginx-with-loadaware-5646666d56-7****   1/1     Running   0          18s   10.XX.XX.115   cn-beijing.10.XX.XX.110   <none>           <none>
   nginx-with-loadaware-5646666d56-k****   1/1     Running   0          18s   10.XX.XX.119   cn-beijing.10.XX.XX.110   <none>           <none>
   nginx-with-loadaware-5646666d56-q****   1/1     Running   0          18s   10.XX.XX.113   cn-beijing.10.XX.XX.111   <none>           <none>
   nginx-with-loadaware-5646666d56-s****   1/1     Running   0          18s   10.XX.XX.120   cn-beijing.10.XX.XX.111   <none>           <none>
   nginx-with-loadaware-5646666d56-z****   1/1     Running   0          18s   10.XX.XX.116   cn-beijing.10.XX.XX.111   <none>           <none>

   La sortie attendue montre qu'après l'activation de la planification tenant compte de la charge, le planificateur détecte les charges des nœuds et utilise la stratégie de planification pour affecter prioritairement les pods à des nœuds autres que cn-beijing.10.XX.XX.112.

Opérations connexes

FAQ