CoreDNS正常工作的验证需先检查Pod状态为Running且READY 1/1，再用busybox执行nslookup kubernetes.default.svc.cluster.local确认解析成功；若失败，重点排查/etc/resolv.conf的nameserver、search域及dnsPolicy配置。
验证CoreDNS是否正常工作
集群部署完成后，第一件事不是写Service，而是确认DNS服务本身能响应请求。很多“服务连不通”的问题，其实卡在CoreDNS根本没起来，或者Pod没拿到正确的/etc/resolv.conf。
执行以下命令检查CoreDNS Pod状态：
kubectl get pods -n kube-system -l k8s-app=kube-dns
必须看到Running且READY 1/1。如果卡在Pending或CrashLoopBackOff，先别急着测服务，得查日志：
kubectl logs -n kube-system deployment/coredns
常见原因包括：镜像拉取失败（尤其国内环境）、RBAC权限缺失、Corefile配置错误导致启动失败。注意coredns Deployment默认使用coredns/coredns:latest，但K8s 1.23+推荐指定明确版本（如v1.10.1），避免因镜像更新引入不兼容。
测试Pod内DNS解析行为
用一个临时busybox Pod直接验证解析路径是否通畅：
kubectl run dns-test --image=busybox:1.35 --rm -it --restart=Never -- sh -c "nslookup kubernetes.default.svc.cluster.local"
成功返回类似：
Server: 10.96.0.10 Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local <p>Name: kubernetes.default.svc.cluster.local Address 1: 10.96.0.1
说明CoreDNS可达，且能解析内置服务。若失败，重点检查三点：
-
/etc/resolv.conf中nameserver是否指向CoreDNS的ClusterIP（如10.96.0.10） -
search域是否包含default.svc.cluster.local等层级（否则curl nginx会失败） - Pod是否设置了
dnsPolicy: Default（这会让它跳过集群DNS，直连宿主机DNS）
跨命名空间服务解析怎么写才对
同命名空间下curl nginx-service能通，不代表跨命名空间也能省略后缀。真实场景中，中间件常部署在infra命名空间，业务Pod在app命名空间，这时必须显式写全：
curl http://redis-master.infra.svc.cluster.local:6379
不能简写为redis-master.infra或redis-master.infra.svc——后者缺.cluster.local，而CoreDNS默认只匹配完整FQDN或带search补全的变体。关键点：
- Service名和命名空间名大小写敏感，
Redis-Master≠redis-master - 若集群自定义了
--cluster-domain=prod.local，后缀必须是.prod.local，不是.cluster.local - Headless Service（
clusterIP: None）会返回Pod IP列表，但解析结果仍是A记录，不是SRV，除非你显式查dig SRV _http._tcp.nginx-service.default.svc.cluster.local
为什么nslookup能通但curl超时
这是最典型的“假通真断”现象：DNS解析成功，但网络层不通。比如：
- Service的
selector没匹配到任何Pod，导致Endpoint为空（kubectl get endpoints nginx-service返回<none>） - Pod就绪探针（
readinessProbe）失败，虽在Running状态但未被加入Endpoint - NetworkPolicy限制了流量，允许DNS（UDP 53）但拒绝HTTP（TCP 80）
- Service类型是
ClusterIP，但你在集群外用curl测试——它只能在Pod内部或节点上访问
排查顺序固定：nslookup → kubectl get endpoints → kubectl get pods -o wide → ping/telnet ClusterIP:Port。别跳步，尤其别用curl结果反推DNS问题。
真正容易被忽略的是ndots:5这个resolv.conf选项：当域名中点号少于5个时，会强制尝试所有search域补全。这意味着curl redis实际发起的是redis.default.svc.cluster.local、redis.svc.cluster.local、redis.cluster.local三次查询。一旦某个补全命中但对应Service不存在，CoreDNS可能缓存负响应（TTL由cache插件控制），后续请求直接返回NXDOMAIN——这种静默失败比超时更难定位。
