1. 课程导论：为什么需要基于连接池水位的 HPA？传统 CPU/MEM 指标的局限性
在 Kubernetes 集群中，Horizontal Pod Autoscaler（HPA） 是保障服务弹性伸缩的核心组件。然而，绝大多数生产环境仍在使用 CPU 和内存作为默认扩缩容指标。这种选择在无状态、计算密集型场景下尚可接受，一旦进入数据库连接池、gRPC 长连接、消息队列消费者等有状态或 IO 密集型服务，CPU/MEM 指标就会暴露出严重的滞后性与失真问题。
本章将深入剖析传统指标的三大局限，并引出基于连接池水位（Connection Pool Water Level）的自定义指标方案，为后续的指标采集、适配器配置、HPA 策略调优奠定理论基础。
1.1 传统 CPU/MEM 指标的三大局限
| 局限维度 | 具体表现 | 典型场景 |
|---|---|---|
| 滞后性 | CPU 利用率上升通常滞后于请求堆积 5~30 秒；内存增长更慢，无法反映瞬时流量尖峰 | 秒杀、抢票、热点事件 |
| 非线性失真 | 连接池耗尽时 CPU 可能仅 30%，但服务已无法处理新请求；内存回收（GC）会导致指标剧烈抖动 | 数据库连接池、Redis 连接、gRPC 流 |
| 业务语义缺失 | CPU/MEM 无法表达“连接池是否还有空闲连接”“队列深度是否超过阈值”等业务状态 | 消息消费者、Thrift 服务、JDBC 连接池 |
⚠️ 生产教训： 某电商平台在双十一大促期间，订单服务 CPU 利用率始终低于 40%，HPA 未触发扩容。实际原因是数据库连接池已耗尽，请求在应用层排队超时，CPU 反而因线程阻塞而降低。最终导致 30% 的订单丢失。事后分析发现，连接池水位在 CPU 飙升前 2 分钟就已达到 95%。
1.2 连接池水位：更精准的扩缩容信号
连接池水位（Connection Pool Water Level）是指当前已使用的连接数占连接池最大容量的百分比。对于任何依赖连接池的服务（数据库、缓存、消息队列、RPC 框架），这个指标直接反映了服务的真实负载压力。
- 实时性高：连接分配与释放发生在微秒级，水位变化几乎与请求到达同步。
- 业务语义明确：水位 80% 意味着连接池即将耗尽，必须立即扩容；水位 30% 表示资源充裕，可以缩容。
- 避免 CPU 抖动干扰：即使 CPU 因 GC 或空闲循环波动，连接池水位依然稳定反映实际处理能力。
💡 核心观点： 连接池水位是 IO 密集型服务的“早期预警系统”，而 CPU/MEM 是“事后报告系统”。基于水位的 HPA 可以在服务容量耗尽之前完成扩容，实现真正的主动弹性。
1.3 传统指标 vs 连接池水位：响应速度对比
下面这张 SVG 图展示了从请求突增到 HPA 触发扩容的完整时间线，对比 CPU 指标与连接池水位指标的响应差异。
1.4 哪些场景必须使用连接池水位？
并非所有工作负载都需要基于连接池水位的 HPA。以下场景是强需求，建议优先采用自定义指标方案：
- 数据库连接池服务：如 Java 应用使用 HikariCP、Druid，Go 应用使用 sql.DB 连接池。
- 缓存连接池：Redis 连接池、Memcached 连接池。
- 消息队列消费者：Kafka 消费者连接数、RabbitMQ 通道数。
- RPC 框架：gRPC 连接池、Thrift 连接池、Dubbo 连接池。
- HTTP 连接池：反向代理、API 网关的出站连接池。
📌 判断标准： 如果服务的最大吞吐量受限于外部资源连接数（而非 CPU 算力），就应该使用连接池水位作为 HPA 指标。一个简单的测试方法是：将 CPU 限制降低 50%，如果 QPS 下降不明显，说明该服务是 IO 密集型，适合连接池水位方案。
1.5 本章小结
| 对比项 | CPU/MEM 指标 | 连接池水位指标 |
|---|---|---|
| 响应速度 | 滞后 15~30 秒 | 实时（秒级） |
| 业务语义 | 无 | 直接反映连接池饱和度 |
| 适用场景 | 计算密集型、无状态服务 | IO 密集型、有状态服务 |
| 扩容准确性 | 容易误判或延迟 | 精准匹配实际负载 |
| 实现复杂度 | 内置支持，零配置 | 需要自定义指标 + Prometheus Adapter |