需求背景

在A5超平面组网场景下，存在远端故障无法感知的问题（具体为端测到一层交换链路故障场景，US故障和5808芯片故障场景无此问题），导致NPU出框链路故障后重拉业务通信失败。由于灵衢网络中端测无明细路由，无路由收敛解决方案，因此需要根据不同场景判断是否隔离节点，避免业务反复在故障节点重试，导致业务无法恢复。

当前现状

当前device-plugin不感知节点内NPU卡的端口故障状态，无法区分“路由可收敛”和“路由不可收敛”场景：

• 当出现路由不可收敛故障时，节点未被及时隔离，导致业务持续在故障节点重试，无法恢复；
• 当出现路由可收敛故障时，若错误隔离节点，会造成资源浪费，影响集群调度效率。

期望实现的功能

device-plugin根据节点内所有NPU卡的端口故障状态，智能判断是否隔离节点或标记为亚健康，具体场景如下：

超平面场景

1. 场景1（路由不可收敛）：节点内仅一个NPU卡有端口up->down故障码（0x81B18603），判定为路由无法收敛场景（fullmesh必定影响业务，H2D端口性能影响50%或单路径），无需区分端口，隔离对应NPU卡所在节点。
2. 场景2（路由可收敛）：节点所有NPU卡都有端口up->down故障码（0x81B18603），判定为路由可收敛场景（US故障或5808故障），无需区分端口（所有UB端口故障大概率是交换侧出问题），不主动隔离NPU，标记为“亚健康”级别，由调度器根据任务亚健康策略决定是否调度。

参数面场景

1. 场景1（UB接1825）：参数面出口为UB端口，告警逻辑与超平面一致，按超平面场景处理。
2. 场景2（UBOE + Bonding）：参数面具备2个UBOE口且做Bonding，故障码为0x81078607：
   • 仅一个口故障：标记为“亚健康”，业务不受影响；
   • 所有UBOE口故障：按“预隔离”处理，隔离节点。

具体设计方案

1. 故障状态获取

device-plugin通过调用hccn_tool工具，周期性（建议周期：10s）查询节点内所有NPU卡的端口故障状态，重点采集：

• 端口故障码（如0x81B18603、0x81078607）；
• UBOE口Bonding状态及每个口的up/down状态。

2. 故障场景判断逻辑

flowchart TD
    A[开始故障检测] --> B{查询所有NPU卡端口故障码}
    B -->|超平面/UB接1825场景| C{故障码0x81B18603分布}
    C -->|仅单卡故障| D[标记节点为'隔离']
    C -->|所有卡故障| E[标记节点为'亚健康']
    B -->|UBOE Bonding场景| F{故障码0x81078607 + Bonding口状态}
    F -->|仅单口down| E
    F -->|所有口down| D
    D --> G[更新节点标签/污点]
    E --> G
    G --> H[等待下一检测周期]

3. 节点隔离/亚健康标记实现

通过Kubernetes API更新device info configmap状态：

• 隔离节点：添加芯片故障级别seperatenpu，状态unhealthy，阻止新Pod调度；
• 亚健康节点：添加芯片故障级别sub-healthy，由调度器根据业务策略决定是否调度。

验收标准

1. POD 1D组网构造端测UB出框单链路故障，节点隔离断点续训；
2. POD 1D组网构造L1 US故障，节点不隔离，可原地恢复业务；
3. Server 1层组网，构造单链路故障，节点隔离断点续训；
4. Server 1层组网，构造交换芯片故障，节点不隔离，可原地恢复业务；
5. Server 2层组网，构造NPU-L1交换单链路故障，节点隔离断点续训；
6. Server 2层组网，构造L1交换芯片故障，节点不隔离，可原地恢复业务；
7. Server UBOE组网，构造参数面一个UBOE网口down，任务亚健康运行；
8. Server UBOE组网，构造参数面两个UBOE网口down,任务中断，节点被隔离出来。

需求价值

• 可靠性增强：通过智能隔离故障节点，避免业务反复在故障节点重试，提升业务恢复成功率；
• 资源利用率优化：区分“可收敛”和“不可收敛”场景，避免错误隔离健康节点，提升集群资源利用率。

交付目标

• 代码合入开源社区device-plugin主干；
• 提供完整的功能文档、设计文档及测试报告；
• 社区发布Release说明。

替代方案

补充说明

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