Deployment回滚本质是切换ReplicaSet而非重装旧配置；默认回滚至上一版本RS，--to-revision可指定目标；需用--record记录变更原因；回滚成功需验证镜像、RS状态及Pod运行情况。
回滚本质是切换 ReplicaSet，不是“重装旧配置”
Deployment 回滚不是把旧 YAML 文件重新 apply 一遍，而是让控制器把 replicas 流量切回到上一个（或指定）的 ReplicaSet。每个修订版本（REVISION）背后都对应一个独立的 RS，它锁定了当时的 Pod 模板（镜像、环境变量、标签等）。只要该 RS 还在（没被自动清理），就能秒级回退。
kubectl rollout undo 的实际行为和关键参数
执行 kubectl rollout undo deployment/ 时，默认回滚到 REVISION 值倒数第二高的版本（即上一版），但前提是那个 RS 仍存在且未被 GC。真正决定回滚目标的是 --to-revision 参数：
- 不加
--to-revision：回滚到历史记录中 revision 编号最大的前一个（例如当前是 5，就回 4） -
--to-revision=2：强制跳转到 revision 2 对应的 RS，哪怕中间有 3、4 两个失败版本 - revision 编号不等于“第几次部署”，而是 Deployment 控制器内部按顺序分配的整数，从 1 开始递增
为什么 rollout history 显示
默认情况下，kubectl rollout history 的 CHANGE-CAUSE 列显示
解决办法是在每次 kubectl apply 或 kubectl set image 时加上 --record 标志：
kubectl set image deploy nginx-test nginx=nginx:v2.0 --record
这样 CHANGE-CAUSE 就会存入命令本身，比如 kubectl set image deploy nginx-test nginx=nginx:v2.0 --record。注意：--record 只记录命令文本，不记录文件内容或 Git 提交 ID——如需更完整溯源，得靠 CI/CD 工具注入 annotations。
回滚失败的三个常见原因及验证方式
回滚命令返回 “rolled back” 并不等于服务已恢复。必须验证三件事：
-
kubectl get deploy -o yaml | grep -A5 "image:"：确认 Pod 模板里的image字段已变回目标版本 -
kubectl get rs：检查旧 RS 的CURRENT数是否上升、新 RS 的CURRENT是否归零（或开始缩容） -
kubectl get pods -l app=：观察新旧 Pod 的 AGE 和 STATUS，确保旧镜像 Pod 正在 Running，且没有卡在ImagePullBackOff或CrashLoopBackOff（旧镜像可能已被删库或权限失效）
最容易被忽略的一点：revisionHistoryLimit 默认是 10，但如果你长期没清理，或者设得太小（比如 2），老 RS 可能早被自动删除，此时 --to-revision=1 就会报错 “revision not found”。回滚前先看 kubectl rollout history 输出的 revision 范围，比盲目执行更可靠。
