双 Deployment 金丝雀是什么
不引入额外组件的最小可用方案：新旧版本各一个 Deployment、共享标签由同一 Service 承接，用副本数近似控制流量比例。适合快速放量验证；需要精确权重、按 header 分流或自动分析时，换带路由能力的方案。核心权衡是用简单换精确：以最小的操作成本获得灰度能力，接受比例误差与手动节奏。
基本信息
| 做法 | 两个 Deployment 相同 pod 标签，Service 按标签选全部 Pod |
|---|---|
| 流量比例 | 近似 = 新副本数/总副本数 |
| 放量操作 | kubectl scale 调整副本 |
| 局限 | 比例不精确；无法按请求或用户维度控制 |
与路由型方案对比
| 方案 | 流量控制 | 适用 |
|---|---|---|
| 双 Deployment + Service | 按副本数近似 | 快速验证、无额外组件 |
| Ingress/网关金丝雀 | 按权重、header | 精确比例、定向验证 |
| Argo Rollouts 等 | 权重加指标自动分析 | 自动化渐进交付 |
典型使用场景
- 快速验证新版本：灰度 1 个副本承接真实流量，看指标再决定
- 发布演练：没有网关或网格能力时用最小手段获得灰度能力
- 回退路径简单：把新版本缩容到 0 即完成回退
- 效果对比：新旧版本并存，直接对比各自日志与指标
- 临时验证假设：怀疑配置问题时用少量副本先跑
- 资源预演：新版本先在真实流量下小规模运行，对比内存与连接数与压测是否一致
- 版本对比排查：怀疑回归时把旧版本副本调多，快速确认问题归因
按副本放量
按副本放量
# 初始 1:9，观察错误率与延迟
kubectl scale deployment/web-v2 --replicas=1 # 约 10%
# 放量到约 50%
kubectl scale deployment/web-v2 --replicas=5 # 约 50%
# 全量切换后下线旧版本
kubectl scale deployment/web-v1 --replicas=0
# 核对两版本实际就绪副本
kubectl get pods -l app=web -o wide要求精确权重、按 header 分流或自动分析时，改用 Ingress canary、网格或 Argo Rollouts 等带路由能力的方案。
标签策略要克制：只共享 Service 选择器需要的标签，避免把版本标签混进选择器导致流量范围失控。
副本比例不等于流量比例：长连接场景按连接建立时刻分配，分布失真更大，用连接数指标交叉核对。