Knative 自动扩缩容事件怎样影响冷启动设计

如果一个报表 API 一小时只有几次请求，Knative 让它缩到零可以节省空闲副本成本；代价是下一次请求要等 Revision 恢复出可用 Pod。冷启动设计的关键不是简单地把副本固定为 1，而是先判断这次等待能否被 Activator 缓冲，再用实例下限、激活规模和缩容窗口把等待控制在业务能接受的范围内。

Knative 官方地址：https://knative.dev/。下面用一个低频的 report-api 作为小项目场景，解释自动扩缩容事件如何影响冷启动，不提供未实际部署的延迟数字。

先把低频服务的冷启动目标说清楚

这个场景有三个目标：空闲时尽量没有应用副本；突发请求到来时不把首个请求直接丢掉；应用启动完成后，后续请求能绕开不必要的缓冲。三者之间存在取舍，不能只看“是否缩到零”。

• 成本优先：接受首次请求多一个启动等待，保留 scale-to-zero。
• 首请求优先：为该 Revision 设置 min-scale: "1"，让它持续保留实例。
• 折中方案：保留缩到零的能力，用 scale-down-delay 延长短暂低谷后的存活时间。

这里的“冷启动”包含镜像拉取、容器启动、探针就绪和请求真正转发等环节。Knative 文档说明，Revision 从零恢复时，Activator 会暂存请求并通知 Autoscaler 需要容量；新 Pod 就绪后，Activator 再把等待中的请求转给应用。它能改善请求承接，但不会让容器启动时间消失。

把一次冷启动拆成请求路径

当 report-api 已缩到零，入口不会把请求直接交给不存在的 Pod。请求会先进入 Activator，Activator 既是从零恢复时的缓冲点，也会把容量不足的信息交给 Autoscaler。Autoscaler 依据并发数或 RPS 等指标调整 Revision 的 Pod 数量，Pod 就绪后，Queue Proxy 仍处于请求路径中。

当 Revision 有足够的空闲容量时，入口可以把流量直接送到应用 Pod；低流量或没有容量时，Activator 会重新进入路径。于是“是否冷启动”与“是否一直经过 Activator”是两个问题：前者关心 Pod 是否需要创建，后者还受到当前容量和 target-burst-capacity 等路由条件影响。

用配置把启动代价变成可选策略

下面是一个解释策略的最小清单片段。它不是完整生产资源，镜像、域名、容器端口和实际资源限制仍要按环境补齐：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: report-api
spec:
  template:
    metadata:
      annotations:
        # 保留 scale-to-zero，但从零激活时先请求两个实例
        autoscaling.knative.dev/activation-scale: "2"
        # 低谷持续一段时间后再缩容，减少短间隔反复冷启动
        autoscaling.knative.dev/scale-down-delay: "5m"
        # 用并发目标参与自动扩容判断，数值应按服务压测与容量评审
        autoscaling.knative.dev/target: "20"
    spec:
      containers:
        - image: registry.example.com/report-api:2026-10
          # 端口和启动命令需与实际镜像契约一致
          ports:
            - containerPort: 8080

min-scale 是持续的最低副本边界；activation-scale 只控制从零恢复时的最小启动规模，Revision 达到过这个规模后，后续仍可能按实际流量缩回更小数量。initial-scale 针对 Revision 创建后的首次目标规模，也不能当成永久保活开关。

scale-down-delay 适合“请求有短间隔波峰”的服务：它让低并发持续一段时间后才执行缩容，但最终仍会缩到下限。若报表任务每天只触发一次，延迟缩容并不能替代对首请求耗时的真实评估。

用 stable 和 panic 窗口解释突发请求

KPA 会在时间窗口上聚合并发或 RPS。稳定窗口用于一般扩缩容；突发流量达到条件后会进入 panic 模式，使用更短的 panic window 更快响应。进入 panic 模式后不会立即因为短时波动缩回去，恢复稳定也需要满足相应的稳定观察条件。

这解释了两个常见误判：第一，把默认窗口当成业务 SLA；第二，只增加 activation-scale，却没有确认单个 Pod 的启动耗时和并发承载能力。启动规模只能改变恢复后的初始容量，不能修复镜像过大、初始化阻塞或探针过慢。

上线前按同一条链路验收

先记录一个空闲周期内的副本数，再让请求打到已缩到零的 Revision，观察请求是否被承接、何时出现 Ready Pod、首请求与后续请求的延迟差异。随后制造一段短波峰，检查是否进入预期的扩容状态。这里的验收数字必须来自自己的环境，不能把文档默认值当作测试结果。

最后把四类证据放到同一份记录：请求是否成功、Activator 是否有等待、Revision 是否就绪、成本是否达到目标。若业务不能接受首请求等待，选择 min-scale: "1" 或其他预热方案；若业务能接受偶发等待，就不要为了消除一次冷启动而永久支付实例成本。

Knative 缩到零后，首个请求会直接失败吗？

不应把 scale-to-zero 自动等同于请求失败。Activator 会在从零恢复时承接和暂存请求，但最终体验仍取决于入口、超时、Pod 启动速度和应用自身健康状态。

activation-scale 设置得越大越好吗？

不是。它只影响从零激活时的起始规模。规模越大，可能增加启动资源和调度压力；应根据突发并发、单 Pod 承载和启动时间共同评估。

scale-down-delay 能彻底消除冷启动吗？

不能。它只是把缩容动作延后，低谷持续后 Revision 仍可能缩到下限。要消除首请求冷启动，应考虑持续的 min-scale 或专门的预热策略。

官方依据：Knative Autoscaling、Request Flow、Configuring scale bounds、KPA-specific autoscaling 和 Activator capacity 文档。本文中的 report-api、镜像地址、参数组合和验收动作是原创设计示例。