在线服务与视频转码应用混部

场景描述

使用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, ...的报错提示，说明测试结果有效。