负责变更与删除的自助服务API
一句话总结
优秀的自助平台在创建后仍让请求与真实状态的差异收敛，区分删除请求与实际回收完成，并保护其他团队的资源。
为什么需要它
平台演示常在应用首次创建时结束，但运营阶段更长：扩大副本、更新配置、删除闲置环境。用户看到“已修改”，部分 Pod 仍可能返回旧配置；删除请求成功，产生费用的资源仍可能残留。只自动化创建、把其余工作交还人工，运维负担只是换了名字。
若开发者把下层 Deployment 从 App 请求的 2 副本手改为 3，哪个是源？本练习以 App 为源，控制器观察差异后会恢复为 2。恢复不是缺陷，而是声明契约的结果；持久变更应修改原请求。
工作原理
验证更新先确认请求 UID 未变。Kubernetes 名称可重用，删除 parcel 后同名重建，即使 URL 和名称相同，UID 也不同，旧应用成功记录不能成为新应用证据。连接下层 Deployment UID 还能识别删除重建的绕行。
Deployment metadata.generation 表示期望配置变化，status.observedGeneration 表示控制器观察到的世代。新声明后旧世代 Ready 可能短暂残留，因此要同时检查 observedGeneration 是否等于当前世代、新旧副本与 available 数是否达标、是否残留终止中的 Pod，以及当前 Pod 是否真实返回 preview。
若只提交“手改 3 后最终为 2”，无法证明差异真的发生，因为它可能一开始就是 2。实验工具会保存 API 已接受 3 副本的 patch 响应，并确认在更晚世代恢复为 2。单个状态与事件过程是不同证据。
删除也有阶段。API server 接受删除后设置 deletionTimestamp；finalizer 存在时对象不会立刻消失，让负责控制器完成清理。事故中删除全部 finalizer 可能让眼前对象消失，却留下外部资源。
练习加入一个教学用保留标记以观察删除中状态。它只延迟上层请求消失，并不保证所有下层资源仍存活；控制器可能先回收下层资源，所以每次都应读真实状态。解除时只移除该标记，并核对 UID、resourceVersion，避免覆盖期间变化。
现场表现
“查不到对象”可能是列表 API 成功且对象不存在，也可能是认证或通信失败。把后者变为空列表会让删除检查器把故障判为成功。只有 App、Deployment、ReplicaSet、Service、Pod 的列表查询均成功且目标不存在，才能确认缺失。
范围也要验证。清理 team-a 时连 team-b 一起删除，自己的应用确实消失，却不是成功清理。应核对其他团队 sentinel UID 与真实响应保持不变。本练习只处理个人 VM 内团队权限，不声称 Namespace 自动完成所有网络和资源隔离。
下一步
下一练习会把同一请求改成 preview、2 副本，观察下层手工变更收敛回源；再分别记录删除中与实际回收，并验证其他团队未受影响。最后编写把观测失败和矛盾保留为 unknown 的诊断器，不从缺失信息推断成功。