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

背景

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

1. 资源争用风暴：业务突发流量时，HPA 未触发扩缩容，导致 Pod 被驱逐（kubectl describe pod | grep -i evict）
2. 资源预留僵化：日常低峰期 HPA 反复缩容，造成频繁的 Pod 启停（kubectl get hpa | grep -i scale）

现象

• 节点资源使用率波动在 60-85% 之间，但 HPA 不触发扩缩容
• kube-reserved 预留的 5% CPU/10% 内存无法动态适配业务负载
• 手动调整 kube-reserved 后，HPA 能响应但需人工干预

已尝试的排查与结果

1. 静态预留调整：将 kube-reserved 提高到 15% CPU/20% 内存，虽缓解了争用风暴，但缩容频率从 3 次/小时飙升到 12 次/小时
2. HPA 配置优化：调大 minReplicas=3，但业务低峰期仍频繁触发 scale-down
3. 监控指标校准：发现 kube-reserved 预留的资源未被 HPA 计入可用池（kubectl describe node | grep -i allocatable）

期望得到的答案形态（请具体、可复现）

• 请给一条在 K8s 里让 kube-reserved 动态适配业务负载的推荐路径，最好带具体配置/命令（如 kube-reserved 与 HPA 的联动策略、基于 Prometheus 的动态阈值计算脚本）；
• 针对「资源预留僵化」问题，请说明如何用 HPA 的 metricsServer + kube-reserved 的动态调整 实现自动博弈（附最小可跑的 YAML 示例）；
• 如果是「基于负载预测的动态预留」方案，请给一个最小可跑的示例（如 Prometheus + Thanos + 自动缩容控制器的组合）；
• 如果结论是「K8s 原生做不到，必须上云原生调度器」，请说明改造成本和有没有更轻量的中间态（比如只对核心业务做动态预留、其余保持静态）。

我引用的两条站内内容，和我的问题同属「资源预留与扩缩容联动」这条线，供参考上下文：

• 站内有篇讲 kube-reserved 预留不足与 HPA 联动失效的根因分析（id=2931）——它解决的是「静态预留不足」这条通道，和我这里「静态预留过剩」是相邻但不同的问题；
• 还有一篇关于 Kubernetes 资源调度「可调试 vs 够安全」取舍的讨论（id=462）——它引出的「调试要能进容器」和我的「HPA 要能自动响应」正好是同一枚硬币的两面，想听听大家在这条线上怎么平衡。