2. Knative核心资源模型概述
Knative Serving 控制面的故障恢复能力，根植于其精心设计的资源模型。理解 Service（服务）、Configuration（配置）、Revision（修订版） 和 Route（路由） 四个核心资源的关系，是掌握故障隔离、版本回滚与流量迁移的基础。这四个资源构成了一个分层、解耦的声明式模型，使得控制面在部分组件失效时仍能维持关键决策。
2.1 四元组角色与职责
每个资源承担独立的职责，通过 Kubernetes 控制器进行协调。下表总结了各资源的角色与关键属性：
| 资源名称 | 缩写 | 核心职责 | 故障恢复关键属性 |
|---|---|---|---|
| Service | ksvc | 用户入口，自动管理 Configuration 和 Route 的生命周期 | 作为单一抽象，屏蔽底层资源变更；故障时自动协调子资源状态 |
| Configuration | config | 定义期望的部署配置（镜像、环境变量、资源限制），每次变更生成新 Revision | 不可变 Revision 链，支持快速回滚到任意历史配置 |
| Revision | rev | 不可变的部署快照，包含代码和配置的冻结版本 | 作为故障恢复的最小单元，支持按版本独立扩缩容和健康检查 |
| Route | route | 流量分发策略，将请求映射到指定 Revision 或百分比分配 | 流量规则与部署解耦，控制面故障时流量仍按最后有效规则转发 |
关键设计原则： Service 是用户唯一需要关心的资源，它自动创建 Configuration 和 Route。Configuration 负责“版本管理”，Route 负责“流量管理”，两者通过 Revision 桥接。这种分离使得控制面在 Route 控制器故障时，Configuration 控制器仍能正常创建 Revision；反之亦然。
2.2 资源关系与生命周期流程
下图展示了四个资源在正常部署和版本更新时的交互流程。箭头方向表示资源的创建或引用关系。
2.3 版本更新与回滚机制
当用户更新 Service 的镜像或环境变量时，Knative 执行以下原子化流程，确保故障恢复的可追溯性：
- Configuration 生成新 Revision： 控制器检测到 Configuration 的
spec.template变更，自动创建新的 Revision（如rev-2），并保留所有历史 Revision（rev-1、rev-0）。 - Route 流量切换： 默认情况下，Route 将
traffic.latestRevision设置为true，流量自动指向最新 Revision。用户也可手动指定百分比分配。 - 回滚操作： 只需修改 Service 的
spec.template指向历史 Revision 的配置，或直接修改 Route 的流量规则，将 100% 流量指向rev-1。
工程经验： 在控制面故障场景下，Revision 的不可变性是最大的安全保障。即使 Configuration 控制器宕机，已存在的 Revision 仍可被 Route 引用并正常服务。建议在生产环境中保留至少 3 个历史 Revision，以应对连续故障。
2.4 资源状态与故障域隔离
每个资源维护独立的状态字段，故障不会跨资源传播。下表展示了各资源在故障时的状态表现：
| 故障场景 | Service 状态 | Configuration 状态 | Revision 状态 | Route 状态 |
|---|---|---|---|---|
| Revision 健康检查失败 | Ready=False | Ready=True（配置有效） | Ready=False | Ready=True（流量切到其他 Revision） |
| Configuration 控制器故障 | Unknown | Unknown | Ready=True（已有 Revision 不变） | Ready=True（流量规则不变） |
| Route 控制器故障 | Unknown | Ready=True | Ready=True | Unknown（但流量仍按最后规则转发） |
| Service 控制器故障 | Unknown | Ready=True（独立运行） | Ready=True | Ready=True（独立运行） |
注意： 虽然资源状态相互独立，但 Service 的
Ready 条件是所有子资源状态的聚合。当子资源故障时，Service 会报告 Ready=False，但不会级联删除或修改子资源。这是控制面故障恢复的核心设计——故障被“观察”而非“传播”。
2.5 资源模型在故障恢复中的价值总结
Knative 的四元组资源模型通过以下机制支撑控制面故障恢复：
- 声明式状态解耦： 每个资源只负责自己的期望状态，控制器独立调谐。一个控制器的故障不会阻塞其他控制器的调谐循环。
- 不可变 Revision 链： 提供确定性的回滚目标，避免因配置漂移导致恢复失败。
- 流量与部署分离： Route 的流量规则独立于 Revision 的部署状态，即使 Revision 正在重启，Route 仍可保持流量转发策略。
- Service 作为故障屏障： 用户只与 Service 交互，底层资源变更对用户透明，简化了故障恢复的操作面。