金丝雀发布
用小流量验证新版本，再逐步扩大。
金丝雀发布的目标是：让新版本先接一小部分流量，验证稳定后再扩大比例。
常见做法
- 两个 Deployment：
track=stable与track=canary - Service 先指向 stable，再逐步引入 canary
- 结合指标与日志判断是否放量
示例思路
# 稳定版本
labels:
app: api
track: stable
# 金丝雀版本
labels:
app: api
track: canary
发布节奏
- 先让 canary 运行起来
- 小流量验证（或灰度用户）
- 观察错误率与延迟
- 扩大比例，必要时回滚
常见坑
- 指标没有看清楚就放量
- 没有单独的监控维度区分版本
实操要点
- 先做快速盘点：
kubectl get nodes、kubectl get pods -A、kubectl get events -A。 - 对比“期望状态”和“实际状态”，
kubectl describe往往能解释漂移或失败原因。 - 名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。
快速检查清单
- 资源定义与业务意图一致。
- Namespace、权限、镜像与环境匹配。
- 上线前具备健康探针与可观测日志。