默认 Kubernetes Scheduler 在高并发下变慢，因其单体同步设计、粗粒度锁、重复计算及未裁剪的15+插件；自定义调度器应复用 client-go 与 scheduler framework，增量更新快照、预过滤节点、禁用非必要插件；Go 层面需调优 GOMAXPROCS、关闭自动 GC、复用对象并禁用 pprof；验证需结合原生指标、批量压测与 informer 配置检查。
为什么默认的 Kubernetes Scheduler 在高并发调度场景下会变慢
Kubernetes 默认调度器（default-scheduler）是单体、同步、锁粒度较粗的设计。当集群节点数超过 500、Pod 创建 QPS 超过 20，常见现象是 scheduler_perf_p99_scheduling_duration_seconds 持续高于 1s，甚至触发 FailedScheduling 事件堆积。根本原因不是 Go 本身慢，而是调度循环中大量重复计算（如 predicate 检查未缓存）、全局锁竞争（sched.scheduleOne 中对 sched.config.NextPod 的互斥访问），以及默认启用全部 15+ 个 predicates/priorities 插件却未按需裁剪。
如何用 Go 编写一个轻量级自定义调度器替代 default-scheduler
核心思路是绕过 kube-scheduler 的插件框架，直接复用 client-go + scheduler framework v1beta3 的关键组件，聚焦真实业务约束。以下为最小可行结构：
- 用
cache.NewSharedInformer监听Pod和Node变化，避免轮询 API Server - 实现
FrameworkEventHandler接口，在OnAdd/OnUpdate中增量更新本地快照（Snapshot），而非每次调度都 List/Watch 全量资源 - 关键优化点：predicate 阶段用
NodeInfo.AllowedTopologies做预过滤，prioritize 阶段用util.GetResourceRequest提前归一化 CPU/Mem 单位，避免 runtime 类型转换开销 - 禁用所有非必要插件：在
ComponentConfig中将plugins字段设为空 map，仅保留NodeResourcesFit和PodTopologySpread（若业务需要）
示例关键片段：
func (s *MyScheduler) Schedule(ctx context.Context, fwk framework.Framework, state *framework.CycleState, pod *v1.Pod) (*framework.ScheduleResult, *framework.Status) {
nodeInfos, err := fwk.SnapshotSharedLister().NodeInfos().List()
if err != nil {
return nil, framework.AsStatus(err)
}
// 过滤掉已打 taint 的 node（跳过 full predicate chain）
filtered := filterByTaints(nodeInfos, pod.Spec.Tolerations)
result := pickBestNode(filtered, pod)
return &framework.ScheduleResult{SuggestedHost: result.NodeName}, nil
}
Go runtime 层面哪些配置能显著降低调度延迟
Kubernetes 调度器本质是 I/O 密集型服务，但 Go GC 和 Goroutine 调度策略会间接影响吞吐。实测有效的调优项：
