4. KPA 工作原理：基于请求并发度的缩放算法

Knative Pod Autoscaler (KPA) 是 Knative Serving 的默认 Pod 水平自动缩放器。与基于 CPU/内存的 HPA 不同，KPA 的核心缩放指标是请求并发度 (Concurrency)，即每个 Pod 正在处理的并发请求数量。KPA 通过精确控制并发度，实现更快速、更平滑的弹性伸缩，特别适合无服务器工作负载。

4.1 核心缩放指标：请求并发度

KPA 不依赖资源利用率，而是直接观测请求并发数。其数据来源是 Activator 或 Queue-Proxy 边车容器上报的指标。

4.2 Panic 模式与 Stable 模式

KPA 设计了两种缩放模式：Stable 模式（稳定模式）和 Panic 模式（恐慌模式），以平衡缩放稳定性与响应速度。

4.2.1 Stable 模式（稳定模式）

在正常情况下，KPA 运行在 Stable 模式。它使用一个较长的观察窗口（默认 60 秒）来计算平均并发度，避免因瞬时流量波动导致频繁扩缩容。

• 窗口大小： 60 秒
• 行为： 平滑、保守，适合稳态流量
• 适用场景： 流量平稳或缓慢增长

4.2.2 Panic 模式（恐慌模式）

当流量突发，并发度在短时间内急剧上升时，KPA 会进入 Panic 模式。它切换到一个更短的观察窗口（默认 6 秒），以更激进的速度进行扩容，快速响应突发流量。

• 触发条件： 在 60 秒窗口内，平均并发度达到目标并发度的 2 倍（即 panic-threshold = 2.0）
• 窗口大小： 6 秒
• 行为： 快速扩容，可能跳过稳定模式的计算
• 退出条件： 并发度回落至目标并发度的 1.1 倍以下，持续 60 秒

下图展示了 KPA 在 Stable 和 Panic 模式下的状态转换与决策流程：

4.3 目标并发度 (Target Concurrency) 配置

Target Concurrency 是 KPA 缩放算法的核心参数，它定义了每个 Pod 期望处理的并发请求数。KPA 通过调整 Pod 数量，使实际并发度尽量接近此目标值。

4.3.1 配置方式

目标并发度可以在 Knative Service 的 YAML 中通过 Annotation 或 Revision Template 配置。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-world
spec:
  template:
    metadata:
      annotations:
        # 设置目标并发度为 10
        autoscaling.knative.dev/target: "10"
        # 可选：设置目标 RPS（如果使用 RPS 模式）
        # autoscaling.knative.dev/target-utilization-percentage: "70"
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go

4.3.2 参数详解

4.3.3 缩放算法示例

假设当前有 3 个 Pod，每个 Pod 的并发数分别为 [8, 12, 10]，目标并发度设置为 10：

1. 计算总并发数： 8 + 12 + 10 = 30
2. 计算期望 Pod 数： ceil(30 / 10) = 3
3. 当前 Pod 数： 3
4. 决策： 无需扩缩容

如果流量突增，并发数变为 [20, 25, 18]：

1. 计算总并发数： 20 + 25 + 18 = 63
2. 计算期望 Pod 数： ceil(63 / 10) = 7
3. 决策： 扩容至 7 个 Pod

4.4 缩放算法流程图

下图展示了 KPA 从指标采集到最终执行扩缩容的完整算法流程：

4.5 关键设计考量

• 避免抖动： Panic 模式退出有 60 秒冷却期，防止频繁模式切换导致 Pod 震荡。
• 目标利用率： 通过 target-utilization-percentage 预留缓冲，避免 Pod 刚好达到目标并发度后立即触发扩容。
• 缩容保护： KPA 默认有缩容冷却期（默认 60 秒），防止流量短暂下降时过度缩容。
• 零流量缩零： 当并发度降为 0 时，KPA 会将 Pod 数缩至 0（如果配置了 min-scale: 0）。