【背景】 在 K8s 集群中，kube-reserved 作为资源预留机制，能防止系统因突发负载导致 OOM 杀进程。但实际落地时，我们常遇到两难：
- 预留过多 → 资源浪费（尤其突发流量少的业务）
- 预留过少 → 业务 QPS 受限（尤其突发流量多的业务）
【常见分歧】
- 固定值派：按 CPU/内存总量的 10-20% 预留，简单粗暴但缺乏灵活性
- 百分比派：按节点资源的固定比例（如 CPU 15%、内存 25%）预留
- 动态计算派：根据历史负载波动、业务类型、集群规模自动调整阈值
【我的倾向】 我更倾向动态计算方案，理由：
- 业务波动性差异大（如秒杀 vs 稳定业务）
- 资源利用率直接影响成本（尤其混合负载集群）
- 配合 HPA 可实现「资源预留 + 弹性扩缩容」的组合拳
【想听你的实践】 你在什么场景下怎么选？
- 是采用固定值/百分比，还是动态方案？
- 如有动态方案，如何计算阈值？
- 是否遇到过预留不足导致的 HPA 联动失效？
（附：某电商大促期间，我们通过动态调整 kube-reserved 阈值，成功将资源浪费率降低 37%）
0赞
0收藏
0楼层