3. Autoscaler 组件总览：单副本 vs 多副本 Autoscaler、核心职责、与 KPA 的关系
在 Knative Serving 控制面中，Autoscaler 是驱动弹性伸缩决策的核心组件。它负责收集 Revision 的并发指标、计算期望副本数，并将决策写入控制面状态。本章从部署拓扑、核心职责以及与 KPA 的协作关系三个维度，系统梳理 Autoscaler 的架构设计。
3.1 单副本 vs 多副本 Autoscaler 部署模式
Knative Autoscaler 支持两种部署拓扑，分别对应不同的可靠性、延迟和资源开销需求。
| 对比维度 | 单副本 Autoscaler | 多副本 Autoscaler |
|---|---|---|
| 部署副本数 | 1 个 Pod | ≥ 2 个 Pod（通常 2~3） |
| 数据一致性 | 强一致（单点读写） | 最终一致（通过 Lease 选主） |
| 伸缩延迟 | 低（无协调开销） | 中（Leader 选举 + 状态同步） |
| 故障恢复 | 需等待 Pod 重建 | 秒级切换（Standby 接管） |
| 适用场景 | 开发/测试、低流量服务 | 生产环境、高可用要求 |
生产建议： 对于 SLA 要求高的服务，始终启用多副本模式。Knative 默认通过
--autoscaler-multi-replica 标志控制，建议设置为 true 并配合 --autoscaler-lease-duration 调整 Leader 切换敏感度。
3.2 Autoscaler 核心职责
无论单副本还是多副本，每个 Autoscaler 实例都承担以下四项核心职责：
- 指标收集：从 Queue-Proxy 侧车或 Activator 获取并发请求数（concurrency）、请求速率（RPS）等实时指标。
- 期望副本计算：根据当前指标、目标并发数（
container-concurrency-target）和稳定窗口，计算期望 Pod 副本数。 - 决策写入：将期望副本数更新到 Revision 的
status.scale字段，触发 HPA 或 SKS 进行实际扩缩容。 - 缩容防护：在缩容时应用
scale-down-delay和stable-window策略，避免抖动。
关键指标公式：
期望副本数 = ceil( 当前并发数 / container-concurrency-target )当并发数为 0 且超过 scale-to-zero-grace-period 时，期望副本数置为 0，触发缩零。
3.3 Autoscaler 与 KPA 的关系
KPA（Knative Pod Autoscaler） 是 Knative 内置的弹性伸缩策略实现，它与 Autoscaler 组件的关系常被混淆。实际上，二者是 策略与引擎 的分工关系：
- KPA：定义伸缩策略（如目标并发数、窗口大小、缩零行为），以 CRD 形式存在于集群中。
- Autoscaler：作为控制面组件，读取 KPA 策略，执行指标计算和副本决策。
下图展示了 Autoscaler 与 KPA 在控制面中的协作流程：
3.4 关键设计要点
- 无状态计算：Autoscaler 本身不存储持久化状态，所有决策依赖当前指标和 KPA 策略，重启后可从最新指标重新计算。
- 多副本一致性：多副本模式下，只有 Leader 实例执行写入操作，Follower 仅做指标缓存，保证 Revision Status 不被并发覆盖。
- KPA 策略热更新：修改 KPA CRD 的
containerConcurrencyTarget或stableWindow后，Autoscaler 在下一个计算周期自动生效，无需重启。
避坑提示： 不要将 Autoscaler 的
--scale-down-delay 设置过小（如 < 30s），否则在流量短时波动时会导致频繁扩缩容，增加 Pod 启动开销。建议生产环境设置为 60s~120s。
3.5 小结
Autoscaler 是 Knative 控制面弹性伸缩的“大脑”，单副本模式适合低风险场景，多副本模式保障生产高可用。它与 KPA 的分工清晰：KPA 定义策略，Autoscaler 执行计算。理解这一关系，是后续深入分析伸缩算法和性能调优的基础。