配置变了，进程为何没有变化
一句话总结
不仅要知道配置存储在哪里，还必须知道 process 何时消费该配置，才能确认恢复完成。
为什么需要它
发现了导致业务路径返回 500 的配置，在 Git 中改成 200 后，Argo CD 也已经 Synced 到新 commit。通过 Kubernetes API 读取 ConfigMap，可以明确看到新值，但 curl 仍持续收到 500。此时若认为“GitOps 不听话”而删除 Pod，问题可能暂时消失；但如果没有理解配置经过什么过程传递给 process，下一次变更还会重复同一故障。应先拆分 source、已传递文件和运行中 process 这三个层次。
工作原理
ConfigMap 是存储在 Kubernetes API 中的配置数据。根据消费方式不同，更新行为也不同。通过 environment variable 注入的值，不会自动替换现有 process 的 environment。通过普通 volume 投射的文件可以更新，但传播可能需要时间；即使文件已经变化，应用是否重新读取也是另一件事。特别是本实验中通过 subPath 挂载单个文件的 container，不会收到 ConfigMap 后续更新。如果忽略消费方式，只记住“ConfigMap 会自动更新”，就会在本实验中直接答错。请参阅官方 ConfigMap 更新条件。
该 Deployment 通过 subPath 把 nginx.conf 单个文件挂载到 /etc/nginx/nginx.conf。第一次 config commit 只修正 ConfigMap 中的 nginx.conf，保留 Deployment spec.template 不变，因此没有理由创建新 Pod。原有 Pod UID 与 container 仍然存在，container 内读取的文件也是旧值，HTTP response 仍为 500。这不是仅凭“cache 太慢”的猜测，而是通过文件和 identity 对照确认的 delivery boundary。盲目增加 sleep 时间并不会改变这种消费方式。
第二次 commit 计算新配置字节的 SHA-256，并写入 Pod template 的 checksum/config annotation。该 annotation 名称并没有 Kubernetes 内置魔法，它只是一项惯例：通过改变 spec.template 的值，让 Deployment 创建新的 ReplicaSet 与 Pod。如果只把 checksum 添加到 Deployment 顶层 metadata，template 没有变化，就不会产生同样效果。新 Pod 会使用当前 ConfigMap 创建 mount，并启动 nginx。将“只修改 ConfigMap”的 commit 与“连 template 一起修改”的 commit 分开，就能直观看到差异。请参阅官方 Deployment 更新。
checksum 不能凭肉眼填写，必须基于真实配置字节计算，连末尾换行是否存在都会改变结果。本实验 helper 会原样编码已保存 ConfigMap 观测中的 nginx.conf value，再进行计算。生产环境中，config file 与 template generation pipeline 必须共享相同规则。其他文件的 checksum 或任意 timestamp 也能触发 rollout，但它们不能证明实际部署了哪份配置。
现场会遇到的情况
必须区分 emergency action 与 permanent recovery。即使手动删除 Pod 能让它读取新配置，该操作也不会在 Git 中留下 desired deployment state 与 change intent。启用 selfHeal 的 resource 被直接修改后，可能重新协调回 Git state。本实验不修改平台运维设置，而通过学员专用 repository 中的两个 commit 保留恢复过程。自动同步不是修复所有错误配置的功能，仍需要人工 review 与 test。请参阅官方自动同步。
确认 rollout 完成时，也不能只看名称。新 Pod UID 必须变化，但 Application 与 Deployment 应保持同一 UID。删除旧 Pod 后又用相同名称重新创建全部 resource，并不属于同一恢复过程。只有同时确认目标 template checksum、observedGeneration、updatedReplicas、Ready、新 Pod 内文件和真实 response，才能声称“读取新配置的新 process 已经响应”。
实验各阶段 JSON 只是为了方便编写报告的学习资料。它会保留 raw data 与 hash，避免误覆盖先前观测，但同一 VM 中的 root 仍能修改全部文件。不能仅因存在 hash，就称其为 remote attestation 或不可篡改 audit system。生产审计应另行设计把日志发送到 trust boundary 之外的机制，以及 access control 与 retention policy。
下一项实验要做什么
分别保存 config change 前后，以及 template change 后的状态。调查中间阶段是否出现“ConfigMap 已是新值，mounted file 与 response 仍是旧值”。最后沿 Git commit parent relationship 区分两次变更，并确认新 Pod 返回 200。重新评分历史阶段时应读取历史记录，而不是再次注入故障。只有 current state check 也一并通过，才能在调查范围内宣布恢复，并把 external path 与持续观测记录为剩余工作。