在Kubernetes中需显式设置dnsPolicy: Default使Pod继承宿主机/etc/resolv.conf，用于调试或绕过CoreDNS；必须验证宿主机DNS有效、Pod内resolv.conf内容一致，并通过nslookup测试解析能力。
在Kubernetes中让Pod直接使用宿主机的/etc/resolv.conf进行DNS解析，适用于调试网络、对接本地DNS服务或绕过集群内部CoreDNS的场景，避免因CoreDNS异常导致域名解析失败。
确认宿主机DNS配置可用
登录任意Node节点，执行cat /etc/resolv.conf，确保文件存在且至少含一个有效nameserver行，例如nameserver 192.168.1.1。若为空或全是#注释，需先配置宿主机DNS，否则Pod将无法解析任何域名。
设置Pod的dnsPolicy为Default
在Pod或Deployment的YAML中，显式指定dnsPolicy: Default：
```yaml
apiVersion: v1
kind: Pod
metadata:
name: dns-test
spec:
containers:
- name: busybox
image: busybox:1.35
command: ["sleep", "3600"]
dnsPolicy: Default
```
【注意：不能省略该字段】即使不写dnsPolicy，Kubernetes默认值也是ClusterFirst，而非继承宿主机——必须显式设为Default才触发继承逻辑。
验证Pod是否真正使用宿主机resolv.conf
步骤一：创建Pod后，进入容器执行：kubectl exec -it dns-test -- cat /etc/resolv.conf
步骤二：对比输出内容与对应Node节点上的/etc/resolv.conf是否完全一致（包括顺序、空行、注释）
步骤三：执行kubectl exec -it dns-test -- nslookup google.com，观察是否能成功返回A记录；若失败，说明宿主机DNS本身不可达或被防火墙拦截。
这一步操作起来很简单，直接把文件拖进去就行。
特殊情况：HostNetwork模式下强制继承
当Pod启用hostNetwork: true时，Kubernetes默认仍可能注入ClusterFirst行为。此时必须同时满足两个条件：
方法一：保留hostNetwork: true + 显式设置dnsPolicy: Default
方法二：改用dnsPolicy: ClusterFirstWithHostNet → 该策略**不继承宿主机resolv.conf**，而是继续走CoreDNS，因此不符合本需求，切勿误选。
方法三（推荐）：不启用hostNetwork，仅靠dnsPolicy: Default即可完整继承，这是最干净、最可控的方式。
