面向初级运维，使用 Linux 节点和稳定 Kubernetes API。命令按 Bash 编写。本文为教学故障场景，日志及结果为示意，不冒充生产实测；执行前确认 context、命名空间和权限。
一、遭遇情况：访问 web 报找不到主机，服务却确实存在
客户端容器请求 http://web，返回名称解析失败。运维人员在另一个命名空间能看到 web Service，因而判断 CoreDNS 出了问题。
本篇案例是客户端和服务不在同一命名空间。短名称默认按客户端的搜索域解析，查询到的是客户端命名空间里的 web，并不是另一处同名服务。
二、原因分析：DNS 返回与应用连接是不同层
常规 Service 名可以写成 服务名.命名空间，完整域名常见为 服务名.命名空间.svc.cluster.local，但集群域不一定是 cluster.local，要根据实际配置确认。
| 现象 | 通常先查什么 |
|---|---|
| NXDOMAIN / no such host | 名称、命名空间和对象存在性 |
| 查询超时 | DNS 端口路径、策略、后端可达性 |
| SERVFAIL | DNS 服务器处理、上游或配置错误 |
| 能解析但 HTTP 失败 | 已越过 DNS，继续查 Service 和应用 |
这些是排查方向，不是单凭一个词就能确认的根因。DNS 缓存、负缓存和不同客户端实现，也可能影响观察时机。
三、排查思路：从发生故障的 Pod 发起测试
kubectl exec 客户端Pod -n 客户端命名空间 -- cat /etc/resolv.conf
kubectl exec 客户端Pod -n 客户端命名空间 -- nslookup kubernetes.default
kubectl exec 客户端Pod -n 客户端命名空间 -- nslookup 服务名.服务命名空间
名称需要替换。不是所有镜像都带 nslookup，缺工具不等于 DNS 故障；可以使用批准的诊断镜像，并放在与故障客户端相同的命名空间、网络与策略条件下测试。
读取 resolv.conf 中 nameserver、search 和 options，核对 Pod 的 dnsPolicy。节点有 NodeLocal DNSCache 时，nameserver 可能不是你预期的 CoreDNS Service IP，不能只凭地址不同就改文件。
四、实践：跨命名空间的短名称问题
以下在测试集群创建两个独立实验命名空间，要求这些名字尚未被真实业务使用：
kubectl create namespace kt10-server
kubectl create namespace kt10-client
kubectl create deployment web -n kt10-server --image=nginx:stable-alpine
kubectl expose deployment web -n kt10-server --port=80 --target-port=80
kubectl rollout status deployment/web -n kt10-server --timeout=120s
kubectl run client -n kt10-client --image=busybox:1.37 --restart=Never --command -- sleep 3600
kubectl wait --for=condition=Ready pod/client -n kt10-client --timeout=120s
从客户端依次测试：
kubectl exec client -n kt10-client -- nslookup web
kubectl exec client -n kt10-client -- nslookup web.kt10-server
kubectl exec client -n kt10-client -- wget -T 3 -qO- http://web.kt10-server:80/
在客户端命名空间没有 web Service 且基础 DNS、跨命名空间网络允许的前提下，第一个查询应失败；第二个应解析到服务，第三个应得到页面。
这不是通过“重启 DNS”修复，而是使用了正确的服务边界。如果当前集群策略禁止跨命名空间连接，第二个可能成功、第三个仍超时，需要转到网络策略判断。
五、连 kubernetes.default 都查不到时
有权限的运维人员可以进一步检查 DNS 服务与后端。以下标签是常见 CoreDNS 部署约定，托管或定制集群应按实际对象调整：
kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
kubectl get service kube-dns -n kube-system
kubectl get endpointslice -n kube-system -l kubernetes.io/service-name=kube-dns -o yaml
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100 --timestamps
Pod Running 不代表 DNS 请求都能处理；检查端点、最近错误与客户端到 DNS 的网络路径。若配置了 egress NetworkPolicy，需要考虑 DNS 实际路径和 UDP/TCP 53，而不是仅放行一个不完整的方向。
上游外部域名失败而集群服务名正常时，应继续查 DNS 转发、上游解析和出口；不要把内部名称与外部名称测试合并成一个结论。
六、修复与验证：在原客户端条件下再查一次
本案例修正应用连接地址为带命名空间的服务名，然后通过受控发布让进程采用新配置。若真正原因是策略或上游配置，只修对应层并保留变更记录，不要盲目重建整个 CoreDNS。
验证包括：原名称按新规则解析、请求到达预期 Service、业务协议正常。仅 nslookup 成功，还没有证明后端端口和认证可用。
七、总结
DNS 故障的顺序是：客户端查询了什么 → 服务在哪个命名空间 → 得到什么响应 → 哪一段 DNS 路径失败。先验证名称和边界，再怀疑系统组件，通常能少走很多弯路。