本文介紹如何使用ack-koordinator快速搭建一套在離線混部環境,並將應用程式切換為混部模式運行。
前提條件
僅適用於ACK Pro版叢集。具體操作,請參見建立ACK Pro版叢集。
已安裝ack-koordinator組件(原ack-slo-manager),且版本≥0.8.0。具體操作,請參見ack-koordinator(ack-slo-manager)。
為達到最佳的混部使用效果,建議您使用神龍裸金屬伺服器和Alibaba Cloud Linux。
資源優先順序與QoS
資源優先順序和服務品質QoS(Quality of Service)是ACK差異化SLO混部模型的兩個核心概念。
資源優先順序是對節點資源容量的描述,為瞭解決叢集“分配率高,利用率低”的矛盾,優先順序之間的主要區別如下:
各優先順序的資源總量會受高優先順序資源的申請量和使用量的影響,例如已申請但未使用的Product資源會以Batch優先順序再次分配。
資源優先順序策略的激進或保守,決定了叢集資源的超賣容量,與資源穩定性的高低成反相關。
超賣優先順序的資源以標準的extended-resource形式更新在Node資訊中。
目前的資源模型包括以下兩個資源等級:
資源優先順序 | 資源計算原理 | 資源名稱 |
Product | 通常為節點對應的實體資源量。 | K8s原生的Node可分配資源(Allocatable),包括CPU和Memory。 |
Batch | 根據節點利用率情況動態計算產生的超賣資源,計算模型為:整機實體資源-Product優先順序的真實使用量,詳情請參見動態資源超賣。 | 以extended-resource形式在Node狀態中動態更新,包括 |
QoS是對應用效能敏感程度的描述,為了說明不同應用對資源品質需求的差異,影響Pod運行過程中的效能表現。具體表現為使用的隔離參數不同,宿主機資源緊張時會優先滿足高等級QoS的需求。目前的資源模型包括以下兩個服務品質等級:
QoS等級 | 適合應用類型 | 資源品質 |
LS (Latency Sensitive) | 延遲敏感型,即線上服務。 | 核心CPU時間片優先調度,記憶體回收時優先保障,可以使用更多的L3Cache和記憶體頻寬資源等。 |
BE (Best Effort) | 資源消耗型,即混部對應的離線作業。 | 核心CPU時間片調度優先順序較低,資源緊張時記憶體會被優先回收,L3Cache和記憶體頻寬等資源的使用受限。 |
資源優先順序和QoS是兩個獨立的維度,可以排列組合進行使用。但由於受模型定義和實際的需求情況的影響,部分排列組合存在約束,常用的典型情境包括以下兩種:
Product+LS:典型的線上應用,通常對應用時延要求較高,對資源品質要求較高。例如Web服務、有延時要求的流式計算等。
Batch+BE:用於混部情境中的低優離線,對資源品質的要求相對更低。例如批處理類型的Spark或MR任務、AI類型的訓練任務等。
管理混部策略
ack-koordinator提供了統一的ConfigMap來管理各項混部策略,您可以參照以下步驟,開啟所有混部相關的最佳化策略。
使用以下ConfigMap,建立configmap.yaml檔案。
#ConfigMap ack-slo-config範例。 apiVersion: v1 kind: ConfigMap metadata: name: ack-slo-config namespace: kube-system data: colocation-config: |- { "enable": true } resource-qos-config: |- { "clusterStrategy": { "lsClass": { "cpuQOS": { "enable": true }, "memoryQOS": { "enable": true }, "resctrlQOS": { "enable": true } }, "beClass": { "cpuQOS": { "enable": true }, "memoryQOS": { "enable": true }, "resctrlQOS": { "enable": true } } } } resource-threshold-config: |- { "clusterStrategy": { "enable": true } }
各項配置關聯的混部策略說明如下:
配置項
功能描述
colocation-config
通過對節點負載資料的即時收集,可以充分挖掘叢集中已指派但未使用的資源量,實現對叢集資源的動態超賣,詳情請參見動態資源超賣。
resource-qos-config
針對不同資源維度提供精細化管理能力,在容器運行階段優先保障高優先順序應用的QoS,詳情請參見容器CPU QoS、容器記憶體QoS和容器L3 Cache及記憶體頻寬隔離。
resource-threshold-config
宿主機彈性資源壓制策略,根據資源使用水位對低優Pod的可用資源進行動態限制,詳情請參見彈性資源限制。
執行以下命令,建立Configmap。
kubectl apply -f configmap.yaml
部署應用
使用以下內容,建立nginx-ls-pod.yaml檔案。
為線上應用添加延時敏感型
LS
標籤。此處以Nginx服務的Pod為例,在Pod的labels
處增加koordinator.sh/qosClass: LS
索引值對。# nginx-ls-pod.yaml檔案。 apiVersion: v1 kind: Pod metadata: labels: koordinator.sh/qosClass: LS app: nginx name: nginx spec: containers: - image: 'koordinatorsh/nginx:v1.18-koord-exmaple' imagePullPolicy: IfNotPresent name: nginx ports: - containerPort: 8000 hostPort: 8000 # 壓測請求訪問的連接埠。 protocol: TCP resources: limits: cpu: '8' memory: 1Gi requests: cpu: '8' memory: 1Gi volumeMounts: - mountPath: /apps/nginx/conf name: config hostNetwork: true restartPolicy: Never volumes: - configMap: items: - key: config path: nginx.conf name: nginx-conf name: config
使用以下內容,建立ffmpeg-be-pod.yaml檔案。
為離線應用添加計算密集型
BE
標籤,並申請超賣資源kubernetes.io/batch-cpu
和kubernetes.io/batch-memory
。此處以轉碼類型的Pod為例,在Pod的labels
處增加koordinator.sh/qosClass: BE
索引值對。# ffmpeg-be-pod.yaml檔案。 apiVersion: v1 kind: Pod metadata: labels: koordinator.sh/qosClass: BE name: be-ffmpeg spec: containers: - command: - start-ffmpeg.sh - '30' - '2' - /apps/ffmpeg/input/HD2-h264.ts - /apps/ffmpeg/ image: 'registry.cn-zhangjiakou.aliyuncs.com/acs/ffmpeg-4-4-1-for-slo-test:v0.1' imagePullPolicy: Always name: ffmpeg resources: limits: # 單位為千分之一核。 kubernetes.io/batch-cpu: "70k" kubernetes.io/batch-memory: "22Gi" requests: # 單位為千分之一核。 kubernetes.io/batch-cpu: "70k" kubernetes.io/batch-memory: "22Gi"
執行以下命令,部署線上應用和離線應用的Pod。
kubectl apply -f nginx-ls-pod.yaml kubectl apply -f ffmpeg-be-pod.yaml
後續操作
應用部署完畢後,您可以使用ACK的在離線混部能力,詳情請參見線上服務與視頻轉碼應用混部。
關於在離線混部功能的更多資訊,請參見: