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 作业（request 12G，limit 20G）。

现象 当节点负载较高时，Pod 会被 kube-reserved/system-reserved 触发驱逐，即使业务 Pod 的 request/limit 总和未达到节点的内存上限。

已尝试的排查与结果

• 确认 kube-reserved 和 system-reserved 的设置合理，但驱逐仍频繁发生。
• 使用 cgroup v2 的 memory.high 和 memory.swappiness 参数调整，但效果有限。
• 检查节点的 page cache 使用情况，发现部分内存被内核占用导致业务 Pod 被误判。

期望得到的答案形态

1. 如何精准计算 kube-reserved 和 system-reserved 的值，避免业务 Pod 被驱逐？
2. 如何通过调整 cgroup 参数和内存预算，确保业务 Pod 不被误判？
3. 有哪些实际案例或最佳实践可以参考？