默认 Kubernetes Scheduler 不够用，因其调度策略静态编译、无法动态调整权重、不支持业务指标、跨集群调度及外部数据集成，且缺乏多租户差异化策略能力。
为什么默认的 Kubernetes Scheduler 不够用
默认 DefaultScheduler 基于预选（Predicates）和优选（Priorities）两阶段做决策，但它的调度策略是静态编译进 kube-scheduler 的，无法动态调整权重、引入业务指标（如服务 SLA、GPU 显存碎片率、节点能耗），也不支持跨集群或带状态的协同调度。当你需要按自定义规则（比如“把同属一个订单链路的 Pod 尽量打散到不同机房”）做调度时，它就无能为力。
- 无法在调度时读取外部数据（如 Prometheus 指标、服务注册中心健康状态）
- 修改调度逻辑必须重编译 kube-scheduler，上线周期长
- 不支持多租户隔离下的差异化策略（如 A 部门容忍 5% 资源超卖，B 部门禁止超卖）
如何用 Golang 编写一个可插拔的 Custom Scheduler
核心是实现 Scheduler 接口并注册到 scheduler.NewScheduler 流程中，但更推荐基于 k8s.io/kubernetes/pkg/scheduler/framework v1beta3+（K8s 1.22+）开发 Plugin，避免直接 fork 主流程。
- 用
Framework注册QueueSort、PreFilter、Filter、Score等扩展点，每个函数接收context.Context和*framework.CycleState - 关键结构体：用
framework.Handle获取 clientset、SharedInformerFactory、EventRecorder - 不要在
Filter中调用阻塞 API（如 HTTP 请求），应提前在PreFilter异步加载并缓存到CycleState
func (pl *MyPlugin) Filter(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeInfo *framework.NodeInfo) *framework.Status {
node := nodeInfo.Node()
if node == nil {
return framework.NewStatus(framework.Error, "node not found")
}
// 从 state 取预加载的 GPU 显存利用率 map
gpuUtil, _ := state.Read("gpu_utilization")
if util, ok := gpuUtil.(map[string]float64); ok {
if util[node.Name] > 0.9 {
return framework.NewStatus(framework.Unschedulable, "GPU utilization too high")
}
}
return nil
}
如何让自定义调度器安全接入生产集群
不能直接替换默认 scheduler，必须共存并按 spec.schedulerName 分流。否则会导致系统组件（如 kube-proxy、coredns）无法被调度。
- Deployment 中指定
schedulerName: my-scheduler，否则走默认调度器 - RBAC 必须包含
nodes、persistentvolumeclaims、services的list/watch权限（Filter/Score 阶段常需这些信息） - 启动参数加
--bind-address=0.0.0.0:10259 --secure-port=10259并配置 ValidatingWebhook 拦截非法schedulerName - 用
PodTopologySpreadConstraints+ 自定义 Score 插件配合，避免单节点资源倾斜
常见性能陷阱与规避方式
Golang 调度器插件最易在并发和内存上翻车：所有 Plugin 实例共享同一个 framework.Framework，但每个调度周期会新建 CycleState —— 如果你在 PreFilter 里反复创建大对象（如全量节点 metric 切片），GC 压力会陡增。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Pool复用频繁分配的小结构体（如nodeScoreslice） - Filter 阶段禁止使用
time.Sleep或任何同步等待；要用context.WithTimeout包裹外部调用 - Score 插件返回值必须归一化到 [0, 100]，否则和其他插件分数无法加权；别直接返回原始毫秒延迟
- 日志用
klog.V(4).InfoS控制粒度，生产环境禁用 V(5)+，避免 I/O 成瓶颈
真正难的不是写完一个 Plugin，而是让几十个 Plugin 在高并发下稳定输出可解释、可回溯的调度结果——比如某个 Pod 被拒，得立刻知道是哪个 Plugin 的哪行逻辑、用了什么数据判定的。这要求你从第一天就设计好 CycleState 的 trace key 和 metrics 上报路径。
