2. Knative 核心概念：Configuration、Revision、Route、Service 的关系与生命周期管理
在 Knative Serving 中，Service 是用户面对的最高抽象，它内部由 Configuration、Revision 和 Route 三个核心资源协同工作。理解这四者的关系与生命周期，是掌握灰度发布与回滚策略的基础。
2.1 核心概念定义
| 资源 | 缩写 | 职责 | 关键特性 |
|---|---|---|---|
| Service | ksvc | 自动管理 Configuration 和 Route 的全生命周期 | 用户入口；自动创建 Route 和 Configuration；支持自动扩缩容到零 |
| Configuration | config | 定义服务的期望配置（镜像、环境变量、资源限制等） | 每次变更配置都会生成一个新的 Revision；不可变快照 |
| Revision | rev | 代表一个特定配置的不可变快照 | 自动扩缩容的最小单元；每个 Revision 拥有唯一的名称和元数据 |
| Route | route | 将流量按百分比分配到不同的 Revision | 支持灰度、蓝绿、A/B 测试；默认指向最新 Revision |
关键认知：Service 是“自动模式”，直接操作 Configuration + Route 是“手动模式”。在生产环境中，灰度发布和回滚通常需要手动调整 Route 的流量分配，而非完全依赖 Service 的自动行为。
2.2 四者关系：从创建到流量分发
下图展示了 Knative Service 内部资源的创建与引用关系：
关系总结：
- Service → Configuration + Route：Service 是 Controller，自动创建并管理 Configuration 和 Route。
- Configuration → Revision：每次 Configuration 变更（如镜像更新）都会生成一个新的 Revision，旧 Revision 保留。
- Route → Revision：Route 通过流量百分比将请求分发到指定的一个或多个 Revision。
2.3 生命周期管理：从创建到回滚
以下是一个典型的 Knative Service 生命周期流程，包含创建、更新、灰度发布和回滚：
2.4 生命周期关键操作与命令
以下是与生命周期管理相关的常用 kn 命令：
# 1. 创建 Service（自动创建 Configuration 和 Route）
kn service create my-service --image gcr.io/knative-samples/helloworld:latest
# 2. 查看 Revision 列表
kn revision list --service my-service
# 3. 更新 Service 配置（自动生成新 Revision）
kn service update my-service --image gcr.io/knative-samples/helloworld:v2
# 4. 手动调整 Route 流量（灰度发布）
kn service update my-service --traffic my-service-00001=90 --traffic my-service-00002=10
# 5. 回滚：将流量全部切回旧 Revision
kn service update my-service --traffic my-service-00001=100
生命周期管理要点：
- Revision 不可变：一旦生成，Revision 的配置不可修改。任何变更都必须通过 Configuration 生成新 Revision。
- 回滚本质：回滚不是删除新 Revision，而是通过 Route 将流量重新指向旧 Revision。旧 Revision 始终存在，直到被显式删除。
- 流量分配粒度：Route 支持精确到 1% 的流量分配，适合精细化的灰度发布。
2.5 生命周期状态转换
每个 Revision 在生命周期中会经历以下状态：
| 状态 | 说明 | 是否接收流量 |
|---|---|---|
| Active | Revision 已就绪，Pod 正常运行 | 是 |
| Reserved | Revision 已就绪，但当前没有流量指向它（保留以备回滚） | 否（但可随时激活） |
| Retired | Revision 被显式标记为不再使用，可能被垃圾回收 | 否 |
回滚策略与生命周期：在灰度发布失败时，回滚操作本质上是将 Route 的流量从新 Revision（Active）切回旧 Revision（Reserved）。旧 Revision 由于处于 Reserved 状态，其 Pod 可能已被缩容到零，但 Knative 会在流量到达时自动扩容，无需手动干预。这是 Knative 回滚“快”的关键原因之一。