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

背景

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

1. 资源争用风暴：业务突发流量时，HPA 未触发扩缩容，导致 Pod 被驱逐（kubectl describe pod | grep -i evict）
2. 预留浪费：低峰期 kube-reserved 占用的资源无法回收，造成 2.3% 的 CPU/8% 内存浪费（基于 cAdvisor 资源利用率统计）

现象

• HPA 未触发扩缩容的条件：节点可用 CPU < 70% 且内存 < 60%（默认阈值）
• kube-reserved 保留的资源在 23:00-6:00 低峰期持续占用，导致节点可用资源 < 40%
• 业务侧要求 HPA 快速响应（5 分钟内扩容），但 kube-reserved 预留导致实际可用资源不足

已尝试

1. 调整 kube-reserved 为 3% CPU/5% 内存，但触发驱逐频率上升 40%
2. 使用 system-reserved 保留 2% 内存，但节点资源利用率波动大
3. 尝试 HPA 的 maxReplicas 与 kube-reserved 做动态绑定，但实现复杂度高

期望答案

1. 动态阈值计算公式：如何根据历史负载（如 24h 内 CPU/内存利用率）自动调整 kube-reserved 的保留比例？
2. HPA 与预留的博弈机制：是否可设计 HPA 在资源预留不足时自动触发扩缩容？比如当节点可用资源 < 50% 时，HPA 忽略 kube-reserved 直接扩容？
3. 现有方案对比：k8s 1.28+ 的 kube-reserved 与 1.24 的实现差异，是否支持更精细的动态调整？

引用：

• 《K8s kube-reserved预留不足与HPA联动失效的根因分析与动态阈值计算方案设计》
• 《网络层的「静默降级」：TCP 重传 0.1% 到底算不算故障？》