K8s 集群"节点驱逐（eviction）"的代价到底怎么量化？一次驱逐 = Pod 重建 + 冷启动 + 业务短暂不可用，这个代价有没有人算过具体数字（时间、QPS 损失、业务损失）？和"多花 20% 成本避免驱逐"相比，哪个更划算？

背景

• K8s 1.28.9 / containerd 1.7.13 / cgroup v2，10 节点（16C64G）生产集群。
• 最近一年做降本项目，节点利用率从 ~60% 提到 ~80%，账单确实降了 20%+。
• 但随之而来的是驱逐事件增加：从每月 1–2 次涨到 5–8 次，每次驱逐 = Pod 重建 + 冷启动 + 业务短暂不可用。
• 业务侧反馈"偶发一批请求超时"，但监控上驱逐事件很少被注意到（因为驱逐后 Pod 自动重建，用户无感知）。

现象

1. 驱逐事件从每月 1–2 次涨到 5–8 次，集中在节点内存压力大时（同节点混部 Java 批跑 Pod 触发 page cache reclaim）。
2. 每次驱逐的代价：Pod 重建 30–60s + 冷启动 10–30s + 业务短暂不可用 1–3 个请求批次（QPS ~1200 的订单服务，每批次约 1200 × 10s = 12000 请求受影响）。
3. 监控上 kubelet_evictions_total 有计数，但没有和业务侧的 QPS / P99 关联，导致驱逐事件在 dashboard 上"隐形"。
4. 驱逐后 Pod 自动重建，用户侧只看到"偶发一批请求超时"，没有明确的告警。

已尝试的排查与结果

• 把驱逐阈值从 memory.available < 100Mi 调到 memory.available < 200Mi，驱逐事件减少 50%，但节点利用率从 80% 降到 ~72%（多花了 ~8% 的成本）。
• 试了 kubelet.evictionHard.memory.available 和 kubelet.evictionSoft.memory.available 的组合，发现 evictionSoft 的 grace period（10s）对驱逐事件的影响不大，驱逐仍然发生在 evictionHard 触发时。
• 把驱逐敏感的 Pod（订单服务）迁到独占节点，驱逐事件减少 80%，但多花了一台机器的成本（~15% 的账单），对 1200 QPS 的订单服务来说性价比太低。
• 试了 PodDisruptionBudget（PDB）防止驱逐，但 PDB 只防"自愿驱逐"（如节点维护），对"非自愿驱逐"（如内存不足）无效。

期望得到的答案形态

1. 有没有人量化过"一次驱逐"的具体代价（Pod 重建时间 + 冷启动时间 + 业务损失），最好有 kubelet 日志 + Pod 事件 + 业务侧的 QPS / P99 数据。
2. "驱逐代价"和"多花 20% 成本避免驱逐"相比，哪个更划算？有没有人做过"驱逐代价 = X 元/次" vs "多花 20% 成本 = Y 元/月"的对比？
3. 驱逐阈值（memory.available < 100Mi vs 200Mi）到底该按什么定？按节点规格？按业务 SLO？按历史驱逐率？
4. K8s 有没有"驱逐代价"的监控指标（比如 kubelet_evictions_total + Pod 事件 + 业务侧的 QPS / P99 关联），能不能做一个"驱逐代价 dashboard"？

引用

• id=976 的"利用率当目标还是余量当目标"（我做了降本但驱逐事件增加，想看看别人的取舍）
• id=1039 的"余量留多少"（我想看看别人怎么定"余量红线"）