提交提案之前，请先检索仓库内是否已有相同的提案，如已有请在同一提案中进行讨论。

💻 需求背景、当前现状、期望实现的功能内容、具体的设计方案、以及测试方案

需求背景
安装MindCluster时，需要根据不同的服务器形态打不同的节点标签。这增加了部署复杂性和维护成本。随着集群规模的扩大，手动标签管理变得越来越困难。以Atlas 800 训练服务器为例，需要打如下标签：
node-role.kubernetes.io/worker=worker
workerselector=dls-worker-node
host-arch=huawei-arm或host-arch=huawei-x86
accelerator=huawei-Ascend910
accelerator-type=module
（可选）nodeDEnable=on

当前现状
这些节点标签，配置繁琐，对客户使用不友好。

期望实现的功能内容
1.组件自动识别节点上的NPU类型及服务器形态，无需用户手动添加标签
2.保持与现有功能的兼容性
3.简化配置，提升用户部署和使用体验

具体的设计方案
一、节点标签
1.node-role.kubernetes.io/worker：K8s标识节点role是worker。虽然实际的业务中没有使用，但考虑到用户在资源管理、节点亲和性等场景会使用到，该标签保留。
2.host-arch：无调用点，直接去掉
3.workerselector：用于组件安装时的节点选择，需要保留。dls-master-node或者dls-worker-node
4.nodeDEnable：决定volcano是否接收noded上报的节点故障。noded上报的节点故障、dp上报的芯片故障都应该直接接入断点续训，无需通过配置单独控制。该配置冗余，需要去掉。
5.server-usage：（train不是用户手动打上去的，此处只关心infer的场景）
①大EP场景下，依据accelerator-type及server-usage找到800I A2和800I A3设备，针对这两种设备上的任务，将转换为GB单位的NPU HBM信息打在pod的annotation，传递给MindIE。修改后：mindie当前没有使用该标签，相关代码可以直接去掉。node label，setHardwareTypeToPod
②推理场景热复位，针对推理设备，若为多卡复位（800I A2需要8张卡一起复位），且已经有一张卡在复位中或者卡上有非L1的故障，则就算当前节点上还有健康的空闲芯片，也上报空的可用卡给volcano，不允许有新的任务再次被调度到节点上。修改后：此处本身就是针对推理设备，无需再单独判断节点是否有server-usage=infer的标签。node label，isNeedBlockAllDevice
③推理场景热复位，针对800I A2的热复位，针对此设备，分为了有HCCS环和无HCCS环。修改后：此处本身就是针对推理设备，无需再单独判断节点是否有server-usage=infer的标签，只要判断是A2设备即可。node label，resetCommonInferCard
④dp给节点打configuration标签时，对于infer的设备，device ip默认为空值。对于推理分布式场景，也是需要生成ranktable的。因此无论是infer还是train，都需要正常给device ip赋值。node label，getDeviceListIP
⑤训练场景热复位，判断热复位的时候，一次性复位几张卡。修改后：热复位的芯片范围，与具体的设备类型和board id相关，和节点标签无关，不会随着节点标签的变化而变化。A2设备，无环的场景，单卡复位。有环的场景，8卡或者16卡复位。A3设备，整机复位。deviceUsage，GraceTolerance
⑥在线热复位场景，将推理设备的rank id置为-1，并将其写入reset config中。takd根据cm内容进行停止训练进程及热复位之后的训练进程恢复。deviceUsage，setTaskDevInfoCache
6.accelerator：
①volcano通过节点label判断芯片类型，改为用dp获取到的，直接写在节点label上，做到外部无感
②dp的selector从accelerator，换成workerselector=dls-worker-node，和noded、npu exporter统一
③去掉dp的key为accelerator的selector，屏蔽310、310P、910、A5设备的dp部署yaml的差异，通过ascend docker runtime实现驱动的挂载。
dp新增环境变量MOUNT_BY_RUNTIME_FOR_DP，ascend docker runtime检测到有这个环境变量，并且检测到主机路径存在，则进行默认挂载。如果需要自定义主机路径，则自行修改yaml中的配置即可。若感知到映射的容器路径已经被挂载了，则不被重复挂载
同时，由ascend docker runtime挂载的，作为注释放在dp的部署yaml中。同时新增说明，这些路径由ascend docker runtime默认挂载，如果需要自定义，则放开注释，自行修改宿主机路径即可，容器内的映射路径勿动。
最后dp的yaml只保留4个：soc设备且使用volcano调度器的、soc设备且不使用volcano调度器的、其他设备使用volcano调度器的、其他设备不使用volcano调度器的。
7.accelerator-type：
①动态算力切分场景，针对910B场景的16卡设备，需要考虑整卡调度的亲和性。修改后：A2和A3在整卡调度场景不考虑亲和性。CheckNodeNPUByTask、UseAnnotation
②volcano的handler选择，优先使用schedule_policy即可
③ascend operator针对A3场景的ranktable生成，优先使用schedule_policy或sp-block判断即可

二、日志创建
通过日志的主机挂载卷类型为DirectoryOrCreate，配合initContainers，进行日志的创建。

initContainers:
- name: init-setup
image: clusterd:v26.0.0
command: ['如果权限过高，则修改']
securityContext:
runAsUser: 0 # root
runAsNonRoot: false
volumeMounts:
- name: log-clusterd
mountPath: /var/log/mindx-dl/clusterd

替代方案

补充说明

欢迎加入社区，感谢您对社区的贡献 🎉!