Container Service for Kubernetes:Enable CPU QoS for containers

Étape 1 : Appliquer le ConfigMap

1. Créez un fichier nommé configmap.yaml avec le contenu suivant :

   Pour appliquer la QoS du processeur à une charge de travail telle qu'un Deployment, ajoutez l'étiquette koordinator.sh/qosClass au modèle de Pod sous template.metadata .

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ack-slo-config
     namespace: kube-system
   data:
     # Enable the CPU QoS feature for containers.
     resource-qos-config: |
       {
         "clusterStrategy": {
           "lsClass": {
             "cpuQOS": {
               "enable": true,
               "groupIdentity": 2
             }
           },
           "beClass": {
             "cpuQOS": {
               "enable": true,
               "groupIdentity": -1
             }
           }
         }
       }

   Le champ lsClass configure les Pods LS ; beClass configure les Pods BE. Le tableau suivant décrit les principaux paramètres sous cpuQOS.

   Paramètre	Type	Valeurs valides	Description
   enable	Booléen	true / false	true : active la QoS du processeur à l'échelle du cluster. false : la désactive.
   groupIdentity	Entier	-1 à 2	Priorité de planification du noyau pour le cgroup. Les valeurs plus élevées indiquent une priorité plus élevée. Par défaut : 2 pour les Pods LS, -1 pour les Pods BE. Définissez sur 0 pour désactiver l'identité de groupe pour cette classe.

2. Vérifiez si le ConfigMap ack-slo-config existe déjà dans l'espace de noms kube-system :

   • S'il existe, exécutez la commande de correctif suivante pour le mettre à jour sans écraser les autres champs de configuration :

     kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)"

   • S'il n'existe pas, créez-le :

     kubectl apply -f configmap.yaml

Étape 2 : Déployer un Pod LS et vérifier

1. Créez un fichier nommé ls-pod-demo.yaml avec le contenu suivant :

   apiVersion: v1
   kind: Pod
   metadata:
     name: ls-pod-demo
     labels:
       koordinator.sh/qosClass: 'LS' # Specify the QoS class of the Pod as LS.
   spec:
     containers:
     - command:
       - httpd
       - -D
       - FOREGROUND
       image: registry.cn-zhangjiakou.aliyuncs.com/acs/apache-2-4-51-for-slo-test:v0.1
       imagePullPolicy: Always
       name: apache
       resources:
         limits:
           cpu: "4"
           memory: 10Gi
         requests:
           cpu: "4"
           memory: 10Gi
     restartPolicy: Never
     schedulerName: default-scheduler

2. Déployez le Pod :

   kubectl apply -f ls-pod-demo.yaml

3. Sur le nœud, vérifiez l'identité de groupe attribuée au cgroup du Pod LS :

   cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-pod1c20f2ad****.slice/cpu.bvt_warp_ns

   Résultat attendu :

   # The group identity of the LS Pod is 2, which indicates high priority.
   2

Étape 3 : Déployer un Pod BE et vérifier

1. Créez un fichier nommé be-pod-demo.yaml avec le contenu suivant :

   apiVersion: v1
   kind: Pod
   metadata:
     name: be-pod-demo
     labels:
       koordinator.sh/qosClass: 'BE' # Specify the QoS class of the Pod as BE.
   spec:
     containers:
       - args:
           - '-c'
           - '1'
           - '--vm'
           - '1'
         command:
           - stress
         image: registry-cn-beijing.ack.aliyuncs.com/acs/stress:v1.0.4
         imagePullPolicy: Always
         name: stress
     restartPolicy: Always
     schedulerName: default-scheduler

2. Déployez le Pod :

   kubectl apply -f be-pod-demo.yaml

3. Sur le nœud, vérifiez l'identité de groupe attribuée au cgroup du Pod BE :

   cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod4b6e96c8****.slice/cpu.bvt_warp_ns

   Résultat attendu :

   # The group identity of the BE Pod is -1, which indicates low priority.
   -1

Le Pod LS a une identité de groupe de 2 et le Pod BE a une identité de groupe de -1. Cette différence confirme que la QoS du processeur est active : le noyau donne la priorité aux ressources processeur pour les charges de travail LS par rapport aux charges de travail BE.

Compatibilité des protocoles lors de la mise à niveau vers ack-koordinator

Les versions antérieures d'ack-slo-manager (v0.8.0 et antérieures) utilisaient l'annotation alibabacloud.com/qosClass pour configurer la QoS du processeur. ack-koordinator prend en charge les deux protocoles, ce qui vous permet de mettre à niveau le composant et de migrer vos Pods vers le protocole koordinator.sh de manière incrémentielle. Notez que la prise en charge de l'ancien protocole alibabacloud.com a pris fin le 30 juillet 2023. Mettez à jour vos ressources vers le nouveau protocole dès que possible.