使用kubectl部署PD分离服务示例

kubectl create namespace mindie

PD场景下需配置“deploy_mode”参数为PD分离部署模式，如下所示：

"deploy_mode"= "pd_separate"

如需进行异构部署，则需要配置“is_heterogeneous”参数为“true”，如下所示：

is_heterogeneous: true

配置文件ms_controller.json中的“default_p_rate”和“default_d_rate”参数分别控制集群中P节点和D节点数量的比值，默认均为0，根据模型、硬件、服务信息等自动决策最佳配比，也可以根据场景分别设置为P和D节点的实际数量。

PD场景下需配置“deploy_mode”参数为PD分离部署模式，如下所示：

deploy_mode="pd_separate"

• modelName：模型名配置，关联模型权重文件的模型，如配置为llama3-8b。
• modelWeightPath：模型权重文件目录配置，默认情况下脚本会挂载物理机的/data目录，modelWeightPath需配置为/data路径下的模型权重路径，确保集群可调度Ascend计算节点在该路径下存在模型文件。
• worldSize：配置一个P/D实例占用的NPU卡数；例如配置为“2”，表示使用两张卡。
• npuDeviceIds：卡号配置成从0开始编号，总数与worldSize一致，如配置为[[0,1]]。
• inferMode：配置为dmi。

“tls_enable”参数为控制是否使用HTTPS的开关，若集群内MindIE组件使用了HTTPS接口，需设置“tls_enable”为“true”，并导入证书到容器内，配置相应的证书路径。如使用HTTP接口，则设置“tls_enable”为“false”，无需准备证书文件。

建议用户打开tls_enable，确保通信安全；如果关闭则存在较高的网络安全风险。

在部署脚本目录中的deployment目录下找到mindie_server.yaml、mindie_ms_coordinator.yaml、mindie_ms_controller.yaml和mindie_server_heterogeneous.yaml（仅异构场景配置）文件。

• 本脚本仅作为一个部署参考，Pod容器的安全性由用户自行保证，实际生产环境请针对镜像和Pod安全进行加固。
• 用户在使用kubetl部署Deployment时，可修改deployment的配置yaml文件，请避免使用危险配置，确保使用安全镜像（非root权限用户），配置安全的Pod上下文。
• 用户应挂载安全路径（非软链接，非系统危险路径，非业务敏感路径），并设置合理的文件目录权限，避免挂载/home等公共目录，防止被非法用户篡改，导致容器逃逸问题。

• mindie_server.yaml主要配置的字段如下所示：
  • replicas： 配置P和D的总实例数，4个实例即配置为4。
  • huawei.com/Ascend910：配置一个P/D实例占用的NPU卡数，与MindIE Serve的config.json配置文件中worldSize参数配置的卡数保持一致。
  • image：配置镜像名。
    • MindIE与ATB Models配套使用场景：镜像名请参见MindIE与ATB Models配套使用场景。
    • MindIE与MindSpore配套使用场景：镜像名请参见MindIE与MindSpore配套使用场景。
  • startupProbe：启动探针，默认启动时间为500秒，如果在该时间内服务未启动成功，Pod将会自动重启。请用户根据实际场景设置合理的启动时间。
  • affinity：反亲和部署配置，默认注释不启用，去掉注释后开启。开启后，每个MindIE Server Pod将会反亲和部署到不同的计算节点，多个Pod不会部署到同一节点。
  • nodeSelector：节点选择，配置期望调度的节点，通过节点参数实现。
    • hardware_type：异构部署需要配置，同构部署无需配置；使能MindIE MS Controller决策异构推理身份。
    • hardware-type：异构部署需要配置，同构部署无需配置；是纳管到K8s集群的节点标签，用于分配异构设备资源，异构部署之前，需执行下面命令为异构计算节点打上标签。

      kubectl label node xx_node hardware-type=xx_device

      

      异构场景下，参数取值需满足以下要求：

      • hardware_type：如配置为P节点，该参数必须为"800I A2(32G)"；如需配置为D节点，该参数必须为"800I A2(64G)"。
      • hardware-type：该参数的值不能有空格。
• mindie_ms_coordinator.yaml和mindie_ms_controller.yaml文件主要关注image镜像名的修改。
  • MindIE与ATB Models配套使用场景：镜像名请参见MindIE与ATB Models配套使用场景。
  • MindIE与MindSpore配套使用场景：镜像名请参见MindIE与MindSpore配套使用场景。
  

  • mindie_ms_coordinator.yaml文件需特别关注livenessProbe（存活探针）参数，在高并发推理请求场景下，可能会因为探针超时，从而被K8s识别为Pod不存活，导致K8s重启Coordinator容器，建议用户谨慎开启livenessProbe（存活探针）。
  • 为了支持MindIE Controller故障恢复功能，mindie_ms_controller.yaml文件中volumes参数的name: status-data所配置的目录，必须为待部署计算节点（该计算节点通过nodeSelector参数指定）上真实存在，且volumeMounts参数中的name: status-data挂载路径必须为：/MindIE Service安装路径/logs。
• mindie_server_heterogeneous.yaml文件主要配置的字段如下所示：
  • replicas： 配置P和D的总实例数，4个实例即配置为4。
  • huawei.com/Ascend910：配置一个P/D实例占用的NPU卡数，2卡即配置为2。
  • image：配置镜像名。
    • MindIE与ATB Models配套使用场景：镜像名请参见MindIE与ATB Models配套使用场景。
    • MindIE与MindSpore配套使用场景：镜像名请参见MindIE与MindSpore配套使用场景。
  • startupProbe：启动探针，默认启动时间为500秒，如果在该时间内服务未启动成功，Pod将会自动重启。请用户根据实际场景设置合理的启动时间。
  • nodeSelector：节点选择，配置期望调度的节点，通过节点参数实现。
    • hardware_type：异构部署需要配置，同构部署无需配置；使能MindIE MS Controller决策异构推理身份，该参数配置的值与mindie_server.yaml文件中hardware_type参数的值不能一样。
    • hardware-type：异构部署需要配置，同构部署无需配置；是纳管到K8s集群的节点标签，用于分配异构设备资源，异构部署之前，需执行下面命令为异构计算节点打上标签，该参数配置的值与mindie_server.yaml文件中hardware-type参数的值不能一样。

      kubectl label node xx_node hardware-type=xx_device2

      

      异构场景下，参数取值需满足以下要求：

      • hardware_type：如配置为P节点，该参数必须为"800I A2(32G)"；如需配置为D节点，该参数必须为"800I A2(64G)"。
      • hardware-type：该参数的值不能有空格。

环境变量配置请参考配置说明。

配置容器内mindie安装的目录：根据制作镜像时实际的安装路径，修改MINDIE_USER_HOME_PATH的value值，如安装路径是/xxx/Ascend/mindie, 则配置为/xxx 。

export MINDIE_USER_HOME_PATH={镜像的安装路径}

使用以下命令拉起集群。

bash deploy.sh

执行命令后，会同步等待global_ranktable.json生成完成，如长时间处于阻塞状态，请ctrl+c中断后查看集群Pod状态，进行下一步的调试定位。

global_ranktable.json样例如下所示，样例中参数解释如表1所示。

{
  "version": "1.0",
  "status": "completed",
  "server_group_list": [
    {
      "group_id": "0",
      "server_count": "1",
      "server_list": [
        {
          "server_id": "xxx.xxx.xxx.1",
          "server_ip": "xxx.xxx.xxx.1"
        }
      ]
    },
    {
      "group_id": "1",
      "server_count": "1",
      "server_list": [
        {
          "server_id": "xxx.xxx.xxx.1",
          "server_ip": "xxx.xxx.xxx.1"
        }
      ]
    },
    {
      "group_id": "2",
      "server_count": "2",
      "server_list": [
        {
          "server_id": "xxx.xxx.xxx.1",
          "server_ip": "xxx.xxx.xxx.1",
          "device": [
            {
              "device_id": "0",
              "device_ip": "xxx.xxx.xxx.1",
              "device_logical_id": "0"
            }
          ],
          "hardware_type": "800I A2(32G)"
        },
        {
          "server_id": "xxx.xxx.xxx.2",
          "server_ip": "xxx.xxx.xxx.2",
          "device": [
            {
              "device_id": "1",
              "device_ip": "xxx.xxx.xxx.2",
              "device_logical_id": "1"
            }
          ],
          "hardware_type": "800I A2(64G)"
        }
      ]
    }
  ]
}

• 如果部署失败，则需要参见12卸载集群后重新部署。
• 集群默认刷新挂载到容器内的configmap的频率是60s，如遇到容器内打印“status of ranktable is not completed”日志信息的时间偏久，可在每个待调度的计算节点修改kubelet同步configmap的周期，即修改/var/lib/kubelet/config.yaml中的syncFrequency参数，将周期减少到5s，注意此修改可能影响集群性能。

  syncFrequency: 5s

  然后使用以下命令重启kubelet：

  swapoff -a
  systemctl restart  kubelet.service
  systemctl status kubelet

• 确保Docker配置了标准输出流写入到文件的最大规格，防止磁盘占满导致Pod被驱逐。

  需在待部署服务的计算节点上修改Docker配置文件后重启Docker：

  1. 使用以下命令打开daemon.json文件。

     vim /etc/docker/daemon.json

     在daemon.json文件中添加日志选项“log-opts”，具体内容如下所示。

     "log-opts":{"max-size":"500m", "max-file":"3"}

     参数解释：

     max-size=500m：表示一个容器日志大小上限是500M。

     max-file=3：表示一个容器最多有三个日志，超过会自动滚动更新。

  2. 使用以下命令重启Docker.

     systemctl daemon-reload
     systemctl restart docker

若使能异构集群推理，执行以下命令：

bash deploy.sh heter

kubectl get pods -n mindie

如启动4个MindIE Server实例，回显如下所示：

1
2
3
4
5
6
7

NAME                                     READY   STATUS    RESTARTS   AGE    IP               NODE       NOMINATED NODE   READINESS GATES
mindie-ms-controller-7845dcd697-h4gw7    1/1     Running   0          145m   xx.xx.xx.xx    ubuntu10   <none>           <none>
mindie-ms-coordinator-6bff995ff8-l6fwz   1/1     Running   0          145m   xx.xx.xx.xx    ubuntu10   <none>           <none>
mindie-server-7b795f8df9-2xvh4           1/1     Running   0          145m   xx.xx.xx.xx   ubuntu     <none>           <none>
mindie-server-7b795f8df9-j4z7d           1/1     Running   0          145m   xx.xx.xx.xx   ubuntu     <none>           <none>
mindie-server-7b795f8df9-v2tcz           1/1     Running   0          145m   xx.xx.xx.xx   ubuntu     <none>           <none>
mindie-server-7b795f8df9-vl9hv           1/1     Running   0          145m   xx.xx.xx.xx   ubuntu     <none>           <none>

• 以mindie-ms-controller开头的为MindIE MS的Controller控制器组件。
• 以mindie-ms-coordinator开头的为MindIE MS的Coordinator调度器组件。
• 以mindie-server开头的为MindIE Server推理服务组件。

如观察Pod进入Running状态，表示Pod容器已成功被调度到节点并正常启动，但还需要进一步确认业务程序是否启动成功。

• 通过脚本示例提供的log.sh脚本可查询这些Pod的标准输出日志，查看程序是否出现异常：

  bash log.sh

  

  若使配置了异构集群推理，执行以下命令：

  bash log.sh heter

• 如需要查询具体某个Pod（如上面mindie-server-7b795f8df9-vl9hv）的日志，则执行以下命令：

  kubectl logs mindie-server-7b795f8df9-vl9hv -n mindie

• 如需要进入容器查找更多定位信息，则执行以下命令：

  kubectl exec -it mindie-server-7b795f8df9-vl9hv -n mindie -- bash

• 如需确认的P，D对应的Pod，待MindIE MS Controller组件启动（如上面mindie-ms-controller-7845dcd697-h4gw7处于READY 1/1状态）后，则执行以下命令：

  kubectl logs mindie-ms-controller-7845dcd697-h4gw7 -n mindie | grep UpdateServerInfo

  查询到P节点和D节点的Pod IP，并结合上面查询Pod状态命令回显的IP可找到对应的Pod。