K8s kube-reserved动态阈值设计：如何让HPA在资源预留与业务需求间自动博弈？

背景

我们维护一个高密度业务集群（1500+节点），kube-reserved 保留了 5% CPU/10% 内存，但遇到两个典型问题：

1. 资源争用风暴：业务突发流量时，HPA 未触发扩缩容，导致 Pod 被驱逐（kubectl describe pod | grep -i evict）
2. 资源预留僵化：日常流量波动时，HPA 频繁扩缩容，造成节点 CPU/内存的毛刺抖动（cfs_throttled 指标全绿但墙钟 > CPU 时间差值达 150ms+）

已尝试的排查与结果

• 确认 kube-reserved 配置正确（--kube-reserved-cpu=5% --kube-reserved-memory=10%）
• 检查 HPA 的 minReplicas/maxReplicas 范围合理（10~50 副本）
• 排查节点 PSI 指标（/proc/pressure/cpu 的 some 值未明显抬升）
• 验证 cpu.cfs_quota 配置（未达到节点 CPU 核数上限）

期望得到的答案形态

1. 动态阈值计算模型：如何量化「业务需求」与「资源预留」的博弈边界？
2. HPA 触发条件优化：在 kube-reserved 基础上，如何设计 HPA 的扩缩容触发阈值？
3. 监控指标建议：除 PSI 外，哪些指标能更早捕获「资源争用风暴」？
4. 实践案例：是否有成功将 kube-reserved 与 HPA 联动的方案？

引用依据：

• 问题1：资源争用风暴导致 Pod 被驱逐
• 问题2：资源预留僵化引发 HPA 毛刺抖动
• 讨论：容量规划中固定 vs 动态池的边界判断逻辑