4. Knative 容量参数之并发度（Concurrency）：软限制与硬限制、target 与 limit 的区别及配置示例

在 Knative Serverless 架构中，并发度（Concurrency）是控制每个 Pod（Revision 实例）能够同时处理的最大请求数量的核心容量参数。正确配置并发度直接影响服务的响应延迟、资源利用率以及自动扩缩容的灵敏度。Knative 提供了两对关键概念：软限制（Soft Limit）与硬限制（Hard Limit），以及target 与 limit。理解它们的区别是精细化调优的基础。

4.1 核心概念：软限制 vs 硬限制

Knative 通过两个层级的参数来管理并发：

• 软限制（Soft Limit / Target）：由 Autoscaler 读取，用于计算期望的 Pod 副本数。它不是一个强制性的上限，而是扩缩容的“目标值”。Autoscaler 会尽力让每个 Pod 的并发量接近这个值。
• 硬限制（Hard Limit）：由 Activator / Queue-Proxy 强制执行。当并发请求数达到此上限时，新的请求会被排队（或返回错误，取决于配置），确保 Pod 不会过载。

4.2 target 与 limit 的区别

在 Knative 的配置模型中，target 和 limit 分别对应上述的软限制和硬限制：

4.3 并发度参数的工作流程

下图展示了请求从 Ingress 到 Pod 的过程中，软限制与硬限制如何协同工作：

4.4 配置示例

以下 YAML 示例展示了如何通过 Annotation 和 Spec 字段配置并发度参数：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: concurrency-demo
  namespace: default
spec:
  template:
    metadata:
      annotations:
        # 软限制：Autoscaler 期望每个 Pod 的并发目标为 10
        autoscaling.knative.dev/target: "10"
        # 目标利用率百分比：实际目标 = 10 * 0.7 = 7
        autoscaling.knative.dev/targetUtilizationPercentage: "70"
    spec:
      containerConcurrency: 20   # 硬限制：Queue-Proxy 最多允许 20 个并发请求
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          ports:
            - containerPort: 8080

4.5 参数组合场景分析

不同的 target 与 limit 组合会产生不同的行为模式：

4.6 最佳实践与诊断要点

• 设置合理的硬限制：始终设置 containerConcurrency，避免无限制导致 Pod 资源耗尽。建议值基于应用的单请求资源消耗和 Pod 资源上限计算。
• target 与 limit 的比值：通常 target 设置为 limit 的 50%~80%，为突发流量预留缓冲空间。
• 监控实际并发：通过 Queue-Proxy 暴露的 metrics 端点（如 queue_requests_per_concurrency）观察实际并发是否接近 target，判断是否需要调整。
• 避免 target 过低：target 设置过低（如 1）会导致频繁扩缩容，增加冷启动开销。对于短请求服务，建议 target 在 5~20 之间。