17370845950

默认 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，就会误判为可调度。

你需要解析 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）重新注册一遍，否则调度逻辑不完整。