Container Service for Kubernetes：線上服務與視頻轉碼應用混部

情境描述

使用ACK叢集部署線上服務應用Nginx，並在相同節點混合部署視頻轉碼應用FFmpeg，用於充分發掘叢集中已申請但未使用的實體資源。同時啟用ack-koordinator的資源隔離能力，保障線上服務Nginx的運行，規避來自離線應用FFmpeg的幹擾。

應用部署架構

在ACK叢集中的機器運行Nginx伺服器應用作為線上服務，與視頻解碼應用FFmpeg混部。其中，標識Nginx Pod的QoS等級為高優先順序延遲敏感型LS（Latency Sensitive），標識FFmpeg Pod的QoS等級為低優先順序BE（Best Effort）。本文將對比在不同混部配置下，Nginx應用表現的效能差異。

準備工作

環境準備

• 在ACK Pro叢集中建立2個節點用於構建混部環境。其中一個節點作為測試機，將運行Nginx和FFmpeg的混部測試；另一節點作為壓測機，將運行用戶端的wrk，向Nginx請求Web服務，製造壓測請求。具體操作，請參見建立ACK Pro版叢集。

• 為了能夠充分使用ack-koordinator提供的混部最佳化能力，建議測試機使用神龍裸金屬伺服器及Alibaba Cloud Linux。

• 安裝ack-koordinator（ack-slo-manager）並開啟相關混部策略，詳情請參見快速入門。本文以ack-koordinator v0.8.0版本為例進行說明。

線上應用準備

部署混部測試所需的線上服務應用和壓測工具。

1. 使用以下YAML內容，建立ls-nginx.yaml檔案。

   展開查看YAML詳情

   ---
   # nginx應用配置
   apiVersion: v1
   data:
     config: |-
       user  nginx;
       worker_processes  80; # Nginx的Worker個數，影響Nginx Server的並發。
   
       events {
           worker_connections  1024;  # 預設值為1024。
       }
   
       http {
           server {
               listen  8000;
   
               gzip off;
               gzip_min_length 32;
               gzip_http_version 1.0;
               gzip_comp_level 3;
               gzip_types *;
           }
       }
   
       #daemon off;
   kind: ConfigMap
   metadata:
     name: nginx-conf
   
   ---
   # Nginx執行個體，作為線上類型服務應用。
   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: '80'
             memory: 10Gi
           requests:
             cpu: '80'
             memory: 10Gi
         volumeMounts:
           - mountPath: /apps/nginx/conf
             name: config
     hostNetwork: true
     restartPolicy: Never
     volumes:
       - configMap:
           items:
             - key: config
               path: nginx.conf
           name: nginx-conf
         name: config
     nodeName: cn-beijing.192.168.2.93  # 請替換為您的測試機的節點名稱。

2. 執行以下命令，部署Nginx應用。

   kubectl apply -f ls-nginx.yaml

3. 執行以下命令，查看Nginx應用的Pod狀態。

   kubectl get pod -l app=nginx -o wide

   預期輸出：

   NAME    READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
   nginx   1/1     Running   0          43s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

   由預期輸出得到，Pod的狀態為Running ，表示Nginx應用已在測試機上正常運行。

4. 在壓測機上，執行以下命令，部署壓測工具wrk。

   wget -O wrk-4.2.0.tar.gz https://github.com/wg/wrk/archive/refs/tags/4.2.0.tar.gz && tar -xvf wrk-4.2.0.tar.gz
   cd wrk-4.2.0 && make && chmod +x ./wrk

離線應用準備

準備部署混部測試所需的離線視頻轉碼應用FFmpeg。

1. 使用以下YAML內容，建立be-ffmpeg.yaml檔案。

   展開查看YAML詳情

   # FFmpeg執行個體，作為離線類型計算應用。
   apiVersion: v1
   kind: Pod
   metadata:
     name: be-ffmpeg
     labels:
       app: ffmpeg
     # 1. 按照K8s預設混合部署模式部署：刪除以下koordinator.sh/qosClass=BE的label。
     # 2. 按照ACK差異化SLO混部模式部署：保留以下koordinator.sh/qosClass=BE的label。
       koordinator.sh/qosClass: BE
   spec:
     containers:
       # FFmpeg的進程數量可以根據測試需求調節，進程數越多對應的離線資源使用率越高，預設為25個進程，每個進程有兩個線程並發工作。
       - command:
           - start-ffmpeg.sh
           - '25'
           - '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:
         # 1. 按照K8s預設混合部署模式部署：刪除以下擴充資源kubernetes.io/batch-cpu和kubernetes.io/batch-memory。
         # 2. 按照ACK差異化SLO混部模式部署：保留以下擴充資源kubernetes.io/batch-cpu和kubernetes.io/batch-memory。
         # 具體資源需求量請按節點規格按需調整。
           limits:
             kubernetes.io/batch-cpu: 70k
             kubernetes.io/batch-memory: 22Gi
           requests:
             kubernetes.io/batch-cpu: 70k
             kubernetes.io/batch-memory: 22Gi
     hostNetwork: true
     restartPolicy: Never
     nodeName: cn-beijing.192.168.2.93  # 請替換為您的測試機的節點名稱。

2. 執行以下命令，部署FFmpeg應用。

   kubectl apply -f be-ffmpeg.yaml

3. 執行以下命令，查看FFmpeg應用的Pod狀態。

   kubectl get pod -l app=ffmpeg -o wide

   預期輸出：

   NAME        READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
   be-ffmpeg   1/1     Running   0          15s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

   由預期輸出得到，Pod的狀態為Running ，表示FFmpeg應用已在測試機上正常運行。

操作步驟

本文將進行三組實驗，分別採用以下三種的應用混合部署模式，對比不同混部模式下線上應用的效能表現和節點的資源使用率。

實驗結果總覽

• 對比基準和對照組：採用K8s預設的混合部署後，節點CPU平均利用率明顯提升（從29.6%變為65.1%），Nginx RT-p90和RT-p99明顯增大，RT效能出現了長尾現象。

• 對比基準和實驗組：採用ACK差異化SLO混部後，節點CPU平均利用率明顯提升（從28.5%變為64.8%），Nginx RT-p90和RT-p99相對基準有所增高，但仍屬於可接受範圍內。

• 對比對照組和實驗組：ACK差異化SLO混部相比K8s預設混部，節點CPU平均利用率相近，Nginx RT-p90和RT-p99明顯下降，基本與基準資料持平。

綜上，線上服務與視頻轉碼應用混部情境下，採用ACK差異化SLO混部模式能夠有效提升節點CPU資源使用率，抑制資源混部幹擾。

部署應用

線上應用獨立部署樣本

在測試機上只部署線上應用Nginx，測試線上服務未混部時的效能資料。

1. 參照線上應用部署，在測試機上部署線上應用Nginx。

2. 使用壓測工具wrk，向Nginx應用發起壓測請求。

   # node_ip填寫測試機的IP地址，用於wrk向測試機發起壓測；8000是Nginx暴露到測試機的連接埠。
   ./wrk -t6 -c54 -d60s --latency http://${node_ip}:8000/

3. 執行以下命令，擷取測試機的節點CPU平均利用率。

   kubectl top node

   預期輸出：

   NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   cn-beijing.192.168.2.93   29593m       29%    xxxx            xxxx
   cn-beijing.192.168.2.94   6874m        7%     xxxx            xxxx

   由預期輸出得到，壓測中測試機的平均CPU資源使用率約為29%。

4. 等待wrk運行結束後，執行以下命令，擷取wrk的壓測結果。

   建議重複多次測試，以獲得相對穩定的結果。

   Running 1m test @ http://192.168.2.94:8000/

   預期輸出：

     6 threads and 54 connections
     Thread Stats   Avg      Stdev     Max   +/- Stdev
       Latency   402.18us    1.07ms  59.56ms   99.83%
       Req/Sec    24.22k     1.12k   30.58k    74.15%
     Latency Distribution
        50%  343.00us
        75%  402.00us
        90%  523.00us
        99%  786.00us
     8686569 requests in 1.00m, 6.88GB read
   Requests/sec: 144537.08
   Transfer/sec:    117.16MB

   RT指標是本次衡量線上服務Nginx應用在不同情境下運行效能的關鍵計量。由預期輸出得到，Latency Distribution部分包含了wrk請求在Nginx應用上回應時間RT（Response Time）的分布。例如，90% 523.00us表示本次壓測中RT的90分位值（P90）為523.00us。Nginx應用在未混部情境下壓測得到的RT-P50、RT-P90、RT-P99分別為343us、523us、786us。

K8s預設混合部署樣本

將線上應用Nginx和離線視頻轉碼應用FFmpeg在測試機上混合部署，在壓測機上通過wrk工具向Nginx應用發起請求。操作步驟與ACK差異化SLO混合部署樣本基本相同，請參照該樣本進行部署，按照YAML中的注釋修改相關參數。

ACK差異化SLO混合部署樣本

在測試機上以ACK差異化SLO的BE Pod的形式部署視頻轉碼應用FFmpeg，測試線上服務在與視頻轉碼應用在差異化SLO混部下的效能資料。

1. 參考快速入門，開啟差異化SLO混部。

   相關功能說明如下：

   • 動態資源超賣：採用開啟後的預設配置。用於合理超賣節點未使用的實體資源，提供給BE Pod調度。

   • 彈性資源限制：cpuSuppressThresholdPercent設定為65，其他採用開啟後的預設配置。用於在節點CPU資源使用率超出閾值（65%）時，壓制BE應用的CPU使用，以保障LS應用的CPU效能。

   • 容器CPU QoS：採用開啟後的預設配置。用於啟用Alibaba Cloud Linux的CPU Identity能力，在核心調度中優先保障LS應用的CPU調度，避免因BE應用對LS應用運行在同一對SMT超執行緒上而產生的幹擾。

   • 容器L3 Cache及記憶體頻寬隔離：採用開啟後的預設配置。用於啟用裸金屬伺服器的容器L3 Cache和記憶體頻寬隔離機制，優先保障LS應用的L3 Cache和記憶體頻寬使用，緩解BE應用的資源競爭幹擾。

   重要

   • 容器CPU QoS功能僅在節點的作業系統版本為Alibaba Cloud Linux時生效；使用其他動作系統版本時，該功能不會開啟。

   • 容器L3 Cache及記憶體頻寬隔離功能僅在節點為裸金屬伺服器時生效；使用其他伺服器類型時，該功能不會開啟。

2. 參照線上應用部署，在測試機上部署線上應用Nginx。

3. 使用以下YAML內容，建立be-ffmpeg.yaml檔案。

   展開查看YAML詳情

   # FFmpeg執行個體，作為離線類型計算應用。
   apiVersion: v1
   kind: Pod
   metadata:
     name: be-ffmpeg
     labels:
       app: ffmpeg
     labels:
       # 指定FFmpeg應用為ACK差異化SLO的BE類型。
       koordinator.sh/qosClass: BE
   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:
         # 指定申請動態超賣資源kubernetes.io/batch-cpu和kubernetes.io/batch-memory。
           limits:
             kubernetes.io/batch-cpu: 70k
             kubernetes.io/batch-memory: 22Gi
           requests:
             kubernetes.io/batch-cpu: 70k
             kubernetes.io/batch-memory: 22Gi
     hostNetwork: true
     restartPolicy: Never
     nodeName: cn-beijing.192.168.2.93  # 請替換為您的測試機的節點名稱。

4. 執行以下命令，部署FFmpeg應用。

   kubectl apply -f besteffort-ffmpeg.yaml

5. 執行以下命令，查看Pod狀態。

   kubectl get pod -l app=ffmpeg -o wide

   預期輸出：

   NAME                READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
   besteffort-ffmpeg   1/1     Running   0          15s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

6. 使用壓測工具wrk，執行以下命令，向Nginx應用發起壓測請求。

   # node_ip填寫測試機的IP地址，用於wrk向測試機發起壓測；8000是Nginx暴露到測試機的連接埠。
   ./wrk -t6 -c54 -d60s --latency http://${node_ip}:8000/

7. 執行以下命令，查看測試機的CPU資源使用率。

   kubectl top node

   預期輸出：

   NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   cn-beijing.192.168.2.93   65424m       63%    xxxx            xxxx
   cn-beijing.192.168.2.94   7040m        7%     xxxx            xxxx

   由預期輸出得到，壓測中測試機的平均CPU資源使用率約為63%。

8. 等待wrk運行結束，擷取wrk列印的壓測結果。

   壓測結果請參見實驗結果總覽。

常見問題

在使用wrk壓測中，測試結果提示“Socket errors: connect 54,”怎麼辦？

問題描述

在使用wrk壓測中，測試結果提示Socket errors: connect 54,。測試中的wrk Client和Nginx Server建立串連失敗，測試結果失效。

問題原因

該錯誤通常是因為用戶端的串連數受限，導致用戶端建立串連失敗。

解決辦法

為了避免該錯誤，請在壓測機上檢查系統的TCP串連配置，並嘗試啟用TCP串連重用。

1. 登入壓測機，執行如下命令，查看是否開通TCP串連重用。

   sudo sysctl -n net.ipv4.tcp_tw_reuse

   命令輸出為0或2，說明系統未完全開啟TCP串連重用。

2. 執行如下命令，啟用TCP串連重用。

   sudo sysctl -w net.ipv4.tcp_tw_reuse=1

3. 使用wrk工具再次發起壓測請求。

   檢查測試結果不再包含Socket errors: connect 54, ...的報錯提示，說明測試結果有效。