前言
在云原生架构中，系统是否能够真正做到“弹性伸缩”，取决于对底层扩缩容引擎的控制力。从基础的资源监控（CPU/内存），到面向业务的 Serverless 并发调度，扩缩容不仅是简单的“超过阈值就加机器”，而是一套精密结合了数学计算、防抖动容错以及业务特性的控制流。
扩缩容的核心大脑：K8s 原生 HPA 的底层规则
HPA (Horizontal Pod Autoscaler) 是 Kubernetes 中基于硬件资源和自定义指标的扩缩容标杆。它的每一次动作，都严格遵循一系列数学运算与时间窗口规则。
1. 核心计算公式与容忍度
HPA 的扩缩容决策由以下公式驱动：
$$期望副本数 = \lceil 当前副本数 \times \frac{当前指标平均值}{期望指标平均值} \rceil$$
- 向上取整： 计算结果一旦大于当前副本数（例如计算得出 4.1），系统就会扩容到 5。
- 10% 容忍盲区 (Tolerance)： 为防止微小数值波动引发的系统启停震荡，K8s 默认内置 0.1 的容忍度。当实际比值在 0.9 到 1.1 之间时，HPA 会视为正常波动，放弃触发扩缩容计算。
2. 指标基准与计算维度
- 计算基准： CPU 和内存的计算基准是 Pod 的
Request值，而非Limit。若未配置 Request，基于基础资源的 HPA 将直接失效。 - 平均值评估： HPA 提取所有目标 Pod 的资源消耗总和，计算算术平均值后，再与设定的目标百分比进行比对。
3. 时间窗口与防抖规则
- 采样频率： 默认每 15 秒同步并计算一次指标。
- 扩容（Scale Up）： 零延迟触发。只要指标越过阈值且超出容忍度，立刻执行扩容。为防止瞬间拉爆集群，单次扩容上限被限制为“新增 4 个 Pod”或“当前副本数翻倍”（取两者最大值）。
- 缩容（Scale Down）： 极其谨慎。系统默认包含 5 分钟的冷却期（Stabilization Window）。HPA 会记录过去 5 分钟内的最大期望副本数，只有当当前流量长期处于低位，且历史最大期望值也低于当前副本数时，才会真正执行缩容。
KPA vs HPA：轻骑兵与重装步兵的博弈
在引入 Knative 后，我们拥有了 KPA (Knative Pod Autoscaler)。它与 HPA 在扩缩容哲学上有着本质的区别。
1. 核心定位
- KPA (并发/流量驱动)： 适合轻量级 API、网关和极速启动的微服务。它的视角中只有 HTTP 请求数，反应达到秒级，且原生支持极致的“缩容到 0”。
- HPA (资源/计算驱动)： 适合重度计算、复杂报表生成或老旧臃肿的单体应用。它死守 CPU 和内存底线，具备长达数分钟的防抖机制，保护系统不被大颗粒度的复杂任务拖垮。
2. 指标欺骗与“活活憋死”危机
如果一个服务面临的是“低并发，极高 CPU 消耗”（例如极其复杂的数据库查询、加密解密算法），坚持使用 KPA 会引发灾难。KPA 看到并发量未达标，会拒绝扩容；而仅有的几个高耗时请求却足以将单台 Pod 的 CPU 打满，最终导致后续请求全部堆积超时。此时，必须果断切换回 HPA，以底层算力作为唯一的扩缩容衡量标准。
3. 规模降为零的底层限制 (Scale-to-Zero)
- Knative 通过其独有的
Activator组件实现 0 到 1 的冷启动请求拦截与挂起，因此 KPA 能够完美缩容到 0。 - 原生 HPA 强依赖 Metrics Server 采集现存 Pod 的 CPU/内存数据。如果副本数为 0，数据链路断裂，HPA 陷入“脑死亡”。因此，Knative 中一旦切换为 HPA 控制，必须强制设置最小副本数 $\ge$ 1。
精准扩容：利用 OpenTelemetry 寻找黄金并发点
在使用 KPA 这一类基于并发扩缩容的引擎时，如何设定合理的最大并发值是一大难题。通过 OpenTelemetry 结合利特尔法则与压测，可以科学地找出这个“饱和崩溃拐点”。
1. 获取瞬时并发指标
使用 OTel 的 http.server.active_requests (Gauge 类型) 指标，可以实时拦截并绘制出服务在任意时刻的真实活跃处理请求量曲线。
2. 理论估算 (Little’s Law)
通过利特尔法则进行初步理论验证：
$并发数 = RPS \times 平均响应时间(秒)$
若某接口高峰期承受 200 RPS，平均耗时 50ms（0.05秒），则单台 Pod 的理论安全并发度为 10。
3. 寻找真实拐点与打折策略
真实的容量规划绝不能单纯依赖理论推算，必须针对单实例进行阶梯式压测。监控 P99 延迟 (http.server.request.duration)、错误率和底层 CPU。一旦发现并发加压到某个点时，P99 延迟瞬间飙升，该数值即为极限并发。
黄金打折法则： 在配置 Knative Target 时，需将测出的极限安全并发值打 70% 到 80% 的折扣。系统需要预留充足的时间窗口（几秒钟）来拉起新 Pod，满载配置会直接导致扩容期间老实例崩溃。
架构选型对照表
对于不同业务模型，正确的扩展策略能兼顾高可用性与资源成本：
| 业务特征 | 推荐扩缩容策略 | 核心原因解析 |
| —————————- | ———————- | ———————————————————— |
| 轻量级 API、高频网关 | KPA (基于并发/RPS) | 响应极快，纯流量驱动，能够完美吸收瞬间脉冲请求并支持缩容到 0。 |
| 重度计算、复杂报表 | HPA (基于 CPU) | 无需压测探底，死守算力底线，防止单点 CPU 被复杂逻辑打爆。需维持最小副本为 1。 |
| 异步队列跑批、定时任务 | KEDA / HPA | 后台任务无需极速扩容，更看重持续的计算能力与队列积压深度的精准映射。 |
| 强依赖下游慢速组件的服务 | KPA (基于并发) | 下游拖累导致耗时暴增但 CPU 极低。HPA 会拒不扩容导致连接池耗尽，KPA 可迅速增加副本摊薄请求。 |
架构师补充建议：
如果你放弃压测，选择绝对硬件指标作为扩缩容基准（HPA），强烈建议配合使用 VPA (Vertical Pod Autoscaler) 辅助工具。开启 VPA 的推荐模式，它能够通过长期观测给出最合理的 CPU Request 基线值，作为 HPA 扩缩容计算公式中完美的“分母”，从而实现自动化资源调配的闭环。
