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

kubectl create namespace mindie

PD场景下需配置为PD分离部署模式：

deploy_mode="pd_separate"

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

PD场景下需配置为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文件。

用户在使用kubetl部署deployment时，可修改deployment的配置yaml文件，请避免使用危险配置，确保使用安全镜像(非root权限用户)，配置Pod安全上下文，挂载安全路径(非软链接，非系统危险路径，非业务敏感路径)并设置了安全的文件目录权限。本脚本仅作为一个部署参考，Pod容器的安全性由用户自行保证，实际生产环境请针对镜像和Pod安全进行加固。

• 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配套使用场景。
  • livenessProbe：存活探针，当服务启动时间较长时，则需要延迟存活检测开始时间，配置initialDelaySeconds为合理值。
  • nodeSelector：节点选择，配置期望调度的节点，通过节点标签实现。
• 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 Server环境变量配置为PD部署模式：

export PD_MODE=0

配置容器内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": "coordinator",
          "server_ip": "xxx.xxx.xxx.1"
        }
      ]
    },
    {
      "group_id": "1",
      "server_count": "1",
      "server_list": [
        {
          "server_id": "controller",
          "server_ip": "xxx.xxx.xxx.1"
        }
      ]
    },
    {
      "group_id": "2",
      "server_count": "2",
      "server_list": [
        {
          "server_id": "server",
          "server_ip": "xxx.xxx.xxx.1",
          "device": [
            {
              "device_id": "0",
              "device_ip": "xxx.xxx.xxx.1"
            }
          ]
        },
        {
          "server_id": "server",
          "server_ip": "xxx.xxx.xxx.2",
          "device": [
            {
              "device_id": "1",
              "device_ip": "xxx.xxx.xxx.2"
            }
          ]
        }
      ]
    }
  ]
}

• 如果部署失败，则需要参见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

kubectl get pods -n mindie

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

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

• 如需要查询具体某个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。