K8s集群中Node.js Pod出现getaddrinfo ENOENT错误的排查咨询

我们项目中部署在K8s集群内的多个Node.js微服务，有时会因域名解析错误导致HTTP调用失败。

例如，某服务调用同命名空间内的crud-service时出现如下异常：

Error: getaddrinfo ENOENT crud-service
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:109:26)
    at GetAddrInfoReqWrap.callbackTrampoline (node:internal/async_hooks:130:17)

目前已确认以下情况：

• 该问题为偶发，无明确触发原因；
• 在出现问题的Pod中执行nslookup crud-service命令，域名解析正常；
• 多个Pod均存在此问题，调用集群外部主机时也会出现；
• 该问题与DNS服务器无关，若为DNS问题应出现EAI_AGAIN错误，无效主机则会出现ENOTFOUND错误。

排查思路与定位方法 #

一、Node.js自身DNS机制排查 #

• 检查DNS缓存配置：Node.js默认缓存DNS查询结果，可通过process.env.NODE_DNS_CACHE_TTL查看缓存超时时间，尝试临时设置NODE_DNS_CACHE_TTL=0禁用缓存，观察问题是否复现。
• 捕获DNS解析日志：在服务中添加DNS模块的监听逻辑，记录dns.lookup、dns.resolve的调用参数、结果与错误，同时确认服务使用的DNS服务器地址，对比解析失败时的进程状态（如内存、CPU占用）。
• 对比解析方式差异：Node.js的http模块默认用dns.lookup（依赖系统libc），而nslookup直接调用DNS服务器。可在代码中替换为dns.resolve发起解析，对比两种方式的错误出现频率，判断是否为libc层面的解析问题。

二、K8s集群网络环境排查 #

• 检查Pod的DNS配置：通过kubectl exec <pod-name> -- cat /etc/resolv.conf查看Pod内的nameserver、search、options配置，对比正常Pod与异常Pod的配置差异，确认是否存在DNS服务器地址变更的情况。
• 验证DNS端口可达性：在异常Pod中用nc -zv <dns-server-ip> 53测试DNS服务器的UDP/TCP 53端口是否可达，排查偶发的网络抖动导致的请求失败。
• 检查CoreDNS状态：查看kube-system命名空间下CoreDNS Pod的运行日志（kubectl logs -n kube-system <coredns-pod-name>），搜索是否存在查询超时、过载的记录，确认DNS组件是否存在异常。
• 排查Pod资源限制：通过kubectl top pod <pod-name>查看Pod的CPU、内存使用情况，若资源接近限制阈值，可能导致Node.js进程无法及时处理DNS请求，进而抛出异常。

三、系统与libc层面排查 #

• 确认libc版本：在Pod中执行ldd --version查看libc版本，对比正常与异常Pod的版本是否一致，不同版本的libc可能存在DNS解析逻辑差异。
• 持续测试系统DNS解析：编写脚本循环执行nslookup crud-service并记录结果，同时关联Node.js服务的错误时间点，查看是否存在时间上的对应关系。
• 排查并发请求限制：部分K8s网络插件或系统可能限制DNS请求并发数，当服务并发发起大量查询时可能触发限制，尝试调整服务的DNS请求并发数，观察问题是否缓解。

四、应用代码与依赖排查 #

• 检查HTTP客户端配置：若使用第三方HTTP客户端（如axios），查看其是否有自定义DNS解析或超时配置，部分客户端可能将解析错误映射为ENOENT。
• 验证动态域名逻辑：确认代码中是否存在动态生成域名的场景，排查是否有偶发的变量拼接错误导致无效域名（虽可能性低，但需排除）。
• 升级依赖包：检查DNS、网络相关依赖包是否存在已知bug，尝试升级到最新稳定版本，排除依赖包问题导致的异常。

内容的提问来源于stack exchange，提问作者Stefano Modena