Go微服务需显式适配cgroup内存限制，1.19+版本须读取/memory.max设GOMEMLIMIT并预留10%缓冲，否则易因GC阈值误判触发OOMKilled。
Go 微服务本身不调度资源，它只是被调度的对象；弹性资源调度靠 Kubernetes 的 kube-scheduler + HPA/VPA + 自定义指标协同完成，Go 程序只需做好三件事：暴露健康探针、适配 cgroup 限制、支持优雅退出。
Go 服务必须显式适配容器内存限制（cgroup v2）
默认情况下 Go 运行时无视 /sys/fs/cgroup/memory.max，仍按宿主机总内存估算 GC 阈值，极易触发 OOMKilled。尤其在低内存限制（如 512Mi）的 Pod 中，runtime.MemStats.Sys 可能远超实际可用内存。
- Go 1.19+ 必须读取
/sys/fs/cgroup/memory.max，过滤掉max字符串后设为GOMEMLIMIT（单位字节），建议留 10% 缓冲：GOMEMLIMIT=$((mem_limit * 90 / 100)) - 旧版 Go（debug.SetMemoryLimit，且必须早于任何 goroutine 启动
- 别依赖
resources.limits.memory自动生效——Go 运行时不会读它，只认环境变量或 API 调用
Kubernetes 中 Go 服务的 HPA 配置关键字段
HPA 不会因你写了“高并发 Go 服务”就自动扩容，它只认 YAML 里明确声明的字段和探针响应。漏一项，扩缩容逻辑就失效。
-
livenessProbe和readinessProbe必须指向/healthz，且initialDelaySeconds要 ≥ 服务冷启动耗时（DB 连接、配置加载、gRPC stub 初始化等） -
resources.requests.cpu和resources.requests.memory必须设置，否则 kube-scheduler 无法预估资源占用，HPA 也因缺失指标拒绝扩容 -
terminationGracePeriodSeconds必须 ≥ Go 代码中srv.Shutdown()的 context 超时时间（如 10s），否则系统会在 cleanup 完成前强制 kill
避免在 Go 调度插件或自研调度器中 Goroutine 泄漏
如果你用 Go 编写 Scheduler Framework 插件（如 ScorePlugin 或 FilterPlugin），这些方法是同步调用，但开发者常误加异步逻辑，导致 goroutine 积压拖慢整个调度周期（默认 2s/轮）。
立即学习“go语言免费学习笔记（深入）”；
- 禁止在插件方法内启动无缓冲 channel + goroutine 组合：
go func() { ch —— 若 <code>ch未被及时消费，goroutine 永久阻塞 - 所有 HTTP 客户端调用必须带超时：
http.Client{Timeout: 3 * time.Second}，否则一个慢依赖可卡住整个调度循环 - 节点资源快照等共享状态，用
sync.RWMutex替代全局锁；粗粒度锁会让 Filter 插件串行化，吞吐骤降
Go 应用 CPU 利用率与容器 CPU Quota 的错配问题
容器设置了 cpu.quota=50000（即 500m），但 Go 默认 GOMAXPROCS 可能设为宿主机核数（如 8），结果大量 goroutine 在 P 上排队等待配额，表现为 P99 延迟毛刺、runtime.NumGoroutine() 持续上涨。
- 设
GOMAXPROCS≤ 容器cpu.shares对应的逻辑核数（不是宿主机核数），例如 500m 配置下建议设为 1 或 2 - 用
GODEBUG=schedtrace=1000观察日志中SCHED行：idleprocs长期非零、runqueue持续堆积，就是配额争抢信号 - 避免在 HTTP handler 中做同步 DNS 查询或阻塞文件 I/O —— 这些操作会让 M 线程挂起，拖慢整个 P 的调度
真正容易被忽略的是：Go 程序的负载特征（如 GC 频率、goroutine 生命周期）和容器 cgroup 设置之间没有自动对齐机制，全靠你手动桥接。Kubernetes 不懂 Go，它只认 YAML 和探针；Go 也不懂 Kubernetes，它只认环境变量和系统调用。这两边的缝隙，就是弹性调度失效的高发区。
