📚 课程目录第4章 Knative容量规划基础

4. Knative 流量管理：流量拆分、蓝绿部署、灰度发布策略

Knative Serving 内置了基于 Revision 的流量管理能力，允许运维人员在不重建 Service 的前提下，将流量按比例分配到不同版本的 Revision 上。这一机制是实现蓝绿部署、金丝雀发布、A/B 测试等高级发布策略的基础。本章将深入解析 Knative 流量模型、核心 CRD Traffic 配置，以及三种典型发布策略的实现方法。

4.1 流量管理核心模型

Knative 的流量管理基于以下三个核心概念：

Service：用户面向的稳定端点，始终指向最新的 Configuration 和 Route。
Revision：每次 Configuration 变更时生成的不可变快照，代表一个特定版本的代码和配置。
Traffic 配置：定义在 Route 资源中的 traffic 块，指定每个 Revision 接收的流量百分比。

  关键原则： Knative 的流量拆分是 Revision 级别 的，而非 Deployment 级别。流量通过 Route 的 traffic 块直接路由到不同 Revision 的 Pod 上，无需额外引入 Service Mesh 或 Ingress Controller 的复杂规则。

以下是一个典型的 Route 流量配置示例：

apiVersion: serving.knative.dev/v1
kind: Route
metadata:
  name: my-service
spec:
  traffic:
    - revisionName: my-service-00001
      percent: 90
    - revisionName: my-service-00002
      percent: 10
    - tag: latest
      revisionName: my-service-00002
      percent: 0

配置说明：

revisionName：指定目标 Revision。
percent：分配给该 Revision 的流量百分比，总和必须为 100。
tag：为 Revision 分配一个命名标签（如 latest、stable），可通过 tag-url 直接访问，常用于内部测试。

4.2 流量拆分与路由策略对比

下表对比了 Knative 支持的三种流量管理策略及其适用场景：

策略	流量分配方式	回滚速度	适用场景
蓝绿部署	100% 流量瞬间切换	立即（切回旧 Revision）	全量发布、紧急回滚
金丝雀发布	逐步增加新 Revision 流量（如 1% → 10% → 50% → 100%）	逐步减少新 Revision 流量	风险控制、小范围验证
A/B 测试	基于 Header/Cookie 等条件路由，而非百分比	依赖条件规则调整	功能对比、用户体验实验

实践建议： 对于生产环境，推荐优先使用 金丝雀发布 结合 自动回滚 机制。Knative 本身不提供自动回滚，但可结合 Prometheus 监控指标和 CI/CD 流水线（如 Argo Rollouts）实现。

4.3 蓝绿部署实现

蓝绿部署的核心是维护两个完全独立的环境（蓝环境 = 当前稳定版本，绿环境 = 新版本），通过一次性切换流量完成发布。

实现步骤：

创建新 Revision（绿环境），但不分配流量。
验证新 Revision 健康状态。
修改 Route 的 traffic 块，将 100% 流量指向新 Revision。
保留旧 Revision（蓝环境）作为回滚目标。

# 步骤 3：切换流量到新版本
apiVersion: serving.knative.dev/v1
kind: Route
metadata:
  name: my-service
spec:
  traffic:
    - revisionName: my-service-00002  # 新版本
      percent: 100
    - revisionName: my-service-00001  # 旧版本保留，用于回滚
      percent: 0
      tag: rollback

注意： 蓝绿部署虽然简单，但切换瞬间可能导致少量请求失败（连接耗尽问题）。建议在切换前预热新 Revision 的 Pod，并确保 activator 组件已缓存新 Revision 的路由信息。

4.4 灰度发布（金丝雀）策略

灰度发布通过逐步增加新版本的流量比例，持续观察系统指标，在确认无异常后完成全量发布。

典型灰度发布流程：

阶段 1（验证）：新 Revision 分配 1% 流量，监控错误率和延迟。
阶段 2（小范围）：流量提升至 10%，观察业务指标。
阶段 3（大范围）：流量提升至 50%，准备全量切换。
阶段 4（全量）：流量提升至 100%，清理旧 Revision。

# 阶段 2：金丝雀 10%
apiVersion: serving.knative.dev/v1
kind: Route
metadata:
  name: my-service
spec:
  traffic:
    - revisionName: my-service-00002
      percent: 10
    - revisionName: my-service-00001
      percent: 90

  自动化工具： 结合 kn CLI 或 Kubernetes Job，可以编写脚本自动调整 traffic 配置。例如：kn service update my-service --traffic my-service-00002=10。

4.5 基于标签的流量路由（A/B 测试）

Knative 支持通过 tag 为 Revision 创建独立的访问 URL，结合外部流量管理工具（如 Istio、Cilium）实现基于请求头的精细化路由。

# 为不同 Revision 打标签
spec:
  traffic:
    - revisionName: my-service-00001
      percent: 100
      tag: stable
    - revisionName: my-service-00002
      percent: 0
      tag: canary

此时，canary-my-service.default.example.com 可直接访问新版本，用于内部测试或特定用户群体验证。

4.6 流量管理架构图

下图展示了 Knative 流量管理的核心组件与请求路由路径：

4.7 流量管理最佳实践

实践项	推荐做法	避免做法
Revision 保留	保留最近 3-5 个 Revision 用于快速回滚	删除所有旧 Revision，导致无法回滚
流量验证	使用 `tag` 创建独立 URL 进行预发布验证	直接在生产流量中测试未验证的 Revision
监控集成	结合 Prometheus 监控金丝雀阶段的错误率	仅依赖手动检查日志
自动回滚	在 CI/CD 流水线中设置自动回滚阈值	手动修改 traffic 配置，增加人为失误风险

性能考量： 当流量拆分比例频繁变化时，Knative 的 activator 和 queue-proxy 组件会重新计算路由表。在 Cilium 网络环境下，建议启用 eBPF 加速 以减少路由切换带来的延迟抖动。具体配置将在第 6 章详细展开。