Kubernetes 不优化 Go 服务性能，关键在于正确配置资源、client-go、并发及 Go 运行时适配容器约束；需显式设 GOMAXPROCS、限定 informer 范围并禁用 resync、调平 workqueue 与 client-go 限速参数、启用 GOMEMLIMIT 防 OOM。
直接说结论：Kubernetes 本身不优化 Go 服务性能，真正起作用的是你如何配置资源、调用 client-go、控制并发，以及让 Go 运行时适配容器约束。错把 Kubernetes 当“性能开关”，反而会因 misconfiguration 加剧 GC 飙升、CPU throttling 或 informer 卡死。
Go 服务在 K8s 里 CPU 忽高忽低，大概率是 GOMAXPROCS 没对齐 limits
Go 运行时默认读 /sys/fs/cgroup/cpu/cpu.cfs_quota_us（cgroup v1）或 /sys/fs/cgroup/cpu.max（v2）失败时，会 fallback 到 runtime.NumCPU()——也就是宿主机总核数。结果就是：容器只分到 2 核，Go 却启动 32 个 P，goroutine 在两个核上疯狂抢占，调度延迟飙升，go tool pprof 里能看到大量 runtime.mcall 和 runtime.gopark。
- 必须显式设置
GOMAXPROCS：优先用 Downward API 注入spec.containers[].env，例如valueFrom.fieldRef.fieldPath: 'status.containerStatuses[0].resources.limits.cpu'，再在启动脚本中解析为整数 - 更稳妥的做法是用
uber-go/automaxprocs：它自动读 cgroups，无需手动解析，且兼容 v1/v2 - 绝对不要依赖
docker run --cpus=2或 K8s 的resources.limits.cpu: "2"让 Go 自动感知——它不会
client-go Informer 吃光内存或卡住几秒，多半是没限范围也没关 resync
一个没加 namespace 和 fieldSelector 的 cache.NewSharedIndexInformer，等价于对整个集群做 ListWatch。Pod 数超 5k 时，首次全量同步可能卡住 10 秒以上；若还开着 ResyncPeriod（默认 10 小时），每 10 小时就来一次全量重刷，etcd 压力陡增。
- 强制限定监听范围：比如只关心
default命名空间的 Pod，就传v1.ListOptions{Namespace: "default"}；想只监听带app=apilabel 的，加LabelSelector: "app=api" - 关闭周期性重同步：
cache.NewSharedIndexInformer(..., 0)中第四个参数设为0，禁用 resync - 避免在
AddFunc/UpdateFunc里做任何耗时操作：HTTP 调用、DB 查询、JSON marshal/unmarshal 全部扔进 workqueue，否则阻塞整个 informer 事件队列
Workqueue 处理慢、积压爆炸，不是并发数太少，而是限速器和 client-go QPS 没配平
常见误区是猛加 go controller.processNextWorkItem() 的 goroutine 数，结果 queue.Get() 内部 mutex 争抢加剧，同时 client-go 因 rest.Config.QPS 默认值（5）太低，大量请求被 apiserver 返回 429 Too Many Requests，key 卡在队列里不 Done()，越积越多。
立即学习“go语言免费学习笔记（深入）”；
- 并发数要反推：假设单次 reconcile 平均耗时 60ms，能容忍最多 60 个积压，则理论并发 ≈ 1000 / 60 ≈ 16 → 实际设 10～12 更稳
- 同步调大
rest.Config.QPS和Burst：比如并发 10，可设QPS: 20, Burst: 50，留出 buffer 防抖动 - 限速器别硬套默认：
DefaultControllerRateLimiter()适合故障恢复，但 ConfigMap 频繁更新时会指数退避到秒级重试；高频场景建议NewBucketRateLimiter(100, 100)（每秒 100 令牌）或组合NewTickRateLimiter(10*time.Second, 10)
内存持续上涨被 OOMKilled，GOGC 可能只是表象，GOMEMLIMIT 才是关键
容器 memory.limit: 256Mi，Go 程序堆长期维持在 200Mi，一次日志批量 flush 或临时 map 构造就突破上限被杀。这不是 GC 不够勤快，而是 Go 运行时默认不主动归还内存给 OS，且预留内存（mcache、arena metadata）也计入 RSS。
- Go 1.19+ 强烈启用
GOMEMLIMIT：设为略低于容器 limit，例如GOMEMLIMIT=200Mi，运行时会严格按此限制堆增长，超限直接 panic（比 OOMKilled 更可控） - 搭配
GOGC=30：降低 GC 触发阈值，减少单次 STW 时间，适合内存敏感场景 - 慎用
debug.FreeOSMemory()：它触发全局内存归还，会引发短暂停顿，仅适合低峰期手动调用，不要放定时器里
最常被忽略的一点：所有 workqueue.RateLimitingInterface.Add(key) 后，必须保证 processNextWorkItem 中无论成功失败都执行 defer queue.Done(key)。漏掉这句，panic 一发生，key 就永远卡在 inFlight 计数里，队列内存泄漏，控制器迟早僵死。
