在线服务与视频转码应用混部 - 容器服务 Kubernetes 版 ACK

阿里云容器服务ACK支持通过ack-koordinator组件为集群开启差异化SLO能力，差异化SLO适用于在线服务应用和离线计算应用混合部署在同一节点的使用场景。本文介绍如何使用ack-koordinator支持在线服务与视频转码应用的混部。

场景描述

使用ACK集群部署在线服务应用Nginx，并在相同节点混合部署视频转码应用FFmpeg，用于充分发掘集群中已申请但未使用的物理资源。同时启用ack-koordinator的资源隔离能力，保障在线服务Nginx的运行，规避来自离线应用FFmpeg的干扰。

应用部署架构

在ACK集群中的机器运行Nginx服务器应用作为在线服务，与视频解码应用FFmpeg混部。其中，标识Nginx Pod的QoS等级为高优先级延迟敏感型LS（Latency Sensitive），标识FFmpeg Pod的QoS等级为低优先级BE（Best Effort）。本文将对比在不同混部配置下，Nginx应用表现的性能差异。

在离线混部过程中主要使用的相关特性：

资源复用：通过动态资源超卖，允许离线应用复用在线应用已申请但未使用的物理资源，提升集群的资源利用率。
资源隔离：通过容器CPU QoS、弹性资源限制、容器L3 Cache及内存带宽隔离等手段，约束离线应用的资源使用，优先保障在线应用的运行。

准备工作

环境准备

在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版本为例进行说明。

在线应用准备

部署混部测试所需的在线服务应用和压测工具。

使用以下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  # 请替换为您的测试机的节点名称。

执行以下命令，部署Nginx应用。
```
kubectl apply -f ls-nginx.yaml
```

执行以下命令，查看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应用已在测试机上正常运行。

在压测机上，执行以下命令，部署压测工具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。

使用以下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  # 请替换为您的测试机的节点名称。

执行以下命令，部署FFmpeg应用。
```
kubectl apply -f be-ffmpeg.yaml
```

执行以下命令，查看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应用已在测试机上正常运行。

操作步骤

本文将进行三组实验，分别采用以下三种的应用混合部署模式，对比不同混部模式下在线应用的性能表现和节点的资源利用率。

部署方式	说明
在线应用独立部署（基线）	将在线应用Nginx在测试机上只部署在线应用Nginx，不部署离线视频转码应用FFmpeg。在压测机上通过wrk工具向Nginx应用发起请求，用于模拟未混部场景，测试Nginx应用在无离线应用干扰情况下的压测性能表现，以及压测过程中节点的资源利用率。
K8s默认混合部署（对照组）	将在线应用Nginx和离线视频转码应用FFmpeg在测试机上混合部署，在压测机上通过wrk工具向Nginx应用发起请求。其中FFmpeg应用采用K8s Best Effort模式部署，Pod不填写Requests和Limits，通过调节进程数，可以控制节点的CPU使用率，本文实验对应的CPU使用率为65%。用于模拟采用K8s默认混合部署的场景，测试Nginx应用在默认混部下的压测性能表现，以及压测过程中节点的资源利用率。
ACK差异化SLO混部（实验组）	将在线应用Nginx和离线视频转码应用FFmpeg在测试机上混合部署；在压测机上通过wrk工具向Nginx应用发起请求。其中FFmpeg应用采用ACK差异化SLO的BE模式部署，Pod填写动态资源超卖的扩展资源，测试机上开启弹性资源限制、容器CPU QoS、容器L3 Cache及内存带宽隔离等ACK差异化SLO功能。用于模拟采用ACK差异化SLO混部的场景，测试Nginx应用在ACK差异化SLO混部下的压测性能表现，以及压测过程中节点的资源利用率。

实验结果总览

本次实验采用以下指标，评估不同应用混合部署模式下Nginx应用的性能表现和节点的资源利用率：

响应时间RT（Response Time）分位值：RT是在线应用通常关注的性能指标，RT越低代表在线服务性能越好。RT指标通过收集wrk压测结束后打印的信息获得，在实验中反映了Nginx应用响应wrk请求所花费的时间。例如RT-p50表示Nginx响应前50% wrk请求最大所花费的时间（中位数），RT-p90表示Nginx响应前90% wrk请求最大所花费的时间。
节点CPU平均利用率：节点的CPU平均利用率反映了节点上应用在一段时间内对CPU资源的使用比率，节点CPU平均利用率越高代表物理资源使用越充分。节点CPU平均利用率指标可以通过kubectl top node命令获得，在实验中反映了各个混合部署模式下，压测中CPU资源的使用比率。

预期结果如下：

指标/部署模式	基线（在线应用独立部署）	对照组（K8s默认混合部署）	实验组（ACK差异化SLO混部）
Nginx RT-p90（ms）	0.533	0.574（+7.7%）	0.548（2.8%）
Nginx RT-p99（ms）	0.93	1.07（+16%）	0.96（+3.2%）
节点CPU平均利用率	29.6%	65.1%	64.8%

对比基线和对照组：采用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，测试在线服务未混部时的性能数据。

参照在线应用部署，在测试机上部署在线应用Nginx。

使用压测工具wrk，向Nginx应用发起压测请求。

# node_ip填写测试机的IP地址，用于wrk向测试机发起压测；8000是Nginx暴露到测试机的端口。
./wrk -t6 -c54 -d60s --latency http://${node_ip}:8000/

执行以下命令，获取测试机的节点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%。

等待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混部下的性能数据。

参考快速入门，开启差异化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及内存带宽隔离功能仅在节点为裸金属服务器时生效；使用其他服务器类型时，该功能不会开启。
参照在线应用部署，在测试机上部署在线应用Nginx。

使用以下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  # 请替换为您的测试机的节点名称。

执行以下命令，部署FFmpeg应用。
```
kubectl apply -f besteffort-ffmpeg.yaml
```

执行以下命令，查看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>

使用压测工具wrk，执行以下命令，向Nginx应用发起压测请求。

# node_ip填写测试机的IP地址，用于wrk向测试机发起压测；8000是Nginx暴露到测试机的端口。
./wrk -t6 -c54 -d60s --latency http://${node_ip}:8000/

执行以下命令，查看测试机的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%。

等待wrk运行结束，获取wrk打印的压测结果。
压测结果请参见实验结果总览。

关于在离线混部功能的更多信息，请参见：

常见问题

在使用wrk压测中，测试结果提示“Socket errors: connect 54,”怎么办？

问题描述

在使用wrk压测中，测试结果提示Socket errors: connect 54,。测试中的wrk Client和Nginx Server建立连接失败，测试结果失效。

问题原因

该错误通常是因为客户端的连接数受限，导致客户端建立连接失败。

解决办法

为了避免该错误，请在压测机上检查系统的TCP连接配置，并尝试启用TCP连接重用。

登录压测机，执行如下命令，查看是否开通TCP连接重用。
```
sudo sysctl -n net.ipv4.tcp_tw_reuse
```
命令输出为0或2，说明系统未完全开启TCP连接重用。
执行如下命令，启用TCP连接重用。
```
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
```
使用wrk工具再次发起压测请求。
检查测试结果不再包含Socket errors: connect 54, ...的报错提示，说明测试结果有效。

说明

操作步骤中使用的指令仅在压测机上执行，测试机无需配置。测试完成后，请通过sysctl -w net.ipv4.tcp_tw_reuse恢复原始配置，避免不必要的影响。