灰度发布基础：概念与部署策略对比
灰度发布（Gray Release / Canary Release）是云原生环境下降低发布风险的核心手段。其本质是让新版本逐步接管生产流量，在验证稳定后再全量上线。本章从概念出发，系统对比金丝雀发布、蓝绿部署、滚动更新三种主流策略的适用场景与运维留痕要点。
核心认知：灰度发布不是单一技术，而是一套流量治理 + 版本管理 + 可观测性的组合实践。GitOps 声明式模型天然适合灰度批次管理，因为每次流量切分都可以通过清单变更留痕。
2.1 灰度发布核心概念
灰度发布包含三个关键要素：
- 灰度批次（Batch）：将目标实例划分为若干批次，每批次承载一定比例的流量。
- 流量权重（Weight）：通过负载均衡或服务网格控制新旧版本之间的流量分配比例。
- 观测窗口（Observation Window）：每批次发布后等待的时间，用于收集指标、日志、告警，判断是否继续下一批次。
| 要素 | 说明 | 运维留痕字段示例 |
|---|---|---|
| 灰度批次 | 实例分批数量与每批大小 | batch.size: 2 batch.total: 5 |
| 流量权重 | 新旧版本流量比例 | canary.weight: 10% |
| 观测窗口 | 每批次等待时间或健康检查条件 | observation.window: 5m |
| 回滚条件 | 触发自动回滚的指标阈值 | rollback.on.error_rate > 1% |
GitOps 留痕要点：灰度批次参数必须写入 Git 仓库的 Application 或 Rollout 资源清单中，每次批次推进都对应一次 Git Commit，形成不可篡改的发布审计链。
2.2 三种主流灰度策略对比
金丝雀发布、蓝绿部署、滚动更新是生产环境最常用的三种策略。下表从流量切换方式、资源消耗、回滚速度、适用场景四个维度进行对比。
| 对比维度 | 金丝雀发布 | 蓝绿部署 | 滚动更新 |
|---|---|---|---|
| 流量切换方式 | 渐进式权重调整 | 一次性全量切换 | 逐实例替换 |
| 资源消耗 | 低（复用旧实例） | 高（需双倍资源） | 低（原地替换） |
| 回滚速度 | 快（权重归零） | 极快（切回蓝环境） | 慢（逐实例回滚） |
| 适用场景 | 功能验证、A/B 测试 | 重大版本、数据库迁移 | 常规补丁、无状态服务 |
| 运维留痕复杂度 | 中（需记录权重变化） | 低（记录环境切换） | 高（需记录每实例状态） |
2.3 金丝雀发布详解
金丝雀发布（Canary Release）是最灵活的灰度策略。新版本先部署到少量实例（金丝雀），验证通过后逐步扩大流量比例，直至全量。
常见误区：金丝雀发布不等于“只部署一台实例”。生产环境建议金丝雀批次至少包含 2 个实例，避免单点故障导致误判。同时，金丝雀批次应承载真实用户流量，而非仅内部测试流量。
2.4 蓝绿部署详解
蓝绿部署（Blue-Green Deployment）维护两套独立环境：蓝环境（当前生产）和绿环境（新版本）。验证通过后，通过负载均衡一次性将流量从蓝切到绿。
GitOps 留痕实践：蓝绿部署在 Git 仓库中通常维护两套 Kustomize Overlay 或 Helm Values 文件（
overlays/blue 和 overlays/green）。切换时只需修改 Ingress 或 Service 的 selector 指向目标环境，提交后 ArgoCD 自动同步。
2.5 滚动更新详解
滚动更新（Rolling Update）是 Kubernetes 默认的更新策略。它逐个或逐批替换旧版本 Pod，始终保持可用实例数量不低于设定阈值。
| 参数 | 说明 | 典型值 |
|---|---|---|
maxSurge |
更新期间允许超出期望副本数的最大 Pod 数量 | 25% 或 1 |
maxUnavailable |
更新期间允许不可用的最大 Pod 数量 | 25% 或 0 |
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2 # 最多额外创建 2 个 Pod
maxUnavailable: 1 # 最多允许 1 个 Pod 不可用
template:
spec:
containers:
- name: app
image: my-app:2.0.0
滚动更新局限：滚动更新无法精细控制流量比例，新 Pod 就绪后立即接收流量。对于需要灰度验证的场景，建议使用 Argo Rollouts 或 Flagger 等渐进式交付工具，它们支持基于权重的金丝雀发布和自动回滚。
2.6 策略选型决策树
根据团队成熟度和业务场景，可按以下逻辑选择灰度策略：
- 无状态服务 + 常规发布 → 滚动更新（K8s 原生，零额外成本）
- 需要流量验证 + 快速回滚 → 金丝雀发布（Argo Rollouts / Flagger）
- 重大版本 + 数据库变更 → 蓝绿部署（双环境隔离，回滚最快）
- 多版本 A/B 测试 → 金丝雀发布 + 流量镜像（服务网格）