kubernetes中“docker容器dns超时”实为pod因coredns解析失败或延迟导致服务调用卡在域名解析阶段，根源在于k8s dns体系与网络栈协同失当，需隔离故障点、验证路径、消除负缓存、加固连通性。
在 Kubernetes 环境中，所谓“Docker 容器 DNS 超时”实际是 Pod（底层由容器运行时如 containerd 或 dockershim 托管）因 CoreDNS 解析失败或延迟，引发服务调用卡在域名解析阶段，最终导致微服务请求超时。这不是 Docker 本身的配置问题，而是 K8s DNS 体系与网络栈协同失当的结果。核心思路是：**隔离 DNS 故障点、验证解析路径、消除负缓存干扰、加固数据面连通性**。
确认是否真为 DNS 层超时
别一上来就调 CoreDNS。先在业务 Pod 内用带时间度量的工具定位瓶颈：
- 执行
curl -w "@curl-format.txt" -o /dev/null http://svc-name.namespace.svc.cluster.local，重点看time_namelookup是否远高于其他字段（如 >5s） - 对比直连 ClusterIP：
curl -w "@curl-format.txt" -o /dev/null http://10.96.123.45，若后者毫秒级而前者十几秒，基本锁定 DNS - 进容器执行
nslookup svc-name.namespace.svc.cluster.local，观察是否卡住、返回timeout或NXDOMAIN
检查 Pod 的 DNS 配置与连通性
很多超时源于 Pod 根本没连上 CoreDNS：
- 查看
/etc/resolv.conf：必须含nameserver <coredns-service-ip></coredns-service-ip>（通常是10.96.x.x），且search行含namespace.svc.cluster.local svc.cluster.local cluster.local - 用
telnet <coredns-svc-ip> 53</coredns-svc-ip>或nc -vz <coredns-svc-ip> 53</coredns-svc-ip>测试 UDP/TCP 53 端口是否可达；不通则查 kube-proxy、CNI 插件、节点防火墙或云安全组 - 若使用 HostNetwork 或自定义 DNS 配置（如
dnsPolicy: Default），会绕过集群 DNS，需统一改为ClusterFirst
排查 CoreDNS 自身状态与配置
即使 Pod 连得上，CoreDNS 也可能性能不足或配置错误：
- 检查 Pod 状态：
kubectl get pods -n kube-system -l k8s-app=kube-dns，确保 Ready 且重启数为 0 - 核对 Endpoints：
kubectl get endpoints -n kube-system kube-dns，确认有活跃 IP 和端口（53/UDP, 53/TCP） - 查看日志：
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100 | grep -i "error\|refused\|timeout"，关注 upstream 失败或缓存满警告 - 检查 ConfigMap：
kubectl get cm -n kube-system coredns -o yaml，确认没有误删forward插件，上游 DNS（如1.1.1.1）可访问且未限速
应对 DNS 负缓存与服务变更延迟
Pod 重建、Service 创建后立即调用，常因负缓存（NXDOMAIN 缓存）或记录未同步导致短暂不可解析：
- CoreDNS 默认对 NXDOMAIN 缓存 30 秒，可通过修改 Corefile 中
cache插件参数降低：cache 10 { ... } - 避免硬编码短生命周期域名（如
pod-name.headless-svc），优先走 Service 名（svc-name.namespace.svc.cluster.local） - 应用层加重试逻辑（如指数退避），跳过首次 DNS 失败；或预热：启动时主动
nslookup关键服务名 - 对 headless Service，确认 EndpointSlice 已就绪：
kubectl get endpointslice -n namespace --field-selector service=<svc-name></svc-name>
