默认 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 调度策略会间接影响吞吐。实测有效的调优项：
立即学习“go语言免费学习笔记（深入）”；
- 启动时设置
GOMAXPROCS=4（而非默认的逻辑核数）：避免过多 P 导致 netpoller 竞争，尤其在容器内 CPU limit 为 2–4 核时更稳定 - 禁用后台 GC：通过
debug.SetGCPercent(-1)关闭自动 GC，改用runtime.GC()在低峰期手动触发（如每 5 分钟一次），防止 STW 毛刺 - 减少内存分配：用
sync.Pool复用framework.CycleState实例；避免在PreFilter中构造大 struct，改用指针传递 - 关闭 HTTP pprof（除非调试）：
http.DefaultServeMux = nil，移除默认注册的/debug/pprof/*handler，减少 goroutine 泄漏风险
如何验证调度器性能提升是否真实有效
不能只看 go tool pprof 的火焰图，要结合 Kubernetes 原生指标和业务语义：
- 对比
kubectl get cm -n kube-system kube-scheduler-config -o yaml中的percentageOfNodesToScore：从默认 50% 降到 10%，可大幅缩短 predicate 时间，但需确保业务 Pod 不因漏筛节点而 Pending - 监控
scheduler_scheduler_goroutines是否稳定在 50–80（过高说明 informer 或 event handler 泄漏） - 用
kubectl create -f批量提交 1000 个带相同 label 的 Pod，观察scheduler_scheduling_attempt_duration_seconds_bucket{result="success"}的 p95 是否从 800ms 降至 200ms 以内 - 检查
evictions_total是否异常升高：过度激进的 cache 更新策略可能导致误驱逐，需在OnDelete中加 version check
最易被忽略的是 informer 的 resyncPeriod —— 默认 10 小时全量刷新会瞬间拉高 CPU，生产环境务必设为 0（禁用）或至少 1 小时以上，依赖事件驱动而非周期同步。
