使用ACK-Koordinator部署在离线混部应用-阿里云帮助中心

本实验主要介绍如何在一个ACK集群中，通过部署混部套件ACK-Koordinator，实现nginx web服务与转码应用ffmepg的混合部署，通过混部实现降本增效，在提升机器利用率的同时，保证nginx服务的性能。

场景简介

本实验基于一个容器服务Kubernetes版ACK托管集群Pro版，其中采用2台配置了Alibaba Cloud Linux 3操作系统的ECS实例作为K8s节点。通过本实验的操作，您可以在一个ACK Pro版集群中安装和部署ack-koordinator，然后部署在线应用nginx和离线转码应用ffmpeg进行混部测试，通过开启containerd NRI环境来优化Pod的QoS参数，帮助您保障应用的混部性能。

实验架构

在本实验中，我们会在ACK Pro版集群中运行在线应用nginx和离线应用ffmpeg的混部测试。其中，一台节点会运行nginx Pod，作为nginx server端，并在同一节点上运行ffmpeg，形成在离线混部的环境；另一台同网段节点作为client端运行wrk，向nginx发送请求。

wrk端发压参数：thread数量2，connection连接数16，持续时间1分钟。

本次实验需要至少如下3轮测试，以便得到可对照的实验结果：

基线（baseline）：单独部署nginx，进行nginx的压测。本组代表nginx的基线性能。
对照组（control）：将nginx和ffmpeg混部，进行nginx的压测。其中ffmpeg采用Kubernetes besteffort QoS部署。本组代表Kubernetes原生混部的性能。
实验组（exp）：将nginx和ffmpeg混部，进行nginx的压测。其中ffmpeg采用Koordinator BE QoS部署，开启containerd NRI环境（可选）。本组代表ACK差异化SLO混部的性能。

费用说明

本实验时长2个小时，预计产生费用为3.65元。如果您调整了资源规格、使用时长，或执行了本方案以外的操作，可能导致费用发生变化，请以控制台显示的实际价格和最终账单为准。

背景知识

本场景主要涉及以下云产品和服务：

开通容器服务并为角色授权

在创建ACK集群之前，您需要免费开通相应服务。如果您在创建ACK集群前没有开通容器服务ACK，可能会导致集群无法创建或创建失败。建议您按照以下操作开通容器服务，并为容器服务默认角色授权。

说明

如果您的阿里云账号已开通过容器服务器ACK并且已完成角色授权，请跳过此小节步骤。

开通容器服务ACK。
首次开通容器服务ACK时，您需要登录容器服务ACK开通页面，集群类型选择ACK Pro版，单击立即开通。
角色授权。
首次登录容器服务ACK时，为了您账号的ACK集群云资源的访问安全，您需要同意授权阿里云账号创建容器服务默认角色，授权该默认角色是为了确保ACK能够正常调用相关的云服务资源，从而实现集群的创建、管理和维护等功能。角色授权操作步骤如下。
登录容器服务管理控制台，单击前往RAM进行授权进入云资源访问授权页面，然后单击同意授权。完成以上授权后，刷新控制台即可使用。

创建实验资源

在实验页面，勾选我已阅读并同意《阿里云云起实践平台服务协议》和我已授权阿里云云起实践平台创建、读取及释放实操相关资源后，单击开始实操。
创建资源需要5分钟左右的时间，请您耐心等待。
在云产品资源列表，您可以查看本场景涉及的云产品资源信息。

环境准备

本节进行实验环境的检查和相关配置。

在云产品资源列表的容器服务ACK版区域，单击管理。
在集群列表页面，找到目标集群，单击集群名称。
在左侧导航栏，选择节点管理 > 节点。
在本实验中，将第一个节点作为实验的测试机，用来运行nginx和ffmpeg。将第二个节点作为实验的压测机，运行wrk client。
说明
后续步骤将以测试机和压测机来称呼两个节点，便于描述操作步骤。
重置容器服务ACK集群两个节点的ECS登录密码。
1. 在节点页面，单击测试机节点的实例ID。
2. 在实例详情页签的基本信息区域，单击重置密码。
3. 在重置实例密码对话框中，设置新密码和确认密码，重置密码的方式选择在线重置密码，配置SSH密码登录策略选择开启，单击确认修改。
4. 返回至容器服务管理控制台页签。在节点页面，单击压测机节点的实例ID。
5. 在实例详情页签的基本信息区域，单击重置密码。
6. 在重置实例密码对话框中，设置新密码和确认密码，重置密码的方式选择在线重置密码，配置SSH密码登录策略选择开启，单击确认修改。
获取集群KubeConfig并通过kubectl工具连接集群。
说明
在本实验中，使用一台云服务器ECS（非ACK集群的节点）通过Kubernetes命令行工具kubectl来管理容器服务ACK集群以及应用。
1. 重置云服务器ECS的登录密码。
  1. 在云产品资源列表的ECS云服务器区域，单击管理。
  2. 在实例详情页签的基本信息区域，单击重置密码。
  3. 在重置实例密码对话框中，设置新密码和确认密码，重置密码的方式选择在线重置密码，配置SSH密码登录策略选择开启，单击确认修改。
    返回如下结果，表示ECS实例root用户的登录密码重置成功。
2. 在云产品资源列表的ECS云服务器区域，单击远程连接。
3. 在登录实例对话框中，输入重置后的root用户密码，单击确定。
  说明
  为便于描述操作步骤，此云服务器ECS的远程连接窗口后续步骤称为ECS终端。
4. 安装kubectl工具。
  1. 执行如下命令，添加Kubernetes官方仓库。
```
cat >> /etc/yum.repos.d/kubernetes.repo <<EOF
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=0
repo_gpgcheck=0
EOF
```
  2. 执行如下命令，安装kubectl工具。
```
sudo yum install -y kubectl
```
5. 获取集群凭证。
  1. 返回至容器服务管理控制台页签。在左侧导航栏中，单击集群信息。
  2. 在基本信息页签，单击连接信息。
  3. 在连接信息页签，单击公网访问，获取公网访问凭证并复制。
    说明
    后续步骤会使用到公网访问凭证。
6. 配置KubeConfig并验证集群连通性
  1. 返回至云服务器ECS终端页签。执行如下命令，创建$HOME/.kube目录。
```
mkdir -p $HOME/.kube
```
  2. 执行如下命令，编辑$HOME/.kube/config配置文件。
```
vim $HOME/.kube/config
```
  3. 按i键进入编辑模式，将获取到的公网访问凭证粘贴到config配置文件中。
  4. 按Esc键退出编辑模式，然后输入:wq并回车，保存并退出文件。
  5. 执行如下命令，以验证集群的连通性。
```
kubectl get namespace
```
    返回如下结果，可以看到所有的命名空间，表示您可直接使用该云服务器ECS通过Kubernetes命令行工具kubectl来管理容器服务ACK集群。

升级containerd

NRI (Node Resource Interface) 即节点资源接口，是一种允许用户插件化增强容器资源管理能力的机制。本实验中将部署ack-koordinator组件，提升混部性能。ack-koordinator中包含了NRI插件，当节点开启了containerd NRI环境时，能够更灵敏、及时地保障混部性能。

NRI要求containerd >= v1.7.0，本实验中测试机的containerd版本为1.6.36，所以需要对测试机的containerd版本进行升级。

升级containerd版本的步骤如下：

返回至容器服务管理控制台页签。在左侧导航栏中，选择节点管理 > 节点。
在节点页面，找到测试机节点，选择其右侧操作列下的更多 > 节点排水。
说明
对测试机节点进行排水操作，驱逐节点上的Pods，便于升级测试机的containerd版本。
在节点排水对话框中，单击确定。
在节点页面，等待测试机节点的排水完成，状态变为就绪和不可调度，大约需要2分钟，可单击页面右上角的图标刷新页面查看状态。
在节点页面，找到测试机节点，选择其右侧操作列下的更多 > Workbench远程连接。
在登录实例对话框中，输入测试机节点重置后的root用户密码，单击确定。
说明
为便于描述操作步骤，此测试机节点的远程连接窗口后续步骤称为测试机终端。
在安全组白名单开通提示对话框中，单击一键添加。

依次执行如下命令，对测试机节点的containerd版本升级。

#下载containerd 1.7.1，您也可以选择安装其他1.7.0以上的版本
wget -c https://labfileapp.oss-cn-hangzhou.aliyuncs.com/ACK/containerd-1.7.1-linux-amd64.tar.gz
#停止containerd的systemd服务
systemctl stop containerd
#解压并替换节点的containerd二进制
tar -xzvf containerd-1.7.1-linux-amd64.tar.gz -C /usr/
#更新containerd配置，开启NRI的支持
tee -a /etc/containerd/config.toml << EOF
  [plugins."io.containerd.nri.v1.nri"]
    disable = false
    disable_connections = false
    plugin_config_path = "/etc/nri/conf.d"
    plugin_path = "/opt/nri/plugins"
    plugin_registration_timeout = "5s"
    plugin_request_timeout = "2s"
    socket_path = "/var/run/nri/nri.sock"
EOF
#启动containerd的systemd服务
systemctl restart containerd
#检查containerd版本升级成功，预期显示安装的版本号，如1.7.1
containerd -v

返回如下结果，表示测试机节点的containerd版本升级成功。

返回至容器服务管理控制台页签。在节点页面，找到测试机节点，选择其右侧操作列下的更多 > 调度设置。
在调度设置对话框中，开启节点可调度，单击确定。

部署nginx应用进行基线测试

本节部署测试所需的在线服务应用nginx和压测工具wrk。

返回至ECS终端页签。使用以下YAML内容，创建ls-nginx.yaml文件。

执行如下命令，创建ls-nginx.yaml文件，
```
vim ls-nginx.yaml
```

按i键进入编辑模式，将如下内容复制并粘贴到ls-nginx.yaml文件中。

说明

您需要将YAML内容中的nodeName参数修改为测试机节点名称。

---
# nginx应用配置
apiVersion: v1
data:
  config: |-
    user  nginx;
    worker_processes  2;

    events {
        worker_connections  32;
    }

    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: 'registry.cn-hangzhou.aliyuncs.com/koordinator-sh/nginx:v1.18-koord-exmaple'
      imagePullPolicy: IfNotPresent
      name: nginx
      ports:
        - containerPort: 8000
          hostPort: 8000 # 压测请求访问的端口。
          protocol: TCP
      # 具体资源需求量请按节点规格按需调整。
      resources:
        limits:
          cpu: '2'
          memory: 4Gi
        requests:
          cpu: '1'
          memory: 2Gi
      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-hangzhou.192.168.64.0  # 请替换为测试机的节点名称。

按Esc键退出编辑模式，然后输入:wq并回车，保存并退出文件。

执行如下命令，部署Nginx应用。
```
kubectl apply -f ls-nginx.yaml
```
执行如下命令，查看Nginx应用的Pod状态。
```
kubectl get pod -l app=nginx -o wide
```
请您耐心等待大约一分钟，当Pod状态变为Running时，表示Nginx应用已在测试机上正常运行。
在压测机上部署压测工具wrk。
1. 返回至容器服务管理控制台页签。在节点页面，找到压测机节点，选择其右侧操作列下的更多 > Workbench远程连接。
2. 在登录实例对话框中，输入压测机节点重置后的root用户密码，单击确定。
  说明
  为便于描述操作步骤，此压测机节点的远程连接窗口后续步骤称为压测机终端。
3. 执行如下命令，部署压测工具wrk。
```
yum install -y unzip
wget -O wrk-4.2.0.tar.gz https://labfileapp.oss-cn-hangzhou.aliyuncs.com/ACK/wrk-4.2.0.tar.gz && tar -xvf wrk-4.2.0.tar.gz
cd wrk-4.2.0 && make && chmod +x ./wrk
```
在压测机终端中，执行如下命令，用wrk工具对测试机上的nginx应用进行压测。
说明
您需要将命令中的${node_ip}修改为测试机节点的IP地址。
```
# ${node_ip}改为测试机的IP地址，用于wrk向测试机发起压测；8000是Nginx暴露到测试机的端口。
./wrk -t2 -c6 -d60s --latency http://${node_ip}:8000/
```
在ECS终端中，执行如下命令，获取测试机的节点CPU平均利用率。
```
kubectl top node
```
返回如下结果，可以查看到本次压测中基线组的测试机的平均CPU资源利用率。

收集wrk工具的压测结果，作为基线组的性能数据。

在压测机终端中，等待wrk运行结束后，获取wrk的压测结果。

说明

建议重复多次测试，以获得相对稳定的结果。

预期输出：

Running 1m test @ http://192.168.64.0:8000/
  2 threads and 6 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   176.92us  209.04us  13.24ms   97.82%
    Req/Sec    18.25k     1.35k   19.51k    85.00%
  Latency Distribution
     50%  152.00us
     75%  163.00us
     90%  180.00us
     99%    1.00ms
  2178950 requests in 1.00m, 1.72GB read
Requests/sec:  36306.41
Transfer/sec:     29.43MB

RT指标是本次衡量在线服务Nginx应用在不同场景下运行性能的关键指标。由预期输出得到，Latency Distribution部分包含了wrk请求在Nginx应用上响应时间RT（Response Time）的分布。

例如，90% 180.00us表示本次压测中，基线组的RT的90分位值（P90）为225.00us。

重复3组实验后，Nginx应用在未混部场景下（基线组）压测得到RT-P50、RT-P90、RT-P99的平均值。例如，分别为195us、225us、265us，平均CPU资源利用率约为19%。

部署ffmpeg应用进行对照组测试

本节部署测试所需的离线视频转码应用FFmpeg。

说明

本节中，测试机节点上将进行FFmpeg的部署，此时测试机节点同时部署着nginx，nginx部署流程请参考上一小节。

在ECS终端中，使用以下YAML内容，创建besteffort-ffmpeg.yaml文件。

执行如下命令，创建besteffort-ffmpeg.yaml文件。
```
vim besteffort-ffmpeg.yaml
```

按i键进入编辑模式，将如下内容复制并粘贴到besteffort-ffmpeg.yaml文件中。

说明

您需要将YAML内容中的nodeName参数修改为测试机节点名称。

# FFmpeg实例，作为离线类型计算应用。
apiVersion: v1
kind: Pod
metadata:
  name: be-ffmpeg
  labels:
    app: ffmpeg
    # 1. 进行对照组测试时，ffmpeg按照K8s besteffort模式进行默认混合部署，删除koordinator.sh/qosClass=BE的label。
    # 2. 进行实验组测试时，ffmpeg按照ACK差异化SLO混部模式部署，增加koordinator.sh/qosClass=BE的label。
spec:
  containers:
    # FFmpeg的进程数量可以根据测试需求调节，进程数越多对应的离线资源使用率越高，以下配置2个进程，每个进程有1个线程并发工作。
    - command:
        - start-ffmpeg.sh
        - '2'
        - '1'
        - /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
      # 1. 进行对照组测试时，ffmpeg按照K8s besteffort模式进行混合部署，不填写资源请求和限制
      # 2. 进行实验组测试时，ffmpeg按照ACK差异化SLO模式进行混合部署，填写以下资源请求和限制
      # resources:
      #   limits:
      #     kubernetes.io/batch-cpu: 2k
      #     kubernetes.io/batch-memory: 2Gi
      #   requests:
      #     kubernetes.io/batch-cpu: 1k
      #     kubernetes.io/batch-memory: 1Gi
      # 具体资源需求量请按节点规格按需调整。
  hostNetwork: true
  restartPolicy: Never
  nodeName: cn-hangzhou.192.168.64.0  # 请替换为您的测试机的节点名称。

按Esc键退出编辑模式，然后输入:wq并回车，保存并退出文件。

在ECS终端中，执行如下命令，部署FFmpeg应用。
```
kubectl apply -f besteffort-ffmpeg.yaml
```
在ECS终端中，执行如下命令，查看FFmpeg应用的Pod状态。
```
kubectl get pod -l app=ffmpeg -o wide
```
请您耐心等待大约一分钟，当Pod状态变为Running时，表示FFmpeg应用已在测试机上正常运行。

在压测机终端中，执行如下命令，用wrk工具对测试机上的nginx进行压测。

说明

您需要将命令中的${node_ip}修改为测试机节点的IP地址。

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

在ECS终端中，执行如下命令，获取测试机的节点CPU平均利用率。
```
kubectl top node
```
返回如下结果，可以查看到本次压测中基线组的测试机的平均CPU资源利用率。
收集wrk工具的压测结果，作为对照组的性能数据。
在压测机终端中，等待wrk运行结束后，获取wrk的压测结果。
说明
建议重复多次测试，以获得相对稳定的结果。

重复3组实验后，Nginx应用在未混部场景下（基线组）压测得到RT-P50、RT-P90、RT-P99的平均值。例如，分别为211us、234us、7.71ms，平均CPU资源利用率约为74%。

部署ack-koordinator

本笑节部署ack-koordinator组件，开启ACK差异化SLO混部环境。关于安装ack-koordinator组件的标准流程，请参考ack-koordinator（ack-slo-manager）。

下面介绍ack-koordinator的部署示例。

在云产品资源列表的容器服务ACK版区域，单击管理。
在集群列表页面，找到目标集群，单击集群名称。
在左侧导航栏中，选择运维管理 > 组件管理。
在组件管理页面，搜索ack-koordinator，找到ack-koordinator(ack-slo-manager)组件，单击安装。
在安装组件ack-koordinator(ack-slo-manager)面板，单击确定，确认安装ack-koordinator组件的配置。
安装ack-koordinator组件后，单击页面右上角的图标刷新页面，当ack-koordinator组件右上角状态显示为已安装，说明部署成功。

开启混部QoS配置，部署ffmpeg应用进行实验组测试

本小节中，测试机节点上将进行FFmpeg的部署，此时测试机同时部署着nginx，nginx部署流程请参考之前章节。

在ECS终端中，使用以下YAML内容，创建ack-slo-config.yaml文件。
1. 执行如下命令，创建ack-slo-config.yaml文件。
```
vim ack-slo-config.yaml
```
2. 按i键进入编辑模式，将如下内容复制并粘贴到ack-slo-config.yaml文件中。
```
# ConfigMap ack-slo-config样例。
apiVersion: v1
kind: ConfigMap
metadata:
  name: ack-slo-config
  namespace: kube-system
data:
  # 开启动态资源超卖能力
  # 其中，cpuReclaimThresholdPercent和memoryReclaimThresholdPercent参数控制混部资源水位，
  # 可根据节点规格按需调整
  colocation-config: |
    {
      "enable": true,
      "cpuReclaimThresholdPercent": 80,
      "memoryReclaimThresholdPercent": 80,
      "memoryCalculatePolicy": "usage"
    }
  # 开启弹性资源限制能力
  resource-threshold-config: |
    {
      "clusterStrategy": {
        "enable": true
      }
    }
  # 开启CPU QoS能力
  resource-qos-config: |
    {
      "clusterStrategy": {
        "lsClass": {
          "cpuQOS": {
            "enable": true
          }
        },
        "beClass": {
          "cpuQOS": {
            "enable": true
          }
        }
      }
    }
```
3. 按Esc键退出编辑模式，输入:wq并回车，保存并退出文件。
  说明
  上述配置开启了以下ACK差异化SLO混部的能力：
  - 动态资源超卖：根据节点资源水位，合理超卖空闲的物理资源，提供给BE Pod调度。
  - 弹性资源限制：采用开启后的默认配置。用于在节点CPU资源利用率超出安全水位时，压制BE应用的CPU使用，以保障LS应用的CPU性能。
  - 容器CPU QoS：采用开启后的默认配置。用于启用Alibaba Cloud Linux的Group Identity能力，在内核调度中优先保障LS应用的CPU调度，避免因BE应用对LS应用运行在同一对SMT超线程上而产生的干扰。
  - CPU Burst性能优化策略：采用开启后的默认配置。用于优化LS应用的性能，规避CPU Throttled现象。
在ECS终端中，执行如下命令，下发ACK差异化SLO混部的配置。
```
kubectl apply -f ack-slo-config.yaml
```
在ECS终端中，执行如下命令，删除之前章节创建的FFmpeg Pod应用。
```
kubectl delete pod be-ffmpeg
```

在ECS终端中，使用以下YAML内容，创建be-ffmpeg.yaml文件。

执行如下命令，创建be-ffmpeg.yaml文件。
```
vim be-ffmpeg.yaml
```

按i键进入编辑模式，将如下内容复制并粘贴到be-ffmpeg.yaml文件中。

说明

您需要将YAML内容中的nodeName参数修改为测试机节点名称。

# FFmpeg实例，作为离线类型计算应用。
apiVersion: v1
kind: Pod
metadata:
  name: be-ffmpeg
  labels:
    app: ffmpeg
    # 1. 进行对照组测试时，ffmpeg按照K8s besteffort模式进行默认混合部署，删除koordinator.sh/qosClass=BE的label。
    # 2. 进行实验组测试时，ffmpeg按照ACK差异化SLO混部模式部署，增加koordinator.sh/qosClass=BE的label。
    koordinator.sh/qosClass: BE
spec:
  containers:
    # FFmpeg的进程数量可以根据测试需求调节，进程数越多对应的离线资源使用率越高，以下配置2个进程，每个进程有1个线程并发工作。
    - command:
        - start-ffmpeg.sh
        - '2'
        - '1'
        - /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
      # 1. 进行对照组测试时，ffmpeg按照K8s besteffort模式进行混合部署，不填写资源请求和限制
      # 2. 进行实验组测试时，ffmpeg按照ACK差异化SLO模式进行混合部署，填写以下资源请求和限制
      # 具体资源需求量请按节点规格按需调整。
      resources:
        limits:
          kubernetes.io/batch-cpu: 2k
          kubernetes.io/batch-memory: 2Gi
        requests:
          kubernetes.io/batch-cpu: 1k
          kubernetes.io/batch-memory: 1Gi
  hostNetwork: true
  restartPolicy: Never
  nodeName: cn-hangzhou.192.168.64.0  # 请替换为测试机的节点名称。

按Esc键退出编辑模式，输入:wq并回车，保存并退出文件。

在ECS终端中，执行如下命令，部署FFmpeg应用。
```
kubectl apply -f be-ffmpeg.yaml
```
在ECS终端中，执行如下命令，查看FFmpeg应用的Pod状态。
```
kubectl get pod -l app=ffmpeg -o wide
```
请您耐心等待大约一分钟，当Pod状态变为Running时，表示FFmpeg应用已在测试机上正常运行。
在压测机节点终端中，执行如下命令，用wrk工具对测试机上的nginx进行压测。
说明
您需要将命令中的${node_ip}修改为测试机节点的IP地址。
```
# ${node_ip}改为测试机的IP地址，用于wrk向测试机发起压测；8000是Nginx暴露到测试机的端口。
./wrk -t2 -c6 -d60s --latency http://${node_ip}:8000/
```
在ECS终端中，执行如下命令，获取测试机的节点CPU平均利用率。
```
kubectl top node
```
返回如下结果，可以查看到本次压测中基线组的测试机的平均CPU资源利用率。
收集wrk工具的压测结果，作为实验组的性能数据。
在压测机节点终端中，等待wrk运行结束后，获取wrk的压测结果。
说明
建议重复多次测试，以获得相对稳定的结果。

重复3组实验后，Nginx应用在ACK差异化SLO混部场景下（实验组）压测得到RT-P50、RT-P90、RT-P99的平均值。例如，分别为204us、223us、4.76ms，平均CPU资源利用率约为79%。

实验结果总览

本次实验采用以下指标，评估不同应用混合部署模式下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-p50	0.151	0.170 (+12.6%)	0.158 (+4.6%)
Nginx RT-p90（ms）	0.180	0.224 (+24.4%)	0.193 (+7.2%)
Nginx RT-p99（ms）	1.03	1.24 (+20.3%)	1.23 (+19.4%)
节点CPU平均利用率	28%	86%	79%

总结分析：

对比基线和对照组：采用K8s默认的混合部署后，节点CPU平均利用率明显提升（从28%变为87%），Nginx RT-p50、RT-p90和RT-p99均明显增大，RT性能出现了长尾现象。
对比基线和实验组：采用ACK差异化SLO混部后，节点CPU平均利用率明显提升（从28%变为78%），Nginx RT-p50、RT-p90和RT-p99相对基线有所增高，但长尾现象明显收敛。
对比对照组和实验组：ACK差异化SLO混部相比K8s默认混部，节点CPU平均利用率相近，Nginx RT-p90和RT-p99明显下降，基本与基线数据持平。

综上，在线服务与视频转码应用混部场景下，采用ACK差异化SLO混部和containerd NRI机制，能够有效提升节点CPU资源利用率，抑制资源混部干扰。

常见问题

问题描述

在使用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恢复原始配置，避免不必要的影响。

清理资源

在完成实验后，如果无需继续使用资源，选择不保留资源，单击结束实操。在结束实操对话框中，单击确定。
在完成实验后，如果需要继续使用资源，选择付费保留资源，单击结束实操。在结束实操对话框中，单击确定。请随时关注账户扣费情况，避免发生欠费。