在Kubernetes集群中,您可能會將延遲敏感型LS(Latency Sensitive)和低優先級BE(Best Effort)的應用部署在同一節點上。雖然應用會有CPU Request和Limit的限制,但不同優先級的應用之間可能會存在CPU資源的爭搶,導致服務質量,尤其是高優先級應用的服務質量下降。建議您開啟容器CPU QoS功能,優先保障LS應用的CPU資源使用。
為了幫助您更好地理解本文檔并使用本功能,推薦您參見Kubernetes官方文檔了解Pod Qos類、為容器和 Pod 分配內存資源等概念,并參見Group Identity功能說明了解Group Identity功能原理。
為什么需要容器CPU QoS
為了充分利用節點資源,在離線混部場景會將高優先級的LS應用和低優先級的BE應用部署在同一臺機器上。雖然Kubernetes根據應用的CPU Request和Limit限制容器物理資源的使用,但容器間CPU資源的競爭仍然不可避免。例如,BE應用和LS應用共享物理核或邏輯核時,在BE應用負載較高時,會干擾LS應用的運行,導致服務響應延遲變高。
為了提高LS應用可用的CPU資源的穩定性,降低BE應用帶來的干擾,ack-koordinator基于Alibaba Cloud Linux提供了容器CPU QoS功能。ack-koordinator基于Group Identity提供的Linux調度優先級支持差異化保障不同優先級應用的CPU調度,將LS應用標識為高優,BE應用標識為低優,在混合部署場景中有效改善LS應用的服務質量。
啟用容器CPU QoS后,您將獲得以下功能特性。
LS應用的任務能更快地被操作系統調度運行,提高響應速度和性能。
BE應用的任務被喚醒時,不會搶占LS應用的進程,避免對高優先級任務的干擾。
即使在同時多線程SMT(Simultaneous MultiThreading)的場景下,BE應用的任務也不會與LS應用的任務在同一物理核心上并行執行,防止BE任務因爭奪同一物理核心的計算資源而對LS任務的性能產生影響。
前提條件
已創建ACK集群,且符合以下要求:
集群版本:1.18及以上。如需升級集群,請參見手動升級集群。
操作系統:本功能使用的Group Identity參數依賴Alibaba Cloud Linux。關于內核版本號限制,請參見Group Identity功能說明。
說明若您的操作系統類型不是Alibaba Cloud Linux,您可以使用CPU彈性資源限制功能控制BE類型Pod可使用的CPU資源量,請參見啟用CPU資源彈性限制能力。
已安裝ack-koordinator組件,且組件版本為v0.8.0及以上,請參見ack-koordinator(ack-slo-manager)。
費用說明
ack-koordinator組件本身的安裝和使用是免費的,不過需要注意的是,在以下場景中可能產生額外的費用:
ack-koordinator是非托管組件,安裝后將占用Worker節點資源。您可以在安裝組件時配置各模塊的資源申請量。
ack-koordinator默認會將資源畫像、精細化調度等功能的監控指標以Prometheus的格式對外透出。若您配置組件時開啟了ACK-Koordinator開啟Prometheus監控指標選項并使用了阿里云Prometheus服務,這些指標將被視為自定義指標并產生相應費用。具體費用取決于您的集群規模和應用數量等因素。建議您在啟用此功能前,仔細閱讀阿里云Prometheus計費說明,了解自定義指標的免費額度和收費策略。您可以通過賬單和用量查詢,監控和管理您的資源使用情況。
操作步驟
您可以通過ConfigMap在集群維度開啟容器CPU QoS功能,為LS、BE類型的Pod配置對應的CPU Group Identity的優先級。Group Identity可以為每一個CPU cgroup設置身份標識,系統內核在調度包含具有身份標識的任務時,會根據不同的優先級做相應處理。
配置完成后,您便可以在Pod YAML中通過Labelkoordinator.sh/qosClass
聲明Pod對應的CPU QoS類。對于未指定koordinator.sh/qosClass
的Pod,ack-koordinator將遵循Kubernetes原生的QoS類來配置,其中BestEffort類型的Pod為BE
、其他QoS類的Pod為LS
。
使用以下ConfigMap,創建configmap.yaml文件,啟用CPU QoS功能。
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的優先級。
groupIdentity
值越大,表示容器在內核調度的優先級越高。更多信息,請參見Group Identity功能說明。默認情況下,LS Pod為
2
,BE為-1
。0
表示關閉。查看命名空間kube-system下是否存在ConfigMap
ack-slo-config
。存在:使用PATCH方式進行更新,避免干擾ConfigMap中其他配置項。
kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)"
不存在:執行以下命令創建ConfigMap。
kubectl apply -f configmap.yaml
使用以下YAML內容,創建ls-pod-demo.yaml文件,其中指定Pod的QoS類為LS,并將YAML文件部署到集群中。
說明如需在工作負載(例如Deployment)中配置,請在
template.metadata
字段下配置Pod對應的Annotation。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
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文件,其中指定Pod的QoS類為BE,并將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
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 Pod的Group Identity為高優先級,BE Pod的Group Identity為低優先級,即LS Pod的CPU服務質量將被優先保障。
FAQ
當前已經通過ack-slo-manager的舊版本協議使用了CPU QoS功能,升級為ack-koordinator后是否繼續支持CPU QoS功能?
舊版本(≤0.8.0)的Pod協議中,通過在Pod的Annotation中填寫alibabacloud.com/qosClass
啟用CPU QoS。
ack-koordinator保持了對以上舊版本協議的兼容,您可以將組件無縫升級至ack-koordinator,并逐步將Pod切換為koordinator.sh協議。ack-koordinator將對以上舊版本協議兼容至2023年07月30日,我們建議您將原協議資源字段及時升級到新版本。
ack-koordinator各版本對CPU QoS功能的適配如下。
組件版本 | alibabacloud.com協議 | koordinator.sh協議 |
≥0.5.2且<0.8.0 | 支持 | 不支持 |
≥0.8.0 | 支持 | 支持 |