Slurm和K8S

1、观点差异

• K8s专为管理长时间运行的流程而构建的

            协调多个微服务，扩展、管理可用性，通常支持一个或多个web服务

• 云原生系统假设有"infinite"可用资源

              优先级不是云编排的核心，体现在调度语义上，"Affinity"与"Anti-Affinity"设置不能转换为批处理工作流程

• HPC系统假设系统大小是固定的

              但是工作量是无限的，队列优先级对于大多数大型系统至关重要

• Slurm是一个策略引擎
• Slurm涵盖了几个相关的HPC系统管理任务

              作业排队和优先级，作业记账，用户对计算资源的访问控制（cgroups、pam_slurm_adopt），大规模作业启动(MPI、PMIx、nss_slurm、sbcast)

2、Kubernetes Batch支持

• K8s对批处理工作流程的支持有限

              以"pods"或"jobs"为模型，由于"jobs"模型的问题，大多数工作流使用"pods"

• 优先级模型有限

              先进先出是最常见的

• MPI风格的工作负载支持较弱

              默认K8s组件不保证并发pod调度

• "MPI Operator"是确保Pod同时启动的最常用组件

              无法扩大规模，很难达到80(!)以上的ranks

3、HPC 与云原生的融合

• 弥合HPC和云原生工作负载之间的差距
• 用一种方法，将熟悉的命令、工具和优先级模型引入到新的架构中

4、可能的模型

从Slurm的角度来看，可能的方法有:

• "Over"
• "Adjacent"
• "Under"

4.1、"Over"

• Slurm管理资源
• 在批处理作业中临时创建的K8s集群
• 在作业启动之前，K8s control plane不可用...
• 除了测试/开发之外不用特别有用

4.2、"Adjacent"

• 两个control plane重叠
• 安装Slurm K8s调度器插件

              让Slurm优先考虑并安排 Slurm 和 K8s 工作负载

• K8s作业通过kubelet运行

              拥有K8s的全部能力

• Slurm作业通过Slurm运行

              高吞吐量，支持大规模MPI工作

• POC（Proof-of-concept）已经开始工作

              通过"slurm-k8s-bridge" K8s调度程序插件

• 局限性

              K8s调度只关心节点

• 目前没有进一步的粒度可用

              正在努力做到这一点，但变更很难向上游推进
              Slurm调度插件忽略了亲和/反亲和以及其他K8s调度机制，因为它们没有直接建模到传统的HPC概念

4.3、"Under"

• 在K8s环境中运行Slurm集群
• K8s云原生提供商已经出现
• 长期"login"节点（pod）提供传统用户体验
• 自动缩放可用于将资源移入/移出 Slurm 的控制

优点

• Slurm用户的传统体验
• 允许更高的吞吐量和完整的MPI支持

缺点

• K8s的工作负载超出了Slurm的范围
• Slurm和K8s工作负载之间的优先级很难确定
• K8s调度的所有限制均适用