这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 Kubernetes 支持声明式发布，但稳定发布依赖镜像不可变、探针合理、策略清晰和回滚预案。
20.1 Deployment 更新
kubectl set image deployment/order-service \
app=registry.example.com/shop/order-service:1.3.0
kubectl rollout status deployment/order-service
历史：
kubectl rollout history deployment/order-service
回滚：
kubectl rollout undo deployment/order-service
kubectl rollout undo deployment/order-service --to-revision=3
20.2 滚动策略
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
| 参数 | 含义 |
|---|---|
| maxUnavailable | 更新时最多不可用副本数 |
| maxSurge | 最多临时超出期望副本数 |
0 / 1 更稳但速度较慢；1 / 0 快但可能短暂降容量。
20.3 发布前检查
1. 镜像 tag 不可变
2. 数据库迁移兼容新旧版本
3. 配置和 Secret 就绪
4. 资源 requests / limits 足够
5. 探针正确
6. 日志指标可见
7. 服务依赖可用
8. 回滚预案明确
20.4 数据库变更
推荐 expand / migrate / contract：
第一阶段：新增兼容字段和表
第二阶段：双写或迁移数据
第三阶段：应用切换新逻辑
第四阶段：确认稳定后删除旧结构
不要让新旧应用依赖不兼容的表结构。
20.5 流量发布策略
| 策略 | 特点 |
|---|---|
| Rolling | 默认，逐批替换 |
| Blue/Green | 双环境切换 |
| Canary | 小流量验证 |
| A/B | 按用户特征分流 |
| Feature Flag | 业务逻辑开关 |
简单服务用 Deployment 滚动；核心链路可叠加网关灰度和监控自动回滚。
20.6 发布失败判断
观察：
- rollout 状态；
- Pod ready 数；
- HTTP 5xx；
- P95/P99 延迟；
- 核心业务成功率；
- 日志错误；
- 依赖资源指标。
本章小结
发布是版本、配置、数据、流量和观测的组合动作。Kubernetes 提供滚动和回滚能力，业务稳定性还需要兼容性设计、灰度和自动判断。
思考题
- maxSurge 和 maxUnavailable 如何权衡？
- 为什么镜像 tag 要不可变？
- 数据库兼容发布如何设计？
- 金丝雀发布观察哪些指标？
- 回滚是否总是能解决数据结构问题？