应立即回滚至稳定版本：先用kubectl get pods -l app=xxx确认异常状态，再通过kubectl rollout history查看修订记录，最后执行kubectl rollout undo或指定--to-revision回滚，并用rollout status和get rs验证生效。
当线上 Deployment 出现 CrashLoopBackOff、ImagePullBackOff 或持续不可用时，必须在分钟级内切回上一个稳定版本，避免业务中断。
确认当前 Deployment 处于异常状态
先检查 Pod 状态是否已失常：kubectl get pods -l app=【你的应用标签】。若看到大量 ContainerCreating、ErrImagePull 或 0/1 Ready，说明升级失败已发生。
再验证滚动更新是否卡住：kubectl rollout status deployment/【deployment-name】。如果命令长时间无返回或报错 “timeout”“no progress”，就该立即回滚。
查看可用的历史修订版本
执行 kubectl rollout history deployment/【deployment-name】，输出中 REVISION 列显示数字，CHANGE-CAUSE 显示操作记录（如未加 --record，则为
注意：revision 数字越大代表越新，但 revision=2 不一定比 revision=1 更稳定——它只是上次更新产生的快照。真正稳定的版本，是你上次成功运行超过 5 分钟且无报错的那个 revision。
若只看到 1 条记录，说明此前未触发过模板变更（比如只做过扩容），此时无法回滚到“上一个部署版本”，因为根本不存在另一个 revision。
执行回滚操作
方法一：直接回滚至上一版（最常用）
执行 kubectl rollout undo deployment/【deployment-name】。该命令会将 Pod 模板切回前一个 revision 对应的 ReplicaSet，并立即触发滚动更新流程。
方法二：指定回滚到某个已知稳定 revision
执行 kubectl rollout undo deployment/【deployment-name】 --to-revision=【目标revision号】。例如回滚到 revision 3：--to-revision=3。
【关键前提】：回滚操作仅还原 .spec.template 部分（镜像、环境变量、卷挂载等），而 replicas 数量、HPA 配置、Service 关联等不受影响。所以扩容后回滚，副本数仍保持扩容值。
验证回滚是否生效
第一步：观察滚动进度
kubectl rollout status deployment/【deployment-name】 —— 等待输出 “deployment 【deployment-name】 successfully rolled out”。
第二步：确认 Pod 使用的镜像已切换
kubectl get deploy/【deployment-name】 -o jsonpath='{.spec.template.spec.containers[0].image}'。
第三步：检查新旧 ReplicaSet 状态
kubectl get rs -l app=【你的应用标签】 —— 正常应看到旧 RS 的 DESIRED/CURRENT/READY 全部回升至目标副本数，新 RS 的 DESIRED 降为 0。
