金丝雀发布的重点从来不只是 YAML，而是把发布风险拆小。你先让新版本吃一小部分真实流量，观察指标，再决定是继续放量还是快速回滚。它的价值就在于：出问题时，先坏一小块，而不是先坏全量。

金丝雀发布的核心思路

  • 保持一个已知稳定的版本继续服务
  • 额外起一个规模更小的 canary 版本
  • 只给 canary 一部分流量
  • 观察真实指标和日志
  • 决定继续放量还是回滚

这是一种非常务实的降低发布爆炸半径的方式。

一个简单的标签思路

# stable Deployment 模板
template:
  metadata:
    labels:
      app: api
      track: stable

---

# canary Deployment 模板
template:
  metadata:
    labels:
      app: api
      track: canary

这个标签拆分很重要，因为它让路由层能清楚地区分稳定版本和灰度版本。

金丝雀发布依赖什么前提

如果这些基础没打稳，canary 很容易变成“更慢但并不更安全的发布”：

  • Deployment rollout 行为可预测
  • probes 能真实反映可用性
  • 指标能区分新旧版本
  • 回滚路径足够清晰和快速

所以这篇和下面几篇是天然连着看的：

  • kubernetes-quickstart-deployment-replicaset.md
  • kubernetes-quickstart-probes.md
  • kubernetes-quickstart-declarative-config.md

常见的流量切分方式

没有哪一种方式适合所有团队，常见做法包括：

  • Ingress 权重路由
  • Service Mesh 流量拆分
  • 外部负载均衡规则
  • 小环境里用副本比例近似模拟

流量控制越精细，你对 canary 的评估通常也会越真实。

发布前一定要先定好的东西

别等 canary 跑起来才临时讨论“到底算成功还是失败”。至少先明确：

  • 什么算成功
  • 什么算失败
  • 观察窗口有多长
  • 哪些指标最重要
  • 谁来决定推进或回滚

没有这些，所谓的 canary 很容易退化成“慢一点的盲发版”。

最值得看的指标

  • 错误率
  • 延迟
  • 饱和度
  • 业务指标
  • 按版本切分的日志异常

关键不在于看更多图，而在于大家提前说清楚：到底哪几条信号真正决定这次发布该不该继续。

最危险的兼容性问题

真正难的灰度，很多时候不是“代码逻辑变了”，而是：

  • 数据结构变了
  • 协议不兼容了
  • 配置假设变了
  • cache key / schema 变了

如果新旧版本不能安全共存，那灰度本身就会变得很危险。

一套很实用的灰度节奏

  1. 先确认稳定版本当前是健康的
  2. 部署少量 canary 副本
  3. 给它一小部分真实流量
  4. 按固定观察窗口看指标
  5. 达标就放量，不达标就快速回滚

越短、越无聊、越可重复的流程，通常越靠谱。

FAQ

Q: 没有 Service Mesh，还能做 canary 吗？ A: 可以。虽然没有精细流量控制会差一些，但通过双 Deployment、基础路由和清晰监控，仍然能做出有价值的灰度验证。

Q: 做 canary 最容易犯的错是什么？ A: 在没有明确成功信号、也没有按版本拆分可观测数据的情况下就放量。

Q: 什么场景不太适合 canary？ A: 当新旧版本无法兼容共存，或者流量和指标根本没法拆分时，canary 的价值会明显下降。

下一步阅读

  • 接着读 kubernetes-quickstart-deployment-replicaset.md，理解 rollout 基础
  • 再读 kubernetes-quickstart-probes.md，因为 readiness 配不好会直接毁掉 canary
  • 回头看 kubernetes-quickstart-declarative-config.md，保证发布状态可审阅、可回滚

收个尾

金丝雀发布真正的价值，不是让发布看起来更高级，而是让失败更小、回滚更快。把它理解成“给发布加刹车”，很多判断反而会更简单。

参考链接