K8s调度器插件必须基于scheduler.Framework实现，因v1.22起旧算法已弃用；硬改默认调度器会导致升级覆盖、e2e失败；插件为独立二进制，通过--scheduler-name注册，需正确注册、命名并实现扩展点，避免热路径阻塞与归一化失真。
为什么 K8s 调度器插件必须用 framework.Plugin 接口而不是直接改 default scheduler
因为从 v1.22 开始，Kubernetes 官方已弃用 pkg/scheduler/algorithm 下的旧调度逻辑，所有扩展必须基于 scheduler.Framework 实现；硬改默认调度器不仅无法通过 e2e 测试，还会在升级时被覆盖。你写的插件本质是独立二进制，通过 --scheduler-name 注册进 kube-scheduler 进程，不侵入主干代码。
常见错误现象：plugin "MyPlugin" is not registered —— 多半是没在 New 函数里调用 frameworkruntime.Register，或注册名和配置中写的不一致。
- 插件必须实现
framework.EnqueueExtensions（如需监听 Pod 变更）和至少一个核心扩展点（如Filter、Score） -
PluginName()返回值必须全大写+驼峰，且和ComponentConfigYAML 里的name完全一致 - 不要在
Filter里做 HTTP 请求或数据库查询——它在调度热路径上，超时会直接导致 Pod Pending
如何让自定义插件感知业务标签并过滤节点
不能只靠 node.Labels["env"] == "prod" 这种硬编码判断，节点标签可能缺失、拼写错误，或被其他组件覆盖。真正可靠的方式是结合 Pod.Spec.Affinity.NodeAffinity + 自定义 annotation 解耦语义。
使用场景：比如要求“订单服务 Pod 必须调度到装有硬件加密卡的节点”，而这类节点用 node.kubernetes.io/hw-encrypt: "true" 标记，但业务侧不想暴露底层细节。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在 Pod 模板里加 annotation：
myorg.io/require-hw-encrypt: "true" - 插件
Filter方法中用pod.GetAnnotations()提取该值，再查节点 label 是否匹配 - 务必用
framework.NewStatus(framework.Unschedulable, "missing hw encrypt")返回明确原因，否则kubectl describe pod看不到失败理由 - 注意 label key 区分大小写，
"Env"和"env"是两个不同键
Score 插件怎么避免打分结果被其他插件归一化抹平
K8s 默认对所有 Score 插件结果做线性归一化（0–100），如果你的业务打分逻辑依赖绝对数值（比如按机房延迟毫秒数倒排），直接返回 int64(50) 就会被压成 50，失去区分度。
性能影响：归一化本身开销小，但若你在 Score 里反复调用 clientset.Nodes().Get() 查延迟，单次调度可能增加 200ms+，集群规模大时会拖慢整体吞吐。
- 打分前先缓存节点网络指标（用
cache.SharedInformer监听 Node 更新 + 定期 ping） - Score 函数里只查本地 map，返回值建议落在 0–1000 范围内（框架归一化时仍保留相对比例）
- 如果必须用原始值，可在
NormalizeScore扩展点里 return 原样值（但要确保不 panic，nil nodeInfo 需跳过） - 别在
ScoreExtensions().NormalizeScore里加日志——它每节点调用一次，高频日志会刷爆 disk
调试时 pod 卡在 Pending，但 scheduler 日志没报错怎么办
大概率是你的插件在 Filter 或 PreFilter 返回了 framework.NewStatus(framework.Error, ...)，而 kube-scheduler 默认把 Error 当作内部异常忽略，不写入事件也不打印详细堆栈。
最容易被忽略的地方：Golang 的 context.Context 超时设置。kube-scheduler 对每个插件调用设了 3s 限时，你插件里任何阻塞操作（比如没设 timeout 的 http.Client）超过这个时间，就会静默失败。
- 在
main.go启动插件时，强制开启 debug 日志：--v=4，否则framework层的 status 传递过程不可见 - 检查
kubectl get events --field-selector reason=FailedScheduling，真实原因通常藏在这里 - 用
dlv attach连上正在运行的 kube-scheduler 进程，在plugin.Filter入口下断点，确认是否真的执行到了你的逻辑 - 所有外部依赖（etcd、Prometheus API）必须带 context 和 timeout，例如：
ctx, cancel := context.WithTimeout(ctx, 500*time.Millisecond)
