📚 课程目录第2章 Knative核心概念

2. Knative Serving 架构：Revision、Configuration、Route、Service 资源模型详解

Knative Serving 的核心是围绕四个 Kubernetes 自定义资源（CRD）构建的声明式模型：Service、Route、Configuration 和 Revision。这四个资源共同定义了 Serverless 工作负载的部署、流量路由、版本管理和自动扩缩容行为。理解它们之间的关系是掌握 Knative 容量回退演练的前提。

2.1 核心资源模型总览

下图展示了 Knative Serving 中四个核心资源的层级关系与数据流。Service 作为用户入口，向下管理 Route 和 Configuration；Configuration 每次变更都会生成一个新的 Revision；Route 负责将流量按比例分配到不同的 Revision 上。

2.2 四大资源模型详解

2.2.1 Revision（修订版本）

Revision 是 Knative Serving 中不可变的部署快照。每次 Configuration 的 spec 发生变更（例如更新容器镜像、修改环境变量、调整资源请求），Knative 都会自动创建一个新的 Revision。Revision 是容量回退演练中最核心的操作对象——回退的本质就是将流量指向一个旧的 Revision。

不可变性：一旦创建，Revision 的 spec 不可修改。任何变更都必须通过 Configuration 生成新的 Revision。
自动扩缩容：每个 Revision 关联一个 PodAutoscaler 资源，负责根据流量指标将 Pod 副本数从 0 扩缩到目标值。
生命周期：Revision 可以处于 Active、Reserve 或 Retired 状态。只有 Active 的 Revision 才会接收流量并维持 Pod 实例。

容量回退关键点： 回退操作本质上是将 Route 的流量 100% 指向一个旧的 Revision。该 Revision 必须处于 Active 状态，且其对应的 Pod 模板（镜像、环境变量、资源限制）与回退目标完全一致。

2.2.2 Configuration（配置）

Configuration 负责描述期望的部署状态，它定义了 Pod 模板（容器镜像、端口、环境变量、资源请求与限制等）。Configuration 遵循“配置即代码”原则，每次 spec 更新都会触发 Revision 的自动创建。

属性	说明	回退演练中的角色
`spec.template`	Pod 模板定义，包含容器镜像、端口、环境变量、资源限制等	回退时不需要修改 Configuration，只需调整 Route 流量
`status.latestReadyRevisionName`	最新就绪的 Revision 名称	用于确认当前最新版本是否健康
`status.latestCreatedRevisionName`	最新创建的 Revision 名称（可能未就绪）	用于排查创建失败的场景

2.2.3 Route（路由）

Route 负责将入站流量按比例分配到不同的 Revision 上。它支持精确的流量百分比分配、基于 Header 的流量切分（灰度发布）以及默认路由规则。在容量回退演练中，Route 是执行回退动作的“开关”。

apiVersion: serving.knative.dev/v1
kind: Route
metadata:
  name: my-service-route
spec:
  traffic:
  - revisionName: my-service-00001   # 旧版本，回退目标
    percent: 100                      # 100% 流量指向旧版本
  - revisionName: my-service-00002   # 新版本，回退后不再接收流量
    percent: 0
  - latestRevision: false            # 不自动指向最新 Revision

注意： 修改 Route 的流量分配是即时生效的，不会触发 Pod 重建。但目标 Revision 必须已经存在且处于 Active 状态。如果目标 Revision 的 Pod 副本数为 0，Knative 会自动从 0 开始扩容，首次请求可能会有冷启动延迟。

2.2.4 Service（服务）

Service 是 Knative Serving 的顶层抽象，它自动管理 Route 和 Configuration 的生命周期。用户通常只与 Service 交互，Knative 会自动生成对应的 Route 和 Configuration。Service 提供了以下关键能力：

统一入口：用户只需定义 Service，Knative 自动创建 Route 和 Configuration。
自动路由：默认情况下，Service 会将 100% 流量指向最新就绪的 Revision。
版本管理：Service 的 spec.template 变更会自动创建新 Revision，并保留历史 Revision 供回退使用。

2.3 资源模型交互流程

下图展示了用户发起一次部署更新时，四个资源之间的完整交互流程。理解这个流程有助于在容量回退演练中精准定位需要操作的对象。

2.4 资源模型在容量回退中的角色对比

资源	回退中的角色	是否需要修改	修改影响
Service	顶层入口，通常不直接修改	否（除非需要保留回退标签）	修改 Service 会触发新 Revision 创建，与回退目标冲突
Route	回退执行者，控制流量分配	是（修改 traffic 字段）	即时生效，不重建 Pod，但目标 Revision 必须 Active
Configuration	版本生成器，保留历史 Revision	否	修改 Configuration 会创建新 Revision，打乱回退目标
Revision	回退目标，不可变部署快照	否（不可修改）	只能通过 Route 指向它来激活流量

2.5 关键设计原则

不可变基础设施原则： Knative Serving 通过 Revision 的不可变性，确保了每次部署的确定性。回退时，你回退的是一个已知的、经过验证的、不可变的部署快照，而不是重新执行一次可能因环境差异导致结果不同的部署流程。这是 Knative 相比传统 Deployment 回退的核心优势。

声明式 vs 命令式： 回退操作是声明式的——你声明“流量应该指向 Revision v1”，Knative 负责将实际状态收敛到该声明。不需要手动缩放 Pod 或回滚镜像版本。
流量与部署解耦： Route 负责流量，Configuration 负责部署。回退只涉及 Route 的流量调整，不影响 Configuration 的版本演进历史。
版本保留策略： Knative 默认保留所有 Revision，但可以通过 spec.revisionRetention 控制保留数量。在容量回退演练前，应确保目标 Revision 未被自动清理。