2. 核心概念：Revision、Configuration、Route、Service 四元组的关系与生命周期
Knative Serving 的资源模型由四个核心 CRD（Custom Resource Definition）构成：Service、Route、Configuration 和 Revision。这四元组构成了 Knative 控制面弹性伸缩的骨架。理解它们之间的关系与生命周期，是掌握自动缩放（Autoscaling）和流量管理的前提。
2.1 四元组角色总览
下表从职责、生命周期和弹性伸缩角色三个维度，对比了四个核心资源：
| 资源 | 核心职责 | 生命周期特征 | 在弹性伸缩中的角色 |
|---|---|---|---|
| Service | 用户入口，管理流量路由与配置的自动部署 | 长期存在，用户直接操作 | 作为顶层控制器，触发 Revision 创建与流量切换 |
| Route | 流量分发，将请求映射到指定 Revision | 长期存在，由 Service 或用户管理 | 决定哪些 Revision 接收流量，影响 Pod 的激活/闲置状态 |
| Configuration | 管理 Revision 的期望状态（镜像、环境变量等） | 长期存在，每次更新生成新 Revision | 定义 Revision 模板，间接控制 Pod 的资源配置与扩缩容参数 |
| Revision | 代表一次代码/配置的快照，不可变 | 创建后不可变，可被保留或废弃 | 直接对应 Pod 模板，是弹性伸缩的最小单元 |
关键认知：Revision 是四元组中唯一直接与 Pod 实例绑定的资源。弹性伸缩决策（扩缩容、从零启动、闲置回收）最终都作用于 Revision 所管理的 Pod 集合。
2.2 四元组关系与生命周期流程
下图展示了四元组之间的引用关系以及一次典型部署的生命周期流转：
2.3 各资源在弹性伸缩中的具体角色
2.3.1 Revision：弹性伸缩的直接执行单元
Revision 是 Knative 中唯一直接管理 Pod 副本数的资源。每个 Revision 对应一个 Deployment 和一个 PodAutoscaler（KPA）对象。弹性伸缩的所有指标采集、决策和执行都围绕 Revision 展开：
- 从零启动（Scale from Zero）：当 Revision 的 Pod 数为 0 时，KPA 根据 Route 的流量请求，触发 Pod 创建。
- 闲置回收（Scale to Zero）：当 Revision 在配置的窗口期内未收到流量，KPA 将 Pod 数缩至 0。
- 并发限制：Revision 的
containerConcurrency字段定义了每个 Pod 的最大并发请求数，是扩缩容的核心参数。
2.3.2 Configuration：Revision 模板与扩缩容参数的来源
Configuration 定义了 Revision 的 Pod 模板（PodSpec），其中包括：
- 容器镜像、资源请求/限制（CPU、内存）。
- 并发数设置（
containerConcurrency）。 - 扩缩容注解（
autoscaling.knative.dev/class、autoscaling.knative.dev/metric等）。
Configuration 本身不直接参与伸缩决策，但它通过 Revision 模板间接决定了 Pod 的规格和伸缩策略。
2.3.3 Route：流量驱动伸缩的触发器
Route 负责将外部请求分发到指定的 Revision。在弹性伸缩中，Route 扮演了“流量感知器”的角色：
- 激活流量：当 Route 将流量指向某个 Revision 时，该 Revision 的 KPA 会保持至少一个活跃 Pod。
- 灰度发布：通过 Route 的流量百分比配置，可以控制新旧 Revision 的 Pod 数量，实现平滑伸缩。
- 流量切换与回滚：Route 的变更会立即影响 Revision 的流量负载，从而触发 KPA 的扩缩容动作。
2.3.4 Service：四元组的统一入口
Service 是用户最常操作的资源。它自动创建 Route 和 Configuration，并确保它们保持一致。Service 的 spec.template 实际上就是 Configuration 的模板。当用户更新 Service 时，Knative 控制面会自动：
- 生成新的 Revision。
- 更新 Configuration 指向最新 Revision。
- 更新 Route 将流量逐步或全部切换到新 Revision。
最佳实践：在生产环境中，建议直接使用 Service 资源进行部署。Knative 会自动处理 Route 和 Configuration 的生命周期，避免手动管理带来的配置漂移风险。仅在需要精细控制流量灰度策略时，才单独操作 Route 和 Configuration。
2.4 四元组生命周期状态机
下图展示了四元组在典型部署、更新和回滚场景下的状态流转：
2.5 四元组与弹性伸缩的交互总结
在 Knative 控制面中，四元组通过以下协作模式实现弹性伸缩：
- Service 作为用户意图的载体，统一管理配置和路由。
- Configuration 负责维护 Revision 的不可变链，确保每次变更可追溯、可回滚。
- Revision 是 Pod 模板的实例化，KPA 直接监控其 Pod 的并发指标并执行伸缩。
- Route 通过流量分配，决定哪些 Revision 需要保持活跃，哪些可以被缩容至零。
常见误区：不要将 Service 视为一个简单的 Deployment 封装。Service 的自动路由管理特性意味着：即使 Revision 被缩容至零，Route 依然保留其引用。当新请求到达时，KPA 能够根据 Route 的指向，快速从零启动正确的 Revision。如果直接操作 Deployment 绕过 Knative 控制面，将失去这一核心能力。