第 4 章 · 滚动升级与回滚
本章目标：掌握 Kubernetes RollingUpdate、三类探针、PodDisruptionBudget 与数据库协同顺序；在 demo-mall prod 实现 15 分钟内回滚 SLA；能在小紫 应用部署 → 升级历史 完成 undo。
学时建议：2～2.5 小时（含 1.5 小时跟练）
前置：ops-deploy ch03 产出镜像；小紫云计算 · 应用部署；ch02 配置外置。
4.1 场景说明
| 项目 | 内容 |
|---|---|
| 背景 | demo-api 1.4.2 稳定运行 prod；发布 1.4.3 后 5xx 升高 |
| 你的角色 | 发布执行人 + 复核人，需在变更窗口内完成升级或回滚 |
| 本章任务 | 配置滚动策略与探针；完成一次升级；模拟错误镜像 5 分钟内回滚 |
| 约束 | prod maxUnavailable: 0；readiness 不得深度依赖下游 DB（防雪崩） |
| 成功标准 | MTTR < 15min；变更单含预写回滚命令 |
滚动 vs 蓝绿/金丝雀：本章是日常默认策略；高级策略见 ch09。
4.2 学完你能
| 能力 | 验收标准 |
|---|---|
| 解释 RollingUpdate | 说清 maxSurge / maxUnavailable 对可用性的影响 |
| 配置三类探针 | liveness / readiness / startup 各写一段 YAML |
| 执行回滚 | CLI 与 应用部署 → 升级历史 → 回滚 两种方式 |
| 变更窗口 | 填写 T-1 与 T+15min 检查清单 |
| DB 协同 | 说出加列/删列/不可逆迁移的发布顺序 |
| PDB | 解释 minAvailable 对节点维护的意义 |
4.3 滚动升级原理
v1 Pod ──► v2 Ready ──► 流量切换 ──► 摘除 v1 ──► 全量 v2Deployment 策略片段：
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # 升级期最多额外 1 个 Pod（或 25%）
maxUnavailable: 0 # 不允许可用副本减少
minReadySeconds: 15 # Ready 后再等 15s 才计为 Available
revisionHistoryLimit: 10| 参数 | 生产推荐 | 说明 |
|---|---|---|
| maxSurge | 25% 或 1 | 升级期额外 Pod，加快替换 |
| maxUnavailable | 0 | 大促保证可用副本不减少 |
| minReadySeconds | 10～30 | 防止就绪抖动立即接流量 |
| progressDeadlineSeconds | 600 | 超时标记 ProgressDeadlineExceeded |
你应该看到：kubectl rollout status deployment/demo-api -n prod-app 输出 successfully rolled out。
4.4 逐步跟练 · 第一步：配置健康检查（约 30 分钟）
在 应用部署 → demo-api → 编辑 YAML 加入：
containers:
- name: api
livenessProbe:
httpGet: { path: /healthz, port: 8080 }
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet: { path: /ready, port: 8080 }
periodSeconds: 5
failureThreshold: 3
startupProbe:
httpGet: { path: /healthz, port: 8080 }
failureThreshold: 30
periodSeconds: 10| 探针 | 失败后果 | 典型误配 |
|---|---|---|
| readiness | 不接 Service 流量 | path 查 DB 导致全 Pod Not Ready |
| liveness | kubelet 重启容器 | initialDelay 过短 → 重启风暴 |
| startup | 慢启动保护 | 未配时 liveness 误杀 Java/Go 冷启动 |
原则：readiness 只检查本进程可服务；深度依赖检查放 /ready-deep 且仅 staging 启用。
你应该看到：新 Pod 先 startup 通过 → readiness True → 旧 Pod 终止；系统容器 无频繁 Restart。
4.5 逐步跟练 · 第二步：正常滚动升级（约 25 分钟）
场景：prod 从 1.4.2 → 1.4.3（staging 已验证同 tag）。
步骤 1 — 变更单 T-1
- 备份（ch11）、回滚命令写入变更单
- 运维 → 监控告警 打开 demo-api Dashboard
步骤 2 — 更新镜像
kubectl set image deployment/demo-api \
demo-api=registry.devops.svc:5000/demo-api:143-b7e2a01 -n prod-app
kubectl rollout status deployment/demo-api -n prod-app --timeout=600s或 应用部署 → 升级 → 选择新 tag。
步骤 3 — T+15min 观察
- 5xx 率无突增；P99 无翻倍；抽样下单 3 笔
你应该看到：ReplicaSet 新旧交替；Events 无 FailedMount；Grafana 发布标注线可对齐变更时间（ch07）。
4.6 逐步跟练 · 第三步：错误发布与回滚（约 30 分钟）
注入：部署已知坏镜像 demo-api:broken（或错误启动命令）。
步骤 1 — 发现