Kubernetes 域名解析问题排查实战：短名为什么有时能解析，有时不行

一个很常见的现象是：同一个集群里，不同 Pod 对同一个服务名的解析结果不一样 ------有的 Pod 能直接 ping service-name，有的却报 unknown host。这类问题看起来像 DNS 故障，但实际上往往是 namespace、search 域、dnsPolicy 导致的解析规则差异。

本文结合一个真实排查案例，系统梳理 Kubernetes 域名解析的规则、现象、排查方式和解决思路。

一、问题现象

我们在两个不同 Pod 里测试同一个服务名：

Pod A

复制代码

[root@abm-appmanager-0 /app]
# ping noarch-paas-product
PING noarch-paas-product.data-manager.svc.cluster.local (10.59.133.120) 56(84) bytes of data.

Pod B

复制代码

[root@rds-service-broker-66bc7fc5d8-cm4jq /]
# ping noarch-paas-product
ping: unknown host noarch-paas-product

随后我们继续测试完整域名：

复制代码

# ping noarch-paas-product.data-manager.svc.cluster.local
PING noarch-paas-product.data-manager.svc.cluster.local (10.59.133.120) 56(84) bytes of data.

这说明：

DNS 服务本身是正常的
Service 记录是存在的
问题集中在短名解析规则，不是集群 DNS 整体故障

二、先理解 Kubernetes 域名解析规则

Kubernetes 中的服务名解析，分为两种：

1. 短名

例如：

复制代码

noarch-paas-product

短名是否能解析，依赖 Pod 内的：

当前 namespace
/etc/resolv.conf 中的 search 域
dnsPolicy

短名通常只在同 namespace 内有效。

2. 全名（FQDN）

例如：

复制代码

noarch-paas-product.data-manager.svc.cluster.local

只要：

Service 存在
CoreDNS 正常
DNS 记录正确

那么全名通常可以跨 namespace 解析。

三、为什么同一个集群里，不同 Pod 结果不一样

这个问题的关键在于：不同 Pod 的 DNS 配置和上下文可能不同。

原因 1：Pod 所在 namespace 不同

Kubernetes 的短名解析默认是"当前 namespace 优先"。

比如服务在：

复制代码

data-manager

那么在这个 namespace 内，输入：

复制代码

noarch-paas-product

系统会自动补全为：

复制代码

noarch-paas-product.data-manager.svc.cluster.local

但如果 Pod 不在这个 namespace，短名就不一定能补到正确位置。

原因 2：Pod 的 search 域不同

Pod 内的 /etc/resolv.conf 决定了短名补全规则。

正常情况下会包含类似：

复制代码

search <namespace>.svc.cluster.local svc.cluster.local cluster.local

如果某个 Pod 的 search 域缺失，或者被手动覆盖，短名就无法自动补全。

原因 3：dnsPolicy 不同

如果 Pod 使用的是：

ClusterFirst：通常走集群 DNS，适合 K8s Service 解析
Default：可能走节点 DNS，不一定能解析集群内部服务
None：完全自定义 DNS，容易出问题

所以不同 Pod 即使在同一个集群，只要 dnsPolicy 不一样，表现就可能不同。

四、这个案例的真实结论

从测试结果看：

短名 noarch-paas-product在某些 Pod 中不可解析
全名 noarch-paas-product.data-manager.svc.cluster.local可以正常解析

因此根因大概率是：

短名解析所依赖的 namespace 或 search 域不匹配，而不是 CoreDNS 故障。

五、排查思路

遇到类似问题时，建议按以下步骤排查。

第一步：确认 Service 是否存在

先确认目标 Service 在哪个 namespace：

复制代码

kubectl get svc -A | grep noarch-paas-product

你需要确认：

Service 名称是否正确
namespace 是否正确
是否真的存在

第二步：确认 Pod 所在 namespace

查看当前 Pod 归属：

复制代码

kubectl get pod rds-service-broker-66bc7fc5d8-cm4jq -o wide -n <namespace>

因为短名解析通常只在当前 namespace 内生效。

第三步：查看 Pod 的 resolv.conf

进入 Pod 执行：

复制代码

cat /etc/resolv.conf

重点检查：

nameserver
search
options

你要看 search 里是否包含：

复制代码

<namespace>.svc.cluster.local
svc.cluster.local
cluster.local

如果没有，这个 Pod 的短名解析大概率就会失败。

第四步：检查 dnsPolicy

查看 Pod 配置：

复制代码

kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A3 dnsPolicy

推荐一般使用：

复制代码

dnsPolicy: ClusterFirst

如果被设置成 Default 或 None，DNS 行为就可能和预期不一致。

第五步：验证全名是否可解析

在 Pod 内测试：

复制代码

ping noarch-paas-product.data-manager.svc.cluster.local

如果全名能解析，说明：

CoreDNS 正常
Service 记录存在

这时问题基本就定位到短名补全规则。

第六步：检查 CoreDNS 是否健康

如果全名也失败，就要查 CoreDNS：

复制代码

kubectl get pods -n kube-system | grep coredns
kubectl logs -n kube-system <coredns-pod-name>

如果 CoreDNS 异常，通常会出现：

多个 Pod 都无法解析
全名和短名都失败

六、短名和全名的使用建议

1. 同 namespace 内访问

可以直接用短名：

复制代码

service-name

前提是 DNS 配置正常。

2. 跨 namespace 访问

建议直接使用全名：

复制代码

service-name.namespace.svc.cluster.local

这是最稳妥、最不容易出错的方式。

3. 不要假设所有 Pod 的解析规则一致

即使是同一个集群：

不同 namespace
不同 dnsPolicy
不同 sidecar
不同网络环境

都可能导致解析行为不同。

七、一个简单的判断口诀

可以记住下面几句话：

短名看 namespace
全名看 DNS
短名解析失败，先查 search 域
全名解析失败，先查 CoreDNS
同集群不同 Pod 表现不一样，先查 resolv.conf 和 dnsPolicy

八、最终结论

本次问题并不是 Kubernetes DNS 整体故障，而是 短名解析规则与 namespace / search 域不一致 导致的。

当我们使用完整域名 service-name.namespace.svc.cluster.local 时，DNS 可以正常解析，这进一步证明了 CoreDNS 和 Service 记录是健康的。

所以在实际生产中，遇到类似"有的 Pod 能解析，有的不能解析"时，不要第一时间怀疑 DNS 故障，而应该优先检查：

Pod 所在 namespace
/etc/resolv.conf 中的 search 域
dnsPolicy 是否为 ClusterFirst
是否使用了完整域名