容器场景的更新核验差异

在主机上，安全更新最常见的错觉是“包管理器返回成功就算生效”。到了容器场景，这个错觉换了件外衣：镜像构建流水线显示通过，编排平台里副本状态是运行中，滚动更新按预期走完，界面一片绿色，但真正对外提供服务的实例，可能仍然跑在旧的镜像层上，或者跑在新镜像上却沿用着旧的配置。

核验对象从进程转到镜像

主机上要回答的是“运行中的进程有没有换到新加载的库”，容器里要回答的是“正在跑的实例对应哪一份镜像，它引用的配置和凭据又是哪一版”。前一个问题靠对比运行内核和进程映射的库文件就能接近答案，后一个问题必须落到实例的镜像标识上。标签是可变的人为约定，摘要才是不可变的事实；同一个标签在不同时间指向不同摘要，是容器更新核验中最常见的偏差来源。构建阶段装了什么包、装了什么版本，在运行阶段无法用包管理器历史回溯，只能通过镜像本身确认。

生效动作换了语义

主机上“重载”是一个独立动作，可以先测配置再平滑替换，连接不中断。容器里这个动作基本被“替换实例”覆盖：配置通常通过挂载或环境变量在启动时注入，实例起来后不会再回头读取。这意味着配置变更和镜像变更往往走同一条路径，也意味着只改配置的变更同样需要一次实例替换，而不是一次重载。反过来，凡是容器内进程被要求原地重载的场景，都要单独确认它是否真的换到了新二进制。

还有几处主机上不存在的盲区。镜像层缓存会让构建复用旧层，“重新构建了”不等于“依赖真的更新了”；多副本滚动更新期间新旧实例可能长时间共存，入口层和内部调用会打到不同版本；健康检查只能证明进程活着、端口在听，证明不了登录、写入和回调这类真实业务路径可用；数据卷、外部存储和挂载的密钥不随镜像更新，实例换了，状态可能还停在老版本上。

因此核验证据链需要重新定义：记录本次发布实际使用的镜像摘要而非标签，记录实例启动时间以确认没有旧副本残留，按真实业务入口走一遍登录、读写和定时任务，并明确回滚点是一个可复现的镜像摘要加配套配置。它们和主机上那份包清单、内核版本、服务启动时间的作用完全一致——下一次更新时，不必再去猜上次到底生效了没有。