Knative Serving 核心资源模型：Revision、Configuration、Route、Service

Knative Serving 的资源模型是理解自动扩缩与流量调度的基础。整个模型围绕四个核心 CRD（Custom Resource Definition）构建：Service、Configuration、Revision 和 Route。它们共同定义了从代码部署到流量路由的完整生命周期。

2.1 四层资源模型总览

下图展示了 Knative Serving 的四层资源模型及其关系。Service 作为顶层抽象，向下管理 Configuration 和 Route；Configuration 每次变更都会生成一个新的 Revision；Route 根据流量规则将请求分发到指定的 Revision。

2.2 四大资源详解

2.2.1 Revision（修订版）—— 不可变的快照

Revision 是 Knative Serving 中最核心的不可变资源。每次 Configuration 的 spec.template 发生变更（例如修改环境变量、镜像版本、资源请求/限制），Knative 都会自动创建一个新的 Revision。每个 Revision 代表一个特定配置的快照，包含完整的 PodTemplateSpec。

• 不可变性：Revision 一旦创建，其 spec 不可修改。任何变更都只能通过创建新的 Revision 实现。
• 自动扩缩单元：每个 Revision 可以独立进行自动扩缩（缩容到零、扩容到目标并发数）。
• 版本管理：默认保留最近 N 个 Revision（可通过 revision-history-limit 配置）。
• 流量目标：Route 可以将流量精确分配到任意 Revision，支持蓝绿部署、金丝雀发布。

2.2.2 Configuration（配置）—— 期望状态的描述

Configuration 负责描述服务的“期望状态”。它定义了 Revision 的模板（spec.template），包括容器镜像、环境变量、资源配额、探针等。Configuration 的每次更新都会触发 Revision 的创建。

2.2.3 Route（路由）—— 流量分发策略

Route 负责将外部请求按照配置的流量比例分发到不同的 Revision。它支持灵活的流量管理策略，是实现灰度发布、A/B 测试、蓝绿部署的核心组件。

• 流量比例：通过 spec.traffic 字段定义每个 Revision 的流量百分比，总和必须为 100。
• 默认目标：可以设置 @latest 指向 Configuration 的最新就绪 Revision，简化配置。
• 命名 Revision：支持按 Revision 名称精确分配流量，例如 revisionName: "hello-world-00001"。
• URL 分配：每个 Route 会生成一个唯一的 URL（如 http://hello-world.default.example.com），作为服务访问入口。

# Route 流量配置示例
apiVersion: serving.knative.dev/v1
kind: Route
metadata:
  name: hello-world
spec:
  traffic:
    - revisionName: hello-world-00001
      percent: 10        # 10% 流量到旧版本
    - revisionName: hello-world-00002
      percent: 90        # 90% 流量到新版本
    - latestRevision: true
      percent: 0         # 预留 0% 用于快速切换

2.2.4 Service（服务）—— 用户唯一操作入口

Service 是 Knative Serving 对用户暴露的最高层抽象。它自动管理 Configuration 和 Route 的生命周期。用户只需编写 Service YAML，Knative 控制器会自动创建对应的 Configuration 和 Route，并保持三者同步。

2.3 资源模型工作流程

当用户提交一个 Service YAML 时，Knative Serving 内部执行以下步骤：

1. Service 控制器接收到 Service 资源，检查 spec.template 是否变更。
2. 如果 spec.template 有变化，Configuration 控制器创建一个新的 Revision，Revision 名称格式为 {service-name}-{递增序号}。
3. 新 Revision 的 Pod 自动扩缩控制器（KPA/HA）开始工作：如果配置了缩容到零，且当前无请求，Pod 数量变为 0。
4. Route 控制器更新路由规则，将 @latest 指向新 Revision，并根据 spec.traffic 分配流量。
5. 当请求到达 Route 的 URL 时，Activator（如果 Pod 缩容到零）或 Queue Proxy（如果 Pod 运行中）将请求转发到目标 Revision 的 Pod。

2.4 资源模型对比总结