Container Service for Kubernetes：CPU Burst效能最佳化策略

費用說明

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

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

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

使用情境

以下是此CPU Burst功能可以應用的幾個樣本：

• 容器CPU資源用量低於Limit限制，但容器CPU Throttled指標仍然時常出現，影響應用效能表現。開啟CPU Burst可以有效解決CPU Throttled限流問題，提升應用服務品質。

• 容器應用在啟動載入階段CPU資源消耗較高，但在載入完成後的日常狀態下其CPU用量相對正常。開啟CPU Burst一方面可以滿足應用啟動階段的資源需求，另一方面可以避免為容器設定過高的資源規格，減少資源浪費。

原理說明

Kubernetes為容器資源管理提供了Limit（約束）的語義描述。對於CPU這類分時複用型的資源，當容器指定了CPU Limit，作業系統會按照一定的時間周期約束資源使用。例如對於CPU Limit = 2的容器，作業系統核心會限制容器在每100 ms周期內最多使用200 ms的CPU時間片。

CPU使用率是衡量容器運行狀態的關鍵計量，管理員通常會參考該指標來設定容器CPU Limit。相較於常用的秒層級指標，百毫秒層級下容器的CPU使用率往往呈現更為明顯的毛刺特徵。若容器在100 ms內將CPU Limit消耗完成，線程會因限流（CPU Throttled）而被作業系統掛起，如下圖所示。

下圖展示了一台4核節點、某CPU Limit = 2的Web服務類容器，在收到請求（req）後各線程（Thread）的CPU資源分派情況。可以看出，即使容器在最近1s內整體的CPU使用率較低，受CPU Throttled機制的影響，Thread 2仍需要等待下一個周期才能繼續將req 2處理完成，進而導致請求的響應時延（RT）變大，這通常就是容器RT長尾現象嚴重的原因之一。

Alibaba Cloud Linux提供了CPU Burst功能，允許容器在空閑時積累一些CPU時間片，用於滿足突發時的資源需求，進而可以提升容器效能、降低延遲指標。更多資訊，請參見在cgroup v1介面開啟CPU Burst功能。

對於尚未支援CPU Burst策略的核心版本，ack-koordinator會通過類似的原理，監測容器CPU Throttled狀態，並動態調節容器的CPU Limit，實現與核心CPU Burst策略類似的效果。

上述自動調節CFS quota的策略，還可用於滿足容器CPU資源需求突增的情境。例如當業務流量突然上漲，ack-koordinator可以在保障整機負載水位安全的前提下，秒層級內快速解決CPU的資源瓶頸。

Alibaba Cloud Linux提供的核心級CPU Burst策略有著更高的靈敏度，我們強烈建議您為延遲敏感型應用（Latency Sensitive）開啟該特性。

使用方式

通過Pod Annotation開啟CPU Burst

annotations:
  # 設定為auto， 表示開啟該Pod的cpu burst功能。
  koordinator.sh/cpuBurst: '{"policy": "auto"}'
  # 設定為none， 表示關閉該Pod的cpu burst功能。
  #koordinator.sh/cpuBurst: '{"policy": "none"}'

通過ConfigMap全域開啟CPU Burst

1. 使用以下ConfigMap樣本，建立configmap.yaml檔案，表示預設開啟全叢集的CPU Burst策略。

   apiVersion: v1
   data:
     cpu-burst-config: '{"clusterStrategy": {"policy": "auto"}}'
     #cpu-burst-config: '{"clusterStrategy": {"policy": "cpuBurstOnly"}}'
     #cpu-burst-config: '{"clusterStrategy": {"policy": "none"}}'
   kind: ConfigMap
   metadata:
     name: ack-slo-config
     namespace: kube-system

2. 查看命名空間kube-system下是否存在ConfigMapack-slo-config。

   • 若存在ConfigMapack-slo-config，使用PATCH方式進行更新，避免幹擾ConfigMap中其他配置項。

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

   • 若不存在ConfigMapack-slo-config，執行以下命令進行建立ConfigMap。

     kubectl apply -f configmap.yaml

指定Namespace開啟部分容器的CPU Burst

apiVersion: v1
kind: ConfigMap
metadata:
  name: ack-slo-pod-config
  namespace: koordinator-system # 首次使用時需要先手動建立該Namespace
data:
  #單獨開啟或關閉部分Namespace的Pod。
  cpu-burst: |
    {
      "enabledNamespaces": ["white-ns"],
      "disabledNamespaces": ["black-ns"]
    }

CPU Burst策略進階配置參數

# 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策略的相關進階參數：

驗證CPU Burst效果

驗證步驟

1. 使用以下樣本應用的YAML內容，建立名為apache-demo.yaml檔案。

   在Pod對象的metadata下配置annotations，為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 # 注意修改模板中指定節點的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 Throttled及利用率指標，可以看到開啟CPU Burst能力後，CPU Throttled情況得到了消除，同時Pod整體利用率基本保持不變。

FAQ

當前已通過ack-slo-manager的舊版本協議使用了CPU Burst功能，升級為ack-koordinator後是否繼續支援？

舊版本的Pod協議要求在Annotation中填寫alibabacloud.com/cpuBurst，ack-koordinator對此舊版本協議完全相容，您可將組件無縫升級至新版本。

ack-koordinator對各版本協議的適配如下。