详解Kubernetes安装过程中的服务发现与域名解析测试-Golang-PHP中文网

coredns正常工作的验证需先检查pod状态为running且ready 1/1，再用busybox执行nslookup kubernetes.default.svc.cluster.local确认解析成功；若失败，重点排查/etc/resolv.conf的nameserver、search域及dnspolicy配置。

详解kubernetes安装过程中的服务发现与域名解析测试

验证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"

成功返回类似：

Kubernetes Network Policy Generator

使用加权评分卡在12项标准上评估和比较隐私解决方案供应商。适用于选择隐私管理软件、比较数据保护方案等场景。

下载

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</p>

说明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></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——这种静默失败比超时更难定位。