一眼识别pod是否被oomkilled：直接查看kubectl describe pod 中events部分是否有warning oomkilling，或last state显示exit code 137且oomkilled: true。
怎么一眼识别Pod是不是被OOMKilled杀掉的
直接看 kubectl describe pod <pod-name></pod-name> 输出里的 Events 部分——只要出现 Warning OOMKilling 或状态里写着 OOMKilled，基本就坐实了。注意不是所有“重启”都报这个，只有内核级内存不足触发 OOM Killer 才会打上这个标记。
常见误判点：只看 kubectl get pods 显示 CrashLoopBackOff 就以为是代码异常，其实背后可能是 OOMKilled 导致容器连日志都来不及刷就挂了；还有人翻 kubectl logs 为空，就断定“没出错”，但 OOMKilled 的进程根本没机会写日志。
- 执行
kubectl describe pod <pod-name></pod-name>，重点扫Events和Last State字段 - 看到
Exit Code 137+OOMKilled: true是铁证 - 别依赖
kubectl top pod做判断——它采样间隔太粗（默认15s），而 Go 程序瞬时 GC 峰值可能几秒就冲破 limit 然后被杀，监控根本抓不到
Go服务在K8s里为什么特别容易OOMKilled
Go runtime 不像 JVM 那样默认感知 cgroup 限制，它会按宿主机总内存估算 GC 触发阈值和堆增长策略。比如节点有 64Gi 内存，你的 Pod 只配了 memory: 512Mi，但 Go 还是可能分配出 1.2Gi 的瞬时堆对象（尤其高并发读写 JSON、拼接大字符串、未复用 sync.Pool），结果一过 limit 就被 kubelet 杀掉。
- Go 程序不会主动向内核“让出”已分配但未使用的内存，
runtime.GC()也不保证立即释放物理内存 -
container_memory_usage_bytes指标包含 page cache 和 RSS，但 OOMKiller 判定依据是container_memory_working_set_bytes（实际驻留内存），两者常差 200Mi+ - 别信 “我用了
pprof没发现泄漏”——pprof 抓的是堆快照，而 OOM 往往发生在 GC 暂停期间的内存尖峰，快照根本拍不到
resources.limits.memory 怎么设才不踩坑
不能拍脑袋填 512Mi 或 1Gi。得结合 Go 程序的真实 RSS 峰值来定，且必须留出 buffer 给 runtime 开销（如 goroutine 栈、mcache、bypass malloc 的大对象）。
立即学习“go语言免费学习笔记（深入）”；
- 先在测试环境压测，用
curl http://<pod-ip>:6060/debug/pprof/heap?debug=1</pod-ip>查看inuse_space，再用cat /sys/fs/cgroup/memory/memory.usage_in_bytes在容器内看真实 RSS - limit 至少设为 RSS 峰值的 1.5 倍，比如压测看到 RSS 最高 380Mi，那就设
limits.memory: "600Mi" - requests 要等于或略低于 limit（如
requests.memory: "512Mi"），避免调度器把 Pod 扔到内存紧张的节点上 - 绝对不要只设 limit 不设 request——Kubernetes 会把它当成 0，导致调度混乱
livenessProbe 怎么配才不会火上浇油
GC STW（Stop-The-World）期间 HTTP 健康端点卡住是常态，如果 livenessProbe 的 timeoutSeconds 太短或 failureThreshold 太低，就会在 OOM 前先把 Pod 重启一遍，掩盖真正问题。
- 把
initialDelaySeconds设成应用冷启动+首次 GC 完成时间之和，比如 Go 服务通常要 20~40 秒，别用默认的 10 秒 -
periodSeconds至少 30 秒，timeoutSeconds不低于 8 秒，failureThreshold改成 5（连续 5 次失败才重启） - 健康检查路径别走完整业务链路，用
/healthz这种只返回200 OK的轻量端点，避开 DB 连接、缓存查询等不确定延迟环节
最麻烦的点其实是：OOMKilled 往往不是单一原因，而是资源限制、探针配置、Go 内存模型三者叠加的结果。调一个参数可能缓解表象，但不看 /sys/fs/cgroup/memory/ 底层指标，就永远不知道 runtime 真实吃了多少内存。
