从 apply 到工作负载就绪：按阶段找证据

源笔记把 kubectl apply、API 写入、控制器调谐、Pod 启动和 Service 接流量排成一条长链。它适合作为观察阶段的线索，不能据此推断一次 apply 会同步等到容器或业务就绪。

阶段	先看什么证据	证据的边界
请求被接受	客户端返回、目标对象的版本与字段、API 审计记录或拒绝信息	成功写入目标对象，只说明期望状态已提交；还未证明控制器完成调谐。
工作负载调谐	Deployment 的 `observedGeneration`、副本状态，关联的 ReplicaSet 和 Pod，相关事件	新 Pod 未出现时先区分控制器尚未观察、模板或配额等创建失败。
Pod 被调度	Pod 的 `PodScheduled` 条件、`spec.nodeName` 和调度事件	已绑定节点，不等于该节点能拉镜像、挂卷或启动容器。
节点执行	Pod 条件、容器状态与事件；按症状核对 kubelet、运行时、网络和存储证据	`Running` 也不代表容器通过就绪检查。网络插件与容器运行时取决于集群。
服务接入	Pod `Ready` 条件、Service 选择器、EndpointSlice 或集群仍使用的 Endpoints 后端，以及实际请求	后端出现仍需从真实访问路径验证 DNS、数据面、网络策略和应用响应。

排查时把最早没有成立的阶段作为下一步入口，记录对象 UID、观察时间和事件，避免把后续症状误当根因。可接续控制面与对象生命周期、Pod 生命周期及 Service 不通。

原文需要拆开的前提

原文用“三方合并、annotation、Strategic Merge Patch”描述 apply，这只覆盖特定客户端 apply 与对象路径。服务端 apply 的字段归属与冲突处理不同；应先检查调用参数、客户端版本和对象的 managedFields，再解释变更行为。
原文的 Go 片段含省略号和简化流程，且未给源码版本或提交号。函数名、路径和执行顺序只能作为检索线索，不能作为已核实的逐函数调用证明。
原文把 Calico、传统 Endpoints 控制器和 kube-proxy iptables 串成必经路径。实际集群可能使用其他 CNI、EndpointSlice 或不同 Service 数据面；就绪状态也不自动证明端到端流量可达。

来源：有道导出中的 Kubernetes 控制链路收藏笔记。本页为脱敏后的编辑提炼，尚未对目标版本源码和运行环境验证。