3. Knative 流量管理基础：Revision 流量分配机制、Tagged 与 Untagged 路由、流量百分比配置
Knative Serving 的流量管理是其灰度发布与故障恢复能力的核心。它允许运维人员将流量精确地分配到不同的 Revision（修订版本）上，而无需重建 Service 或修改 Ingress 配置。本章将深入剖析 Revision 流量分配机制、Tagged 与 Untagged 路由的区别，以及流量百分比配置的实战方法。
3.1 Revision 流量分配机制
在 Knative 中，Service 是用户面向的稳定端点，而 Revision 是每次代码或配置变更产生的不可变快照。流量分配的本质是：将发往 Service 的请求，按照预定义的权重比例，转发到不同的 Revision 上。
该机制通过 spec.traffic 字段定义，支持两种路由模式：
- Tagged 路由：为 Revision 分配一个唯一的“标签”（Tag），通过该标签可以直接访问特定 Revision，常用于内部测试或预发布验证。
- Untagged 路由：不分配标签，仅通过 Service 的主域名访问。流量按照百分比配置分配到多个 Untagged Revision 上。
核心原则： 所有 Tagged 路由的流量百分比之和必须为 0（它们不参与主域名流量分配）；所有 Untagged 路由的流量百分比之和必须为 100。
3.2 Tagged 与 Untagged 路由对比
| 特性 | Tagged 路由 | Untagged 路由 |
|---|---|---|
| 访问方式 | 通过 tag-{revision-name}.{service}.{namespace}.example.com 访问 |
通过 Service 主域名 {service}.{namespace}.example.com 访问 |
| 流量百分比 | 必须为 0（不参与主域名流量） | 总和必须为 100（主域名流量） |
| 主要用途 | 内部测试、预发布验证、金丝雀分析 | 生产流量分发、灰度发布、回滚 |
| 是否可被外部访问 | 是，但需要知道特定标签域名 | 是，通过 Service 主域名 |
| 典型场景 | 开发团队验证新版本功能 | 将 10% 流量切到新版本，90% 留在旧版本 |
3.3 流量百分比配置实战
流量百分比配置通过 Knative Service YAML 的 spec.traffic 字段实现。以下是一个典型的灰度发布配置示例：
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: my-service
spec:
template:
metadata:
name: my-service-v2
spec:
containers:
- image: my-image:v2
traffic:
- tag: v2-candidate
revisionName: my-service-v2
percent: 0
- revisionName: my-service-v1
percent: 90
- revisionName: my-service-v2
percent: 10
配置解析：
- Tagged 路由：
v2-candidate标签指向my-service-v2，百分比为 0。团队可通过v2-candidate-my-service.default.example.com直接访问 v2 版本进行验证。 - Untagged 路由：主域名流量中，90% 流向
my-service-v1，10% 流向my-service-v2。
最佳实践： 在灰度发布初期，建议先为候选版本设置 Tagged 路由（percent: 0），待内部验证通过后，再逐步将 Untagged 流量从旧版本迁移到新版本。
3.4 流量分配流程图
下图展示了 Knative 流量分配的核心流程：请求到达 Service 后，根据 spec.traffic 配置，分别路由到 Tagged 和 Untagged 的 Revision 上。
3.5 流量配置的常见操作
以下表格总结了流量配置的常见操作及其对应的 YAML 修改方式：
| 操作 | YAML 修改方式 | 说明 |
|---|---|---|
| 全量发布 | 将 100% 流量指向新 Revision | 新版本完全接管生产流量 |
| 灰度发布 | 将 10% 流量指向新 Revision，90% 指向旧 Revision | 逐步验证新版本稳定性 |
| 回滚 | 将 100% 流量指向旧 Revision | 快速恢复至稳定版本 |
| 蓝绿部署 | 创建新 Revision 并设置 Tagged 路由，验证后切换 Untagged 流量 | 零停机切换，便于快速回退 |
| 金丝雀分析 | 设置 Tagged 路由（percent: 0）用于内部测试，同时设置少量 Untagged 流量 | 结合监控指标决定是否继续放量 |
3.6 流量配置的原子性与幂等性
Knative 的流量配置具有以下两个关键特性：
- 原子性：一次
kubectl apply操作会完整替换整个spec.traffic配置。如果配置不合法（如百分比之和不为 100），Knative 会拒绝该变更，保持原有配置不变。 - 幂等性：多次应用相同的流量配置，结果始终一致。这为自动化运维和 GitOps 流程提供了可靠基础。
避坑提示： 在修改流量配置时，务必确保
spec.traffic 中引用的 Revision 名称存在且处于 Ready 状态。如果引用了不存在的 Revision，Knative 会报错并拒绝更新。
3.7 流量分配架构图
下图展示了 Knative 流量分配的整体架构，包括 Service、Configuration、Revision 以及流量路由的关系：
通过上述架构图可以清晰地看到：Service 通过 Configuration 管理多个 Revision，而 spec.traffic 配置决定了每个 Revision 的流量权重。这种设计使得 Knative 能够在不中断服务的情况下，灵活地进行灰度发布、A/B 测试和故障恢复。