当前位置：首页 > 文章列表 > Golang > Go教程 > Golang优化K8s调度策略详解

Golang优化K8s调度策略详解

2026-01-16 14:38:33 0浏览收藏

从现在开始，努力学习吧！本文《Golang优化K8s调度策略方法解析》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

默认 Kubernetes Scheduler 打分逻辑静态固化，无法动态响应 SLA、GPU 碎片率等业务指标，且原生策略不支持按历史调度状态定制规则；需用 Go 基于 scheduler-framework 实现 ScorePlugin 动态统计同节点同 label Pod 数量并线性打分。

如何使用Golang优化Kubernetes调度策略_Golang集群资源分配优化方法

为什么默认的 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

注意必须注册为 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 等基础插件