背景概述在基于 Kubernetes（K8S）的推理服务部署场景中，服务的稳定性与健康探测机制密切相关。RAS Starter 作为服务拉起与生命周期管理的核心组件，其探测逻辑的准确性直接影响服务的持续可用性。在多套大规格推理任务并行运行的复杂环境中，若探测机制依赖的网络信息存在偏差，可能导致误判服务异常，触发不必要的服务重启，影响整体推理任务的连续性。问题现象在 K8S 环境下部署多套大规格推理服务（如 Deepseek-R1-w8a8 模型）时，使用 RAS Starter 拉起服务后，服务在运行约 20 分钟后被异常重启。日志显示服务状态为 Ready，但探测请求持续失败，最终触发健康检查超时，导致服务被主动重启。 ●软件版本：MindIE 2.2.RC1 ●硬件平台：Atlas 800I A2 ●部署模式：K8S + 多套大 EP 场景 ●关键特征：探测请求目标端口不通，但服务本身运行正常故障排查与根因分析 1. 探测请求异常定位通过分析 RAS 日志，发现探测请求始终无法连接目标服务端口。进一步确认服务 Pod 状态为 Ready，说明服务进程正常运行，问题不在于服务本身，而在于探测机制所依赖的网络信息不准确。 2. 异常 IP 来源追溯日志中记录的探测目标 IP 与预期不符。预期应为推理服务所在命名空间的协调节点（coordinator）浮动 IP（如 10.x.x.x），但实际获取的 IP 来自 kube-system 命名空间下的 haproxy Pod，属于系统组件的内部通信地址。 3. 脚本逻辑缺陷确认深入检查 RAS Starter 脚本，发现其获取 IP 的核心命令为：kubectl get pods -A -owide 该命令在多命名空间环境下会返回所有命名空间中 Pod 的列表，且按默认顺序取第一个匹配的 Pod IP。在当前部署中，首个 Pod 为 kube-system 命名空间下的 haproxy，导致获取到错误的 IP 地址。而实际需要的 IP 应为当前推理服务所在命名空间的 coordinator 浮动 IP，该信息在日志中可通过后续 Pod 列表获取。 4. 问题根因总结在多套大 EP 并行部署的 K8S 环境中，存在多个 haproxy Pod 实例。RAS Starter 脚本使用 -A（所有命名空间）参数获取 Pod 列表，但未对目标命名空间进行过滤，导致优先获取到 kube-system 命名空间下的 haproxy Pod IP，而非推理服务实际使用的 coordinator 浮动 IP。由此引发探测请求失败，20 分钟后触发服务重启。解决方案临时规避方案为快速恢复服务稳定性，建议在当前部署中修改 RAS Starter 脚本中的 IP 获取逻辑，显式指定目标命名空间，确保获取到正确的 coordinator IP：kubectl get pods -n -owide | grep coordinator | awk '{print $6}' 注：为实际推理服务所在命名空间，如 inference-ep-01。该方案可立即解决探测请求不通的问题，避免服务误重启。长期优化方案建议对 RAS Starter 脚本进行逻辑优化，实现自动识别并获取当前推理服务所需 coordinator 的浮动 IP，避免硬编码或依赖顺序。具体优化方向包括： ●增加命名空间参数配置项，支持动态传入； ●通过标签（label）或注解（annotation）识别 coordinator Pod； ●采用更精准的 kubectl 查询方式，如结合 --field-selector 或 --selector 进行过滤。总结与建议本案例揭示了在复杂 K8S 部署环境中，脚本逻辑对系统稳定性的重要影响。即使服务本身运行正常，若探测机制依赖的网络信息错误，仍可能导致服务被误判为异常。建议： ●在脚本设计中避免使用 kubectl get pods -A 等可能引入歧义的全局查询； ●优先通过命名空间、标签、服务名等精准维度定位目标资源； ●在多租户或大 EP 场景下，强化配置项的可定制性与环境适配能力。