rollout undo 是什么
Kubernetes 内置回滚手段：把 Deployment 回退到上一次或指定的修订版本。前提是修订历史仍然保留（由 revisionHistoryLimit 控制，默认 10 个），且目标版本的镜像仍能从仓库拉取。命令只恢复 Pod 模板，不负责处理数据库结构、配置等外部状态的兼容。
基本信息
| 相关命令 | kubectl rollout history / undo / status / restart |
|---|---|
| 回退目标 | 默认上一个版本，--to-revision=N 指定某个修订 |
| 历史保留 | revisionHistoryLimit 默认 10 |
| 查看历史 | kubectl rollout history deploy/NAME --revision=N 看差异 |
| 收敛确认 | kubectl rollout status 观察新副本就绪 |
典型使用场景
- 发布后指标恶化：快速切回上一版本恢复服务。
- 灰度验证失败：回退到验证通过的稳定修订。
- 误改镜像或副本数：撤销被 rollout 记录的变更。
- 审计核对：查看每个修订对应的镜像与提交时间。
- 滚动重启：rollout restart 触发重启但会生成新修订，注意与回滚区分。
常用回滚操作
常用回滚操作
kubectl rollout history deploy/web -n prod
kubectl rollout undo deploy/web -n prod
kubectl rollout undo deploy/web --to-revision=3 -n prod
kubectl rollout status deploy/web -n prod # 确认收敛子命令对照
| 命令 | 作用 | 注意 |
|---|---|---|
| history | 列出修订列表 | 默认只显示镜像摘要 |
| undo | 回退到指定修订 | 默认回退上一个 |
| status | 等待滚动完成 | 观察新副本就绪情况 |
| restart | 滚动重启 | 生成新修订、不等于回滚 |
rollout undo 依赖修订历史：若曾用 kubectl set image 多次直接改动，修订含义要先核对。
回滚只恢复 Pod 模板：ConfigMap、Secret、数据库结构等外部状态不会随回滚变化，要单独处理。
回滚完成后验证业务指标：Pod 就绪只说明进程起来，不代表功能正常。
修订从哪来
| 生成时机 | 修改 Pod 模板即生成新修订（镜像、环境变量、资源等） |
|---|---|
| 记录原因 | 变更原因写在 change-cause 注解里 |
| 数量上限 | 由 revisionHistoryLimit 控制，默认 10 |
排查要点
- 回滚前看 history --revision=N：确认目标修订的镜像与原因。
- 回滚后看 rollout status：同时确认新副本就绪与旧副本下线。
- 发布审计：change-cause 注解记录每次变更原因，历史才有可读性。
为每次发布写变更原因：kubectl annotate deploy/web kubernetes.io/change-cause="release v1.4.2"，history 列表里能看到备注，回滚选版不用靠猜。