K8s kube-reserved预留不足导致Pod驱逐的根因与动态阈值计算方案

背景

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

现象

1. 资源竞争激烈时：CPU/内存使用率超过 kube-reserved 预留值，触发 OOMKilled 或 evicted 事件；
2. 动态负载波动：突发性流量高峰导致预留不足，业务 Pod 被强制驱逐；
3. 阈值静态配置：当前采用固定值（如 CPU 10%、内存 20%），无法适应不同节点硬件差异。

已尝试

• 检查节点资源使用率，发现 kube-reserved 设置为 10% 时，部分节点实际负载常突破 80%；
• 尝试手动调整预留值，但缺乏自动化监控与动态计算机制。

期望答案

1. 根因分析：预留不足的具体触发条件与 kube-reserved/system-reserved 的交互逻辑；
2. 动态计算方案：如何基于节点硬件指标（如 CPU 核数、内存容量、历史负载基线）自动计算安全阈值；
3. 工程实现建议：是否可基于 cAdvisor/metrics-server 构建动态调整策略，或推荐现成的控制器方案。

引用：

• 《K8s kube-reserved/system-reserved 驱逐业务 Pod：动态计算安全阈值的三种方案与取舍》
• 《K8s kube-reserved 驱逐阈值动态计算：基于资源预留策略的工程实现与避坑清单》