K8s 节点 kube-reserved/system-reserved 怎么取值才不驱逐业务 Pod？

背景 我在一个 12 节点（16C64G，K8s 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15，Calico 路由模式）的生产集群里混跑 Java 17 微服务和一个 Flink 作业。节点上 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 阈值被瞬时击穿。

已尝试的排查

1. 调大 kube-reserved 到 4Gi，重启 kubelet 后 allocatable 缩小，但驱逐频率没明显下降；
2. 把 eviction-hard 改成 memory.available<250Mi，驱逐更少但节点开始频繁触发 OOM，宿主机侧 dmesg 出现 oom-killer；
3. 用 kubectl describe node 看 Allocatable 和 Capacity 差值，确认 reserved 确实生效了，但没找到 system-reserved 到底占了多少。

期望得到的答案形态

• kube-reserved / system-reserved / eviction 阈值三者之间应该按什么优先级和公式来取值，而不是各自拍脑袋；
• 在 cgroup v2 + 大页/THP、内核 slab 不可回收内存偏高的节点上，memory.available 这个指标本身是否还可靠，有没有更贴近真实可回收量的判据；
• 有没有一个可复现的压测方法（比如 stress-ng + cgroup 限制），能在我这个 64G 节点上把驱逐边界标定出来，再反推 reserved 该设多大；
• 如果业务 Pod 的 requests 普遍偏小（< 实际使用 30%），这种"账面富余"的节点上，reserved 到底该按 requests 总和还是按实际 RSS 分布来留？

欢迎给具体数字和命令，不要"建议监控"这种空话。