核心是确保pod使用clusterfirst dns策略并正确配置/etc/resolv.conf指向coredns，从而通过标准fqdn（如service-name.namespace.svc.cluster.local）解析集群内服务。
容器内 DNS 服务解析集群内域名，核心是让 Pod 正确使用 CoreDNS，并遵循 Kubernetes 的服务发现命名规则。默认配置下多数场景已自动支持，但需确认和必要时微调。
确认 DNS 策略为 ClusterFirst
这是解析 集群内服务名（如 my-service.default.svc.cluster.local） 的前提。检查 Pod 的 dnsPolicy 字段：
- 若未显式设置，Kubernetes 默认使用 ClusterFirst
- 可通过
kubectl get pod <pod-name> -o yaml</pod-name>查看 spec.dnsPolicy 是否为ClusterFirst - 若为
Default或None，需在 Pod 或 Deployment 中明确指定：dnsPolicy: ClusterFirst
验证 /etc/resolv.conf 配置正确
进入容器执行 cat /etc/resolv.conf，应看到类似内容：
-
nameserver指向 CoreDNS 的 ClusterIP（如10.96.0.10） -
search包含default.svc.cluster.local svc.cluster.local cluster.local -
options ndots:5—— 这保证短域名（如mysql）会自动补全为mysql.default.svc.cluster.local
若 nameserver 是节点 IP 或公网地址，说明 DNS 策略或 kubelet 配置异常。
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
按标准格式访问集群服务
服务发现依赖完整 FQDN（全限定域名），不同范围写法如下：
- 同命名空间：直接用
service-name（靠 search 域自动补全） - 跨命名空间：用
service-name.namespace.svc.cluster.local - 集群内任意位置：用完整形式
service-name.namespace.svc.cluster.local
例如，default 命名空间下的 nginx 服务，在 kube-system 命名空间的 Pod 中可访问为：nginx.default.svc.cluster.local
排查常见失败原因
如果 nslookup nginx 失败，优先检查：
- CoreDNS Pod 是否处于
Running状态（kubectl get pods -n kube-system -l k8s-app=kube-dns） - 对应 Service 是否真实存在且有 Endpoint（
kubectl get endpoints nginx） - Pod 所在命名空间是否被 NetworkPolicy 限制了到 CoreDNS 的 UDP 53 端口通信
- 自定义的
dnsConfig或hostNetwork: true覆盖了默认行为（此时应改用ClusterFirstWithHostNet）
