适用范围与安全边界
本文用于已有 Kubernetes 集群中“域名无法解析、Service 超时、部分节点偶发失败”的分层定位，配合 Kubernetes DNS 与 Service 连通性排障场景 使用。内容状态为 PENDING（待环境验证），示例未在你的集群执行。先确认实际 Kubernetes、CoreDNS、容器运行时及网络插件版本；托管集群、Windows 节点、无 kube-proxy 的数据面不能机械套用 Linux 排查结论。
命令中的 NAMESPACE、SERVICE_NAME、POD_NAME、CONTAINER_NAME、DNS_SERVICE_NAME 与域名均为占位符，必须由负责人替换。第一阶段仅通过 API 读取资源及获准查看的日志，不创建 Pod，不编辑 ConfigMap，不重启 DNS，不清空节点网络规则。日志和资源配置可能含内部拓扑，分享前需要脱敏。
建立可复现的故障矩阵
在工单中记录首次异常时间、调用端命名空间、Pod 与节点、被调服务、协议、端口、期望响应和最近变更。分别标记短名称、完整域名、Service IP、后端 Pod IP 的表现；没有取得探测授权时，先从既有应用日志和监控补齐，未知项保持未知。一次访问成功不能代表全部副本、节点或地址族正常。
对照至少一个正常调用端与一个异常调用端，优先选用同一业务、相同发布版本和请求语义。把“全部域名失败”“仅一个服务失败”“仅外部域名失败”“只在某节点失败”分开，能减少不必要的 DNS 全局调整。记录超时、拒绝连接、NXDOMAIN、SERVFAIL 等原始错误，不把所有失败统一写成网络不通。
先核对 Service 与后端对象
以下查询不更改资源。查看 Service 的类型、选择器、端口映射、地址族和流量策略，再核对同命名空间全部相关 EndpointSlice；一个 Service 可以对应多个切片，不能只查看第一项。示例选择器通过 Service 名称定位切片，仍要核对其管理者与实际目标。
kubectl config current-context
kubectl -n NAMESPACE get service SERVICE_NAME -o yaml
kubectl -n NAMESPACE get endpointslices -l kubernetes.io/service-name=SERVICE_NAME -o yaml
kubectl -n NAMESPACE get pods -o wide --show-labelsEndpointSlice 中的地址、端口与 ready、serving、terminating 条件应结合当前 Service 行为解释。选择器拼写不一致、命名 targetPort 不匹配、后端未就绪均应先交给应用负责人确认；不要直接手改控制器管理的 EndpointSlice。Headless Service、ExternalName 和无选择器 Service 的语义不同，不能统一要求它们存在普通 ClusterIP 与自动生成的后端列表。详见 Service 排查。
将 DNS 服务与业务域名分开
先识别安装中真正使用的 DNS Service、DNS Pod 和可能存在的 NodeLocal DNSCache，不假设组件名称、标签与所有发行版相同。常见 CoreDNS Service 名为 kube-dns，但查询前应确认。检查 DNS Service 的 UDP/TCP 端口、EndpointSlice、Pod 就绪和近期重启；只有日志读取授权时才查看有限时间窗口。
kubectl -n kube-system get services
kubectl -n kube-system get endpointslices -l kubernetes.io/service-name=DNS_SERVICE_NAME -o yaml
kubectl -n kube-system get pod DNS_POD_NAME -o wide
kubectl -n kube-system logs DNS_POD_NAME -c DNS_CONTAINER_NAME --since=10m --tail=200 --timestampsCoreDNS 的 API 访问错误、上游解析错误与进程资源异常要分别记录。未看到查询日志不等于没有请求，因为查询日志插件可能没有启用。启用详细 DNS 日志属于配置变更，会增加负载并记录访问域名，必须另行审批、限定时间并准备撤回；本手册不默认开启。官方核对入口为 DNS 调试。
在授权后检查调用端解析配置
从 Pod 对象先检查 dnsPolicy、dnsConfig、hostNetwork 及所在节点。随后如需实际查看容器内解析文件，应取得 pods/exec 权限和业务负责人同意。kubectl exec 会在容器中启动进程，不是纯 API 只读查询；即使执行的命令只读文件，也可能增加审计事件和少量负载。
kubectl -n NAMESPACE get pod POD_NAME -o yaml
# 下行仅在获得容器内执行授权后使用，不安装软件。
kubectl -n NAMESPACE exec POD_NAME -c CONTAINER_NAME -- cat /etc/resolv.conf比对 nameserver、search 与 ndots，使用实际集群域而非默认认定 cluster.local。短名称受命名空间和搜索域影响；完整域名末尾的点用于避免继续追加搜索后缀。hostNetwork 与 ClusterFirstWithHostNet 的组合需按操作系统核验，Windows 不支持这一策略。不要用修改容器内 /etc/hosts 的方式掩盖服务发现问题。策略边界参考 Pod 与 Service DNS。
批准有限探测后逐层比较
使用已存在且经批准的诊断容器；如果没有 dig、nslookup 或协议客户端，不在业务容器临时安装，也不默认创建特权 Pod。先申请诊断资源、镜像来源和生命周期，再选择具体方案。获准后限制请求次数、超时与目标，禁止扫描整个网段；HTTP 探测只使用业务确认无副作用的健康接口，不向真实支付、任务触发或写接口发测试请求。
从相同源端依次比较完整服务域名、Service IP 和各个后端地址，并记录实际使用的 Service 端口与容器目标端口。对 HTTPS 必须保持正确的主机名、SNI 和证书校验；直接改成 IP 可能制造证书错误，不能据此认定网络故障。UDP 与 TCP DNS 分别测量，应用正常需要的协议才纳入通过标准。诊断工具结果也需与应用实际解析库及缓存行为对照。
分析策略与节点数据面
读取调用端和服务端命名空间 NetworkPolicy，核对真实标签是否被选中、出口和入口是否分别允许目标流量；DNS 还需要考虑实际解析器所在位置。多条标准策略按允许规则累加，而不是按文件顺序覆盖。资源存在不代表网络插件已实施策略。NodeLocal DNS、Service 地址转换与插件扩展策略应按照具体实现评估，不能只凭一份 YAML 下结论。NetworkPolicy 官方说明 说明了这些边界。
若后端直连成功但 Service 路径失败，再检查实际代理实现、节点级异常与已采集的网络指标。使用 eBPF 等替代数据面的集群，不应强行寻找或重启 kube-proxy。将节点、地址族、源命名空间作为对照维度，不清空 iptables、不全网放通、不一次重启所有网络组件。抓包可能包含敏感数据，必须另行确定范围与保留策略。
最小变更、停止条件与回退
只有在证据能指向具体对象后才进入变更：例如纠正单个 Service 的端口引用、恢复误改的标签或撤回一条近期错误策略。审批记录需要包含配置原版本、拟修改字段、预计传播时间、观察窗口和停止负责人。优先在非核心副本或测试命名空间验证，按 GitOps 或平台现有入口落地，避免手动修复被自动同步覆盖。
如果故障扩散到多个节点、API 不稳定、错误率明显上升或无法确认策略影响范围，停止新增变更并升级事件级别。回退只恢复本次已确认修改对象的前一个已知版本；不删除全部策略，不批量重建服务。已产生的业务请求或数据写入无法由配置回退自动撤销，应由应用负责人另行核对。
验收与值班交接
按事先约定的窗口观察完整 DNS 缓存周期、就绪探针周期和代表性业务请求。验收至少覆盖原异常源端、正常对照源端、相关节点与地址族；业务成功率和延迟回到团队基线，DNS 错误和后端重启不再持续增加，同时原来应该拒绝的访问仍然被拒绝。负向权限验证需有独立授权，不能随意连接未批准资产。
交接表记录每条假设、证据、结论、修改对象、恢复时间和未验证项。若只是重启后暂时恢复，标记为临时缓解，不伪装成根因已解决。将配置差异和版本边界关联到场景步骤，后续值班人员能够按同一来源复查，而不是依赖截图猜测当时对象状态。