L'équipe de la communauté open source chinoise a réalisé sa première diffusion en direct, racontant l'histoire de la communauté open source chinoise au nom du partage.

Cet article est partagé par la communauté Huawei Cloud « Test sur l'effet de la préemption des tâches en ligne, de la suppression des ressources CPU pour les tâches hors ligne et de la garantie de la qualité du service pour les tâches en ligne dans le scénario de déploiement mixte natif CCE Cloud ». L'auteur : Vous pouvez vous faire un ami. .

arrière-plan

Les environnements informatiques d'entreprise exécutent généralement deux principaux types de processus : l'un concerne les services en ligne et l'autre les opérations hors ligne.

Tâches en ligne : longue durée d'exécution, trafic de service et utilisation des ressources ont des caractéristiques de marée, sont sensibles aux retards et ont des exigences SLA de service élevées, telles que les services de transactions de commerce électronique, etc.

Tâches hors ligne : Le temps d'exécution est divisé en intervalles, le taux d'utilisation des ressources est élevé pendant le fonctionnement, le délai n'est pas sensible, le taux de tolérance aux pannes est élevé et les interruptions permettent généralement une réexécution, comme le traitement du Big Data, etc.

La principale forme de colocalisation consiste à améliorer l'utilisation des ressources en déployant des tâches en ligne et hors ligne sur le même nœud. Par exemple, un nœud déployait auparavant 3 tâches en ligne avec un SLA de service élevé, et déploie désormais 3 tâches en ligne et 3 tâches hors ligne. de manière mixte. Les services hors ligne utilisent les ressources inutilisées des services en ligne à différentes périodes sans affecter la qualité de service des services en ligne.

Au niveau de la colocalisation des conteneurs, cela implique principalement : 1) Au niveau de la planification, les ressources de planification des nœuds sont sur-planifiées, et les tâches en ligne et hors ligne sont mélangées et planifiées sur le même nœud 2) Au niveau du CPU, les tâches en ligne ; sont préemptés et les tâches hors ligne sont supprimées;3) Le niveau de mémoire n'est pas présenté dans cet article. Grâce à la puissance du processeur de la technologie colocalisée, on peut réaliser que pendant le processus de fonctionnement, le système effectuera automatiquement la « préemption » et la « suppression » en ligne des ressources de tâches hors ligne en fonction de l'utilisation des ressources de tâches en ligne et hors ligne. pour garantir les demandes de ressources des ressources en ligne. Prenons l'exemple d'une machine à 4 cœurs :

Lorsqu'une tâche en ligne nécessite des ressources CPU à 3 cœurs, le système doit « supprimer » la tâche hors ligne pour utiliser jusqu'à 1 ressource CPU à 1 cœur ;
La tâche en ligne était au plus bas de l'activité à cette époque et n'utilisait qu'une seule ressource CPU de base. La tâche hors ligne pouvait utiliser les ressources CPU restantes à court terme, lorsque l'activité des tâches en ligne augmentait, le système garantissait que l'activité en ligne était en cours. pourrait « préempter » les ressources CPU de l'entreprise hors ligne ;

Préparation environnementale

Exigences environnementales

Version cluster :

Cluster v1.19 : v1.19.16-r4 et supérieur
Cluster v1.21 : v1.21.7-r0 et supérieur
Cluster v1.23 : v1.23.5-r0 et supérieur
v1.25 et supérieur

Type de cluster : cluster CCE Standard ou cluster CCE Turbo.

Système d'exploitation du nœud : EulerOS 2.9 (kernel-4.18.0-147.5.1.6.h729.6.eulerosv2r9.x86_64) ou Huawei Cloud EulerOS 2.0

Type de nœud : machine virtuelle élastique.

Version du plug-in Volcano : 1.7.0 et supérieure.

informations environnementales

Le cluster CCE déploie les plug-ins kube-prometheus-stack, grafana et volcano

Démonstration de suppression et de préemption du processeur

Base de référence du test de résistance

Créez la charge de travail requise pour la démonstration et assurez-vous que les deux charges de travail sont planifiées sur le même nœud (puisque l'expression générale dans le tableau de bord est associée au nom du pod, il est recommandé de ne pas utiliser le nom de la charge de travail, sinon cela affectera le affichage normal du tableau de bord)

genre : Déploiement
Version api : apps/v1
métadonnées :
  nom : redis        
spécification :
  répliques : 1
  sélecteur:
    matchLabels :
      application : redis
  modèle:
    métadonnées :
      créationTimestamp : null
      Étiquettes:
        application : redis
      annotations :
        prometheus.io/path : /metrics
        prometheus.io/port : '9121'
        prometheus.io/scrape : 'vrai'
    spécification :
      conteneurs :
        - nom : conteneur-1
          image : swr.cn-north-4.myhuaweicloud.com/testapp/redis:v6
          ressources:
            limites:
              processeur : '1'
            demandes :
              processeur : 250 m
        - nom : conteneur-2
          image : bitnami/redis-exporter : dernière
          ressources:
            limites:
              processeur : 250 m
              mémoire: 512Mi
            demandes :
              processeur : 250 m
              mémoire: 512Mi
      imagePullSecrets :
        - nom : secret par défaut
      nom du planificateur : volcan
---
genre : Déploiement
Version api : apps/v1
métadonnées :
  nom : stress
spécification :
  répliques : 1
  sélecteur:
    matchLabels :
      application : stress
  modèle:
    métadonnées :
      Étiquettes:
        application : stress
    spécification :
      conteneurs :
        - nom : conteneur-1
          image : swr.cn-north-4.myhuaweicloud.com/testapp/centos-stress:v1
          commande:
            - /bin/bash
          arguments :
            - '-c'
            - bien que vrai ; faites écho bonjour ; dormir 10 ; fait
          ressources:
            limites:
              processeur : '4'
              mémoire : 4Gi
            demandes :
              processeur : 2 500 m
              mémoire : 1Gi
      imagePullSecrets :
        - nom : secret par défaut
      nom du planificateur : volcan
      affinité:
        podAffinité :
          requisDuringSchedulingIgnoredDuringExecution :
            - sélecteur d'étiquette :
                expressions de correspondance :
                  - clé : application
                    opérateur : Dans
                    valeurs:
                      - redis
              espaces de noms :
                - défaut
              clé de topologie : kubernetes.io/hostname

Utilisez la commande redis-benchmark pour tester Redis 192.168.1.159pour l'adresse IP du pod de Redis ;

./redis-benchmark -h 192.168.1.159 -p 6379 -n 3000000 -c 100 –q -t SET,INCR,LPUSH,LPOP,RPOP,SADD,HSET,SPOP,ZADD,ZPOPMIN

Observez les indicateurs Redis et l'utilisation du processeur sur la page grafana, qui peuvent être utilisés comme données de référence de base sans interférence.

Scène non mixte

Créez un pool de nœuds pour le déploiement hybride et redéployez les charges de travail ci-dessus vers de nouveaux nœuds

Utilisez à nouveau la commande redis-benchmark pour tester Redis 192.168.1.172pour l'adresse IP du pod de Redis ;

./redis-benchmark -h 192.168.1.172 -p 6379 -n 3000000 -c 100 –q -t SET,INCR,LPUSH,LPOP,RPOP,SADD,HSET,SPOP,ZADD,ZPOPMIN

Entrez dans le conteneur de stress. Une fois que l'indicateur redis a atteint la ligne de base et est devenu stable, exécutez la commande pour augmenter l'utilisation du processeur.

contrainte de -c 4 -t 3600

Observez les indicateurs Redis et l'utilisation du processeur sur la page grafana et constatez que les données de performances de Redis se sont rapidement dégradées pendant le test de résistance du conteneur de stress.

Scène mixte

Mettez à jour le pool de nœuds et configurez l'étiquette hybride pour le nœud dans la configuration avancée :volcano.sh/colocation="true"

Cliquez sur la gestion de la configuration de la configuration du composant pool de nœuds-kubelet - activez la fonctionnalité de colocalisation des nœuds

Modifiez le seuil d'expulsion du nœud à 100 pour éviter l'expulsion directe lorsque l'utilisation du processeur dépasse le seuil lors des tests de résistance.

kubectl annote le nœud 192.168.0.209 volcano.sh/evicting-cpu-high-watermark=100

Modifiez l'annotation de la charge de travail de stress et marquez le stress comme activité hors ligne. La charge de travail Redis n'a pas besoin d'être modifiée.

genre : Déploiement
Version api : apps/v1
métadonnées :
  nom : stress
spécification :
  répliques : 1
  sélecteur:
    matchLabels :
      application : stress
  modèle:
    métadonnées :
      Étiquettes:
        application : stress
      annotations :          
        volcano.sh/qos-level : "-1" # Annotations de tâches hors ligne
    spécification :
      conteneurs :
        - nom : conteneur-1
          image : swr.cn-north-4.myhuaweicloud.com/testapp/centos-stress:v1
          commande:
            - /bin/bash
          arguments :
            - '-c'
            - bien que vrai ; faites écho bonjour ; dormir 10 ; fait
          ressources:
            limites:
              processeur : '4'
              mémoire : 4Gi
            demandes :
              processeur : 2 500 m
              mémoire : 1Gi
      imagePullSecrets :
        - nom : secret par défaut
      nom du planificateur : volcan
      affinité:
        podAffinité :
          requisDuringSchedulingIgnoredDuringExecution :
            - sélecteur d'étiquette :
                expressions de correspondance :
                  - clé : application
                    opérateur : Dans
                    valeurs:
                      - redis
              espaces de noms :
                - défaut
              clé de topologie : kubernetes.io/hostname

Utilisez la commande redis-benchmark pour tester Redis 192.168.1.172 pour l'adresse IP du pod de Redis ;

./redis-benchmark -h 192.168.1.172 -p 6379 -n 3000000 -c 100 –q -t SET,INCR,LPUSH,LPOP,RPOP,SADD,HSET,SPOP,ZADD,ZPOPMIN

Entrez dans le conteneur de stress. Une fois que l'indicateur redis a atteint la ligne de base et est devenu stable, exécutez la commande pour augmenter l'utilisation du processeur.

contrainte de -c 4 -t 3600

Observez les indicateurs Redis et l'utilisation du processeur sur la page grafana. Dans le scénario mixte, même si les tâches hors ligne tentent d'épuiser le processeur du nœud, le système d'exploitation maintient toujours les demandes de processeur des tâches en ligne, garantissant ainsi la qualité de service des tâches en ligne. .

Cliquez pour suivre et découvrir les nouvelles technologies de Huawei Cloud dès que possible~

Cas de test dans le scénario de colocalisation native cloud CCE