机器学习任务上Kubernetes：5步配置与手动调度对照

训练任务排队不一定是集群缺机器，也可能是任务没有申报合适的资源，或节点约束写得过窄。做好Kubernetes机器学习任务调度实践，关键是让调度器知道任务需要什么、允许落在哪里，以及失败后如何恢复。下面以一次使用 PyTorch 训练模型的批处理为例，拆成五步配置，并对照手动调度的取舍。

先选对调度方式：自动分配还是指定节点

自动调度适合多个节点共同承载批任务的集群：提交者描述资源需求和放置条件，由调度器挑选符合条件的节点。手动调度通常通过指定节点名称或节点标签来限制位置，适合临时排障、单节点测试，或确实依赖特定设备的任务。

方式	优势	限制与适用条件
自动调度	任务可在多个合格节点间分配，节点故障或资源变化时更灵活。	依赖准确的资源申报和标签配置；适合常规批量训练。
手动指定节点	位置明确，便于复现单机问题或检查特定硬件。	该节点忙碌或离线时，任务可能无法启动；不宜作为常态调度方式。

手动指定并不会替代资源检查：节点仍须满足任务请求。Kubernetes机器学习任务调度实践应先以自动调度为默认，再把人工限制用于明确的例外。

核对集群资源与节点标签。查看节点可用的处理器、内存和加速设备，以及标签、污点等信息。确认训练镜像所需的运行环境和设备插件已在目标节点可用；不要只依据机器总配置判断是否有空余资源。
准备可重复运行的输入与镜像。将代码和依赖固定在版本明确的容器镜像中，训练数据通过集群可访问的持久卷或对象存储提供。记录数据版本、参数与输出位置，避免容器重启后丢失检查点或重复覆盖结果。
创建批处理工作负载。有限时长、完成后退出的训练通常可用 Kubernetes Job 管理。设置容器入口、重启策略、完成数量与失败重试上限；训练程序应能从已保存的检查点继续，重试次数也应符合任务幂等性。
申报资源并添加放置条件。为处理器、内存及加速设备填写实际需求，依据代表性训练阶段观察峰值，再留出适量余量。若只允许任务使用特定硬件，可用节点选择器或节点亲和性限定；遇到带污点的专用节点，还要配置相匹配的污点与容忍。条件过严会减少可调度节点。
提交后检查状态和日志。先确认 Job 是否创建，再查看对应工作负载的事件、容器日志、重启次数和存储挂载情况。若任务处于等待状态，优先核对资源不足、标签不匹配、污点未容忍和卷无法挂载等原因；修正后再重新提交。

资源请求过低会让调度决策失真，也可能造成运行期间争抢；设得过高则可能让任务长期等不到合适节点。可先用小规模数据或短训练轮次验证流程，再用代表性数据重复运行几次，记录峰值与耗时后调整。具体数值取决于模型、批次大小、数据读取方式和设备类型，不宜照搬其他集群的配置。

这套Kubernetes机器学习任务调度实践也适用于由 Kubeflow 管理的训练流程：工作流工具负责组织步骤，底层工作负载仍要满足集群的资源和节点规则。若持续无法调度，先检查任务实际请求和节点剩余资源，再逐项放宽非必要的亲和条件；不要为了尽快启动而盲目删除设备限制。

一次运行、完成后退出的训练通常更适合 Job；Deployment 更常用于需要持续运行并维持副本数的服务。

可调度性还受资源请求、设备可用量、节点标签、污点和存储条件影响。检查事件信息，逐项确认约束是否匹配。

临时复现特定节点上的问题，或验证某类硬件时可以使用。日常批任务优先自动调度，减少对单一节点的依赖。

定期保存检查点，明确输出路径，并在训练程序中处理重复启动。Kubernetes机器学习任务调度实践不仅要让任务启动，也要确保失败后能恢复和核查。