K8s kube-reserved/system-reserved 驱逐业务 Pod：如何基于资源预留策略动态计算安全阈值？

背景

我们管理一个 Kubernetes 集群，节点上配置了 kube-reserved 和 system-reserved 以确保系统资源的预留。然而，在某些情况下，业务 Pod 会被驱逐，怀疑是由于 kube-reserved 和 system-reserved 的配置不当导致。

现象

1. 资源预留不足：节点内存/CPU 预留值未覆盖系统组件（如 kubelet、cgroup 驱动）实际占用，导致业务 Pod 被误判为资源超限。
2. 动态波动：业务负载突增时，kube-reserved/system-reserved 的静态阈值无法适应资源波动，频繁触发驱逐。
3. 驱逐逻辑模糊：当前配置依赖 kube-reserved 和 system-reserved 的硬性比例（如 10%），但未考虑节点硬件差异、系统组件版本差异等动态因素。

已尝试的排查

• 检查节点资源使用：通过 kubectl describe node 确认 kube-reserved/system-reserved 实际占用（如 kubelet 占用约 1.5G 内存）。
• 验证配置：当前配置为 kube-reserved=10%，但部分节点实际系统组件占用超过 15%。
• 检查驱逐事件：发现驱逐事件多发生于业务 QPS 突增时段，且驱逐后节点 CPU 使用率仍低于 70%。

期望答案形态

1. 动态计算模型：基于节点硬件规格（如内存、CPU 核数）、系统组件版本（如 kubelet 1.28）、历史资源占用统计，给出 kube-reserved/system-reserved 的动态计算公式。
2. 安全边界策略：如何设置 eviction-hard 的内存/CPU 阈值，使其既能覆盖系统组件峰值，又不误伤业务 Pod。
3. 监控与告警：推荐的监控指标（如 node_memory_MemAvailable_bytes、node_cpu_capacity）及告警阈值，用于提前预警资源预留不足。

引用依据

• 问题 2852：已存在关于 kube-reserved/system-reserved 驱逐的讨论，但缺乏动态计算方案。
• 文章 1499：InnoDB Buffer Pool 的 LRU 机制对资源竞争的处理逻辑，可类比资源预留策略的设计思路。