28 的 Ready影响后端集合，24 的 ADD为 Pod 网络准备地址。Service 提供稳定的访问入口，但入口能否把某次请求转发到一个正在响应的 Pod，需要具体节点转发实现、后端集合和实际请求一同证明。不能说“Pod 有 IP”就说明 Service 一定可用。

三份状态不能互换

Pod 的 IP 是运行时网络路径产生的地址；Service 的名称在集群 DNS 中解析为入口地址或别名，转发机制由节点/插件实现；EndpointSlice 等对象描述可用后端及条件，后端的就绪状态来自 Pod/探针。DNS 返回地址并不是 socket 连通的凭据，网络策略是否真的拦截流量还依赖已启用且支持策略的 CNI 插件；有 NetworkPolicy 对象不等于执行层已经配置过滤。

正例：在固定插件的专用 kind VM 给两个 probe-app Pod 设置不同 /identity 输出，访问 Service 多次，记录 Pod UID、EndpointSlice、节点转发规则/程序状态及每次后端 PID；负例：在仅属于自建 namespace 的测试策略里拒绝一条已允许的来源/目标矩阵，再复核真实 HTTP 结果与插件实现。若插件不支持 NetworkPolicy，不可把“策略不生效”描述成 Kubernetes 规范保证放行。入口与统一源码包说明实验资源边界；当前无 kind/CNI，全部 NOT_RUN。

现象 核查 适用条件
DNS 有解析，访问超时 Service 后端/转发与策略 解析不是连通
Pod 可直连，Service 不通 EndpointSlice 与 Service 实现 不是 veth 必然故障
Policy 对象存在但未过滤 插件版本与实测矩阵 不代表策略已执行

练习

  1. 先预测让一只 Pod 的 readiness 返回 503 时 Service 后端集合和直接 Pod IP 请求各怎样变化，观察端点及真实请求差别。
  2. 在确实支持策略的专用插件中，先列出允许/拒绝矩阵再配置 NetworkPolicy，逐条请求并检查策略恢复与清理。

上一篇：28：Ready；下一篇：30：卷到容器。

系列总目录：从进程隔离到运行时与编排。

参考资料