K8s 调度器扩展：自定义优先级与亲和性策略深度解析
一、默认调度器的能力天花板
K8s 默认调度器足够应付 80% 的场景。但当你的 Pod 对 GPU 型号敏感、需要跨可用区严格反亲和、或要求基于实时负载动态调度时，默认的 nodeSelector + affinity 组合就力不从心了。
典型痛点：集群里有 A100 和 V100 两种 GPU 节点，默认调度器只能按 label 匹配，无法感知哪个节点的 GPU 显存碎片率更低、当前温度更优。你要的是"优先 A100，但 A100 负载 > 80% 时 fallback 到 V100"——这种带有优先级的降级链。
还有更棘手的：多个 Deployment 之间的跨 Pod 反亲和。默认的 podAntiAffinity 基于 label selector，但如果你希望"同一个拓扑域内最多 2 个同类 Pod"，直接用 requiredDuringScheduling 会导致集群碎片化，用 preferredDuringScheduling 权重又不够精确。
flowchart TD
A[Pod 创建事件] –> B[Scheduler 监听]
B –> C{默认调度阶段}
C –>|Filter| D[节点过滤]
C –>|Score| E[节点打分]
D –> F[Scheduler Extender]
E –> F
F –> G[自定义 Filter 插件]
F –> H[自定义 Score 插件]
G –> I{通过?}
I –>|否| J[节点剔除]
I –>|是| H
H –> K[最终排序]
K –> L[Bind Pod 到 Node]
二、Scheduler Extender 与 Scheduling Framework 的选型
两种扩展方式：
Scheduler Extender（HTTP Webhook 模式）：调度器在 Filter/Score 阶段通过 HTTP 调用外部服务。优点是解耦，任意语言实现。缺点是每次调度都要额外 HTTP 调用，延迟高；Webhook 不可用时调度整体阻塞。
Scheduling Framework（插件模式）：Go 语言写的编译时插件，和调度器同进程运行。延迟几乎为零，能访问调度器的内部状态。缺点是只能用 Go，且调度器升级时需要重新编译。
生产环境建议：Filter 阶段用 Framework 插件（高吞吐低延迟），Score 阶段用 Extender（业务逻辑灵活变更）。
三、自定义 Scoring 插件实现
package main
import (
"context"
"fmt"
"math"
"sync"
"time"
v1 "k8s.io/api/core/v1"
"k8s.io/apimachinery/pkg/runtime"
"k8s.io/kubernetes/pkg/scheduler/framework"
"k8s.io/kubernetes/pkg/scheduler/framework/plugins/feature"
"k8s.io/kubernetes/pkg/scheduler/framework/plugins/names"
)
const PluginName = "GPUWearLevel"
// GPUWearLevel 基于 GPU 利用率漂移节点打分。
// 设计决策：不使用实时指标（Prometheus 查询有延迟抖动），
// 而是读取 Node 上的 annotation，由外部 DaemonSet 定期写入。
// 这样调度器内部无 IO，保持确定性。
type GPUWearLevel struct {
handle framework.Handle
mu sync.RWMutex
}
var _ framework.ScorePlugin = &GPUWearLevel{}
func (p *GPUWearLevel) Name() string {
return PluginName
}
// Score 为节点打分。
// 分数 = (1 – GPU利用率) * 100，确保低负载节点获高分。
// 没有 GPU annotation 的节点给 0 分——不参与 GPU 工作负载调度。
func (p *GPUWearLevel) Score(
ctx context.Context,
state *framework.CycleState,
pod *v1.Pod,
nodeName string,
) (int64, *framework.Status) {
nodeInfo, err := p.handle.SnapshotSharedLister().NodeInfos().Get(nodeName)
if err != nil {
return 0, framework.NewStatus(framework.Error, fmt.Sprintf("node not found: %s", nodeName))
}
node := nodeInfo.Node()
if node == nil {
return 0, framework.NewStatus(framework.Error, "node object is nil")
}
// 读取外部 DaemonSet 写入的 annotation
gpuUtilStr, ok := node.Annotations["gpu-scheduler.example.com/utilization"]
if !ok {
return 0, framework.NewStatus(framework.Success, "no gpu annotation, skip")
}
var gpuUtil float64
if _, err := fmt.Sscanf(gpuUtilStr, "%f", &gpuUtil); err != nil {
return 0, framework.NewStatus(framework.Error, fmt.Sprintf("invalid gpu annotation: %v", err))
}
// 利用率越低的节点分越高，上限 100
score := int64((1.0 – gpuUtil) * 100)
if score < 0 {
score = 0
}
return score, framework.NewStatus(framework.Success, "")
}
// ScoreExtensions 返回空——NormalizeScore 不做归一化，保持原始分。
func (p *GPUWearLevel) ScoreExtensions() framework.ScoreExtensions {
return nil
}
四、边界分析与架构权衡
自定义调度的隐性成本
禁用场景
- 集群规模 < 10 节点，自定义调度纯属过度设计
- 对延迟要求 > 99.9% 可用性的场景，HTTP Extender 的单点风险太高
- 业务调度逻辑频繁变更的场景（改一次插件就要重启调度器）
五、结语
自定义调度不是炫技。只有当你明确知道默认调度器哪里不够用时才动手。优先用 Scheduling Framework 做 Filter/Sort，用 Node annotation 传指标——把复杂计算放在调度器外面，保持核心链路轻量。记住一件事：调度决策越快越好，100ms 的延迟放大到千级 Pod 就是 100 秒。
