Kubernetes支援將多種類型的應用以容器化的方式部署在同一台宿主機上運行,不同優先順序的應用可能會競爭CPU資源,導致應用服務受損。ack-koordinator支援基於容器的QoS等級,優先保障高優先順序應用的CPU效能。本文介紹如何使用容器CPU QoS功能。
背景資訊
為了充分利用機器中的資源,通常會將高優先延遲敏感性LS(Latency-Sensitive)和低優先順序BE(Best-Effort)的任務部署在同一台機器上,導致兩種不同優先順序任務之間存在資源競爭問題。Kubernetes根據應用的CPU Request/Limit,為容器設定實體資源限制,但仍存在容器間對CPU資源的競爭。例如,BE應用和LS應用共用物理核或邏輯核時,當BE應用負載較高時,會干擾LS應用的運行,導致服務響應延遲變高。
為了提高LS應用使用CPU資源的穩定性,降低BE應用的幹擾,ack-koordinator基於Alibaba Cloud Linux 2,提供了容器CPU QoS功能。ack-koordinator基於Group Identity提供的Linux調度優先順序,差異化保障不同優先順序應用的CPU調度,將LS應用標識為高優,BE應用標識為低優,在混合部署情境中有效改善LS應用的服務品質。更多資訊,請參見Group Identity功能說明。
通過啟用容器CPU QoS功能,您可以擷取以下功能特性:
LS應用的任務喚醒延遲最小化。
BE應用的任務喚醒不會對LS容器造成效能影響。
BE應用的任務不會通過同時多線程SMT(Simultaneous MultiThreading)調度器共用物理核而對LS應用造成效能影響。
前提條件
僅支援ACK Pro版叢集。具體操作,請參見建立ACK Pro版叢集。
已安裝ack-koordinator(原ack-slo-manager)。具體操作,請參見ack-koordinator(ack-slo-manager)。
使用限制
系統組件版本要求如下表所示。
組件 | 版本要求 |
Kubernetes | ≥v1.18 |
≥v0.8.0 | |
Helm版本 | ≥v3.0 |
作業系統 | Alibaba Cloud Linux 2(版本號碼詳情,請參見Group Identity功能說明) |
若您未使用Alibaba Cloud Linux 2,可以使用ack-koordinator提供的CPU彈性資源限制功能,保障容器CPU服務品質。更多資訊,請參見彈性資源限制。
費用說明
ack-koordinator組件本身的安裝和使用是免費的,不過需要注意的是,在以下情境中可能產生額外的費用:
操作步驟
使用以下ConfigMap,建立configmap.yaml檔案。
#ConfigMap ack-slo-config範例。 apiVersion: v1 kind: ConfigMap metadata: name: ack-slo-config namespace: kube-system data: #開啟容器CPU QoS功能。 resource-qos-config: | { "clusterStrategy": { "lsClass": { "cpuQOS": { "enable": true, "groupIdentity": 2 } }, "beClass": { "cpuQOS": { "enable": true, "groupIdentity": -1 } } } }
lsClass
、beClass
分別用於配置QoS等級為LS、BE的Pod,cpuQOS
用於配置容器CPU QoS功能。關鍵參數說明如下:參數
類型
取值範圍
說明
enable
Boolean
true
false
true:叢集全域開啟容器CPU QoS功能。
false:叢集全域關閉容器CPU QoS功能。
groupIdentity
Int
-1~2
表示CPU Group Identity的優先順序。預設值依據QoS,LS對應2,BE對應-1。0表示關閉。
groupIdentity
值越大,表示容器在核心調度的優先順序越高。例如,按預設配置,QoS等級為LS的容器Group Identity介面配置為cpu.bvt_warp_ns=2
,BE容器配置為cpu.bvt_warp_ns=-1
。更多資訊,請參見Group Identity功能說明。說明對於未指定
koordinator.sh/qosClass
的Pod,ack-koordinator將參考Pod原生的QoSClass來設定參數,其中Besteffort使用ConfigMap中BE的配置,其他QoSClass使用ConfigMap中LS的配置。查看命名空間
kube-system
下是否存在ConfigMapack-slo-config
。若存在ConfigMap
ack-slo-config
,請使用PATCH方式進行更新,避免幹擾ConfigMap中其他配置項。kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)"
若不存在ConfigMap
ack-slo-config
,請執行以下命令進行建立Configmap。kubectl apply -f configmap.yaml
使用以下YAML內容,建立ls-pod-demo.yaml檔案。
apiVersion: v1 kind: Pod metadata: name: ls-pod-demo labels: koordinator.sh/qosClass: 'LS' #指定Pod的QoS層級為LS。 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 restartPolicy: Never schedulerName: default-scheduler
執行以下命令,將ls-pod-demo部署到叢集。
kubectl apply -f ls-pod-demo.yaml
執行以下命令,在單機端的Cgroup分組中查看LS Pod的核心Group Identity生效情況。
cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-pod1c20f2ad****.slice/cpu.bvt_warp_ns
預期輸出:
#LS Pod的Group Identity優先順序為2(高優)。 2
使用以下YAML內容,建立be-pod-demo.yaml檔案。
apiVersion: v1 kind: Pod metadata: name: be-pod-demo labels: koordinator.sh/qosClass: 'BE' #指定Pod的QoS層級為BE。 spec: containers: - args: - '-c' - '1' - '--vm' - '1' command: - stress image: polinux/stress imagePullPolicy: Always name: stress restartPolicy: Always schedulerName: default-scheduler
執行以下命令,將be-pod-demo部署到叢集。
kubectl apply -f be-pod-demo.yaml
執行以下命令,在單機端的Cgroup分組中查看BE Pod的核心Group Identity生效情況。
cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod4b6e96c8****.slice/cpu.bvt_warp_ns
預期輸出:
#BE Pod的Group Identity優先順序為-1(低優)。 -1
由預期輸出得到,LS容器為Group Identity高優先順序,BE容器為Group Identity低優先順序,表示LS容器的CPU服務品質將被優先保障。
FAQ
當前已經通過ack-slo-manager的舊版本協議使用了CPU QoS功能,升級為ack-koordinator後是否繼續支援CPU QoS功能?
舊版本(≤0.8.0)的Pod協議:在Pod的Annotation中填寫alibabacloud.com/qosClass
。
ack-koordinator保持了對以上舊版本協議的相容,您可以將組件無縫升級至ack-koordinator。ack-koordinator將對以上舊版本協議相容至2023年7月30日,我們建議您將原協議資源欄位及時升級到新版本。
ack-koordinator各版本對CPU QoS功能的適配如下。
ack-koordinator版本 | alibabacloud.com協議 | koordinator.sh協議 |
≥0.5.2且<0.8.0 | 支援 | 不支援 |
≥0.8.0 | 支援 | 支援 |