金丝雀发布

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

常见做法

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

示例思路

# 稳定版本
labels:
  app: api
  track: stable
# 金丝雀版本
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

快速复核清单

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

实战补充

把快速入门应用到真实业务时，建议固定一套检查项：资源 requests、就绪探针、日志覆盖、告警阈值、回滚步骤。清单要短小、可重复，并随仓库一起维护，这样每次发布都能快速对齐标准。

排障路径

从现象入手，不要先猜原因。先看事件，再看日志，最后验证流量路径和配置版本是否一致。若访问异常，先确认 readiness 和 endpoints，再逐段排查入口到后端的链路。记录每一步改动，方便回滚和复盘。

小练习

在测试环境做几次常见操作：扩缩容、重启单个 Pod、调整一项配置并验证效果。通过这些小练习，你能更直观地感受到系统收敛速度和异常时的行为。

维护与责任

明确服务归属、值班人和升级窗口，准备常见故障的处理步骤。依赖服务也需要纳入监控和备份计划，确保问题出现时能快速定位和恢复。

交付提醒

发布后用用户视角快速验证一次：访问核心接口、观察延迟和错误率，确认新旧 Pod 的状态稳定。如果涉及存储或网络，顺手核对磁盘用量、DNS 和 endpoints 是否正常。

回滚预案

写下最小可行的回滚步骤，包括需要恢复的配置、镜像版本和校验方式。这样在出现异常时可以迅速还原，而不是现场临时拼步骤。

参考链接

• Deployment
• kubectl rollout
• Service