Container Service for Kubernetes:Ativar a política de otimização de desempenho CPU Burst

Como funciona

A CPU é um recurso de tempo compartilhado. O kernel usa o Completely Fair Scheduler (CFS) para alocar tempo de CPU em ciclos de agendamento fixos. A duração do ciclo é controlada por cpu.cfs_period_us (geralmente 100 ms). O tempo de CPU disponível por ciclo é definido por cpu.cfs_quota_us. Um contêiner com limite de CPU de 4 obtém 400 ms de tempo de CPU por ciclo de 100 ms.

O problema é que o uso da CPU apresenta picos no nível de milissegundo, mesmo quando as médias por segundo parecem baixas. O gráfico abaixo ilustra isso: a linha roxa mostra o uso de CPU por segundo permanecendo bem abaixo de 4 núcleos, enquanto a linha verde indica o uso no nível de milissegundo ultrapassando 4 núcleos em certos períodos. Quando esses picos esgotam a cota do CFS, o kernel limita o contêiner.

A limitação força as threads a aguardar o próximo ciclo de agendamento, aumentando o tempo de resposta (RT) e causando latência de cauda longa. A tabela abaixo demonstra esse cenário na prática para um contêiner de serviço web com limite de CPU de 2 em um nó de 4 núcleos.

<table> <thead> <tr> <td><p>Mesmo quando o uso geral de CPU no último segundo é baixo, a limitação força a Thread 2 a esperar pelo próximo ciclo de agendamento para concluir o processamento da req 2. Isso aumenta o RT da requisição. Esta é uma causa comum de RT de cauda longa.<img></p></td> <td><p>Após ativar o CPU Burst, o contêiner acumula tempo de CPU não utilizado. Ele usa esse tempo durante os picos. Isso melhora o desempenho e reduz a latência.<img></p><p></p></td> </tr> </thead> <colgroup></colgroup> <colgroup></colgroup> <tbody></tbody> </table>

Quando a demanda supera a cota acumulada — como em um aumento repentino de tráfego — o ack-koordinator resolve o gargalo de CPU em segundos, mantendo a carga total do nó dentro de limites seguros.

Casos de uso

Limitação apesar da baixa utilização média. O uso da CPU permanece abaixo do limite na maior parte do tempo, mas picos curtos dentro dos ciclos de agendamento ainda acionam a limitação. O CPU Burst permite que o contêiner utilize a cota acumulada durante esses picos, reduzindo a limitação e melhorando a qualidade do serviço.

Inicialização lenta devido a processos intensivos em CPU. O contêiner exige muita CPU durante a inicialização e o carregamento, estabilizando depois em um estado constante mais baixo. O CPU Burst permite o uso de tempo extra de CPU durante a inicialização, sem exigir um limite de CPU permanentemente alto.

Faturamento

O ack-koordinator é gratuito para instalação e uso. Custos adicionais podem ser aplicados nestes dois casos:

• Recursos do nó de trabalho: o ack-koordinator é um componente não gerenciado. Após a instalação, ele executa em seus nós de trabalho e consome recursos deles. Configure as solicitações de recursos para cada módulo durante a instalação.

• Métricas do Prometheus: o ack-koordinator expõe métricas de perfil de recursos e agendamento no formato Prometheus. Se você ativar a opção Enable Prometheus monitoring metrics for ACK-Koordinator e usar o Alibaba Cloud Prometheus, essas métricas contam como métricas personalizadas e geram cobranças. Revise os preços de instâncias do Prometheus antes de ativar e use consultas de uso para monitorar o consumo.

Pré-requisitos

Antes de começar, verifique se você tem:

• Um cluster gerenciado ACK Pro edition executando Kubernetes 1.18 ou posterior. Consulte Criar um cluster gerenciado ACK e Atualizar manualmente um cluster.

• O ack-koordinator versão 0.8.0 ou posterior instalado no cluster. Consulte ack-koordinator.

Ativar o CPU Burst

É possível ativar o CPU Burst em três escopos. A configuração em um escopo mais restrito tem precedência: anotações de pod substituem ConfigMaps de nível de namespace, que substituem o ConfigMap de nível de cluster.

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

Verificar com teste de carga

Este exemplo usa um pod do Apache HTTP Server para demonstrar que o CPU Burst reduz a latência de acesso.

1. Crie o arquivo apache-demo.yaml com o seguinte conteúdo. A anotação ativa o 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. Implante o Apache HTTP Server.

   kubectl apply -f apache-demo.yaml

3. Execute um teste de carga usando wrk2. Substitua $target_ip_address pelo endereço IP do 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

Configuração avançada

Configure parâmetros avançados em uma anotação de pod ou em um ConfigMap. As anotações de pod têm precedência, seguidas pelos ConfigMaps de nível de namespace e, por fim, pelo ConfigMap de nível de 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>Parameter</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> (padrão): Desativa o CPU Burst. Todos os parâmetros relacionados retornam aos valores iniciais.</p></li> <li><p><code>cpuBurstOnly</code>: Ativa apenas a elasticidade de CPU Burst no nível de kernel do Alibaba Cloud Linux.</p></li> <li><p><code>cfsQuotaBurstOnly</code>: Ativa apenas a elasticidade de cota CFS. Funciona com todas as versões de kernel.</p></li> <li><p><code>auto</code>: Ativa automaticamente ambas as elasticidades — recursos de kernel do Alibaba Cloud Linux e elasticidade de cota 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>Padrão: <code>1000</code>. Unidade: porcentagem.</p><p>Para a elasticidade de CPU Burst no nível de kernel do Alibaba Cloud Linux, define quanto o CPU Burst amplifica além do limite de CPU. Mapeia para o parâmetro de cgroup <code>cpu.cfs_burst_us</code>. Para detalhes, consulte <a href="https://www.alibabacloud.com/help/en/document_detail/306980.html#task-2108025">Ativar CPU Burst usando a interface cgroup v1</a>.</p><p>Por exemplo, com a configuração padrão, <code>CPU Limit = 1</code> define <code>cpu.cfs_quota_us</code> como 100.000. Então <code>cpu.cfs_burst_us</code> torna-se 1.000.000 — um aumento de 10 vezes.</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>Padrão: <code>300</code>. Unidade: porcentagem.</p><p>Quando a elasticidade de cota CFS está ativada, define o aumento máximo permitido para o parâmetro de cgroup <code>cpu.cfs_quota_us</code>. O padrão é 3 vezes.</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>Padrão: <code>-1</code>. Unidade: segundos. -1 significa ilimitado.</p><p>Quando a elasticidade de cota CFS está ativada, define por quanto tempo um pod pode consumir CPU com a cota aumentada (<code>cfsQuotaBurstPercent</code>). Após esse período, o <code>cpu.cfs_quota_us</code> do pod retorna ao valor original. Outros pods não são afetados.</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>Padrão: <code>50</code>. Unidade: porcentagem.</p><p>Quando a elasticidade de cota CFS está ativada, define o limiar seguro de uso de CPU para o nó. Se o uso exceder esse limiar, todos os pods com <code>cpu.cfs_quota_us</code> aumentado retornam aos valores originais.</p></td> <td><p><img></p></td> <td><p><img></p></td> </tr> </tbody> </table>

Perguntas frequentes

Referências

O Alibaba Cloud Linux estende a interface cgroup v1 com suporte a CPU Burst. Para ativar o CPU Burst no nível de cgroup e consultar estatísticas, consulte Ativar CPU Burst usando a interface cgroup v1.