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

背景

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

现象

1. 资源使用突增：节点 CPU/内存使用率在业务高峰期达到 90% 以上，但 kube-reserved 未预留足够空间
2. Pod 驱逐日志：kubelet 报错 eviction: cannot make space for new pod，驱逐的 Pod 为业务关键服务
3. 阈值静态配置：当前 kube-reserved 预留值为 10%（CPU 10%，内存 10%），但实际负载波动较大

已尝试的排查

1. 调整 kube-reserved 预留值至 15%（CPU 15%，内存 15%），但未解决驱逐问题
2. 检查节点资源使用情况，确认无其他资源泄漏
3. 分析 cAdvisor 数据，发现部分 Pod 的资源请求/限制配置不合理

期望答案形态

1. 根因分析：kube-reserved 预留不足的典型场景及诊断方法
2. 动态阈值计算方案：基于历史负载数据的动态预留算法（如滑动窗口均值 + 标准差）
3. 实践建议：如何结合 kube-reserved 和 system-reserved 实现资源安全边界

引用内容

• 《K8s kube-reserved预留不足导致Pod驱逐的根因与动态阈值计算方案》（已存在重复提问）
• 《K8s kube-reserved/system-reserved 驱逐业务 Pod：如何基于资源预留策略动态计算安全阈值？》（已存在重复提问）