為什么需要啟用CPU Burst

Kubernetes集群使用CPU Limit資源約束機制，用于限制容器可以使用的最大CPU資源量，以確保了多個容器之間的資源分配的公平性，防止某個容器過度消耗CPU資源，從而影響其他容器的性能。

CPU是一種分時復用型資源，即多個進程或容器可以共享一個CPU時間片。容器配置了CPU Limit后，操作系統內核會根據CFS (Completely Fair Scheduler) 來控制容器在每個時間周期內（cpu.cfs_period_us）的CPU使用量（cpu.cfs_quota_us）。例如，如果一個容器的CPU Limit = 4，操作系統內核會限制該容器在每段時間周期內（通常是100 ms）最多使用400 ms的CPU時間片。

費用說明

ack-koordinator組件本身的安裝和使用是免費的，不過需要注意的是，在以下場景中可能產生額外的費用：

• ack-koordinator是非托管組件，安裝后將占用Worker節點資源。您可以在安裝組件時配置各模塊的資源申請量。

• ack-koordinator默認會將資源畫像、精細化調度等功能的監控指標以Prometheus的格式對外透出。若您配置組件時開啟了ACK-Koordinator開啟Prometheus監控指標選項并使用了阿里云Prometheus服務，這些指標將被視為自定義指標并產生相應費用。具體費用取決于您的集群規模和應用數量等因素。建議您在啟用此功能前，仔細閱讀阿里云Prometheus計費說明，了解自定義指標的免費額度和收費策略。您可以通過賬單和用量查詢，監控和管理您的資源使用情況。

配置說明

您可以通過Pod Annotation為指定的Pod開啟CPU Burst功能，也可以通過ConfigMap在集群或命名空間維度開啟。

annotations:
  # 設置為auto，開啟該Pod的CPU Burst功能。
  koordinator.sh/cpuBurst: '{"policy": "auto"}'
  # 設置為none，關閉該Pod的CPU Burst功能。
  koordinator.sh/cpuBurst: '{"policy": "none"}'

操作步驟

本示例以一個Web服務型應用為例，展示開啟CUP Burst策略前后的訪問延遲情況，驗證CPU Burst策略帶來的優化效果。

驗證步驟

1. 使用以下示例應用的YAML內容，創建名為apache-demo.yaml文件。

   在Pod對象的metadata字段下配置Annotation，為Pod單獨開啟CPU Burst策略。

   apiVersion: v1
   kind: Pod
   metadata:
     name: apache-demo
     annotations:
       koordinator.sh/cpuBurst: '{"policy": "auto"}'   # 開啟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 # 修改為實際的節點名稱。
     hostNetwork: False
     restartPolicy: Never
     schedulerName: default-scheduler

2. 執行以下命令，部署Apache HTTP Server作為目標評測應用。

   kubectl apply -f apache-demo.yaml

3. 使用wrk2壓測工具發送請求。

   # 下載wrk2開源測試工具并解壓安裝。具體操作，請參見https://github.com/giltene/wrk2。
   # 當前在Apache鏡像配置中開啟了Gzip壓縮模塊，用于模擬服務端處理請求的計算邏輯。
   # 執行發壓命令，注意修改目標應用的IP地址。
   ./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

   說明

   • 修改命令中的目標地址為Apache Pod的IP地址。

   • 通過修改-R參數來調節發送端的QPS壓力。

結果分析

以下數據分別展示了Alibaba Cloud Linux和社區CentOS在CPU Burst策略開啟前后的表現情況。

• 全部關閉表示CPU Burst策略為none。

• 全部開啟表示CPU Burst策略為auto。

由以上對比數據可知：

• 開啟CPU Burst能力后，應用的RT指標的p99分位值有明顯優化。

• 對開啟CPU Burst能力后，CPU Throttled情況大幅減少，而同時Pod整體CPU利用率基本保持不變。

高級參數配置

CPU Burst策略的高級配置參數支持在ConfigMap參數中配置，也支持在Pod Annotation中配置。對于同時在Pod Annotation和ConfigMap配置的參數，Pod Annotation配置優先級大于ConfigMap配置。如果Pod Annotation中沒有對應配置，ack-koordinator會進一步參考Namespace維度的ConfigMap配置；如果Namespace維度也沒有對應配置，ack-koordinator會以集群維度的ConfigMap配置為準。

配置示例如下。

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

# Pod Annotation樣例。
  koordinator.sh/cpuBurst: '{"policy": "auto", "cpuBurstPercent": 1000, "cfsQuotaBurstPercent": 300, "cfsQuotaBurstPeriodSeconds": -1}'

以下為CPU Burst策略的相關高級參數：

FAQ