Kubernetes 集群跑久了，总会撞上几堵墙：高优先级作业排队没章法、低优先级 Pod 占着资源不放、调度器和重调度器各自为政。Koordinator v1.8.0 针对这三个痛点同时出手——新增 Koord-Queue 作业排队系统、强化 Reservation 预占能力、引入 Scheduling Hint 调度协同协议，还把异构设备支持拓展到了国产 MetaX GPU。逐个拆开看。
Koord-Queue：给作业排队装上规则引擎
多租户集群里，谁先跑谁后跑不能靠运气。Koord-Queue 是专为 Koordinator 生态设计的作业排队系统，核心思路是把排队逻辑从调度器内部抽出来，变成可配置的独立组件。
它支持的能力包括：
- 队列容量与配额管理——不同租户/部门分配明确的资源上限，超量作业自动排队。
- 优先级抢占与公平调度——高优先级作业可以越过低优先级排队者，但公平调度保证小租户不会被完全饿死。
- 与 Koordinator Reservation 联动——排队作业获得资源后，Reservation 可以提前锁定，避免"排队通过了但资源又被抢走"的尴尬。
一个最简的 Queue 配置示例：
apiVersion: koordinator.sh/v1alpha1
kind: ClusterQueue
metadata:
name: team-alpha
spec:
schedulingPolicy:
weight: 1 # 权重，用于公平调度
capacity:
cpu: "100"
memory: "200Gi"
eligiblePods:
namespaceSelector:
matchLabels:
queue: team-alpha # 只排带这个标签的命名空间下的 Pod
提交作业时给 Namespace 打上对应标签，Koord-Queue 就会接管排队逻辑：
# 给命名空间打标签，绑定到 team-alpha 队列
kubectl label namespace dev queue=team-alpha
# 提交一批作业，超出配额的会自动排队
kubectl apply -f batch-job.yaml
Reservation 预占升级：集群级锁定 + 多 Pod 共享
v1.7 的 Reservation 已经能预留资源给指定 Pod，但有两个限制：预占范围只在节点级，且一个 Reservation 只服务一个 Pod。v1.8 把这两条线都拉长了。
集群级预占模式——不再绑定具体节点，而是在整个集群范围内声明"我要这么多资源，哪个节点满足都行"。调度器会自动匹配可用节点并锁定。这对大集群特别有用：你不需要提前知道哪个节点有空位。
多 Pod 预占——一个 Reservation 可同时为多个 Pod 预留资源。典型场景：一个分布式训练任务包含 master + worker，它们必须一起调度，否则单独启动 master 毫无意义。
apiVersion: koordinator.sh/v1alpha1
kind: Reservation
metadata:
name: distributed-training-reserve
spec:
preAllocation:
mode: ClusterLevel # 集群级预占，不锁定具体节点
allocateOnce: false # 允许多次分配（多 Pod 共享）
owners:
- labelSelector:
matchLabels:
job-type: training-master
- labelSelector:
matchLabels:
job-type: training-worker
resource:
cpu: "32"
memory: "64Gi"
# 如果集群有 MetaX GPU，也可以预留
koordinator.sh/gpu-metax: "2"
关键字段解读：
preAllocation.mode: ClusterLevel——告诉调度器在整个集群范围寻找满足条件的节点。allocateOnce: false——Reservation 不会在第一个 Pod 绑定后就失效，多个匹配 Pod 都能使用。owners——用标签选择器指定哪些 Pod 有资格使用这份预留。
Scheduling Hint：调度组件间的"悄悄话"
Koordinator 的调度器和 Descheduler（重调度器）以前是各干各的：调度器把 Pod 放到节点上，Descheduler 后来觉得不合适再踢走。来回折腾，Pod 频繁迁移。
v1.8 引入的 Scheduling Hint 是一个内部协议，让调度插件在做出决策前可以"问一句"其他组件的意见。流程变成：
- 调度器收到 Pod 请求，进入 SchedulingHint 阶段。
- 各插件（含 Descheduler 的 Hint 插件）返回
SchedulingHint：建议调度、不建议调度、或中立。 - 调度器综合所有 Hint 做最终决策。
这意味着 Descheduler 可以提前告诉调度器"节点 A 已经过载了，别往那放"，而不是事后驱逐。对在线离线混部场景尤其关键——避免刚调度上去就被判定为"应该迁走"。
目前这是内部协议，用户不需要直接配置，但如果你编写自定义调度插件，可以实现 SchedulingHint 接口参与协同：
// 自定义插件实现 SchedulingHint 接口（伪代码示意）
type MyHintPlugin struct{}
func (p *MyHintPlugin) SchedulingHint(
pod *v1.Pod,
node *v1.Node,
) (framework.SchedulingHint, string) {
// 检查节点负载，给出建议
if nodeOverloaded(node) {
return framework.Deny, "node CPU usage > 80%"
}
return framework.Allow, ""
}
异构设备扩展：MetaX GPU/sGPU 登场
国产 GPU 正在进入越来越多数据中心。v1.8 把异构设备调度从 NVIDIA 延伸到了 MetaX GPU，支持其 sGPU（虚拟化 GPU 分片）能力。这意味着你可以像切 NVIDIA Mig 一样，把一块 MetaX GPU 切成多个 sGPU 实例给不同 Pod 用。
设备声明方式：
apiVersion: v1
kind: Pod
metadata:
name: inference-metax
labels:
koordinator.sh/device-type: metax-gpu
spec:
containers:
- name: inference
image: inference-server:latest
resources:
limits:
koordinator.sh/gpu-metax-core: "50" # 请求 50% GPU 算力
koordinator.sh/gpu-metax-memory: "8Gi" # 请求 8Gi GPU 显存
Koordinator 的 DevicePlugin 会自动完成 sGPU 实例的分配和挂载，不需要手动配置分片策略。
落地建议与风险提示
| 决策点 | 建议 |
|---|---|
| 是否启用 Koord-Queue | 多租户/多队列场景必开；单租户小集群暂不需要 |
| Reservation 集群级模式 | 大集群（50+ 节点）推荐，减少运维手动指定节点；小集群节点级模式更直观 |
| Scheduling Hint | 混部场景（在线+离线）收益最大，纯离线集群暂可观望 |
| MetaX GPU 支持 | 仅在有 MetaX 硬件的集群启用，否则 DevicePlugin 注册无意义 |
需要注意的边界：
- Koord-Queue 目前是 v1alpha1，API 可能后续版本调整，生产使用建议锁定版本并关注 changelog。
- 集群级 Reservation 在极端资源碎片场景下可能匹配延迟——调度器需要遍历更多节点，大规模集群建议配合 NodeShuffle 等碎片整理策略。
- Scheduling Hint 增加了一轮插件调用，调度延迟会略微上升（通常 <5ms），对延迟敏感的极小集群需要评估。
升级到 v1.8 的快速路径：
# 如果已安装 Koordinator，升级 Helm chart
helm repo update
helm upgrade koordinator koordinator/koordinator \
--namespace koordinator-system \
--set koord-queue.enabled=true # 启用 Koord-Queue
# 验证新组件运行状态
kubectl get pods -n koordinator-system -l app=koord-queue
kubectl get pods -n koordinator-system -l app=koord-scheduler
三个能力各解决一个层面的问题：Koord-Queue 管"谁有资格跑"，Reservation 管"资源先锁住"，Scheduling Hint 管"调度前先商量"。合在一起，Kubernetes 上跑混合工作负载的秩序感会明显提升。