3节点K8S集群微服务服务名调用失败及CoreDNS故障排查

你当前遇到的跨服务调用500错误，根因是CoreDNS因上游DNS链路持续超时，引发解析工作线程阻塞，最终导致全集群域名解析能力失效，和Service配置、Pod运行状态、微服务代码本身没有关系。
这里有个常见的认知误区需要澄清：K8S集群内的短服务名解析本身是CoreDNS本地直连响应的，不需要依赖上游DNS，但CoreDNS的请求处理队列是全局共用的——当向上游192.168.100.1发送的所有UDP 53请求持续i/o timeout，会快速占满CoreDNS的所有工作线程，就连本来可以本地直接返回的集群域解析请求，也会因为队列拥堵触发超时，最终出现Pod内wget服务名返回bad address的现象。

• 第一步：分层验证网络连通性，不要一上来就改配置
  • 登录CoreDNS所在的Master节点，先从节点网络层面测试到上游DNS的连通性：执行dig @192.168.100.1 baidu.com，确认节点本身能不能正常收到上游DNS的响应。如果节点层面都超时，说明根本不需要改CoreDNS配置，直接调整节点/etc/resolv.conf里的上游DNS地址就行。
  • 直接进入CoreDNS Pod的容器内部，执行dig @127.0.0.1 currency-exchange.default.svc.cluster.local，跳过所有上游转发环节，看CoreDNS本身能不能直接返回Service对应的ClusterIP。如果这步都返回空，说明CoreDNS的ConfigMap配置错位，把集群域的请求错误转发到了上游。
• 第二步：核对Pod侧的DNS配置有效性
  • 进入业务Pod查看/etc/resolv.conf配置，确认nameserver地址是否为CoreDNS的ClusterIP，search域列表是否正确包含了default.svc.cluster.local、svc.cluster.local、cluster.local三个默认域后缀，避免短域名currency-exchange拼接成错误的全限定域名。
• 第三步：排查Calico NFT后端的跨节点流量拦截问题
  • 你当前环境用了Calico的NFTables后端，要重点检查跨节点的UDP 53流量是否被误拦截：从Worker节点上的业务Pod执行nc -vz <CoreDNS ClusterIP> 53 -u，看UDP端口能不能正常连通。Calico的NFT模式和传统iptables模式的规则链匹配逻辑有差异，很容易出现误丢DNS这类低端口UDP包的问题。
  • 在Master节点执行nft list ruleset | grep 53，检查是否存在针对53端口UDP流量的默认DROP规则，临时测试可以先停掉firewalld验证连通性，确认是防火墙拦截后再单独放通规则，不要长期关闭防火墙。

• 优先修复CoreDNS到上游DNS的链路问题
  • 如果测试发现节点本身就无法连通192.168.100.1，直接把节点/etc/resolv.conf里的上游DNS替换为可用的公共DNS地址，不要依赖不可用的内网DNS。
  • 修改kube-system下的CoreDNS ConfigMap，把原本依赖节点resolv.conf的上游转发配置，改成显式指定的可用DNS地址，避免上游DNS故障直接拖垮CoreDNS的工作线程：
    对应配置块调整为forward . 223.5.5.5 114.114.114.114 { policy sequential max_concurrent 1000 }
  • 一定要在CoreDNS配置里保留对集群域的本地直连规则，确保所有.cluster.local后缀的请求由CoreDNS本地直接响应，不会被转发到上游，从根源上降低上游DNS故障对集群内部服务解析的影响。
• 处理Calico NFT后端的兼容问题
  • 临时把Calico的FELIX_IPTABLESBACKEND参数切回默认的iptables模式，跨节点验证DNS解析是否恢复正常。如果切回后DNS立即正常，说明是NFT后端的规则匹配存在兼容bug，等待Calico版本更新修复即可。
  • 如果必须使用NFT后端，检查Calico Felix的规则插入逻辑，确保跨节点到CoreDNS的53端口UDP流量不会被规则链误匹配DROP。

• 在任意业务Pod内执行nslookup kubernetes.default，正常返回对应ClusterIP
• 在业务Pod内执行nslookup currency-exchange.default.svc.cluster.local，正确返回currency-exchange Service的ClusterIP
• 重新触发currency-conversion的跨服务调用，不再抛出bad address错误，能正常获取接口响应
• 查看CoreDNS Pod日志，不再出现大量i/o timeout的上游请求错误

内容的提问来源于stack exchange，提问作者Faris Cina