判断是Kubelet GC还是Go runtime GC拖慢服务：若Pod频繁OOMKilled但RSS未爆、docker stats内存平缓，则是Go runtime GC失控触发cgroup OOM；若节点磁盘告警、kubectl describe node出现ImageGCFailed事件，则是Kubelet镜像/容器GC问题。
怎么判断是Kubelet GC还是Go runtime GC在拖慢你的服务
先看现象再调参。如果Pod频繁被OOMKilled但top里RSS没爆、docker stats显示内存使用平缓，大概率是Go runtime GC没控住堆，触发了cgroup OOM；如果节点磁盘突然告警、kubectl describe node里出现ImageGCFailed或FreeDiskSpaceFailed事件，那问题在Kubelet镜像/容器GC侧。
关键区分点：Kubelet GC只动磁盘（镜像、容器日志、退出容器），不动内存；Go GC只管堆内存分配与回收，不碰磁盘。两者完全独立，日志和指标也分属不同层级——别用GOGC去救磁盘满，也别靠image-gc-high-threshold压内存抖动。
容器镜像GC参数设多少才不误删生产镜像
默认image-gc-high-threshold=85太激进，尤其在CI/CD高频拉取镜像的节点上，容易把刚部署完还没启动的镜像当“冷数据”清掉。实际要留出缓冲空间：
-
image-gc-high-threshold建议设为92～95，给镜像pull和Pod启动留出窗口 -
image-gc-low-threshold必须比high低至少5个百分点，比如high=95就设low=88，避免GC反复启停抖动 -
minimum-image-ttl-duration不能低于10m——很多灰度发布流程中，新镜像拉下来后要等配置中心下发、健康检查通过才真正启用，短于10分钟易误删
验证方法：改完kubelet参数后，手动docker pull一个测试镜像，sleep 600后再观察是否还在docker images列表里。
Go服务在K8s里必须设的两个环境变量
不设GOMEMLIMIT和GOGC，等于让Go runtime在黑盒里猜内存上限。Kubernetes的resources.limits.memory对Go不可见，它只会按默认规则估算目标堆，结果就是：明明limit=2Gi，HeapAlloc冲到1.8Gi就OOMKilled。
-
GOMEMLIMIT必须显式设置，且要比cgroup limit小：limit=2Gi →GOMEMLIMIT=1900Mi（留100Mi给goroutine栈、mmap元数据） -
GOGC建议从50起步压测：值越低GC越勤、停顿越短，但CPU开销上升；高并发HTTP服务常见取值是30～70，别用默认100 - 两项都必须在容器启动前注入，
os.Setenv运行时修改无效
漏掉GOMEMLIMIT是2026年线上OOM最常见原因——Go 1.19+已支持，旧版本请升级。
sync.Pool用错比不用还糟的三个信号
不是所有对象都适合放sync.Pool。以下情况说明你正在制造更重的GC压力：
- Pool.Get()后不做类型断言校验，直接传给
io.Copy等函数——一旦底层对象被提前Put回Pool，后续Get拿到的是脏数据，引发panic或数据污染 - Put进Pool的对象包含指针字段（比如
struct{ data *[]byte }），而没在Reset里清空——指针指向的老对象无法被回收，造成隐式泄漏 - 在HTTP handler里
defer pool.Put(x)但x是闭包捕获的局部变量——该变量逃逸到堆，Pool反而延长其生命周期
真正安全的sync.Pool用法：只缓存纯值类型或明确Reset过指针字段的临时对象，且Get/Put严格成对出现在同一作用域内。不确定时，先用-gcflags="-m -m"确认逃逸路径。
