Kubernetes集群中curl访问服务DNS出现can't resolve host报错问题

安全阿岳

2026-10-7

问题根因

你遇到的问题核心是musl libc的DNS解析逻辑与K8s集群默认DNS双栈查询的冲突：

你使用的curlimages/curl默认镜像基于Alpine系统，采用musl libc作为运行时库。musl的DNS解析逻辑为：同时查询A（IPv4）和AAAA（IPv6）记录时，只要任意一类记录返回NXDOMAIN（不存在），就判定整个域名不存在，直接丢弃所有有效查询结果。
你执行nslookup时的异常返回也验证了这点：CoreDNS返回了正确的IPv4 A记录（192.168.3.64），但因为该服务没有配置IPv6 AAAA记录，AAAA查询返回NXDOMAIN，所以nslookup会同时输出非权威应答和NXDOMAIN报错，最终退出码为1。

排查步骤

确认Pod DNS配置：执行如下命令查看Pod内部的DNS规则
```
kubectl -n exampleNamespace exec -it pod/curl -- cat /etc/resolv.conf
```
检查是否包含集群默认的search域（如exampleNamespace.svc.cluster.local、svc.cluster.local）和ndots配置。
验证全限定名解析：执行如下命令查询K8s标准服务全限定名，确认是否无NXDOMAIN报错
```
kubectl -n exampleNamespace exec -it pod/curl -- nslookup exampleService.exampleNamespace.svc.cluster.local
```
验证解析器兼容性：启动一个基于glibc的测试Pod（如busybox:glibc、debian:latest），执行相同curl操作，确认是否可以正常访问，排除服务本身的连通性问题。

解决方案

方案1：更换glibc版本的curl镜像，避免musl的解析缺陷，修改Pod配置中的镜像字段为：
```
image: curlimages/curl:latest-glibc
```
方案2：访问时使用K8s服务的完整域名，不需要依赖search域拼接，修改curl命令为：
```
curl http://exampleService.exampleNamespace.svc.cluster.local/path
```
方案3：调整CoreDNS配置禁用IPv6解析（适合不需要IPv6的集群），修改Corefile的kubernetes配置段，添加ipv6 false参数，让CoreDNS对AAAA记录返回空响应而非NXDOMAIN：
```
kubernetes cluster.local in-addr.arpa ip6.arpa {
  ipv6 false
  # 其余原有配置保持不变
}
```

方案4：如果使用glibc镜像，可以在Pod配置中添加DNS参数优化解析逻辑：

spec:
  dnsConfig:
    options:
      - name: single-request-reopen
      - name: ndots
        value: "2"

内容的提问来源于stack exchange，提问作者D. O.