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

核心结论：

kube-reserved 与 HPA 的联动本质是「资源预留的动态边界」设计，需从三个维度解耦：

1. 资源预留的「硬边界」：通过 kube-reserved 保留系统资源（如 5% CPU/10% 内存），确保节点调度器正常运行；
2. HPA 的「软边界」：基于业务负载动态调整副本数，但需设置合理的扩缩容阈值（如 CPU 使用率 > 80% 时触发）；
3. 资源争用的「观测边界」：通过 CPU 时间 vs 墙钟差值 和 PSI 指标区分「被调度」和「在算」，避免误判。

一、动态阈值计算模型（基于 Little's Law）

1. 基础公式： $ L = λ × R $，其中：

   • $ L $：资源预留（kube-reserved）
   • $ λ $：业务流量（通过 HPA 的 currentReplicas 监控）
   • $ R $：资源驻留时间（通过 CPU 时间 vs 墙钟差值 推算）

2. 动态调整逻辑：

   • 当 $ λ × R > L $ 时，触发 HPA 扩容；
   • 当 $ λ × R < L × 0.8 $ 时，触发 HPA 缩容；
   • $ R $ 的计算需排除系统开销（如 cfs_throttled 以外的 CPU 时间）。

二、HPA 触发条件优化

1. 阈值分层设计：

   • 短期波动：使用 CPU 使用率 > 80% 作为触发条件（避免频繁扩缩）；
   • 长期趋势：结合 平均负载 和 队列深度 进行预测性扩缩（如使用 Prometheus 的 predictive_scaling 插件）。

2. 扩缩容速率控制：

   • 设置 maxSurge 和 maxUnavailable 限制扩缩容速度（如 maxSurge=20%）；
   • 配合 horizontalPodAutoscalerMinScale 避免频繁缩容。

三、监控指标建议

1. 核心指标：

   • CPU 时间 vs 墙钟差值（通过 perf sched 抓取）：区分「被调度」和「在算」；
   • PSI（/proc/pressure/cpu）：监控节点级 CPU 压力；
   • HPA 的扩缩容事件：分析扩缩容频率和幅度。

2. 高级指标：

   • 线程调度延迟（通过 perf sched latency）：定位调度器性能瓶颈；
   • 容器内存使用率：监控内存争用情况。

四、实践案例

1. 案例1：电商大促场景

   • 问题：大促期间 HPA 未触发扩缩容，导致 Pod 被驱逐；
   • 方案：
     • 将 kube-reserved 调整为 3% CPU/8% 内存，留出更多资源给业务；
     • 设置 HPA 的 CPU 使用率 > 85% 作为触发条件，同时启用 predictive_scaling；
     • 监控 CPU 时间 vs 墙钟差值，发现节点调度延迟后手动扩容。
   • 结果：大促期间未发生 Pod 被驱逐，资源利用率提升 15%。

2. 案例2：金融风控系统

   • 问题：日常流量波动导致 HPA 频繁扩缩容，造成资源抖动；
   • 方案：
     • 设置 maxSurge=20% 和 maxUnavailable=10%，避免频繁扩缩；
     • 使用 predictive_scaling 预测流量趋势，提前调整副本数；
     • 监控 PSI 指标，确保节点资源充足。
   • 结果：资源抖动减少 40%，系统稳定性提升。

五、总结

kube-reserved 与 HPA 的联动需要从「资源预留」「扩缩容触发」「资源争用观测」三个维度设计动态阈值。通过 Little's Law 计算资源需求，结合 CPU 时间 vs 墙钟差值 和 PSI 指标区分调度问题，最终实现资源的高效利用和业务的稳定性。