使用 Slurm 在 Kubernetes 上运行大规模 GPU 工作负载

Slurm 是一个面向 Linux 的开源集群管理和作业调度系统。它为超过 65% 的 TOP500 系统管理作业调度。大多数运行大规模 AI 训练的组织，都已在 Slurm 作业脚本、公平共享策略和计费工作流方面投入多年。挑战在于如何将 Slurm 的调度能力引入 Kubernetes——这一用于大规模管理 GPU 基础设施的标准平台——同时避免维护两个独立环境。

Slinky 是由 SchedMD（现为 NVIDIA 的一部分）开发的开源项目，采用两种方法实现这种集成：

• slurm-bridge 将 Slurm 调度引入原生 Kubernetes 工作负载，使 Slurm 能够作为 pod 的 Kubernetes 调度器。
• slurm-operator 在 Kubernetes 基础设施上运行完整的 Slurm 集群，将 Slurm 守护进程作为 pod 管理其完整生命周期。

本文重点介绍 slurm-operator，即 NVIDIA 在 Kubernetes 上运行 Slurm 以支持大规模 GPU 训练集群的方式。文章将讲解该 operator 的架构，以及它如何将 Slurm 守护进程映射到 Kubernetes 原语；随后介绍部署过程，包括 Slinky slurm-operator 如何与现有基础设施集成。文章还涵盖了使这一模型具备实用性的 Kubernetes 生态系统集成。最后，我们分享 NVIDIA 在拥有超过 1,000 个 GPU 工作节点和 8,000 多块 GPU 的集群上，将 Slinky 用于生产环境所获得的经验教训。

Slinky slurm-operator 是如何工作的？

Slinky slurm-operator 将每个 Slurm 组件（用于调度的 slurmctld、用于计费的 slurmdbd、用于计算工作节点的 slurmd、用于 API 访问的 slurmrestd）表示为一个 Kubernetes Custom Resource Definition（CRD）。Slurm 集群使用 Custom Resources 定义，Slinky 会创建容器化的 Slurm 守护进程，使其在各自的 pod 中运行，并配置为归属于相应集群。

Slinky 通过 Pod 再生成确保 Slurm 控制平面（slurmctld）的高可用性（HA），无需使用 Slurm 原生 HA 机制。配置变更会自动传播：Kubernetes 会将挂载的配置（ConfigMaps 和 Secrets）同步到控制平面 Pod 中，该 Pod 会检测这些变更，并在调度器零停机的情况下将新配置传播到其工作节点（slurmd）。

借助 Slurm 原生 OpenMetrics 支持和 Prometheus 监控（自 Slurm v25.11 起），可根据集群指标和你所需的扩缩容策略，通过 HorizontalPodAutoscaler（HPA）对工作节点进行自动扩缩容，范围可从单个 Pod 到所有可用工作节点。在缩容时，Slinky 会在终止 Pod 之前完全排空 Slurm 节点，确保正在运行的工作负载先完成。Slinky 会优先选择其工作负载最早完成的 Pod 进行缩容。在推出新的工作节点 Pod 镜像（例如更新的 Slurm 版本或操作系统补丁）时，也会采用相同的“先排空、后终止”流程，因此升级不会中断正在运行的作业。

如何部署 Slinky slurm-operator

在 Kubernetes 上使用 Slinky 部署的 Slurm 集群，其工作方式与非容器化的 Slurm 部署类似。Slinky slurm-operator 会自动启用容器化运行所需的 Slurm 功能：

• 用于在没有共享文件系统的情况下进行配置分发的无配置模式
• 动态节点，使工作节点在启动时注册，而无需在 slurm.conf 中预先定义
• 使用 use_client_ids 的 auth/slurm，用于在没有逐节点身份服务的情况下实现集群范围的用户身份验证

Slinky 可与您现有的数据库和身份基础设施配合使用。Slurm accounting（slurmdbd）可连接到任何兼容 MySQL 或 MariaDB 的数据库，无论该数据库是在集群内运行，还是作为外部托管服务运行。登录 Pod 的身份管理通过 SSSD 实现，因此 Active Directory、LDAP 或任何其他受支持的后端都可无需更改地集成。Slurm 25.11 允许 slurmd 在其容器内强制实施资源隔离（cgroups v2）。这意味着同一工作节点上的多用户并发工作负载可以完全隔离。

Slinky 为每个 Slurm 组件提供参考容器镜像和 Docker 文件。您可以直接使用这些镜像和文件，使用自己的库和依赖项对其进行扩展，或构建完全自定义的镜像，只要其中包含可正常运行的 Slurm 安装即可。

在 Kubernetes 上运行 Slurm 有什么好处？

在 Kubernetes 上运行 Slurm 的运营收益来自其生态系统。无需为 GPU 管理、监控、网络和节点生命周期构建并维护单独的工具链，您可以使用 Kubernetes 中已经存在的工具来解决这些问题。平台团队可以使用声明式 YAML、Helm 部署、滚动更新，以及 Prometheus 或 Grafana 进行可观测性管理集群。

使用 NVIDIA GPU Operator 自动化 GPU 管理

NVIDIA GPU Operator 可自动完成 GPU 驱动安装、容器运行时配置和设备插件部署，使工作负载 Pod 能够自动访问 GPU。

NVIDIA GPU Operator 还会部署 DCGM Exporter，这是一个 GPU 遥测数据收集器。通过 Slinky DCGM 集成和 HPC 作业映射支持，你可以启用按作业统计的 GPU 指标，并使用 Slurm 作业 ID 进行标记，从而在整个集群中实现工作负载级别的 GPU 监控。

要启用此功能，请将以下内容添加到 NVIDIA GPU Operator Helm values 中：

dcgmExporter:
  hpcJobMapping:
    enabled: true
    directory: /var/lib/dcgm-exporter/job-mapping

工作器 Pod 挂载同一目录，使 Slurm prolog/epilog 脚本（在作业开始和完成时运行）能够写入作业映射文件，DCGM Exporter 会自动获取这些文件。

采用 ComputeDomains 的多节点 NVIDIA NVLink

对于 NVIDIA GB200 NVL72 等 GPU 架构，GPU 通过多节点 NVIDIA NVLink 跨节点通信，Slinky 支持访问 ComputeDomains。这是 NVIDIA DRA 驱动提供的一种 Kubernetes 抽象，用于动态管理节点间内存交换（IMEX）域，以实现高带宽 GPU 到 GPU 连接。

在 NVIDIA 部署中，Slinky 使用集群范围的 ComputeDomain（numNodes: 0），当节点加入或离开集群时，会自动将其添加到 IMEX 域或从中移除。这提供了：

• 块拓扑感知：Slinky 与 Topograph 集成，后者使用动态资源分配（DRA）以及 NVIDIA GPU Operator 发布的标签，自动发现集群的 GPU 块拓扑。
• IMEX 插件：Slurm 配置了 SwitchType = switch/nvidia_imex，以使用 NVIDIA IMEX 进行跨节点 GPU 通信。
• 拓扑感知调度：Slurm 25.11 支持在 TopologyPlugin=topology/block 下使用 TopologyParam=BlockAsNodeRank，确保分配结果经过排序，使应用程序能够按节点排名发现各个段。

分布式训练作业可在跨节点边界实现完整的 NVLink 带宽，同时 ComputeDomains 会随着工作负载运行至完成而自动创建和拆除 IMEX 域。

双向状态同步

Slinky 在 Kubernetes 和 Slurm 之间双向同步状态。Slurm 节点状态（Idle、Allocated、Mixed、Down、Drain、Completing、Not Responding）会反映为 Pod 条件，使运维人员能够通过标准 Kubernetes 工具查看 Slurm 状态。

当你使用 kubectl drain 将节点移出以进行维护时，drain 状态和原因会自动同步到 Slurm。运行活动工作负载的 Pod 受到 PodDisruptionBudgets 保护，因此正在进行的作业不会被意外驱逐。

大规模运行的 Slinky slurm-operator

NVIDIA 在生产环境中的多个集群上运行 Slinky slurm-operator，其中一些部署规模扩展到超过 8,000 个 GPU。这些集群每天运行大规模 LLM 训练和多节点推理工作负载。GPU 通信基准测试（NCCL all-reduce 和 all-gather）与非容器化 Slurm 部署的性能相当，Slinky 所运行的 Kubernetes 层没有带来可测量的影响。使用 Helm charts 和声明式配置，新集群可在数小时内从零开始运行作业，无需手动预置。在这一规模下，在 Kubernetes 上运行 Slurm 的运维收益会随着以下方面叠加：

• 统一监控：Prometheus 抓取 Slurm 指标（作业、节点、分区、调度器延迟）以及标准 Kubernetes 指标，Grafana 仪表板在单一视图中展示两者。HPC 无需单独的监控栈。
• 自动化修复：当健康检查将某个节点标记为不健康时，状态会自动从 Kubernetes 同步到 Slurm，并且两个系统中都能看到相同的原因。Slurm 会排空该节点，作业会重新调度到健康硬件上，团队不再需要分别在 K8s 和 Slurm 工具之间进行协调。
• 无中断滚动更新：过去，更新数百个工作 Pod 镜像需要停机。现在，借助 PodDisruptionBudgets 保护正在运行的作业，我们可以在训练作业继续使用剩余容量不间断运行的同时，推出 Slurm 版本更新和操作系统补丁。
• 维护协调：标准 Kubernetes 节点 drain 会同步到 Slurm。作业会优雅完成，维护随之进行；将节点重新上线后，它会自动恢复到 Slurm 集群中。
• 熟悉的工具：平台团队使用 kubectl 进行日常运维。Pod 条件会暴露 Slurm 状态（Idle、Allocated、Drain），无需 Slurm CLI 访问权限，这意味着值班工程师可以用处理其他事务时使用的同一套工具来排查 Slurm 问题。

需要注意的一个约束：Slinky 的 slurm-operator 目前假定每个节点对应一个工作 Pod。如果你的工作负载完全是单节点 Slurm 作业，那么相对于实际需求，这种方式会过度配置；更轻量的集成方式（或 slurm-bridge）可能更适合。Slinky 部署模型在多节点作业调度中更能体现价值。

Slinky slurm-operator v1.1.0 发布亮点

最近发布的 slurm-operator v1.1.0 解决了若干对生产部署很重要的缺口：

• 动态拓扑支持：在 v1.1.0 之前，Slurm 拓扑感知需要静态配置。在 v1.1.0 中，动态节点会根据 worker pod 运行所在的 Kubernetes 节点注册其拓扑，这意味着当 pod 在集群中迁移时，拓扑感知调度也能正确工作。
• DaemonSet 风格的 worker pod 扩缩：在 v1.1.0 之前，worker pod 通过副本数进行扩缩。DaemonSet 风格的扩缩则将 pod 绑定到其 nodeSelector，从而使 Slurm 到 Kubernetes 节点的映射静态保持 1:1。这简化了那些每个 GPU 节点都应始终运行一个 Slurm worker 的集群的运维。
• 未注册工作节点 Pod 修复：健康但未注册到其 Slurm 集群的工作节点 Pod 会被自动重新创建，从而弥合自愈行为中的缺口。

从更长远来看，团队正在推进优雅的 Slurm 集群升级、计划内停机流程、配置回滚以及结构化守护进程日志。目标是让 Slinky 的运维模型符合平台团队对任何生产级 Kubernetes 工作负载的预期：声明式、自愈且可观测。

开始使用 Slinky slurm-operator

Slinky 是开源的，现已可用。通过 Helm 安装 slurm-operator，将你的 Slurm 集群定义为 Custom Resource，你就可以在一小时内让作业在 Kubernetes 上运行起来。slurm-operator Quick Start Guide 会引导你完成完整设置。

Kubernetes 是用于 GPU 计算的合适基础设施底座，而 Slurm 则是一个极其强大的作业调度层，适用于在其之上运行的工作负载。Slinky 让这种组合能够在生产环境中无缝运行。我们计划继续投入，让大规模 AI 训练基础设施的运行变得简单。如果你有问题，或想分享你正在构建的内容，请访问 GitHub 上的 SlinkyProject。