Go应用被驱逐主因是resources配置失配：未设requests致BestEffort QoS最先被驱逐，limits过低或未设GOMEMLIMIT导致RSS超限触发OOM；应配Guaranteed QoS+高priorityClass，并设GOMEMLIMIT=80% limits内存以主动控RSS。
Go应用被驱逐，通常不是代码问题，而是资源声明失配
绝大多数 Go 应用在 K8s 中被节点压力驱逐（如 memory.available 触发），根本原因不是内存泄漏，而是 <code>resources.requests 和 resources.limits 配置不合理 —— 尤其是 Go 程序的 runtime 内存行为与传统语言不同，runtime.MemStats.Alloc 远小于实际 RSS，导致按“逻辑用量”估算的 limit 完全失守。
- Go 的 GC 会延迟释放堆内存，RSS 可能长期维持在
limits附近甚至略超，一旦节点触发硬驱逐（如memory.available），kubelet 直接调用 cgroup OOM killer 终止容器，<code>terminationGracePeriodSeconds失效 - 不设
requests的 Go Pod 默认为BestEffortQoS，在内存压力下最先被驱逐；设了requests == limits才是Guaranteed，但若limits设低，反而加速被 kill - 实测常见坑：用
go build -ldflags="-s -w"减小二进制体积，却忽略GOMEMLIMIT未设，导致 runtime 在节点内存紧张时拒绝主动 GC，RSS 暴涨
给 Go Pod 配 priorityClass 不等于防驱逐，关键看 kubelet 驱逐顺序
Kubelet 驱逐时，**先按 QoS 分组，再在同组内按优先级排序**。也就是说，一个高优先级的 BestEffort Pod，依然会被低优先级的 Guaranteed Pod “压在下面” —— 因为 QoS 优先级高于 priorityClassName。
-
Guaranteed（requests == limits）永远最后被考虑驱逐，哪怕priorityClassName是最低的 -
BestEffort（无requests/limits）最先被驱逐，哪怕你给了system-cluster-critical这种超高优先级 - 真正起作用的组合是：
Guaranteed + high priorityClassName，且该 priorityClass 的value必须 > 其他业务类 Pod（如默认 0 或 1000000），否则调度器抢占时仍可能被挤掉
eviction-hard 配置里 memory.available 是“假空闲”，Go 程序尤其容易误判
memory.available 来自 cgroupfs，计算时**剔除了 inactive_file 缓存**，但 Go 程序大量使用 mmap（如 sync.Pool 底层、http.Transport 的连接池）产生的匿名页不会被计入 file cache，这部分 RSS 占用真实物理内存，却让 memory.available 显示偏高 —— 导致 kubelet 实际触发驱逐时已非常被动。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别信
free -m或cat /sys/fs/cgroup/memory/memory.usage_in_bytes，它们和 kubelet 判断依据不一致；用cat /sys/fs/cgroup/memory/memory.stat | grep total_inactive_file手动验证剔除量 - 腾讯云等托管集群默认
--eviction-hard=memory.available，对 Go 服务太激进；建议调高到 <code>，并搭配软驱逐 <code>--eviction-soft=memory.available - 必须配合
--system-reserved=memory=1Gi，否则 kubelet 自身 RSS 波动会干扰判断，Go 应用日志刷屏时尤其明显
Go 程序里加 GOMEMLIMIT 比改 K8s 配置更治本
从 Go 1.19 起，GOMEMLIMIT 可强制 runtime 主动 GC，把 RSS 控制在指定阈值下，比单纯靠 K8s 驱逐“事后补救”更前置、更可控。
立即学习“go语言免费学习笔记（深入）”；
- 设
GOMEMLIMIT=80% of memory.limits（例如 limits=2Gi → GOMEMLIMIT=1600Mi），runtime 会在接近该值时触发 GC，避免突兀 OOM - 注意：不能设成
90%以上，Go runtime 自身开销（如 goroutine stack、mcache）需预留空间；也不建议设固定字节数（如1500Mi），而应结合 K8s limits 动态注入 - Deployment 中写法示例：
env: - name: GOMEMLIMIT valueFrom: resourceFieldRef: resource: limits.memory divisor: 1再用bc或 initContainer 换算成字节并乘以 0.8，或直接用downwardAPI+ 启动脚本处理
最常被忽略的一点：驱逐不是故障终点，而是信号——它暴露的是资源水位与应用行为的错配。Go 的内存模型决定了你不能只看 Alloc，也不能只调 K8s 参数；得让 runtime 和 kubelet 在同一套内存认知上对话。
