Kubernetes 调度 HPC 作业：KubeRay、GPU 资源与调度器

引言

传统超算用 Slurm 调度作业，而 AI/云原生化浪潮下，Kubernetes 正成为新一代 HPC 与大规模训练的事实调度平台。K8s 的优势在于：统一基础设施（存储/网络/GPU）、弹性伸缩、声明式运维；但要跑好 HPC 作业，原生 K8s 不够——需要 GPU 设备插件、批调度器（Kueue/Volcano）、KubeRay 与 MPI Operator 这类专用控制器。

本文按「跑起来 → 调好度 → 跑多节点 → 生产化」讲解 K8s 调度 HPC 作业：Pod/Job 基础、GPU 资源与设备插件、批调度器、KubeRay 分布式训练、MPI Operator、存储网络考虑与迁移取舍。

前置：/hpc-slurm-scheduling/（Slurm 调度对照）、/hpc-gpu-kernel-optimization/（GPU 资源）、/hpc-dask-ray-python/（Ray 集群）。

目录

• 1. 为什么用 K8s 跑 HPC：统一与弹性
• 2. Pod 与 Job：K8s 的作业模型
• 3. GPU 资源：声明、设备插件与共享
• 4. 批调度器：Kueue 与 Volcano
• 5. KubeRay：在 K8s 跑 Ray 集群
• 6. MPI Operator：多节点分布式作业
• 7. 存储与网络：HPC 负载的 I/O 基础设施
• 8. 生产化：配额、弹性与监控
• 9. 从超算迁移到 K8s 的取舍
• 10. 速查表与一句话记忆
• 延伸阅读

1. 为什么用 K8s 跑 HPC：统一与弹性

K8s 相比传统超算的优势：

适合用 K8s 的场景：

□ 训练/推理与微服务混合部署（AI 平台）
□ 需要弹性伸缩、按需付费
□ 团队已有云原生技术栈
□ 多团队共享集群、配额管理

认知：K8s 不是要取代所有超算——而是把「AI 工作负载 + 云原生服务」统一到一套平台上。

2. Pod 与 Job：K8s 的作业模型

Pod：调度的最小单元，一个 Pod 一个容器（或多个）。

# job.yaml —— 一次性作业
apiVersion: batch/v1
kind: Job
metadata:
  name: compute-job
spec:
  parallelism: 4                 # 并发 4 个 Pod
  completions: 4                 # 完成 4 个才算成功
  template:
    spec:
      containers:
        - name: solver
          image: registry/solver:v1
          command: ["mpirun", "-np", "4", "app"]
          resources:
            limits:
              cpu: "2"
              memory: "8Gi"
      restartPolicy: Never

Job 与原生 HPC 对照：

Slurm sbatch  →  K8s Job
sbatch -n 4   →  parallelism: 4
SBATCH 时间限  →  activeDeadlineSeconds
依赖关系      →  Job 之间依赖 / 工作流控制器

记忆：K8s Job = 「声明式批处理」——parallelism 控并发、completions 控完成数，是跑 HPC 作业的基础。

3. GPU 资源：声明、设备插件与共享

声明 GPU：

resources:
  limits:
    nvidia.com/gpu: 2     # 需要 2 张 GPU

原理：每个节点跑 设备插件（Device Plugin），向 kubelet 注册 GPU 数量；调度器据此把含 GPU 的 Pod 调度到对应节点。

GPU 管理进阶：

MIG（Multi-Instance GPU）：把大卡切分成多个隔离实例：

# 节点上配置 MIG 后，Pod 声明特定 profile
resources:
  limits:
    nvidia.com/mig-1g.10gb: 2

记忆：GPU 进 K8s = 设备插件注册 + Pod 声明 limits——共享与隔离（MIG）是密集调度的关键。

4. 批调度器：Kueue 与 Volcano

原生 K8s 调度器的局限：逐个 Pod 调度、无「整批申请」、无优先级/排队语义——HPC 作业需要批调度器。

Kueue（官方批调度）：

apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor        # 资源池定义
metadata:
  name: gpu-flavor
spec:
  nodeLabels:
    gpu-type: a100
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue           # 队列配额
spec:
  resourceGroups:
    - flavors: [gpu-flavor]
      resources: [{ name: "nvidia.com/gpu", nominalQuota: 16 }]
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue              # 命名空间队列绑定
metadata:
  name: team-a
spec:
  clusterQueue: cluster-a

Volcano（CNCF 批调度，面向 AI/HPC）：

□ 队列 + 优先级 + 抢占
□ gang scheduling（整批启动）
□ 拓扑感知（NUMA/GPU 亲和）
□ 任务组（TaskGroup）多类型 Pod 协同

选型：Kueue 更「云原生官方」，Volcano 更「HPC/AI 特性全」——需要 gang scheduling 与拓扑感知用 Volcano，追求官方集成用 Kueue。

5. KubeRay：在 K8s 跑 Ray 集群

KubeRay 在 K8s 上管理 Ray 集群（把 Ray 的多 worker 编排成 K8s 资源）：

# raycluster.yaml
apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: ray-test
spec:
  headGroupSpec:
    serviceType: ClusterIP
    rayStartParams: { dashboard-host: "0.0.0.0" }
    template:
      spec:
        containers:
          - name: ray-head
            image: rayproject/ray:latest
            resources: { limits: { cpu: "4", memory: "16Gi", nvidia.com/gpu: 1 } }
  workerGroupSpecs:
    - replicas: 4                     # 4 个 worker
      groupName: workers
      template:
        spec:
          containers:
            - name: ray-worker
              image: rayproject/ray:latest
              resources: { limits: { cpu: "8", memory: "32Gi", nvidia.com/gpu: 2 } }

KubeRay 能力：

□ RayCluster：自动创建 head + workers
□ 自动伸缩：按负载增减 worker
□ RayJob：提交即用的训练作业
□ RayService：服务化部署

落地：KubeRay 让「Ray 分布式训练」在 K8s 上声明式运行——写 YAML 即建集群。

6. MPI Operator：多节点分布式作业

MPI Operator（Kubeflow）在 K8s 上编排 MPI 多节点作业：

apiVersion: kubeflow.org/v1
kind: MPIJob
metadata:
  name: mpi-test
spec:
  slotsPerWorker: 1
  runPolicy:
    cleanPodPolicy: All
  worker:
    replicas: 4
    template:
      spec:
        containers:
          - name: mpi-worker
            image: mpi-image:latest
            resources: { limits: { nvidia.com/gpu: 1 } }
  launcher:
    template:
      spec:
        containers:
          - name: mpi-launcher
            image: mpi-image:latest
            command: ["mpirun", "-np", "4", "app"]

MPI Operator 原理：

□ launcher Pod：运行 mpirun 主进程
□ worker Pods：被 mpirun 编排的计算进程
□ 内部通过 K8s 服务/主机名互相通信
□ 支持 GPU 与 InfiniBand 直通（SR-IOV）

注意：MPI 作业对网络敏感——跨节点通信性能取决于 CNI（Calico/Weave）与是否支持 RDMA。

7. 存储与网络：HPC 负载的 I/O 基础设施

存储：HPC 负载通常需要共享文件系统：

网络：

□ 默认 CNI（overlay）：灵活性高，性能一般
□ 高性能网络：DPDK/InfiniBand 直通、SR-IOV、Multus 多网络
□ 分布式训练通信：NCCL 需要高带宽低延迟
□ 拓扑感知：把同一训练任务调度到同一节点组

记忆：K8s 跑 HPC，I/O 是关键瓶颈——共享存储走 CSI、高性能网络走 Multus + RDMA、NCCL 靠拓扑感知调度。

8. 生产化：配额、弹性与监控

生产化 checklist：

□ 配额：Namespace + ResourceQuota / Kueue ClusterQueue 控资源上限
□ 弹性：KubeRay/Kueue 自动扩缩、节点池按需伸缩
□ 监控：Prometheus + DCGM（GPU）+ 训练指标（MLflow/TensorBoard）
□ 日志：统一采集（Loki/EFK）
□ 成本：按节点池/队列拆分账单

多团队治理：

□ 队列隔离：每团队 ClusterQueue + 优先级
□ 抢占与排队：低优先级让位高优先级
□ 配额动态调整：按实际用量重平衡

9. 从超算迁移到 K8s 的取舍

迁移建议：

□ 新 AI 工作负载直接上 K8s
□ 既有纯 MPI 计算维持 Slurm（别为迁移而迁移）
□ 混合：K8s 管 AI/云原生，Slurm 管传统超算，共享存储与网络
□ 迁移前验证：NCCL 性能、存储吞吐、调度语义差异

心法：K8s 不是 Slurm 的终结者，而是「云原生工作负载」的舞台——技术栈统一有收益，但要算清迁移成本。

10. 速查表与一句话记忆

一句话记忆：K8s 调度 HPC = Job 声明作业 + 设备插件给 GPU + Kueue/Volcano 管队列 + KubeRay 跑 Ray + MPI Operator 跑 MPI + Multus 保网络——统一平台与弹性是红利，存储网络与调度语义要精打细算。

延伸阅读

• /hpc-slurm-scheduling/ — Slurm 与 K8s 的调度对照
• /hpc-gpu-kernel-optimization/ — GPU 资源与调优
• /hpc-dask-ray-python/ — Ray 分布式计算（KubeRay 的负载）
• /hpc-cuda-mpi-hybrid/ — 多节点 MPI + GPU 作业
• /hpc-cluster-admin/ — 集群运维与资源管理
• [[hpc]] — 高性能计算专题