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

Funcionamiento

La CPU es un recurso de tiempo compartido. El kernel utiliza el Completely Fair Scheduler (CFS) para asignar tiempo de CPU en ciclos de programación fijos. La duración del ciclo se controla mediante cpu.cfs_period_us (generalmente 100 ms). El tiempo de CPU que un contenedor puede usar por ciclo se controla mediante cpu.cfs_quota_us. Un contenedor con un límite de CPU de 4 obtiene 400 ms de tiempo de CPU por cada ciclo de 100 ms.

El problema es que el uso de CPU presenta picos a nivel de milisegundo, incluso cuando los promedios por segundo parecen bajos. La siguiente gráfica ilustra esto: la línea morada muestra el uso de CPU por segundo manteniéndose muy por debajo de 4 núcleos, mientras que la línea verde muestra que el uso a nivel de milisegundo supera los 4 núcleos en ciertos periodos. Cuando esos picos agotan la cuota CFS, el kernel limita el contenedor.

La limitación obliga a los hilos a esperar al siguiente ciclo de programación, lo que aumenta el tiempo de respuesta (RT) y causa latencia de cola larga. La siguiente tabla muestra cómo se manifiesta esto en la práctica para un contenedor de servicio web con un límite de CPU de 2 en un nodo de 4 núcleos.

<table> <thead> <tr> <td><p>Incluso cuando el uso general de CPU durante el último segundo es bajo, la limitación obliga al Hilo 2 a esperar al siguiente ciclo de programación para terminar de procesar la solicitud 2. Esto aumenta el RT de la solicitud y es una causa común de RT de cola larga.<img></p></td> <td><p>Tras habilitar CPU Burst, el contenedor acumula tiempo de CPU no utilizado y lo aprovecha durante los picos de demanda. Esto mejora el rendimiento y reduce la latencia.<img></p><p></p></td> </tr> </thead> <colgroup></colgroup> <colgroup></colgroup> <tbody></tbody> </table>

Cuando la demanda supera lo que la cuota acumulada puede cubrir, como ocurre ante un aumento repentino de tráfico, ack-koordinator resuelve el cuello de botella de CPU en segundos y mantiene la carga total del nodo dentro de límites seguros.

Casos de uso

Limitación a pesar de una utilización promedio baja. El uso de CPU se mantiene por debajo del límite la mayor parte del tiempo, pero los picos breves dentro de los ciclos de programación siguen desencadenando la limitación. CPU Burst permite que el contenedor consuma la cuota acumulada durante esos picos, lo que reduce la limitación y mejora la calidad del servicio.

Inicio lento debido a una inicialización intensiva en CPU. El contenedor requiere mucha CPU durante el arranque y la carga, y luego se estabiliza en un estado estacionario más bajo. CPU Burst permite que el contenedor use tiempo extra de CPU durante el inicio sin necesidad de configurar un límite de CPU permanentemente alto.

Facturación

ack-koordinator es gratuito para instalar y usar. Pueden aplicarse cargos adicionales en los siguientes dos casos:

• Recursos de nodos worker: ack-koordinator es un componente no gestionado. Tras la instalación, se ejecuta en sus nodos worker y consume sus recursos. Configure las solicitudes de recursos para cada módulo durante la instalación.

• Métricas de Prometheus: ack-koordinator expone métricas de perfilado de recursos y programación en formato Prometheus. Si habilita la opción Enable Prometheus monitoring metrics for ACK-Koordinator y utiliza Alibaba Cloud Prometheus, estas métricas cuentan como métricas personalizadas y generan cargos. Revise los precios de instancias de Prometheus antes de habilitar esta función y utilice consultas de uso para monitorear el consumo.

Requisitos previos

Antes de empezar, asegúrese de contar con lo siguiente:

• Un clúster administrado ACK edición Pro que ejecute Kubernetes 1.18 o posterior. Consulte Create an ACK managed cluster y Manually upgrade a cluster.

• ack-koordinator versión 0.8.0 o posterior instalado en el clúster. Consulte ack-koordinator.

Habilitar CPU Burst

CPU Burst se puede habilitar en tres ámbitos. La configuración en un ámbito más específico tiene prioridad: las anotaciones del pod anulan los ConfigMaps a nivel de namespace, y estos anulan el ConfigMap a nivel de clúster.

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

Verificar con una prueba de carga

Este ejemplo utiliza un pod de Apache HTTP Server para demostrar que CPU Burst reduce la latencia de acceso.

1. Cree el archivo apache-demo.yaml con el siguiente contenido. La anotación habilita CPU Burst para este 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. Despliegue el Apache HTTP Server.

   kubectl apply -f apache-demo.yaml

3. Ejecute una prueba de carga con wrk2. Reemplace $target_ip_address con la dirección IP del pod de 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

Configuración avanzada

Configure los parámetros avanzados en una anotación de pod o en un ConfigMap. Las anotaciones de pod tienen prioridad, seguidas por los ConfigMaps a nivel de namespace y finalmente el ConfigMap a nivel de clúster.

# 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>Parámetro</b></p></td> <td><p><b>Tipo</b></p></td> <td><p><b>Descripción</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> (predeterminado): Deshabilita CPU Burst. Todos los parámetros relacionados se restablecen a sus valores iniciales.</p></li> <li><p><code>cpuBurstOnly</code>: Habilita únicamente la elasticidad de CPU Burst a nivel de kernel de Alibaba Cloud Linux.</p></li> <li><p><code>cfsQuotaBurstOnly</code>: Habilita únicamente la elasticidad de cuota CFS. Funciona con todas las versiones del kernel.</p></li> <li><p><code>auto</code>: Habilita automáticamente ambas elasticidades: las funciones del kernel de Alibaba Cloud Linux y la elasticidad de cuota 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>Predeterminado: <code>1000</code>. Unidad: porcentaje.</p><p>Para la elasticidad de CPU Burst a nivel de kernel de Alibaba Cloud Linux, este valor define cuánto amplifica CPU Burst más allá del límite de CPU. Se asigna al parámetro de cgroup <code>cpu.cfs_burst_us</code>. Para más detalles, consulte <a href="https://www.alibabacloud.com/help/en/document_detail/306980.html#task-2108025">Habilitar CPU Burst mediante la interfaz cgroup v1</a>.</p><p>Por ejemplo, con la configuración predeterminada, <code>CPU Limit = 1</code> establece <code>cpu.cfs_quota_us</code> en 100,000. Entonces <code>cpu.cfs_burst_us</code> pasa a ser 1,000,000, un aumento de 10 veces.</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>Predeterminado: <code>300</code>. Unidad: porcentaje.</p><p>Cuando la elasticidad de cuota CFS está habilitada, este valor establece el aumento máximo permitido para el parámetro de cgroup <code>cpu.cfs_quota_us</code>. El valor predeterminado es 3 veces.</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>Predeterminado: <code>-1</code>. Unidad: segundos. -1 significa ilimitado.</p><p>Cuando la elasticidad de cuota CFS está habilitada, este valor define durante cuánto tiempo un pod puede consumir CPU con la cuota aumentada (<code>cfsQuotaBurstPercent</code>). Después de este periodo, el valor <code>cpu.cfs_quota_us</code> del pod se restablece a su valor original. Otros pods no se ven afectados.</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>Predeterminado: <code>50</code>. Unidad: porcentaje.</p><p>Cuando la elasticidad de cuota CFS está habilitada, este valor establece el umbral seguro de uso de CPU para el nodo. Si el uso supera este umbral, todos los pods con <code>cpu.cfs_quota_us</code> aumentado se restablecen a sus valores originales.</p></td> <td><p><img></p></td> <td><p><img></p></td> </tr> </tbody> </table>

Preguntas frecuentes

Referencias

Alibaba Cloud Linux extiende la interfaz cgroup v1 con compatibilidad para CPU Burst. Para habilitar CPU Burst a nivel de cgroup y consultar estadísticas, consulte Enable CPU Burst using the cgroup v1 interface.