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 —— 若 <code>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 倍。
立即学习“go语言免费学习笔记（深入）”；
- 用
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 数量可控、有没有让健康探针真正反映服务可用性——这些细节比写个自定义调度器插件重要得多。
