Go应用需显式设置resources.requests和limits、避免init阻塞、防止内存泄漏，自研调度插件须杜绝goroutine泄漏；kube-scheduler据此高效调度，保障Pod稳定运行。

Go 语言本身不直接参与 Kubernetes 资源调度；真正做调度的是 kube-scheduler，它用 Go 编写，但用户通常不重写调度器——而是通过扩展点（如调度框架插件）或声明式配置来影响调度行为。优化重点在于：如何用 Go 编写可被 Kubernetes 集群高效调度的 workload，以及如何在自研调度器组件中避免常见性能陷阱。

如何让 Go 应用更“适合”kube-scheduler 调度

调度器依据 Pod 的 requests 和 limits、节点标签、污点容忍等做决策。Go 程序若内存泄漏或 CPU 毛刺大，会导致调度失准或驱逐。

• 务必显式设置 resources.requests.memory 和 resources.requests.cpu，否则 kube-scheduler 可能将多个高内存 Go 服务塞进同一节点，触发 OOMKilled
• Go 程序启动后会预占较多堆内存（runtime.MemStats.Sys 常远高于实际 Alloc），建议用 resources.limits.memory 设为 requests.memory * 1.5 左右，留出 GC 活动空间
• 避免在 init() 中执行阻塞操作（如 HTTP 请求、数据库连接），否则 Pod 卡在 ContainerCreating 或触发 LivenessProbe 失败，被反复重启干扰调度稳定性

在自研调度器插件中避免 Goroutine 泄漏

Kubernetes 调度框架插件（如 PreFilter、Filter）是同步调用，但开发者容易误加异步逻辑，导致 goroutine 积压拖慢整个调度循环。

• 禁止在插件方法内启动无缓冲 channel + goroutine 的组合，例如：go func() { ch —— 若 ch 未被及时消费，goroutine 永久阻塞
• 所有 HTTP 客户端调用必须带超时：http.Client{Timeout: 3 * time.Second}，否则一个慢 API 可能拖住整个调度周期（默认 2s 一周期）
• 缓存共享状态（如节点资源快照）时，用 sync.RWMutex 而非全局锁；读多写少场景下，粗粒度锁会导致 Filter 插件串行化，吞吐骤降

Go 程序自身负载特征对调度的影响

Kubernetes 不感知应用内部并发模型。一个 runtime.GOMAXPROCS(1) 的 Go 服务和一个 GOMAXPROCS(8) 的服务，在调度器眼里只是两个 cpu: 100m 的 Pod，但实际 CPU 利用率可能差 5 倍。

• 用 pprof 在生产环境采集 /debug/pprof/profile?seconds=30，确认真实 CPU 使用是否贴合 requests.cpu；若长期低于 30%，说明该 Pod 被过度分配，应调低 request 值，释放节点资源
• HTTP 服务启用 http.Server.ReadTimeout 和 WriteTimeout，防止慢连接长期占用 goroutine，导致 runtime.NumGoroutine() 持续上涨，最终耗尽节点内存
• 避免在 handler 中直接调用 time.Sleep 或阻塞 I/O；改用带 cancel 的 context：ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)

func handleRequest(w http.ResponseWriter, r *http.Request) {
    ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)
    defer cancel()
    // 后续所有 DB/HTTP 调用都传入 ctx
    data, err := fetchData(ctx)
    if err != nil {
        http.Error(w, err.Error(), http.StatusGatewayTimeout)
        return
    }
    json.NewEncoder(w).Encode(data)
}

真正影响调度效果的，从来不是 Go 语法有多优雅，而是你有没有把 requests 设对、有没有让 goroutine 数量可控、有没有让健康探针真正反映服务可用性——这些细节比写个自定义调度器插件重要得多。