3. Knative 自动扩缩容机制：KPA 与 HPA 对比、并发模型、缩容至零原理
3.1 自动扩缩容的核心目标与决策路径
Knative Serving 的自动扩缩容机制是 Serverless 平台实现“按需分配、按量计费”的基石。其核心目标是在保证服务质量（响应延迟、请求成功率）的前提下，最小化资源占用。当流量上升时，快速增加 Pod 副本；当流量下降时，回收空闲副本，直至缩容为零。
Knative 提供了两种扩缩容策略：Knative Pod Autoscaler (KPA) 和 Horizontal Pod Autoscaler (HPA)。KPA 是 Knative 原生的、基于请求并发数（Concurrency）的扩缩容方案；HPA 则是 Kubernetes 内置的、基于资源指标（CPU/内存）或自定义指标的方案。生产环境中，通常优先使用 KPA 以获得更快的响应速度和更精确的并发控制。
关键决策点： 选择 KPA 还是 HPA，取决于业务场景。对于延迟敏感、流量突发、需要快速缩容至零的 Serverless 工作负载，KPA 是首选。对于需要基于 CPU/内存等资源指标进行扩缩容的传统微服务，HPA 更合适。Knative 也支持同时启用两者，但需注意优先级和冲突。
3.2 KPA 与 HPA 对比分析
| 对比维度 | KPA (Knative Pod Autoscaler) | HPA (Horizontal Pod Autoscaler) |
|---|---|---|
| 扩缩容依据 | 请求并发数（Concurrency）、每秒请求数（RPS） | CPU 使用率、内存使用率、自定义指标（QPS、延迟等） |
| 响应速度 | 极快（秒级），基于 Activator 实时观测 | 较慢（分钟级），依赖 Metrics Server 采集周期 |
| 缩容至零 | 原生支持，通过 Activator 代理空闲 Revision | 不支持，最小副本数通常为 1 |
| 并发模型 | 严格限制每个 Pod 的并发请求数（containerConcurrency） |
不直接控制并发，通过资源利用率间接影响 |
| 配置复杂度 | 低，主要配置 concurrency-target 和 containerConcurrency |
中，需配置指标类型、目标值、稳定窗口等 |
| 适用场景 | Serverless 工作负载、突发流量、延迟敏感型应用 | 传统微服务、有状态服务、需要基于资源指标的场景 |
性能验证要点： 在 Cilium 网络环境下，KPA 的快速扩缩容依赖于 Activator 与 Queue-Proxy 之间的高效网络通信。Cilium 的 eBPF 数据路径可以显著降低 Activator 代理请求的延迟，从而加速并发指标的采集和决策。
3.3 并发模型：从请求到 Pod 副本的映射
KPA 的并发模型是理解其扩缩容行为的关键。核心参数包括：
containerConcurrency：每个 Pod 实例允许的最大并发请求数。硬限制，超过此限制的请求会被排队或拒绝。concurrency-target：KPA 期望每个 Pod 达到的目标并发数。软目标，KPA 会据此计算期望副本数。concurrency-limit：可选，用于覆盖containerConcurrency的软限制。
扩缩容计算公式（简化）：
期望副本数 = 当前总并发数 / concurrency-target例如，设置 containerConcurrency=10，concurrency-target=5。当总并发数达到 100 时，KPA 会尝试扩容到 20 个 Pod（100 / 5 = 20）。每个 Pod 最多处理 10 个并发请求。
避坑指南：
concurrency-target 不应设置得过高或过低。过高会导致 Pod 负载过重，增加延迟；过低会导致频繁扩缩容，造成资源浪费。建议根据实际压测结果，设置为 containerConcurrency 的 50%-70%。
3.4 缩容至零原理
缩容至零是 Knative 区别于传统 Kubernetes 部署的核心特性。其实现依赖于两个关键组件：Activator 和 Queue-Proxy。
- 空闲检测： Queue-Proxy Sidecar 持续监控进入 Pod 的请求。当在
stable-window（默认 60 秒）内没有新请求到达时，Queue-Proxy 向 KPA 报告“空闲”状态。 - 缩容决策： KPA 收到空闲报告后，将期望副本数计算为 0，并通知 Knative Controller 执行缩容操作。
- 路由切换： 在缩容至零之前，Knative 将 Revision 的路由从直接指向 Pod 切换为指向 Activator。Activator 成为请求的代理入口。
- Pod 回收： Kubernetes Deployment 将副本数缩减至 0，所有 Pod 被回收。
- 冷启动： 当新请求到达 Activator 时，Activator 缓存请求，同时触发扩容流程。KPA 计算期望副本数，Kubernetes 创建新 Pod，Queue-Proxy 和用户容器启动，Activator 将缓存的请求转发至新 Pod。
性能验证关键指标：
- 缩容至零延迟： 从最后一个请求结束到 Pod 完全回收的时间。
- 冷启动延迟： 从请求到达 Activator 到第一个响应返回的时间。Cilium 的网络加速可以显著缩短冷启动过程中的网络路径延迟。
- Activator 代理延迟： 请求经过 Activator 转发带来的额外延迟。
3.5 关键配置参数速查
| 参数 | 所属组件 | 默认值 | 说明 |
|---|---|---|---|
containerConcurrency |
Revision (spec) | 0 (无限制) | 每个 Pod 的最大并发请求数。建议设置为一个合理值（如 10-100）以保护应用。 |
concurrency-target |
KPA ConfigMap | 100 | KPA 期望每个 Pod 达到的目标并发数。用于计算期望副本数。 |
stable-window |
KPA ConfigMap | 60s | 缩容稳定窗口。在此时间内无新请求，才允许缩容至零。 |
panic-window |
KPA ConfigMap | 6s | 恐慌模式窗口。当并发突增时，KPA 进入恐慌模式，加速扩容。 |
max-scale |
Revision (annotation) | 无限制 | 最大副本数限制，防止无限扩容。 |
min-scale |
Revision (annotation) | 0 | 最小副本数。设置为 0 允许缩容至零；设置为 >0 则保留常驻 Pod。 |
生产建议： 对于延迟敏感型应用，建议将
stable-window 缩短至 30s 以加快缩容响应，同时设置 min-scale: 1 保留一个常驻 Pod 以避免冷启动延迟。对于成本敏感型应用，保持 min-scale: 0 并优化冷启动速度（如使用 Cilium 加速网络、减小容器镜像体积）。