使用CPU Burst效能最佳化策略提升延遲敏感型應用程式容器效能表現 - Container Service for Kubernetes

受CPU Limit約束，容器在運行過程中可用的CPU資源會受到限制，當真實用量觸發上限時，核心會對其限流（Throttling），進而導致服務品質受損。CPU Burst功能能夠動態感知CPU Throttled現象並對容器參數進行自適應調節。在出現突發負載時，CPU Burst可以為容器臨時提供額外的CPU資源，緩解CPU限制帶來的效能瓶頸，以保障並提升應用（尤其是延遲敏感型應用）的服務品質。

說明

為了協助您更好地理解本文檔並使用本功能，推薦您提前瞭解CFS Scheduler、節點CPU管理原則等相關概念。

為什麼需要啟用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時間片。

功能優勢

CPU使用率是衡量容器運行狀態的關鍵計量，叢集管理員通常會參考該指標來配置容器的CPU Limit。相較於常用的秒層級指標，百毫秒層級下容器的CPU使用率往往呈現更為明顯的毛刺特徵，展示出更多瞬時變化。以下圖為例，如果以秒層級為單位（紫色折線），CPU用量明顯少於4核；而如果以毫秒層級為單位（綠色折線），那麼容器CPU用量在部分時段會超出4核，若將CPU Limit配置為4核，就會導致線程因CPU限流而被作業系統掛起。

原理說明

下方圖片展示了在一台4核節點上，一個CPU Limit = 2的Web服務容器在收到請求（req）後，各個線程（Thread）的CPU資源分派情況。左圖為常規情況，右圖為開啟CPU Burst後的情況。

即使容器在最近1s內整體的CPU使用率較低，但受CPU限流的影響，Thread 2仍需要等待下一個時間周期才能繼續將req 2處理完成，導致請求的響應時延（RT）變大。這是容器RT長尾問題的一個重要原因。 ack-slo-manager example.png

啟用CPU Burst功能後，容器可以在空閑時積累一些CPU時間片，用於滿足突發時的資源需求，進而可以提升容器效能，降低延遲指標。 CPU Burst.png

除了上述情境之外，CPU Burst還適用於容器CPU資源需求突增的情境。例如，當業務流量突然上漲時，ack-koordinator可以在保障整機負載水位安全的前提下，在秒層級內快速解決CPU的資源瓶頸。

說明

ack-koordinator的調節僅涉及節點cgroup參數中的cfs quota，並不會修改Pod Spec的CPU Limit欄位。

使用情境

CPU Burst功能的典型使用情境如下。

容器在大多數時間內CPU資源用量低於設定的CPU Limit，但容器CPU Throttled仍然時常出現，影響應用效能表現。開啟CPU Burst可以讓容器在突發負載時使用積累的時間片，有效解決CPU Throttled限流問題，提升應用服務品質。
容器應用在啟動載入階段CPU資源消耗較高，但在載入完成並進入穩定運行狀態後，其CPU用量會降到一個較低且穩定的水平。開啟CPU Burst後，您無需為容器配置過高的CPU Limit，即可讓應用在啟動階段使用更多時間片，確保應用能夠快速啟動。

費用說明

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

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

前提條件

已建立ACK叢集Pro版且叢集版本為1.18及以上，請參見建立ACK託管叢集、手動升級叢集。
說明
推薦使用Alibaba Cloud Linux作為作業系統，請參見開啟CPU Burst策略是否必須使用Alibaba Cloud Linux作業系統？。
已安裝ack-koordinator組件，且組件版本為0.8.0及以上，請參見ack-koordinator。

配置說明

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

通過Annotation為指定Pod開啟

通過Pod YAML的metadata欄位下配置CPU Burst策略的Annotation，針對指定Pod生效。

說明

如需在工作負載（例如Deployment）中配置，請在template.metadata欄位下配置Pod對應的Annotation。

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

通過ConfigMap在叢集維度開啟

通過ConfigMap配置的CPU Burst策略預設針對全叢集生效。

使用以下ConfigMap樣本，建立configmap.yaml檔案。

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

查看命名空間kube-system下是否存在ConfigMapack-slo-config。
- 存在：使用PATCH方式進行更新，避免幹擾ConfigMap中其他配置項。
```
kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)
```
- 不存在：執行以下命令進行建立ConfigMap。
```
kubectl apply -f configmap.yaml
```

通過ConfigMap在Namespace維度開啟

通過指定Namespace，為部分Pod配置CPU Burst策略時，針對指定命名空間生效。

使用以下ConfigMap樣本，建立configmap.yaml檔案。

apiVersion: v1
kind: ConfigMap
metadata:
  name: ack-slo-pod-config
  namespace: koordinator-system # 首次使用時需要先手動建立該Namespace。
data:
  # 單獨開啟或關閉部分Namespace的Pod。
  cpu-burst: |
    {
      "enabledNamespaces": ["allowed-ns"], 
      "disabledNamespaces": ["blocked-ns"]
    }
  # 為allowed-ns命名空間下的所有Pod開啟了CPU Burst策略，對應policy為auto。
  # 為blocked-ns命名空間下的所有Pod關閉了CPU Burst策略，對應policy為none。

查看命名空間kube-system下是否存在ConfigMapack-slo-config。
- 存在：使用PATCH方式進行更新，避免幹擾ConfigMap中其他配置項。
```
kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)
```
- 不存在：執行以下命令建立ConfigMap。
```
kubectl apply -f configmap.yaml
```

操作步驟

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

驗證步驟

使用以下樣本應用的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

執行以下命令，部署Apache HTTP Server作為目標評測應用。
```
kubectl apply -f apache-demo.yaml
```

使用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。

重要

以下資料僅為理論值，實際請以您的作業環境為準。

Alibaba Cloud Linux	全部關閉	全部開啟
apache RT-p99	107.37 ms	67.18 ms（-37.4%）
CPU Throttled Ratio	33.3%	0%
Pod CPU平均利用率	31.8%	32.6%

CentOS	全部關閉	全部開啟
apache RT-p99	111.69 ms	71.30 ms （-36.2%）
CPU Throttled Ratio	33%	0%
Pod CPU平均利用率	32.5%	33.8%

由以上對比資料可知：

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

說明

Annotation和ConfigMap兩列分別代表是否允許通過Pod Annotation或ConfigMap進行配置。其中，代表支援，代表不支援。

參數	類型	說明	Annotation	ConfigMap
`policy`	string	`none`（預設值）：關閉CPU Burst策略，相關參數會被恢複為建立初始值。 `cpuBurstOnly`：僅開啟Alibaba Cloud Linux核心層級的CPU Burst彈性。 `cfsQuotaBurstOnly`：僅開啟CFS quota的自動彈效能力，支援所有核心版本。 `auto`：自適應開啟以上兩種彈效能力，包括Alibaba Cloud Linux核心特性，以及CFS quota的自動彈效能力。
`cpuBurstPercent`	int	預設值為`1000`，單位為百分比。 Alibaba Cloud Linux核心層級的CPU Burst彈性，表示相較於CPU Limit，CPU Burst放大的百分比。對應Pod的cgroup參數`cpu.cfs_burst_us`。更多資訊，請參見在cgroup v1介面開啟CPU Burst功能。例如，按預設配置，`CPU Limit = 1`對應的`cpu.cfs_quota_us`為100,000，`cpu.cfs_burst_us`會放大10倍為1,000,000。
`cfsQuotaBurstPercent`	int	預設值為`300`，單位為百分比。開啟CFS quota彈效能力時，Pod的cgroup參數（`cpu.cfs_quota_us`）可上調的最大比例，預設為3倍。
`cfsQuotaBurstPeriodSeconds`	int	預設值為`-1`，表示不限制，單位為秒。開啟CFS quota彈效能力時，Pod可以按上限（`cfsQuotaBurstPercent`）持續消耗CPU的時間限制。單個Pod超出時限後，其已經上調的cgroup參數（`cpu.cfs_quota_us`）會被恢複為原始值，其他Pod不受影響。
`sharePoolThresholdPercent`	int	預設值為`50`，單位為百分比。開啟CFS quota彈效能力時，節點CPU使用率的安全水位閾值。超出閾值後，節點中所有已經上調的Pod的cgroup參數（`cpu.cfs_quota_us`）會被恢複為建立初始值。

說明

當您開啟CFS quota的自動調整時（policy設定為cfsQuotaBurstOnly或auto），Pod的CPU Limit在節點上對應的參數（cpu.cfs_quota_us）會隨CPU Throttled情況而動態調整。
在對Pod進行壓測時，建議您同時保持對Pod CPU用量的觀察，或者臨時關閉CFS quota的自動調整（policy設定為cpuBurstOnly或none），以便在生產環境保持更好的資源彈性。

FAQ

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

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

說明

ack-koordinator對舊版本協議的相容期限截止至2023年07月30日。強烈建議您將原協議資源欄位及時升級到新版本。

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

ack-koordinator版本	alibabacloud.com協議	koordinator.sh協議
≥0.2.0	支援	不支援
≥0.8.0	支援	支援

開啟CPU Burst配置後，為什麼Pod仍有CPU Throttled現象出現？

通常會有以下幾個原因，您可以參考以下說明進行調整。

配置格式錯誤，導致CPU Burst策略沒有生效，請參見進階參數配置修改並驗證。
CPU利用率達到cfsQuotaBurstPercent配置的上限時，由於CPU資源不足，仍會出現CPU Throttled現象。
建議您根據應用實際需求情況調整Reqeuest和Limit值。
CPU Burst策略會調整Pod的兩個cgroup參數：cpu.cfs_quota_us和cpu.cfs_burst_us，詳情請參見進階參數配置。其中，cpu.cfs_quota_us在ack-koordinator感知到CPU Throttled後才會進行設定，存在少許延遲；而cpu.cfs_burst_us直接參考配置進行設定，效果更靈敏。
建議您搭配Alibaba Cloud Linux作業系統使用，效果更佳。
CPU Burst策略在調整cpu.cfs_quota_us時會有保護機制，即整機安全水位閾值配置的sharePoolThresholdPercent。當整機利用率過高時，為了避免單個Pod產生更多幹擾，cpu.cfs_quota_us會被重設為初始值。
建議您結合自身應用的實際情況，合理設定整機安全水位閾值，避免因整機利用率過高而影響應用效能。

開啟CPU Burst策略是否必須使用Alibaba Cloud Linux作業系統？

ack-koordinator的CPU Burst策略適用於所有Alibaba Cloud Linux及CentOS開源核心。推薦您使用Alibaba Cloud Linux作業系統。藉助Alibaba Cloud Linux核心特性，ack-koordinator可以提供更加細粒度的CPU彈性管理機制。更多資訊，請參見在cgroup v1介面開啟CPU Burst功能。