发布回滚：坏镜像与 rollout undo

本场景建立在 examples/minimal-loop/ 之上，不引入 Ingress 或 Helm。先保证 web 健康，再故意 set 一个不存在的 tag，让新副本卡在 ImagePullBackOff；此时 rollout status 会长时间不成功，get pods 能看到旧副本与坏副本并存或 READY 残缺。应急动作不是 delete 整个 Deployment，而是 kubectl rollout undo，让控制器把 Pod 模板拨回上一 revision。history 让你看见「回得到哪里」，status 让你确认「已经回到可用」。

# 健康基线
kubectl apply -f examples/minimal-loop/
kubectl rollout status deploy/web

# 故意坏镜像
kubectl set image deploy/web nginx=nginx:does-not-exist-xyz
kubectl get pods -l app=web
kubectl describe pod -l app=web | grep -A5 -i 'Failed\|pull\|BackOff'

# 回滚并确认
kubectl rollout undo deploy/web
kubectl rollout status deploy/web
kubectl rollout history deploy/web

读 status 输出时，关注的是「新 ReplicaSet 是否可用」，不是某一次 curl 碰巧成功。坏镜像场景里，旧 Pod 可能仍在服务流量，表面上「网站还开着」，但副本数与期望已经偏离，下一次节点抖动或缩容就可能把最后一点健康副本打穿。undo 的价值是把期望状态整体拨回已知好版本，而不是手动删掉几个 ErrImagePull 的 Pod 碰运气——删了坏 Pod，控制器仍会按当前（错误的）模板再拉同样坏的副本。

要点

回滚不是认输，而是把「服务恢复」排在「根因分析」前面——revision 就是你买下的后悔药。

做完坏镜像 → undo 之后，你可以加一刀可选练习：kubectl scale deploy/web --replicas=3，在滚动过程中盯 READY 变化，体会 maxUnavailable 对容量的影响。中阶验收标准很具体：能独立完成一次「错误发版的可观测失败 + 一条命令恢复」，并能向同事口述 status / history / undo 各自回答什么问题。