部署命令成功不等于新版本成功

一句话总结

API 接受新声明、控制器观测到该声明、新进程开始处理请求，是三种彼此不同的证据。

为什么需要它

周五下午，新版本部署命令成功执行，Deployment 的 AVAILABLE 也是 2，但用户仍然看到旧页面。既然部署成功，能否断定是浏览器缓存问题？还不能。可能是两个正常的旧 Pod 仍在处理请求，而一个尚未就绪的新 Pod 正在旁边失败。可用性得以维持固然是好事，但仅凭这一点无法证明新版本已经交付。

云原生交付并不止于把源代码移成文件。它是这样一条流程：声明要运行什么，把声明转化为实际进程，观察进程是否已准备好接收请求，并在失败时决定回到哪个状态。CI 侧重于集成和测试变更，持续交付侧重于保持随时可部署的状态；它也不同于把每项变更自动发布到生产环境的持续部署。Git 中存在提交，只是其中部分过程的记录，并非用户响应的证据。

工作原理

Deployment 声明所需的 Pod 模板和副本数。Deployment 控制器创建或调整 ReplicaSet，ReplicaSet 维持所需 Pod。kubelet 运行容器，readiness 报告就绪状态后，Service 的转发目标也会反映该状态。不同组件分别收敛，因此不能把一次 API 响应理解为整个工作已经完成。

调查时，要看对象之间的连接关系，而不是只看名称。沿着 Deployment UID，找到将其指为所有者的 ReplicaSet UID，再找到将该 ReplicaSet 指为所有者的 Pod UID。这样就不会把人工创建的同名 Pod 误认为真实滚动发布的结果。新版本是否启动，应通过容器状态和就绪条件确认；实际交付的是哪个版本，则应另外通过真实响应确认。

Deployment 的 generation 表示声明变更的世代，status.observedGeneration 用于比较控制器已观测的世代。即使两者相同，也不表示新版本已全部就绪。updatedReplicas 表示符合新模板的副本，availableReplicas 表示满足可用条件的副本。必须结合这些值、条件和真实响应判断是否完成。尤其在滚动发布期间，可用副本中可能包含旧版本。

kubectl -n kcna-delivery get deployment web -o yaml
kubectl -n kcna-delivery get replicasets
kubectl -n kcna-delivery get pods -l app=web
kubectl -n kcna-delivery get endpointslices

并非所有变更都会创建新 ReplicaSet。修改 Deployment 对象自身用于说明的 annotation，与修改 spec.template 中的环境变量，位置并不相同。本实验先只修改对象 annotation，确认现有 Pod、ReplicaSet 和 revision 是否保持不变；之后把模板中的 RELEASE 从 v1 改为 v2，比较新 ReplicaSet 和新 Pod 是否出现。重点不在于是否使用同一个 kubectl 发起请求，而在于修改了声明的哪个部分。

配置也是独立边界。ConfigMap 是保存非秘密配置数据的对象。本实验把 color 值注入容器环境变量。即使把 ConfigMap 的 blue 改为 green，已运行进程的环境变量也不会自动重新读取。ConfigMap API 中可能已经是 green，响应却仍然是 blue。不要把这种现象断定为数据丢失，应确认配置在何时、以何种方式被消费。通过文件卷投射配置，或由应用直接读取 API，与注入环境变量的更新规则并不相同，不能一概而论。

实际现场中的情况

如果把部署状态页面上的一个绿灯混合解释为多种含义，应对措施也会走错方向。GitOps 同步可以说明期望声明与集群声明一致，但新应用的业务请求是否成功还需单独验证。镜像标签也一样：不能因为可变标签字符串相同，就保证运行的是相同字节。本实验固定镜像 digest，仅修改小型合成应用的发布环境变量；它不是构建真实新镜像或验证供应链签名的实验。

生产环境还必须确认新版本标识、错误率、延迟以及必要的业务路径。本实验读取六次 HTTP 响应，只是用于比较课堂中的状态样本，并非在统计意义上保证零停机或服务级别目标。保留正常对照组，也是为了区分范围，不能把实验对象的声明变化与整个集群故障视为同一原因。

后续实验要做什么

以返回 v1、blue 的基线开始，只修改 annotation，再只把 ConfigMap 改为 green，并分别比较 Pod 身份。然后真正滚动发布 v2 模板，确认新 Pod 的响应是否变为 green。下一篇理论将说明，当无法就绪的 v3 被部署时，如何守住现有响应并确定恢复边界。

官方依据：Deployment · ConfigMap。