就绪失败与手动回滚会留下什么

一句话总结

进度失败条件不是自动恢复命令，Deployment 回滚也不是连同外部配置和数据一起撤回的事务。

为什么需要它

新的 v3 应用进程仍在运行，端口也已开放，但 readiness 和业务路径返回 503。如果先删除旧 Pod，只留下新版本，用户就会收到错误。本实验在保留两个正常 v2 的同时，只增加一个尚未就绪的 v3，展示“快速扩展新版本”与“保护当前用户请求”发生冲突的场景。

只要服务仍在交付 v2，运维人员就能暂时喘口气。但不能假定一直等待就必然恢复。在探针正确报告失败的情况下，删除 probe 来制造绿灯也不是恢复。真正需要做的是判断应回到哪个版本和配置，并确认实际请求是否已返回该状态。

工作原理

此 Deployment 使用 2 个副本、maxSurge 1 和 maxUnavailable 0。滚动更新期间可以比期望数量多增加一个副本，但不允许更新过程任意减少现有可用副本。如果新 Pod 无法就绪，控制器可以继续保留两个正常的旧 Pod。因此，desired 为 2、实际 Pod 为 3、available 为 2 的状态完全可能。本实验使用整数设置，不能把这里的数字推广到百分比取整规则。

readiness 判断服务是否已准备好接收请求。这个合成应用的 liveness 始终正常，因此不会仅因 v3 未就绪就反复重启容器。结合读取 Pod UID、容器 ID、重启次数和直接 HTTP 响应，可以确认“正在运行但未就绪”。Service 应把请求转发给已就绪的 v2，并排除 v3。maxUnavailable 0 也不能保证抵御外部故障、节点故障或错误探针而实现绝对零停机。

progressDeadlineSeconds 是判断部署无法取得进展的时间预算。本实验为缩短观察时间使用 20 秒，但生产环境中的适当值，应根据镜像下载、应用启动、最短就绪时间等实际预算确定。超过期限后，可以观测到 Progressing 条件为 False、reason 为 ProgressDeadlineExceeded。这既不表示新版本已恢复正常，也不表示 Kubernetes 自动退回了旧模板。

出现失败条件后，还要确认 spec.template 是否仍为 v3，正常 v2 的 UID 和容器是否保持不变，新 v3 是否仍未就绪。调查最后一个正常 revision 后再手动回滚，是接下来的决策。实验选择已经观测过的 v2 revision，而不是死记最小编号或最新编号。

kubectl -n kcna-delivery rollout history deployment/web
kubectl -n kcna-delivery describe deployment web
# 조사한 정상 번호를 사용합니다. 아래 N은 그대로 실행하는 값이 아닙니다.
kubectl -n kcna-delivery rollout undo deployment/web --to-revision=N

回滚是一次返回旧模板的新变更，不要期待历史编号直接缩回过去的数字。此外，本实验可以复用仍然存在的正常 v2 ReplicaSet 和 Pod。不能由此推断所有回滚都必须创建新 Pod，也不能推断总会保留现有 Pod。实际转换取决于哪些 ReplicaSet 仍然存在，以及还有多少存活副本。

实际现场中的情况

代码回滚成功后事故仍未结束，外部状态是原因之一。本实验在部署 v3 前把 ConfigMap 改为 purple。现有 v2 进程仍保留环境变量 green，但配置对象本身已是 purple。即使把 Deployment 回滚到 v2，ConfigMap 也会保持 purple。如果因为当前响应仍是 green 就认为无事，之后产生替代 Pod 时，它可能读取 purple。因此，回滚后还必须同时调查声明的配置和运行中的配置。

数据库模式、外部服务配置、已经发送的消息，是更大的边界。Deployment 历史不会以原子方式撤回这些内容。如果滚动更新要求旧代码与新模式共存，就必须先设计兼容性。这正是需要分阶段部署“添加新列、迁移代码、删除无用列”的原因。本实验不能证明数据库迁移的安全性。

在由 GitOps 管理的生产环境中，期望的恢复状态也必须反映到 Git 声明中。只进行手动修改而保留 Git 原状，协调器可能再次应用旧声明。这里的个人 k3s 没有安装 ArgoCD，因此不能声称实际观察过 self-heal 将变更改回。我们先单独学习 Deployment 的行为边界，再在 GitOps 实验中加入期望状态的来源。

下一项实验要做什么

在正常 v2 运行后部署 readiness 失败的 v3，记录超过期限后仍未自动回滚。手动恢复到正常 revision，再确认 ConfigMap 是否仍为 purple，并另行恢复为 green。不删除策略，也不干扰正常对照组，而是比较真实响应、对象身份和配置这三类证据。

官方依据：Deployment 的回滚与进度条件 · ConfigMap 的消费方式。