Container Service for Kubernetes:Enable the CPU Burst performance optimization policy

Fonctionnement

Le CPU est une ressource partagée dans le temps. Le noyau utilise le Completely Fair Scheduler (CFS) pour allouer le temps CPU selon des cycles d'ordonnancement fixes. La durée du cycle est contrôlée par cpu.cfs_period_us (généralement 100 ms). Le temps CPU qu'un conteneur peut utiliser par cycle est contrôlé par cpu.cfs_quota_us. Un conteneur avec une limite de CPU de 4 obtient 400 ms de temps CPU par cycle de 100 ms.

Le problème réside dans le fait que l'utilisation du CPU est sporadique au niveau de la milliseconde, même lorsque les moyennes à la seconde semblent faibles. Le graphique ci-dessous illustre ce phénomène : la ligne violette montre une utilisation du CPU par seconde restant bien en dessous de 4 cœurs, tandis que la ligne verte montre des pics d'utilisation au niveau de la milliseconde dépassant 4 cœurs à certains moments. Lorsque ces pics épuisent le quota CFS, le noyau limite le conteneur.

La limitation force les threads à attendre le prochain cycle d'ordonnancement, ce qui augmente le temps de réponse (RT) et provoque une latence de longue traîne. Le tableau ci-dessous montre à quoi cela ressemble concrètement pour un conteneur de service web avec une limite de CPU de 2 sur un nœud de 4 cœurs.

<table> <thead> <tr> <td><p>Même lorsque l'utilisation globale du CPU sur la dernière seconde est faible, la limitation force le thread 2 à attendre le prochain cycle d'ordonnancement pour terminer le traitement de la requête 2. Cela augmente le RT de la requête. C'est une cause fréquente de RT de longue traîne.<img></p></td> <td><p>Après avoir activé CPU Burst, le conteneur accumule le temps CPU inutilisé. Il utilise ce temps pendant les pics. Cela améliore les performances et réduit la latence.<img></p><p></p></td> </tr> </thead> <colgroup></colgroup> <colgroup></colgroup> <tbody></tbody> </table>

Lorsque la demande dépasse ce que le quota accumulé peut couvrir, par exemple lors d'une augmentation soudaine du trafic, ack-koordinator résout le goulot d'étranglement du CPU en quelques secondes tout en maintenant la charge totale du nœud dans des limites sûres.

Cas d'utilisation

Limitation malgré une faible utilisation moyenne. L'utilisation du CPU reste inférieure à la limite de CPU la plupart du temps, mais de courts pics au sein des cycles d'ordonnancement déclenchent tout de même la limitation. CPU Burst permet au conteneur de dépenser le quota accumulé pendant ces pics, réduisant ainsi la limitation et améliorant la qualité de service.

Démarrage lent dû à une initialisation intensive en CPU. Le conteneur nécessite un CPU élevé lors du démarrage et du chargement, puis se stabilise à un état stationnaire plus faible. CPU Burst permet au conteneur d'utiliser du temps CPU supplémentaire lors du démarrage sans exiger une limite de CPU élevée en permanence.

Facturation

L'installation et l'utilisation d'ack-koordinator sont gratuites. Des frais supplémentaires peuvent s'appliquer dans les deux cas suivants :

• Ressources des nœuds de travail : ack-koordinator est un composant non géré. Après l'installation, il s'exécute sur vos nœuds de travail et consomme leurs ressources. Configurez les demandes de ressources pour chaque module lors de l'installation.

• Métriques Prometheus : ack-koordinator expose des métriques de profilage des ressources et d'ordonnancement au format Prometheus. Si vous activez l'option Enable Prometheus monitoring metrics for ACK-Koordinator et utilisez Alibaba Cloud Prometheus, ces métriques sont comptées comme des métriques personnalisées et engendrent des frais. Consultez la tarification des instances Prometheus avant d'activer cette option, et utilisez les requêtes d'utilisation pour surveiller la consommation.

Prérequis

Avant de commencer, assurez-vous que :

• Vous disposez d'un cluster ACK managé édition Pro exécutant Kubernetes 1.18 ou version ultérieure. Consultez Créer un cluster ACK managé et Mettre à jour manuellement un cluster.

• ack-koordinator version 0.8.0 ou ultérieure est installé sur le cluster. Consultez ack-koordinator.

Activer CPU Burst

CPU Burst peut être activé à trois niveaux. La configuration à un niveau plus spécifique a la priorité : les annotations de pod remplacent les ConfigMaps au niveau du namespace, qui remplacent elles-mêmes le ConfigMap au niveau du cluster.

annotations:
  # Enable CPU Burst for this pod.
  koordinator.sh/cpuBurst: '{"policy": "auto"}'
  # Disable CPU Burst for this pod.
  koordinator.sh/cpuBurst: '{"policy": "none"}'

Vérifier avec un test de charge

Cet exemple utilise un pod Apache HTTP Server pour démontrer que CPU Burst réduit la latence d'accès.

1. Créez apache-demo.yaml avec le contenu suivant. L'annotation active CPU Burst pour ce pod.

   apiVersion: v1
   kind: Pod
   metadata:
     name: apache-demo
     annotations:
       koordinator.sh/cpuBurst: '{"policy": "auto"}'   # Enable CPU Burst.
   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
     nodeName: $nodeName # Replace with the actual node name.
     hostNetwork: False
     restartPolicy: Never
     schedulerName: default-scheduler

2. Déployez le serveur Apache HTTP.

   kubectl apply -f apache-demo.yaml

3. Exécutez un test de charge à l'aide de wrk2. Remplacez $target_ip_address par l'adresse IP du pod Apache.

   # Download and extract the open-source wrk2 tool. See https://github.com/giltene/wrk2.
   # The Apache image has Gzip compression enabled to simulate server-side request processing.
   # Adjust QPS pressure by changing the -R parameter.
   ./wrk -H "Accept-Encoding: deflate, gzip" -t 2 -c 12 -d 120 --latency --timeout 2s -R 24 http://$target_ip_address:8010/static/file.1m.test

Configuration avancée

Configurez les paramètres avancés dans une annotation de pod ou un ConfigMap. Les annotations de pod ont la priorité, suivies des ConfigMaps au niveau du namespace, puis du ConfigMap au niveau du cluster.

# Example ConfigMap ack-slo-config.
data:
  cpu-burst-config: |
    {
      "clusterStrategy": {
        "policy": "auto",
        "cpuBurstPercent": 1000,
        "cfsQuotaBurstPercent": 300,
        "sharePoolThresholdPercent": 50,
        "cfsQuotaBurstPeriodSeconds": -1
      }
    }

# Example pod annotation.
  koordinator.sh/cpuBurst: '{"policy": "auto", "cpuBurstPercent": 1000, "cfsQuotaBurstPercent": 300, "cfsQuotaBurstPeriodSeconds": -1}'

<table> <thead> <tr> <td><p><b>Paramètre</b></p></td> <td><p><b>Type</b></p></td> <td><p><b>Description</b></p></td> <td><p><b>Annotation</b></p></td> <td><p><b>ConfigMap</b></p></td> </tr> </thead> <colgroup></colgroup> <colgroup></colgroup> <colgroup></colgroup> <colgroup></colgroup> <colgroup></colgroup> <tbody> <tr> <td><p><code>policy</code></p></td> <td><p>string</p></td> <td> <ul> <li><p><code>none</code> (par défaut) : Désactive CPU Burst. Tous les paramètres associés sont réinitialisés à leurs valeurs initiales.</p></li> <li><p><code>cpuBurstOnly</code> : Active uniquement l'élasticité CPU Burst au niveau du noyau Alibaba Cloud Linux.</p></li> <li><p><code>cfsQuotaBurstOnly</code> : Active uniquement l'élasticité du quota CFS. Fonctionne avec toutes les versions du noyau.</p></li> <li><p><code>auto</code> : Active automatiquement les deux élasticités — fonctionnalités du noyau Alibaba Cloud Linux et élasticité du quota CFS.</p></li> </ul></td> <td><p><img></p></td> <td><p><img></p></td> </tr> <tr> <td><p><code>cpuBurstPercent</code></p></td> <td><p>int</p></td> <td><p>Par défaut : <code>1000</code>. Unité : pourcentage.</p><p>Pour l'élasticité CPU Burst au niveau du noyau Alibaba Cloud Linux, cela définit l'amplification de CPU Burst au-delà de la limite de CPU. Correspond au paramètre cgroup <code>cpu.cfs_burst_us</code>. Pour plus de détails, consultez <a href="https://www.alibabacloud.com/help/en/document_detail/306980.html#task-2108025">Activer CPU Burst à l'aide de l'interface cgroup v1</a>.</p><p>Par exemple, avec le paramètre par défaut, <code>CPU Limit = 1</code> définit <code>cpu.cfs_quota_us</code> à 100 000. Ensuite, <code>cpu.cfs_burst_us</code> devient 1 000 000, soit une augmentation de 10 fois.</p></td> <td><p><img></p></td> <td><p><img></p></td> </tr> <tr> <td><p><code>cfsQuotaBurstPercent</code></p></td> <td><p>int</p></td> <td><p>Par défaut : <code>300</code>. Unité : pourcentage.</p><p>Lorsque l'élasticité du quota CFS est activée, cela définit l'augmentation maximale autorisée pour le paramètre cgroup <code>cpu.cfs_quota_us</code>. La valeur par défaut est 3x.</p></td> <td><p><img></p></td> <td><p><img></p></td> </tr> <tr> <td><p><code>cfsQuotaBurstPeriodSeconds</code></p></td> <td><p>int</p></td> <td><p>Par défaut : <code>-1</code>. Unité : secondes. -1 signifie illimité.</p><p>Lorsque l'élasticité du quota CFS est activée, cela définit la durée pendant laquelle un pod peut consommer du CPU avec le quota augmenté (<code>cfsQuotaBurstPercent</code>). Après cette période, le <code>cpu.cfs_quota_us</code> du pod est réinitialisé à sa valeur d'origine. Les autres pods ne sont pas affectés.</p></td> <td><p><img></p></td> <td><p><img></p></td> </tr> <tr> <td><p><code>sharePoolThresholdPercent</code></p></td> <td><p>int</p></td> <td><p>Par défaut : <code>50</code>. Unité : pourcentage.</p><p>Lorsque l'élasticité du quota CFS est activée, cela définit le seuil d'utilisation sécurisée du CPU pour le nœud. Si l'utilisation dépasse ce seuil, tous les pods avec un <code>cpu.cfs_quota_us</code> augmenté sont réinitialisés à leurs valeurs d'origine.</p></td> <td><p><img></p></td> <td><p><img></p></td> </tr> </tbody> </table>

FAQ

Références

Alibaba Cloud Linux étend l'interface cgroup v1 avec la prise en charge de CPU Burst. Pour activer CPU Burst au niveau cgroup et interroger les statistiques, consultez Activer CPU Burst à l'aide de l'interface cgroup v1.