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 流计算作业。

现象 最近频繁出现节点内存驱逐业务 Pod 的情况，影响了服务的稳定性。

已尝试的排查与结果

• 检查了 kube-reserved 和 system-reserved 的配置，发现它们的总和略大于节点可用内存，可能导致资源争抢。
• 调整了部分 Pod 的 request 和 limit，但驱逐问题仍未完全解决。

期望得到的答案形态

• 如何精确计算 kube-reserved 和 system-reserved 的值，以避免触发驱逐？
• 是否有最佳实践或工具推荐，可以辅助进行资源分配和监控？
• 是否有案例或经验分享，说明如何避免此类问题？