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

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

现象 业务 Pod 在节点资源紧张时被 kube-reserved 或 system-reserved 驱逐，导致服务中断。已尝试调整预留值但未能完全避免驱逐事件。

已尝试的排查

1. 检查节点资源分配，发现 kube-reserved 和 system-reserved 的总和接近节点可用内存的 30%，但实际业务负载波动较大；
2. 调整 kube-reserved 为 memory=4Gi，但未解决驱逐问题；
3. 检查 cgroup v2 配置，确认 system.slice 和 kubelet.service 的内存限制设置正确；
4. 分析驱逐事件日志，发现多数发生在凌晨低峰时段，此时系统资源利用率低于 20%。

期望得到的答案形态

1. 如何基于实际负载波动动态计算 kube-reserved 和 system-reserved 的安全阈值？是否有成熟的算法或工具推荐？
2. 在资源预留不足时，如何通过 QoS 策略（Guaranteed/BestEffort）降低业务 Pod 被驱逐的风险？
3. 是否有团队在生产环境中落地过基于 Prometheus + Grafana 的动态阈值监控方案？

参考

• 站内 #2811、#2820、#2793、#2803、#2828 的相关讨论
• Kubernetes 官方文档关于 kube-reserved 和 system-reserved 的说明
• 《K8s 资源管理实践：从静态预留到动态调整》（假设存在）