OOMKilled是容器因内存超限被内核OOM Killer强制终止的状态，表现为退出码137、事件中显示“OOMKilled”，需通过合理配置资源限制、健康探针及内存监控来预防和快速响应。
健康检查本身无法直接捕获 OOM，但可以配合配置和日志快速暴露 OOM 后的异常状态。 Kubernetes 的 OOMKilled 事件发生在内核层，Go 进程被杀前几乎无机会执行任何逻辑——/healthz 端点不会“感知到自己将死”，也不会返回错误。真正能用健康检查做到的，是让 OOM 后的重启行为被探针快速识别并触发告警链路。
为什么 /healthz 在 OOM 后会突然 5xx 或超时
OOMKilled 导致容器终止 → Kubelet 检测到进程退出 → 重启容器 → 新实例启动中，/healthz 端点尚未监听或 handler 未注册 → livenessProbe 失败（connection refused 或 timeout）→ Kubelet 记录 Probe failed 事件 → 告警系统（如 Prometheus Alertmanager）基于 kube_pod_container_status_restarts_total 或 kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} 触发告警。
关键点在于：健康检查不是“检测 OOM”，而是“放大 OOM 引发的不可用信号”。常见误判场景包括：
- livenessProbe 的
initialDelaySeconds设得太短（如 5s），而 Go 应用加载配置、初始化 DB 连接池耗时 8s，导致 probe 在就绪前反复失败，被误判为 OOM 循环 - readinessProbe 和 livenessProbe 指向同一 handler（如都用
/healthz），且该 handler 内部调用了db.PingContext—— OOM 后 DB 连接未重建，/healthz 持续 503，但 Kubelet 实际看到的是 liveness 失败重启，而非 readiness 摘流量 - Pod 日志中已出现
fatal error: runtime: out of memory，但健康端点仍返回 200（因 panic 发生在业务 goroutine，HTTP server goroutine 仍在运行），掩盖真实问题
如何让健康检查暴露 OOM 后的真实异常
核心策略是：把“进程是否存活”和“内存是否可控”两个维度拆开，用不同探针+不同响应语义表达。
- livenessProbe 指向
/livez，只做极轻量快照：runtime.NumGoroutine()是否突增（>500）、debug.ReadGCStats中最近 GC pause 是否 >200ms、或用runtime.ReadMemStats检查mem.Alloc是否接近 cgroup memory limit（需提前读取/sys/fs/cgroup/memory/memory.limit_in_bytes） - 避免在
/livez中访问任何外部依赖或分配大内存，防止 probe 自身触发 OOM - 在
/readyz中不检查内存，但必须确保：一旦服务因 OOM 重启后，DB 连接池、Redis client 等资源能自动重建；否则/readyz会持续失败，Kubernetes 不会把流量导给它，也就不会二次压垮 - Go 启动时记录初始
mem.Alloc和mem.Sys，在/livez中对比当前值，若增长 >3x 且持续 2 轮 probe，返回 500 并带{"reason":"memory_leak_suspected"}
Kubernetes 配置必须匹配 Go 健康逻辑
再好的 Go 健康端点，配错 probe 就等于没写。
-
livenessProbe的timeoutSeconds必须 ≤periodSeconds，否则 probe 卡住会堆积 goroutine，加剧内存压力；推荐设为timeoutSeconds: 1、periodSeconds: 5、failureThreshold: 3 -
readinessProbe的initialDelaySeconds要 ≥ Go 应用完成初始化的时间（比如 DB 连接池 warmup、gRPC client ready），可用time.Since(start)打日志确认，再加 2–3s 缓冲 - 容器 resource limits 必须明确设置
memory，否则 cgroup 无上限，OOMKilled 不会发生，但服务会缓慢卡死——此时健康检查也无意义 - 在 Pod spec 中加
terminationMessagePolicy: FallbackToLogsOnError，确保 OOM 后容器日志可查（尤其是 fatal error 行）
最易被忽略的一点：健康检查不能替代内存分析。一旦告警触发，立刻用 go tool pprof http://pod-ip:6060/debug/pprof/heap 抓 heap profile，而不是只盯着 /healthz 返回值。OOM 往往是累积泄漏，不是单次大分配。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
