共享 GPU 集群里，任务提交先后不等于业务重要性。要让紧急训练优先获得合适的加速卡，同时避免低优先级作业被无序挤占，可以采用一套清晰的Kubernetes机器学习任务调度实践：先分级，再限制范围，最后验证抢占和公平性。
先明确优先级能解决什么
Kubernetes 的 PriorityClass 为工作负载指定优先级。调度器通常先处理优先级较高的待调度 Pod；若集群资源不足，符合条件时也可能抢占较低优先级的 Pod。不过，优先级不是资源保证：它不能创造空闲 GPU，也不意味着正在运行的训练会自动保存进度后再退出。
因此，适合优先级控制的场景包括临近截止时间的实验、交互式调试和日常批量训练。若训练进程被驱逐后无法续跑，应先配置检查点保存与恢复流程，再考虑允许抢占。
按步骤配置，而不是只改一个级别
- 盘点任务类别。把作业分成少量明确档位，例如紧急、常规和低优先级。为每档确定负责人、适用条件和可占用的资源范围，避免所有团队都把任务标成最高级。
- 建立 PriorityClass。由集群管理员创建不同优先级的类别，并设置合理的数值顺序。工作负载通过 priorityClassName 选择类别；不要轻易设置全局默认高优先级，否则未分类任务也可能获得不该有的优势。
- 标记可运行 GPU 的节点。检查节点是否已由对应设备插件公布加速器资源，再使用节点标签和 node affinity 限定任务。需要隔离专用节点时，可加 taint，并让获准的训练 Pod 配置匹配的 toleration。这样能减少任务落到不兼容节点上的情况。
- 设置抢占边界。检查优先级类的抢占策略，以及命名空间内的资源配额和 PodDisruptionBudget。配额用于限制团队总用量；中断预算可以影响某些自愿驱逐操作，但不能把它当成所有抢占的绝对保护。先在测试队列验证高优先级任务能否调度、哪些低优先级任务会受影响。
- 验证训练恢复。用可重复的测试任务观察等待时间、驱逐事件和节点分配结果；确认被中断任务能从检查点恢复，并记录谁可以申请高优先级。测试规模应以集群容量为限，不宜直接拿生产中的关键训练做验证。
单卡作业与分布式训练要分开看
单个 Pod 申请加速器
设备插件会向 Kubernetes 注册扩展资源，工作负载按集群实际公布的资源名称申请设备。此类资源通常按整数分配；如果集群启用了设备共享机制，实际隔离和性能则取决于插件与硬件配置。调度前应确认所需驱动、运行时和节点标签一致，优先级本身不会解决这些兼容问题。
多 Pod 训练需要成组启动
分布式训练常需多个工作进程同时就绪。若只提高每个 Pod 的优先级，默认调度也可能先放入部分 Pod，剩余成员继续等待，造成资源被占住却无法开训。此时可评估 Volcano 等支持 gang scheduling（成组调度）的方案：满足整组启动条件再运行，更适合有固定成员数的作业；代价是要额外维护调度组件和作业配置。单 Pod 训练通常不需要这层复杂度。
让优先级兼顾效率与公平
常见风险是高优先级任务长期占满设备，常规任务一直排队。可按团队或项目设置资源配额，保留一部分容量用于日常作业，并定期查看待调度时间、抢占次数、失败率和 GPU 空闲情况。若任务需求差异很大，还应按设备型号、显存容量或网络条件细分节点池，避免只看优先级、不看任务是否真的适配。
归根结底，Kubernetes机器学习任务调度实践要同时回答三个问题：谁可以优先、优先时能否抢占、被中断后怎样恢复。把这些规则落实到优先级类、节点约束、配额和检查点机制中，优先级才会成为可管理的调度策略，而不是一项容易被滥用的标签。
常见问题
高优先级任务一定先运行吗？
不一定。它仍需满足资源、节点标签、设备和调度约束；没有合适空闲资源时可能继续等待。
低优先级训练会被直接删除吗？
只有发生符合条件的抢占等情况才可能被驱逐。是否能恢复取决于训练程序是否保存检查点及其重启配置。
优先级能替代资源配额吗？
不能。优先级用于表达调度先后和抢占关系；配额用于限制命名空间或团队的资源使用，两者应配合设置。
