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）和一个 Flin

现象 最近频繁出现节点内存驱逐业务 Pod 的问题，且驱逐逻辑似乎与 kube-reserved/system-reserved 的配置有关。每次驱逐后，Pod 会自动重启，但系统资源使用率并未显著下降，疑似存在资源分配不合理的情况。

已尝试的排查与结果

• 检查了 kube-reserved 和 system-reserved 的默认值，发现其总和占节点内存的 15% 左右；
• 调整了 kube-reserved 和 system-reserved 的值，但驱逐仍频繁发生；
• 确认了节点的内存使用情况，发现内存使用率未超过 80%；
• 检查了 Pod 的 requests 和 limits 设置，发现其配置合理。

期望得到的答案形态

1. 如何精确计算 kube-reserved 和 system-reserved 的值以避免驱逐业务 Pod？
2. 有哪些工具或方法可以监控和分析驱逐事件？
3. 在 cgroup v2 环境下，如何优化资源分配以减少驱逐风险？