2. 核心组件与工作流：Activator、Queue-Proxy、Autoscaler 组件的角色与交互流程

Knative Serving 的自动扩缩容能力并非由单一组件完成，而是由三个核心组件——Activator、Queue-Proxy 和 Autoscaler——通过精密的协作流程共同实现。理解每个组件的职责以及它们之间的交互关系，是掌握 Knative 弹性伸缩机制的基础。

2.1 组件角色定义

下表从功能定位、部署位置和核心职责三个维度，对三个核心组件进行对比：

2.2 组件交互流程全景

下图展示了从请求到达 Knative 服务到完成自动扩缩容的完整交互流程：

2.3 核心交互流程详解

Knative 的自动扩缩容交互流程可以分为以下四个关键阶段：

1. 流量拦截与冷启动（缩容至零场景）
   • 当 Revision 的 Pod 数为 0 时，所有入站请求首先到达 Activator。
   • Activator 将请求暂存，同时通知 Autoscaler 需要扩容。
   • Autoscaler 通过 Kubernetes API 将 Deployment 的 replicas 调整为 1。
   • Pod 启动后，Queue-Proxy 和用户容器就绪，Activator 将请求转发至新 Pod。
2. 并发控制与指标采集
   • 每个 Pod 内的 Queue-Proxy 作为 Sidecar 代理所有进出流量。
   • Queue-Proxy 维护一个请求队列，控制并发数不超过 containerConcurrency 设置。
   • Queue-Proxy 每秒采集以下指标：平均并发数、请求排队深度、请求延迟。
3. 指标聚合与扩缩容决策
   • Autoscaler 通过 gRPC 或 HTTP 接口，从所有 Queue-Proxy 实例拉取指标。
   • Autoscaler 使用 Panic Window（6 秒） 和 Stable Window（60 秒） 两个时间窗口进行指标聚合。
   • 根据聚合后的并发数，计算期望 Pod 数：期望 Pod 数 = 当前总并发数 / 目标并发数。
4. 扩缩容执行
   • Autoscaler 通过修改 Kubernetes Deployment 的 replicas 字段执行扩缩容。
   • 扩容时，Autoscaler 会考虑 冷却时间 和 最大扩容速率，避免过度扩容。
   • 缩容时，Autoscaler 会逐步减少 Pod 数，确保服务稳定性。

2.4 组件交互的三种工作模式

根据 Revision 的当前 Pod 数和流量状态，Knative 会在以下三种模式间切换：

2.5 组件间通信协议

三个核心组件之间的通信采用以下协议和接口：

• Activator ↔ Autoscaler： 通过 gRPC 协议通信。Activator 在拦截请求后，向 Autoscaler 发送 StatMessage，包含请求的统计信息。
• Queue-Proxy ↔ Autoscaler： 通过 HTTP/1.1 协议通信。Queue-Proxy 在每个指标采集周期（默认 1 秒）向 Autoscaler 的 /metrics 端点上报指标数据。
• Autoscaler ↔ Kubernetes API： 通过 Kubernetes API 调整 Deployment 的 replicas 字段。

2.6 组件交互的容错机制

Knative 在组件交互中设计了多层容错机制，确保自动扩缩容的可靠性：

• Activator 高可用： Activator 以 Deployment 形式部署，支持多副本。当某个 Activator 实例故障时，流量自动切换到其他健康实例。
• 指标上报超时： 如果 Queue-Proxy 在 2 秒内未收到 Autoscaler 的响应，会认为上报失败，并在下一个周期重试。
• Autoscaler 无状态设计： Autoscaler 不持久化状态，所有决策基于当前指标。重启后可以从 Queue-Proxy 重新获取指标。
• 降级策略： 如果 Autoscaler 无法获取指标（如网络分区），会保持当前 Pod 数不变，避免错误缩容导致服务不可用。