请求已保存，为什么应用还没就绪？
一句话总结
自助 API 不是隐藏安装命令的按钮，而是持续把用户请求与真实资源状态相连接的契约。请求被接受、完成同步、准备就绪是三个不同问题的答案。
为什么需要它
若开发者每次请求测试应用都由平台团队手工创建 Deployment 和 Service，交付很容易遗漏：有的没有 Service，有的副本数不同。共享模板也只解决复制当时的问题，之后的变更和删除仍由各团队负责。自助平台把重复请求变成简单 API，再由控制器持续管理后续资源。
但 API 变简单不等于运维责任消失。HTTP 请求成功时，镜像可能仍在下载。API server 保存声明，控制器处理声明，应用执行自身准备流程，三者负责人和完成时点都不同。
工作原理
本练习 App 只接收 replicas 和 channel。XRD 定义 API 名称、范围和输入格式：replicas 为 1 到 3，channel 为 stable 或 preview。这不是说明文字，超限请求必须由 API server 拒绝，且对象不能保存。开发者可在自身 Namespace 操作 App，却无权直接创建下层 Deployment。
Composition 决定 App 由哪些资源组成。函数创建 Deployment 和 Service，把请求名连接到资源名与 selector，把副本数传给 Deployment，把 channel 传入环境变量。若 Service 选中了别的 App 标签，即使 HTTP 成功也不能证明自己的请求就绪，因此还要核对 owner UID 和 Pod 所有权链。
| 观测 | 已确认 | 尚未确认 |
|---|---|---|
| App 创建成功 | API 已保存请求 | 容器是否启动 |
| Synced=True | 控制器已处理请求 | 准备条件与应用是否正常 |
| Ready=True | 满足 Composition 定义的准备条件 | 条件是否充分代表业务成功 |
| 对应 Pod 的 HTTP 响应 | 代码以预期 channel 响应 | 后续变更和删除是否正常 |
Ready 的含义取决于准备条件。Deployment 通常提供 Available 条件，而错误 Composition 查找 Ready 条件；即使容器和 HTTP 正常，上层 App 仍报告未就绪。删除准备检查只能让显示变绿，却会把真正未准备的应用也标为成功。
现场表现
输入有效性与权限是不同问题。自己团队创建 replicas=4 违反 schema；向其他团队创建合法 replicas=1 则违反权限。若都称为“请求错误”，用户无法知道应修改值还是团队目标。应检查真实响应和对象是否保存，并分别说明原因。
团队边界要用受限 ServiceAccount 而非管理员测试。管理员成功不能证明用户可用；权限查询失败也不能自动解释成 no，否则会把工具故障误当隔离成功，观测失败必须单独记录。
下一步
创建后的更新与删除仍遵循同样原则。下一篇会连接 observed generation、owner UID 与 finalizer；后续练习将核对实际 App 请求文件与对应 Pod 的 HTTP，并记录当前资源和所有权，而非只提交声明文件。