第 9 章　升级、回滚与配置更新

先区分三种改变

修改 Deployment 的 Pod 模板，例如镜像或探针，会触发新的滚动发布。只修改副本数是扩缩容，不会生成同样意义上的新模板版本。只修改外部 ConfigMap 内容，也不会自动产生 Deployment 的新模板修订。

本章不依赖另一个真实镜像版本，而是故意填错镜像标签，观察一次失败更新，然后恢复。务必先确认当前两个 Pod 均就绪。

kubectl rollout history deployment/hello-web -n k8s-book
kubectl set image deployment/hello-web -n k8s-book \
  web=nginx:this-tag-does-not-exist-k8s-book
kubectl rollout status deployment/hello-web -n k8s-book --timeout=45s
kubectl get pods -n k8s-book

预期更新超时，新 Pod 可能显示 ErrImagePull 或 ImagePullBackOff。因为设置了 maxUnavailable: 0 与 maxSurge: 1，且旧副本仍健康、集群资源足够，旧版本应继续服务。这是演示条件下的行为，不是对所有故障零中断的保证。

恢复到上一版

kubectl rollout undo deployment/hello-web -n k8s-book
kubectl rollout status deployment/hello-web -n k8s-book --timeout=120s
kubectl get pods -n k8s-book

undo 恢复之前的 Pod 模板。它不会撤销数据库迁移，也不会把 ConfigMap、Secret 或 PVC 一起恢复。因此“能够回滚镜像”不能等同于“整个系统能够回到过去”。长期管理应让 Git 中的声明文件也与目标版本一致。

修改网页

将 configmap.yaml 中的欢迎语改成“我完成了第一次配置更新”，然后：

kubectl apply -n k8s-book -f configmap.yaml
kubectl rollout restart deployment/hello-web -n k8s-book
kubectl rollout status deployment/hello-web -n k8s-book --timeout=120s

重新启动端口转发并刷新浏览器。rollout restart 通过修改 Pod 模板注解触发滚动重建。此处用它来得到清晰、可预期的练习结果；大型系统通常会使用配置版本化、校验和注解或应用热加载机制。

本章自测：为什么更新 ConfigMap 不等于产生新镜像版本？Deployment 回滚能恢复昨天的数据库数据吗？