数据中心 / 云
NVIDIA Mission Control 2.5 如何将自动恢复能力引入 Kubernetes
2026 年 10 月 26 日
在数千张 GPU 上训练大规模 AI 模型是一项关键性操作，必须内置监控与自动化机制，以在规模化环境中优化集群的韧性与正常运行时间。对于数据中心运维人员而言，这一概念并不陌生；早在 AI 工厂出现之前，他们就已经开始测量平均修复时间（MTTR）与平均故障间隔时间（MTBF）。
如今，风险与挑战进一步升级。现代 AI 工厂会在数百个节点上运行分布式训练任务，持续数天甚至数周。在此规模下，运维模式发生了转变：必须主动管理硬件异常、软件错误、网络超时与资源争用，才能确保工作负载按计划推进。当企业在共享基础设施中同时运行数十个此类多节点并发工作负载时，依赖人工干预、静态检查点与被动监控的传统方法根本无法扩展。
这正是为什么像 NVIDIA Mission Control 提供的自动恢复引擎这类软件服务，对于扩大生产级 AI 规模至关重要。此前，该引擎能够跨全栈检测、诊断并恢复异常，但仅局限于使用 Slurm 的高性能计算（HPC）工作负载。作为 Mission Control 2.5 的一部分，该服务现已扩展至由 NVIDIA Run:ai 管理的基于 Kubernetes 的工作负载。
本文将展示 Mission Control 最新版本如何将其集成韧性框架应用于 Kubernetes 工作负载，帮助 AI 工厂运维从被动维护转向主动式自愈基础设施。
内置韧性服务
Mission Control 自动恢复引擎背后的愿景十分明确：AI 工厂应当是具备自愈能力的系统。故障需被即时发现，恢复决策应基于工作负载上下文与故障类型智能生成，任务则应在最小化干扰或算力浪费的前提下自动恢复。
其核心目标是查明故障原因，隔离异常并将其标记以待维护，同时尽可能减少时间损耗，使工作负载迅速回归有效计算状态。
图 1. 在 AI 工厂中，恢复自动化应尽快将节点移出高风险或停滞状态，使其重新回到可调度的高效计算状态，从而避免任务丢失与机会成本损失。
自动恢复引擎由两项核心服务构成：
- 自动任务恢复
- 自动硬件恢复
真正的自治型韧性更宜被视为一个控制闭环，而非单一恢复功能。因此，自动恢复引擎会与作业调度器（HPC 或 Kubernetes）协同工作，提供一套集成的三层框架，各组件在其中扮演独立但协调的角色。
本文将以基于 Kubernetes 的工作负载调度为重点进行阐述。
图 2。NVIDIA Mission Control 2.5 自主恢复引擎的三个组成部分：Kubernetes 调度器、自主作业恢复服务以及自主硬件恢复服务。
循环中的三个角色
我们从 Kubernetes 工作负载放置层开始介绍。在 Mission Control 中，NVIDIA Run:ai 作为 Kubernetes 的默认调度器被包含在软件套件内。它负责管理基于 Kubernetes 的 AI 工作负载、队列与策略，并将作业调度至可用资源上。
自主作业恢复服务提供工作负载上下文层。该服务会监控正在运行的作业，追踪每个作业的执行位置，并利用历史故障数据与作业拓扑结构来判断最合理的恢复路径。通过资源管理器集成，这些指导信息会被转化为重启、重试、重新排队或重新放置等具体操作。
自主硬件恢复服务则构成基础设施健康层。它持续监控节点与 GPU 状态，在必要时将异常设备从调度池中隔离，并执行诊断或修复流程，防止硬件问题蔓延至新作业。
保持职责分离正是该架构具备可移植性的关键。自主作业恢复服务无需直接修复硬件，而硬件恢复服务也不必深入理解每一种训练框架。此外，调度器能够直接将工作负载导向就绪资源，而无需等待根本原因的诊断结果。
故障路径的实际表现
以下场景展示了控制回路在 Mission Control 中如何根据自主恢复引擎检测到的故障信号采取不同的行为。
场景 1：训练过程中的硬件故障
当分布式训练作业在一组 GPU 池上运行时，其中一块 GPU 开始出现故障。故障初期可能表现为 ECC 错误、工作进程挂起或作业内的通信超时。
关键在于接下来的处理流程：恢复机制将分为两条并行轨道。自主作业恢复服务会捕获作业上下文，并定位疑似出问题的节点或 GPU。
原文较长（约 8,720 字），完整内容请浏览更多。