2. Knative Service 基础回顾：Service、Configuration、Revision 核心概念与关系

在深入流量管理与集群升级兼容性测试之前，必须重新建立对 Knative Service 核心资源模型的精确理解。Knative Serving 的资源模型由三个核心 CRD（自定义资源定义）构成：Service、Configuration 和 Revision。它们之间通过 Route 资源形成一套完整的“声明-构建-路由”生命周期。

2.1 核心资源定义与职责

2.2 三者的层级关系与数据流

下图展示了 Knative Service 内部资源的创建与引用关系。用户提交 Service YAML 后，Controller 将其拆解为 Configuration 和 Route，Configuration 每次 spec 变更都会生成一个不可变的 Revision。

2.3 核心概念详解

2.3.1 Service — 用户操作的唯一入口

Knative Service 是对 Deployment、Service、Ingress 等 Kubernetes 原生资源的高层抽象。用户只需定义 spec.template 中的 PodSpec（容器镜像、端口、环境变量等），Knative 自动完成以下工作：

• 创建 Configuration 来追踪配置版本。
• 创建 Route 来管理流量路由。
• 根据流量规则自动调整 Pod 副本数（缩零能力）。

2.3.2 Configuration — 配置版本的管理者

Configuration 是 Knative 实现“不可变部署”的核心。每次用户更新 Service 的 spec.template，Configuration 都会创建一个新的 Revision。关键特性：

• 自动版本号递增： 每次变更生成 revision-001、revision-002 等。
• 回滚能力： 通过 spec.template.metadata.annotations 中的 knative.dev/rollout 或直接修改 Configuration 的 spec.template 指向旧 Revision 的配置。
• 状态追踪： status.latestReadyRevisionName 指示当前可用的最新 Revision。

# 查看 Configuration 状态示例
kubectl get configuration <service-name> -o jsonpath='{.status.latestReadyRevisionName}'

2.3.3 Revision — 不可变的部署快照

Revision 是 Knative 中最底层的部署单元，它直接对应一个 Kubernetes Deployment。每个 Revision 包含：

• 完整的 PodSpec 快照（镜像、命令、环境变量、资源限制）。
• 自动生成的 Revision 名称（如 helloworld-v1-abc123）。
• 独立的端点状态，供 Route 进行流量分发。

2.4 三者的生命周期交互流程

以下流程描述了一个典型的 Knative Service 从创建到更新的完整生命周期：

1. 创建 Service： 用户提交 ksvc YAML，Knative 控制器创建 Configuration 和 Route。
2. Configuration 生成 Revision： Configuration 根据 spec.template 创建第一个 Revision（rev-001），并启动 Pod。
3. Route 路由流量： Route 默认将 100% 流量指向 status.latestReadyRevisionName（即 rev-001）。
4. 更新 Service： 用户修改镜像版本，Service 更新 Configuration 的 spec.template。
5. 生成新 Revision： Configuration 创建 rev-002，新 Pod 启动，旧 Pod 保持运行。
6. 流量切换： 用户通过 Route 的 spec.traffic 逐步将流量从 rev-001 切到 rev-002（灰度发布）。
7. 回收旧 Revision： 当 rev-002 稳定后，用户可移除 rev-001 的流量条目，Knative 自动缩容旧 Pod。

2.5 流量管理中的角色分配

在流量管理与集群升级兼容性测试的上下文中，三个资源的分工如下：