17370845950

Go语言不直接参与Kubernetes Pod调度，调度由kube-scheduler实现；优化路径包括开发自定义调度器、编写Scheduler Framework插件或合理配置affinity/taints。

Go 语言本身不直接参与 Kubernetes 的 Pod 调度决策；调度逻辑由 kube-scheduler 组件实现，它是用 Go 编写的，但用户不能“在自己的 Go 程序里调用某个函数来改变调度结果”。真正的优化路径是：通过扩展 kube-scheduler（写自定义调度器）、编写调度策略插件（Scheduler Framework 插件），或在应用层配合调度机制（如合理设置 affinity/taints）。下面分几个实操关键点说明。

如何开发一个自定义调度器（Custom Scheduler）并接入集群

当你需要完全绕过默认调度器、实现特定业务逻辑（比如按 GPU 显存碎片率排序节点），最直接的方式是写一个独立的 Go 程序，监听未调度 Pod，执行调度决策后 Patch spec.nodeName。

• 必须使用 client-go 连接集群，权限需包含 get/list/watch Pod 和 patch Pod 的 RBAC
• 核心逻辑是：List 所有 status.phase == "Pending" 且 spec.nodeName == "" 的 Pod → 运行你自己的打分/过滤逻辑 → 调用 Patch 设置 spec.nodeName
• 注意避免竞态：多个自定义调度器实例同时 Patch 同一个 Pod 可能失败，需加乐观锁（检查 resourceVersion）或用 LeaderElection
• 不要删除或修改 status.phase，kubelet 会根据 spec.nodeName 自动更新状态

package main

import (
    "context"
    "fmt"
    "k8s.io/client-go/kubernetes"
    "k8s.io/client-go/tools/clientcmd"
    v1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/apimachinery/pkg/types"
)

func main() {
    config, _ := clientcmd.BuildConfigFromFlags("", "/etc/kubernetes/kubeconfig")
    clientset := kubernetes.NewForConfigOrDie(config)

    pendingPods, _ := clientset.CoreV1().Pods("").List(context.TODO(), v1.ListOptions{
        FieldSelector: "spec.nodeName==",
        LabelSelector: "scheduler=custom", // 仅处理打了 label 的 Pod
    })

    for _, pod := range pendingPods.Items {
        node := selectNode(pod) // 你的业务逻辑
        patchData := fmt.Sprintf(`{"spec":{"nodeName":"%s"}}`, node)
        clientset.CoreV1().Pods(pod.Namespace).Patch(
            context.TODO(),
            pod.Name,
            types.StrategicMergePatchType,
            []byte(patchData),
            v1.PatchOptions{},
        )
    }
}

如何为 kube-scheduler 编写 Scheduler Framework 插件（v1.22+ 推荐）

这是官方推荐的扩展方式，比替换整个调度器更安全、可组合。你需要用 Go 实现 Filter、Score、Reserve 等接口，并编译进调度器二进制或作为外部插件（via gRPC）运行。

• 插件必须实现 schedulerapi.Plugin 接口，注册到 frameworkruntime.Registry
• Filter 阶段决定“能否调度”，返回 framework.CodeUnschedulable 表示拒绝；Score 阶段返回整数分数，影响最终节点选择
• 配置需写入 ComponentConfig YAML，通过 --config 启动 kube-scheduler；若用外部插件，还需启动 gRPC server 并配置 extenders
• 调试时注意：插件 panic 会导致整个调度器 crash，务必用 defer/recover 包裹核心逻辑

为什么直接改 client-go 的 ListWatch 逻辑无法影响真实调度

很多人误以为“用 Go 监听 Pending Pod + 主动 Bind”就能替代调度器，但这是无效的：kube-scheduler 内部的 Bind 操作不仅设 spec.nodeName，还会触发一系列同步动作（如更新 Node.Status.Allocatable、记录事件、校验 PodTopologySpreadConstraints）。单纯 Patch spec.nodeName 会跳过这些检查，导致资源超卖或拓扑约束失效。

• 正确做法是调用 SchedulerInterface.ClientSet.CoreV1().Pods(ns).Bind()，传入 v1.Binding 对象（含 Target.Name）
• 该操作等价于 kube-scheduler 发起的 Bind，会触发 Admission 和 Status 更新
• 但 Bind 需要 bind 权限（不是 patch），RBAC 中要显式声明

哪些调度相关字段必须由 Go 程序正确生成（而非手写 YAML）

如果你用 Go 动态生成 Pod 清单（比如 Operator 场景），以下字段的值生成错误会导致调度失败或行为异常：

• spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[].matchExpressions[].operator：只接受 In、NotIn、Exists、DoesNotExist、Gt、Lt；写成 IN 或 in 会被静默忽略
• spec.tolerations[].effect：必须是 NoSchedule、PreferNoSchedule 或 NoExecute；拼错将导致容忍失效
• spec.topologySpreadConstraints[].topologyKey：必须与 Node Label key 完全一致（区分大小写），且不能是保留键如 kubernetes.io/hostname 以外的内置键，除非启用了对应特性门控

最容易被忽略的是：所有调度策略字段都依赖 API 版本一致性。用 corev1 包生成对象时，若集群是 v1.26+，而 client-go 版本是 v0.25.x，TopologySpreadConstraints 字段可能根本不存在——必须严格对齐 client-go 与集群 minor version。