金丝雀发布

金丝雀发布的目标是：让新版本先接一小部分流量，验证稳定后再扩大比例。

常见做法

• 两个 Deployment：track=stable 与 track=canary
• Service 先指向 stable，再逐步引入 canary
• 结合指标与日志判断是否放量

示例思路

# stable 版本（在 Deployment 模板里）
template:
  metadata:
    labels:
      app: api
      track: stable

---

# canary 版本（另一个 Deployment）
template:
  metadata:
    labels:
      app: api
      track: canary

发布节奏

1. 先让 canary 运行起来
2. 小流量验证（或灰度用户）
3. 观察错误率与延迟
4. 扩大比例，必要时回滚

常见坑

• 指标没有看清楚就放量
• 没有单独的监控维度区分版本

实操要点

• 先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
• 对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
• 名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

• 资源定义与业务意图一致。
• Namespace、权限、镜像与环境匹配。
• 上线前具备健康探针与可观测日志。

灰度发布是可控风险

灰度发布通过小流量验证新版本，避免一次性影响全部用户。灰度发布 的重点不是 YAML，而是观察与决策：你要定义指标阈值，并在异常时快速回滚。

基线与灰度对象

基线代表当前稳定版本，灰度版本只差镜像或配置。通过标签区分两者，并保证路由层可以单独指向灰度。灰度规模要小但具代表性，避免只在边缘样本上验证。

流量切分方式

可以使用 Ingress 权重、服务网格或双 Service 方式分流。如果没有网格，也可以通过控制灰度副本数量近似分流，并结合指标观察趋势。关键是让灰度有足够真实流量。

指标与护栏

在发布前定义成功指标，如错误率、延迟、饱和度与业务指标。设定明确阈值和观察窗口。触发阈值后应果断回滚，灰度的价值来自于对护栏的尊重。

回滚与清理

回滚要快，保持旧镜像可用，避免需要前向迁移的数据库变更。灰度成功后清理旧 ReplicaSet 和临时路由规则，保证历史清爽便于排障。

数据兼容性

涉及协议或数据格式时风险最高，应采用向后兼容读写或双写策略。如果必须破坏兼容性，需要协调切换窗口并提前沟通。

分步发布流程

先建立基线指标，再部署少量灰度副本，接入小比例流量并等待观察窗口。如果指标稳定，再逐步扩大流量；若指标回退，立即回滚并记录原因。

功能开关配合

灰度阶段可结合功能开关，降低新功能影响面。配置与代码应保持版本同步，避免因配置差异导致误判。

metadata:
  labels:
    app: demo-api
    track: canary

快速复核清单

确认基线稳定、指标看板就绪、回滚路径明确，再启动灰度。小步验证比一次性上线更安全。

收个尾：灰度不是“更复杂”，而是“更可控”

灰度最重要的不是写更多 YAML，而是把风险拆小：

• 每次只放一点流量
• 指标不对就立刻停（别硬扛）
• 回滚路径要随时能执行（不要等出事才想怎么回去）

你把灰度当成“带刹车的发布”，而不是“更花哨的发布”，很多决策反而会简单。

参考链接

• Deployment
• kubectl rollout
• Service