kube-scheduler是唯一合法调度器，Go无法直接调用函数调度Pod；必须通过提交corev1.Binding对象至API Server，且需满足Pending状态、匹配spec.schedulerName、具备create bindings权限等硬性条件。
别指望在 Go 代码里调用一个函数就能“调度 Pod”——kube-scheduler 才是唯一合法的调度器，Go 只能用来扩展它、绕过它，或配合它。
为什么不能直接用 Go 函数调度 Pod
你写个 schedulePod() 函数，传入 pod 和 node，它不会生效。Kubernetes 不提供类似 kube-scheduler.Schedule() 这样的公开 API。调度决策必须通过合法的 Binding 对象提交给 API Server，且需满足以下硬性条件：
- Binding 请求必须发往
/api/v1/namespaces/{ns}/pods/{name}/binding路径，不能 Patchspec.nodeName（旧方式已弃用，v1.25+ 默认拒绝） - 请求体必须是标准
corev1.Binding结构，含Target.Kind="Node"和Target.Name - 发起者必须有
create bindings权限（不是patch pods） - Pod 必须处于
Pending阶段且spec.schedulerName匹配你的调度器名
自定义调度器必须设置 spec.schedulerName
这是绕过默认调度器的开关。不设这个字段，你的调度器哪怕成功提交 Binding，kube-scheduler 也会在几秒后覆盖掉——它会发现 Pod 还没被自己处理，就强行再绑一次。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Deployment 或 Pod 模板中显式指定：
spec.schedulerName: "my-scheduler" - 你的调度器启动时，必须监听
spec.schedulerName == "my-scheduler"的 Pod，否则会漏掉目标 - 多个调度器共存时，
schedulerName是隔离边界；混用会导致竞态和反复绑定 - 注意：设置后，该 Pod 将完全忽略 default-scheduler 的所有亲和性/污点规则，你的逻辑要全量接管
用 client-go 提交 Binding 的正确姿势
Binding 不是普通资源，client-go 没有封装好的 Bindings() 方法，必须手动构造 RESTClient 或用 corev1client.PodsClient 的 Bind() 方法。
立即学习“go语言免费学习笔记（深入）”；
- 不要用
clientset.CoreV1().Pods(ns).Patch()改nodeName—— 这在 v1.25+ 集群会返回Forbidden: pod updates may not change fields other than `spec.containers[*].image`, `spec.initContainers[*].image`, `spec.activeDeadlineSeconds`, `spec.tolerations` - 正确调用：
clientset.CoreV1().Pods(ns).Bind(ctx, binding, metav1.CreateOptions{})，其中binding是*corev1.Binding - Binding 的
ObjectMeta.Namespace必须和 Pod 一致，Name必须是 Pod 名，UID可为空（API Server 自动填充） - 错误示例：
binding.ObjectMeta.Name = "mynode"→ 应该是 Pod 名；binding.Target.APIVersion = "v1"缺失 → 会报no kind "Binding" is registered for version "v1"
最容易被忽略的权限与调试点
90% 的自定义调度器失败不是逻辑问题，而是卡在权限或状态判断上。
- RABC 必须包含：
verbs: ["create"], resources: ["bindings"]，光有pods/bind别名不够，得写全资源名 - 监听 Pending Pod 时，要用
FieldSelector: "status.phase=Pending,spec.schedulerName=my-scheduler"，只靠 label 或 namespace 过滤会漏判 - Binding 失败时，API Server 返回的是
403 Forbidden或409 Conflict，不是500 InternalError；查kubectl get events -A看FailedScheduling事件更准 - 本地调试时，
BuildConfigFromFlags加载的 kubeconfig 若含多个 user/context，必须显式指定--context，否则可能用错证书
