如何平衡K8s节点资源预留与业务Pod稳定性？

【背景】 K8s节点kube-reserved/system-reserved机制本为防驱逐设计，但实际运维中常面临「预留过多导致资源浪费」与「预留不足触发OOM杀Pod」的两难。近期某业务线因预留计算不足，单节点突发GC导致Pod批量驱逐，损失30分钟吞吐量。

【常见分歧】

1. 硬阈值派：按CPU/内存峰值1:1硬留，杜绝风险（如阿里云推荐）
2. 动态预留派：根据历史负载波动动态调整（需实时监控+自动补偿）
3. 分级策略派：区分核心业务/边缘服务，核心服务强制预留，边缘服务按需分配

【我的倾向】 倾向「动态预留+分级策略」组合：

• 核心业务（如支付、订单）强制保留20%资源
• 边缘服务（如日志采集）按实时负载动态调整
• 配合NodePressureLimit机制，当预留资源不足时自动触发降级

【想听你的实践】 你在哪些场景下见过更聪明的方案？

• 如何量化「安全边界」？
• 是否尝试过机器学习预测资源波动？
• 有没遇到过预留策略导致的反向问题（如资源浪费）？