📚 课程目录第4章自动扩缩配置参数详解

4. 扩缩策略配置：minScale、maxScale、concurrency-target、concurrency-limit 参数详解

Knative Serving 的自动扩缩（Autoscaler）是 Serverless 架构的核心能力，它通过四个关键参数精确控制 Pod 的扩缩行为。理解这些参数的含义、优先级和典型配置，是优化资源利用率与保障服务稳定性的前提。

4.1 参数总览与作用域

四个参数分别定义在 RevisionTemplate 的 spec.containerConcurrency 和 metadata.annotations 中。下表列出它们的名称、作用域与核心作用：

参数名	配置位置	默认值	核心作用
minScale	`annotations`	0（未设置时）	保证最少运行的 Pod 数量，避免冷启动
maxScale	`annotations`	0（无上限）	限制最大 Pod 数量，防止资源耗尽
concurrency-target	`annotations`	100（基于 `container-concurrency`）	Autoscaler 期望每个 Pod 达到的并发数，用于扩缩决策
concurrency-limit	`spec.containerConcurrency`	0（无限制）	硬限制单个 Pod 能同时处理的最大请求数

关键区别： concurrency-target 是 Autoscaler 的目标值，用于计算期望 Pod 数；concurrency-limit 是硬限制，超过的请求会被排队或拒绝。两者配合使用才能实现精准控制。

4.2 参数详解与配置示例

4.2.1 minScale：保底 Pod 数

当服务流量降至零时，minScale 决定是否保留空闲 Pod。设置为 1 或更高可以消除冷启动延迟，但会增加基础资源开销。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-world
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "2"   # 至少保留 2 个 Pod
        autoscaling.knative.dev/maxScale: "10"  # 最多 10 个 Pod
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go

4.2.2 maxScale：资源安全上限

防止突发流量导致 Pod 数量无限增长，保护集群资源。生产环境必须设置合理的 maxScale。

注意： 如果 maxScale 设置过小，高并发时请求可能被拒绝（503）；设置过大则可能耗尽节点资源。建议根据压测结果逐步调整。

4.2.3 concurrency-target：扩缩决策目标

Autoscaler 根据当前总请求数除以 concurrency-target 计算期望 Pod 数。例如，总请求 500，target 为 50，则期望 Pod 数为 10。

annotations:
  autoscaling.knative.dev/target: "50"   # 每个 Pod 目标并发 50

4.2.4 concurrency-limit：请求硬限制

在 spec.containerConcurrency 中设置，限制单个 Pod 同时处理的请求数。超过限制的请求会被 Knative 的 Queue-Proxy 排队或拒绝。

spec:
  containerConcurrency: 10   # 每个 Pod 最多同时处理 10 个请求

4.3 参数协同工作流程

下图展示了四个参数在请求处理与扩缩决策中的协同关系：

4.4 典型配置场景对比

不同业务场景对这四个参数的配置策略差异很大。下表列出三种典型场景的推荐配置：

场景	minScale	maxScale	concurrency-target	concurrency-limit	说明
延迟敏感型 API	2	20	10	20	保留保底 Pod，低目标并发保证响应速度
批处理/异步任务	0	50	100	200	允许缩零，高并发吞吐优先
Webhook/回调服务	1	10	50	100	平衡延迟与资源成本

4.5 参数优先级与常见陷阱

优先级规则： concurrency-limit > concurrency-target。如果 limit 小于 target，Autoscaler 永远无法达到目标，会导致持续扩容。
陷阱一： minScale 与 maxScale 相等时，服务变为固定副本数，失去弹性扩缩能力。
陷阱二： 不设置 maxScale 时，突发流量可能导致 Pod 数量激增，耗尽集群资源。
陷阱三： concurrency-target 设置过小（如 1），会导致 Pod 数量过多，增加调度和网络开销。

  最佳实践： 先通过压测确定服务的单 Pod 最佳并发处理能力，将 concurrency-limit 设为该值的 1.2~1.5 倍作为安全余量，concurrency-target 设为 limit 的 60%~80%。然后根据流量模型设置 minScale 和 maxScale。

4.6 扩缩参数与流水线测试任务的关联

在 CI/CD 流水线中执行测试任务时，合理配置扩缩参数可以显著提升资源利用效率：

测试任务 Pod 的 minScale=0： 允许测试任务完成后自动缩零，不占用集群资源。
maxScale 限制并行度： 防止大量测试任务同时启动导致集群过载，建议设置为流水线最大并行数的 1.5 倍。
concurrency-target 与测试用例粒度： 如果每个测试 Pod 处理一个用例，target 设为 1；如果处理一批用例，target 设为批大小。

下图展示扩缩参数在流水线测试任务中的具体应用：

通过合理配置这四个扩缩参数，Knative 服务可以在保证响应速度的同时最大化资源利用率，而流水线测试任务也能实现按需分配、用完即释放的弹性效果。