Kubernetes资源预留策略：静态阈值 vs 动态计算，如何平衡稳定性与资源利用率？

【背景】 Kube-reserved预留不足导致Pod驱逐的根因分析中，发现传统静态阈值（如CPU 20%、内存50%）在业务波动场景下频繁触发OOM Killer，而动态计算方案（如基于历史负载的滑动窗口）又存在实现复杂度高、实时性差的问题。

【常见分歧】

1. 静态阈值派：认为简单可靠，避免误杀
2. 动态计算派：主张按业务特征自适应调整
3. 混合策略派：用机器学习预测负载

【我的倾向】 倾向动态计算+阈值衰减机制，参考《Kafka慢消费者停机8天》的offsets.retention设计思路，用滑动窗口统计95%分位负载，设置阈值为max(历史峰值0.8, 当前负载1.2)。但需注意：

• 需要业务侧配合提供QoS分类
• 与CIS安全基线核对报告中的资源隔离策略协同
• 需要监控系统支持毫秒级指标采集

【想听你的实践】 你在哪些场景下选择过动态计算？如何处理误杀风险？是否遇到过阈值设置的踩坑案例？