默认 Kubernetes Scheduler 打分逻辑静态固化，无法动态响应 SLA、GPU 碎片率等业务指标，且原生策略不支持按历史调度状态定制规则；需用 Go 基于 scheduler-framework 实现 ScorePlugin 动态统计同节点同 label Pod 数量并线性打分。
为什么默认的 Kubernetes Scheduler 不够用
默认 default-scheduler 基于预选（Predicates）和优选（Priorities）两阶段做决策，但它的打分逻辑是静态编译进二进制的，无法动态响应业务指标（比如服务 SLA、GPU 显存碎片率、跨机房延迟）。当你需要按自定义规则（如“优先调度到同节点已运行 3 个以上该服务实例的节点”）做调度时，原生策略基本失效。
Golang 是编写自定义 scheduler 的事实标准语言——Kubernetes 本身用 Go 写，scheduler-framework v1beta2+ 提供了稳定扩展点，且所有核心接口（FilterPlugin、ScorePlugin、BindPlugin）都是 Go 接口。
如何用 Go 实现一个 ScorePlugin 控制 Pod 分散度
分散度控制常见于避免单点故障，比如禁止同一 Deployment 的 Pod 落在同一节点。这不是靠 PodAntiAffinity 能完全覆盖的（它不感知历史调度结果），需在打分阶段动态统计。
- 实现
Score方法时，从framework.NodeInfo中获取当前节点上已存在的同 label Pod 列表：func (p *spreadPlugin) 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("failed to get node info: %v", err)) } count := 0 for _, existingPod := range nodeInfo.Pods() { if labels.SelectorFromSet(pod.Labels).Matches(labels.Set(existingPod.Pod.Labels)) { count++ } } // 越少越优：线性衰减打分（0~100） score := int64(100 - count*10) if score < 0 { score = 0 } return score, nil } - 注意必须注册为
ScorePlugin并设置Weight（如Weight: 5），否则框架不会调用；Weight决定该插件得分在总分中的放大系数 - 不要在
Score中发起 API 请求（如 List Pods）——这会严重拖慢调度吞吐；所有依赖数据应通过SnapshotSharedLister获取，它是 scheduler 内存快照，零延迟
FilterPlugin 中如何校验 GPU 显存碎片是否足够
原生 NodeResourcesFit 只检查总量，但 GPU 显存不可分割（如 A100-80G 不能拆成两个 40G），若节点剩余 30G，而 Pod 申请 40G，就会误判为可调度。
立即学习“go语言免费学习笔记（深入）”；
你需要解析 nvidia.com/gpu 设备分配状态，并检查是否有单张卡满足需求：
- 从
nodeInfo.AllocatableResource拿不到卡级信息，得用nodeInfo.ResourceNames(v1.ResourceName("nvidia.com/gpu"))+ 自定义 device plugin 状态同步机制 - 更可靠的做法：监听
DevicePlugin的/var/lib/kubelet/device-plugins/kubelet.sock，或依赖NodeFeatureDiscovery注入的 annotation（如feature.node.kubernetes.io/pci-0302_10de.present）做粗筛 - 关键陷阱：
Filter阶段不能修改nodeInfo，但可以返回framework.NewStatus(framework.UnschedulableAndUnresolvable, "no free GPU card")直接拒绝节点
部署自定义 scheduler 后 Pod 一直 Pending？排查要点
90% 的 Pending 问题出在调度器未被正确绑定，或与 default-scheduler 冲突：
- 确认 Pod 的
schedulerName字段显式设为你的调度器名（如my-scheduler），否则仍走 default-scheduler：spec: schedulerName: my-scheduler containers: [...]
- 检查你的 scheduler 是否设置了正确的
--scheduler-name=my-scheduler启动参数，并监听了独立的--port（避免端口冲突） - 看日志里有没有
"No nodes found that match filters"—— 这说明所有 FilterPlugin 都返回了Unschedulable；用kubectl describe pod查Events字段，错误详情就藏在里面 - 如果你的调度器没启用
VolumeBinding插件，而 Pod 带 PVC，会因无法预绑定 PV 卡住；必须显式启用VolumeBinding和NodeRestriction等基础插件
最易忽略的是：自定义 scheduler 默认不继承 default-scheduler 的全部插件链，哪怕只改一个 ScorePlugin，也得手动把其他必需插件（如 NodeResourcesFit、PodTopologySpread）重新注册一遍，否则调度逻辑不完整。
