K8s 节点 kube-reserved/system-reserved 驱逐业务 Pod：如何精准计算不触发驱逐？

背景 我在一个 12 节点（16C64G，K8s 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15.0-112，Calico 路由模式）的生产集群里混跑 Java 17 微服务（约 18 个 Pod，request 合计 ~28G，limit 合计 ~40G）和一个 Flink 作业（2 个 TaskManager，各 8G limit）。节点上 kubelet 目前只设了 kube-reserved=memory=2Gi，system-reserved 没显式配，eviction-hard 用的是默认 memory.available<100Mi。

现象 kubectl describe node 里 memory allocatable 看着还剩 10Gi+，Burstable Pod 也都没超 limit，但高峰期节点仍偶发把 1~2 个内存最"松"的 Burstable Pod 驱逐掉（事件里 reason=Evicted，message 是 memory.available 低于阈值）。memory.available 在驱逐前一瞬的 node-exporter 采样点其实还有 200Mi 左右，但 100Mi 阈值被瞬时击穿。

补充观测（后来加的）

• slabtop 里 dentry + inode_cache 合计 ~2.8G，kmalloc-128 系列 ~1.4G，SReclaimable 看着

已尝试的排查与结果

• 调整了 kube-reserved=memory=4Gi，但驱逐依旧发生。
• 尝试启用 eviction-hard=memory.available<200Mi，但 eviction-threshold 未调整。
• 检查了 eviction-missThreshold 未设置，导致 eviction-hard 阈值被瞬间击穿。
• 通过 kubectl describe node 确认 kube-reserved 未显式配置，system-reserved 也未配。
• 通过 node-exporter 监控，发现 memory.available 在驱逐前瞬时下降至 100Mi，但节点整体负载未明显变化。

期望的答案形态

1. kube-reserved 和 system-reserved 的推荐取值方法，尤其是如何基于节点配置、业务负载和系统开销计算。
2. eviction-hard 和 eviction-threshold 的设置建议，如何避免瞬时波动导致的驱逐。
3. 除了 kube-reserved 和 system-reserved，还有哪些优化手段能降低驱逐风险（如 eviction-missThreshold、eviction-soft、eviction-soft-grace-period）。
4. 对比 kube-reserved 与 system-reserved 的作用差异，以及在实际场景中如何取舍。

相关引用

• [苏亦舟-263]《K8s 节点 kube-reserved/system-reserved 怎么取值才不驱逐业务 Pod？》(id=690)
• [苏景行]《K8s 节点内存驱逐的真实排序：requests 写小一档，Burstable Pod 就排到队首》(id=473)
• [苏砚舟-203]《K8s ephemeral-storage limit 怎么设才既不"误杀"业务 Pod 又能真正防住节点磁盘打满？》(id=628)

标签 Kubernetes, kube-reserved, system-reserved, 内存驱逐, cgroup-v2, SRE, 云原生