跳至主要內容

批处理队列与容量治理

高谷深陵大约 7 分钟约 2028 字

训练平台收到 200 个 GPU 作业后，控制器立即为每个 Job 创建 Pod。所有 Pod 进入 Pending，Cluster Autoscaler 同时申请大量节点，云账号配额和镜像仓库被瞬间打满；真正能在本周完成的作业只有 20 个。问题不在调度算法，而在系统没有先做准入、配额和排队，直接把所有业务需求翻译成了实时基础设施需求。

另一个集群接入了队列，却把“允许作业启动”和“Pod 放到哪个节点”混为一谈。Kueue 已把 Workload 标记为 Admitted，Pod 仍因 GPU 拓扑 Pending；团队误以为队列失效。准入控制、Job 控制器、Pod 调度和节点供给是四个状态机，任何工具都不会替其他层完成工作。

Kubernetes Kueue Volcano Goldilocks 队列准入 Gang Scheduling 公平共享和容量治理知识海报
批处理队列与容量治理批任务先由 Kueue 等控制器决定何时获得配额，再由 kube-scheduler 或 Volcano 决定 Pod 如何放置，最后进入容量和公平治理。高清原图

在线服务与批任务需要不同容量合同

在线服务持续接收请求，容量不足通常以延迟和错误率暴露；批任务可以排队，容量目标更多是等待时间、完成期限、吞吐和公平性。AI/HPC 作业还需要 gang、GPU 拓扑、数据位置和 checkpoint。把在线 HPA 模型直接套给批任务，容易同时启动大量 Pod，却没有足够节点和下游能力。

在线服务：需求 -> 指标 -> 副本 -> 调度 -> SLO 恢复
批处理：提交 -> 配额/准入 -> PodGroup/Pod -> 调度 -> 运行 -> 完成期限

容量评审先区分可延迟、不可中断、可抢占、需成组启动和有截止时间的工作负载，再决定是否进入队列、使用哪种调度器、保留多少静态容量。

Kueue 决定作业何时获得配额

Kueue 通过 LocalQueue 接收命名空间内作业，ClusterQueue 定义集群级资源与策略，ResourceFlavor 表达不同节点或容量类型，Cohort 支持队列间借用，Workload 保存准入状态，AdmissionCheck 对接额外检查。它不会替 kube-scheduler 选择 Node。

kubectl get localqueue,workload -A
kubectl get clusterqueue,resourceflavor,cohort
kubectl describe workload -n '<namespace>' '<workload>'
kubectl get event -A --sort-by=.lastTimestamp | grep -E 'Admitted|Pending|Evicted'

正向实验提交一个配额内 Job，观察 Workload 从 QuotaReserved 到 Admitted，随后跟踪 Pod 调度和完成；反向实验使用不存在的 ResourceFlavor 或耗尽 nominal quota，预期作业留在队列且原因明确。清理时删除实验 Job、Workload、LocalQueue，并恢复借用与抢占配置。Kueue 概览说明了准入责任。

Volcano 参与批量工作负载的实际调度

Volcano 提供 VolcanoJob、PodGroup、Queue 和调度插件，支持 Gang Scheduling、DRF、公平共享、抢占、回收和回填。工作负载通过 Volcano 控制器或 schedulerName: volcano 进入其调度路径；未指定的普通 Pod 仍由默认调度器处理。

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: gang-demo
spec:
  minAvailable: 4
  schedulerName: volcano
  queue: research

Gang 的关键证据是 PodGroup 条件、最小成员、队列状态和候选资源，而不是四个 Pod 是否都已经创建。错误 actions 顺序、激进抢占、webhook 故障和 alpha API 升级都可能扩大影响面。Volcano 调度器概览用于核对当前机制。

Goldilocks 把推荐带入审核，不替团队决策

Goldilocks 创建并读取 VPA 对象，把 CPU、内存 recommendation 组织成可读视图；默认推荐模式不会自动修改生产 request。它适合发现长期过大或过小配置，但样本窗口、周期性任务、突发、内存泄漏和 sidecar 都会影响结论。

团队把推荐与 P50、P95、峰值、OOM、节流、发布和故障窗口对照，形成变更候选，再走压测、灰度和回滚。Dashboard 可能暴露命名空间、资源画像和容量敏感信息，必须接入认证授权。不能把一个绿色建议按钮直接连到生产 GitOps。

公平共享不能只看瞬时利用率

静态配额保障边界却可能闲置；借用提高利用率却需要明确回收；抢占恢复高优先级容量却会浪费低优作业已完成的计算。公平性至少观察租户份额、等待时间、完成时间、借用量、回收次数、抢占损失和饥饿时长。

PriorityClass、Kueue queue priority、Volcano Queue 和 ResourceQuota 可能同时影响结果。必须建立统一优先级等级和审批入口，防止租户通过不同对象绕过政策。反向实验让一个租户持续提交高优作业，验证低优队列仍能在规定时间获得容量。

容量模型保留故障与发布余量

Rightsizing 不是把 request 调到历史平均值。模型至少使用峰值与分位数、增长趋势、发布重叠、节点故障、zone 故障、冷启动、GPU 碎片、DaemonSet 开销和队列期限。内存不可压缩，突发工作集和缓存预热需要单独预算。

required = steadyPeak
         + releaseOverlap
         + failureReserve
         + schedulingFragmentation
         + startupBuffer
         + measurementError

负优先级占位 Pod 可以在突发时释放调度容量，预热节点缩短供给时间，镜像预拉取缩短启动；三者分别付出 Pod、节点和存储网络成本。用相同阶梯、突发和故障负载比较 P95 恢复时间与空闲费用。

可观测要穿过队列、调度和节点

批任务时间线包含提交、Workload 创建、配额保留、准入、Pod 创建、PodGroup Ready、首次调度、节点供给、任务运行与完成。在线指标只有节点利用率时，无法判断等待来自配额、gang、GPU、云库存还是应用初始化。

日志和指标按 workload UID、queue、flavor、PodGroup、Pod UID、NodeClaim 和云实例关联。告警分别覆盖队列等待 SLO、长时间 QuotaReserved、Admitted 后 Pending、反复抢占、节点供给失败和完成期限风险，避免所有问题都落成一条“作业慢”。

容量事件必须有跨团队责任矩阵。业务 owner 定义截止时间、可抢占性和 checkpoint；平台 owner 维护队列、准入与调度器；基础设施 owner 维护 GPU、节点供给、配额和库存；安全 owner 管理 webhook、ServiceAccount、云身份和敏感作业数据。作业等待超过 SLO 时先判断停在哪个状态，再通知对应 owner，不能让所有告警都流向集群管理员。

每次策略变更还要保存前后对照：队列等待分位数、租户份额、借用与回收、抢占损失、GPU 碎片、节点小时和按期完成率。利用率提高但完成期限恶化，或高优先级恢复但低优队列持续饥饿，都表示优化没有达到系统目标。容量评审必须允许回滚到上一个配额与调度策略版本。

升级退出先停止新准入

Kueue 仍处于 0.x 发行线，Volcano 含 alpha/beta API，升级前必须备份 CR、核对 CRD 转换、webhook、Job framework 和调度器兼容。先暂停新准入，让运行中作业完成或 checkpoint，在隔离队列验证新版本，再逐步恢复。

退出时把作业切回原生 Job/默认 scheduler 或替代队列，确认没有 Suspended、Admitted、PodGroup 和终止中的任务；随后删除 webhook、CRD、ClusterRole、ServiceAccount、Secret、Dashboard 和专用节点。长期 owner 要同时负责配额政策、升级、值班、容量复盘和租户沟通，不能把队列平台变成无人维护的黑盒。

跳到正文