Slurm与Kubernetes融合的GPU集群技术

在Kubernetes上借助Slurm运行大规模GPU工作负载

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

Slinky是一个由SchedMD（现为某机构的一部分）开发的开源项目，它通过两种方法实现这种集成：

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

本文聚焦于 slurm-operator，这也是某机构在Kubernetes上为大规模GPU训练集群运行Slurm的方式。文章将介绍该算子的架构、如何将Slurm守护进程映射到Kubernetes原语，然后涵盖部署——包括Slinky slurm-operator如何与现有基础设施集成。同时还会介绍使该模型实用的Kubernetes生态系统集成。最后，分享在某机构生产环境中运行Slinky的经验，该环境拥有超过1,000个GPU工作节点和8,000多个GPU。

Slinky slurm-operator如何工作？

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

图1. Slinky CRD及其引用关系

Slinky通过Pod重建确保Slurm控制平面（slurmctld）的高可用性（HA），无需依赖Slurm原生的HA机制。配置更改会自动传播：Kubernetes将挂载的配置（ConfigMaps和Secrets）同步到控制平面Pod，该Pod检测到更改并将新配置传播给其工作器（slurmd），且调度器零停机。

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

如何部署Slinky slurm-operator

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

• 无配置模式：无需共享文件系统即可分发配置。
• 动态节点：工作器在启动时注册，无需在slurm.conf中预定义。
• auth/slurm：配合use_client_ids实现集群范围用户身份验证，无需每节点身份服务。

图2. 使用Slinky在Kubernetes上部署的完整Slurm集群，包括登录Pod、工作器Pod自动扩缩、作业计费以及与身份和数据库服务的集成

Slinky可与现有数据库和身份基础设施配合使用。Slurm计费（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进行可观测性来管理集群。

使用某机构GPU Operator自动化GPU管理

某机构GPU Operator可自动执行GPU驱动程序安装、容器运行时配置和设备插件部署，使工作器Pod能够自动访问GPU。

某机构GPU Operator还会部署DCGM Exporter（一个GPU遥测收集器）。借助Slinky DCGM集成和HPC作业映射支持，可以启用按Slurm作业ID标记的每作业GPU指标，从而实现跨集群的工作负载级GPU监控。

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

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

工作器Pod挂载相同的目录，允许Slurm prolog/epilog脚本（在作业启动和完成时运行）写入作业映射文件，DCGM Exporter会自动拾取这些文件。

通过ComputeDomains实现多节点NVLink

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

在某机构的部署中，Slinky使用集群范围的ComputeDomain（numNodes: 0），该域会随着节点加入或离开集群而自动将节点添加或移出IMEX域。这提供了：

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

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

双向状态同步

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

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

Slinky slurm-operator的大规模应用

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

• 统一监控：Prometheus同时抓取Slurm指标（作业、节点、分区、调度器延迟）和标准Kubernetes指标，Grafana仪表板在单个视图中显示两者。无需为HPC单独建监控栈。
• 自动修复：当健康检查标记节点为不健康时，状态会自动从Kubernetes同步到Slurm，在两个系统中显示相同的原因。Slurm排空该节点，作业重新调度到健康的硬件上，团队不再需要分别协调K8s和Slurm工具。
• 无中断滚动更新：更新数百个工作器Pod镜像过去需要停机。通过PodDisruptionBudgets保护正在运行的作业，现在可以在训练作业继续不间断运行的同时，滚动发布Slurm版本更新和操作系统补丁。
• 维护协调：标准的Kubernetes节点排空同步到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中，动态节点将根据工作器Pod运行的Kubernetes节点注册其拓扑，这意味着当Pod在集群中移动时，拓扑感知调度能正确工作。
• DaemonSet风格的工作器Pod扩缩：在v1.1.0之前，工作器Pod通过副本计数进行扩缩。DaemonSet风格的扩缩将Pod与其nodeSelector绑定，使Slurm到Kubernetes节点的映射为静态1:1。这简化了每个GPU节点都应始终运行Slurm工作器的集群的操作。
• 未注册工作器Pod修复：健康但未注册到其Slurm集群的工作器Pod会被自动重建，弥补了自愈行为中的一个缺口。

在更长远的规划中，团队正在致力于优雅的Slurm集群升级、计划内停机工作流、配置回滚以及结构化的守护进程日志记录。目标是使Slinky的操作模型符合平台团队对任何生产级Kubernetes工作负载的期望：声明式、自愈和可观测。

Slinky slurm-operator入门

Slinky是开源的，现已可用。通过Helm安装slurm-operator，将Slurm集群定义为自定义资源，即可在一小时内让作业在Kubernetes上运行。slurm-operator快速入门指南将引导完成完整设置。

Kubernetes是GPU计算的正确基础设施基板，而Slurm是运行于其上的工作负载的一个极其强大的作业调度层。Slinky使这种组合在生产环境中无缝工作。我们计划持续投入，简化运行大规模AI训练基础设施的流程。如有疑问或想分享正在构建的内容，请访问GitHub上的SlinkyProject。FINISHED