K3S集群中Node.js后端Pod运行5-30小时后出现ENOTFOUND错误的原因排查求助

云上老周

2026-4-28

结合你在K3S v1.21.5+k3s2集群中运行Node.js后端服务的场景，以及高并发压力测试下出现的无规律ENOTFOUND错误（对应employees-service的DNS解析失败），我来梳理几个核心排查方向——这些都是这类问题里比较常见的诱因：

1. 集群DNS组件（CoreDNS）的稳定性问题

K3S默认用CoreDNS作为集群内部DNS服务，高并发压力下CoreDNS的性能或稳定性可能出问题：

先检查CoreDNS Pod的运行状态，看有没有频繁重启、资源耗尽的情况：
```
kubectl get pods -n kube-system -l k8s-app=kube-dns
```
查看CoreDNS的日志，确认有没有缓存失效、上游DNS超时或者服务端点同步延迟的报错：
```
kubectl logs -n kube-system -l k8s-app=kube-dns
```
另外，K3S v1.21版本的CoreDNS默认配置里，cache插件的缓存时长是否合理？如果缓存TTL过短，高并发下会导致重复解析请求过载；也可以检查是否启用了loop插件防止循环解析，避免解析异常。

Node.js的DNS解析依赖系统线程池，高并发场景下容易出现瓶颈：

Node.js默认UV_THREADPOOL_SIZE是4，DNS解析会占用这些线程，压力测试下线程池耗尽会导致解析延迟甚至失败。可以尝试给Pod设置环境变量UV_THREADPOOL_SIZE=64（根据实际并发调整），提升线程池容量。
检查Node.js的DNS缓存策略：默认的DNS缓存TTL可能和K8S Service的DNS记录TTL不匹配，或者你有没有使用第三方DNS客户端（比如dns-promises）导致解析逻辑异常。可以手动验证在Pod内执行nslookup employees-service，看是否能稳定解析。

employees-service作为K8S Service，其后端Pod的扩缩容、重启可能导致Endpoint同步不及时，进而DNS解析异常：

检查employees-service对应的Endpoint状态，确认里面的IP是否和实际运行的Pod IP一致，有没有出现Endpoint为空或IP过期的情况：
```
kubectl get endpoints employees-service
```
检查kube-proxy Pod的运行状态和日志，kube-proxy负责同步Service和Endpoint规则，若它出现异常会导致服务解析失效：
```
kubectl get pods -n kube-system -l k8s-app=kube-proxy
kubectl logs -n kube-system -l k8s-app=kube-proxy
```

部分Pod的DNS配置错误或网络策略拦截了DNS请求：

进入出现错误的Pod，检查DNS配置文件/etc/resolv.conf，确认nameserver指向CoreDNS的ClusterIP（通常是10.43.0.10），且包含正确的搜索域（比如default.svc.cluster.local）：
```
kubectl exec entrypoint-sdk-54c8788caa-aa3cj -- cat /etc/resolv.conf
```
检查集群内的网络策略，确认没有禁止Pod访问kube-system namespace下的CoreDNS服务（需要允许UDP/TCP 53端口的流量）：
```
kubectl get networkpolicies
```

节点的网络波动、DNS缓存或iptables规则异常也可能导致解析失败：

登录到错误Pod所在的节点，检查节点的/etc/resolv.conf是否正常，手动执行nslookup employees-service测试解析稳定性。
检查节点的iptables规则，确认K3S kube-proxy配置的Service转发规则是否存在且正常：
```
iptables-save | grep employees-service
```
排查节点的网络状态，比如网卡是否有中断、路由是否正常，这些都可能导致DNS请求无法到达CoreDNS。

建议你先从CoreDNS状态和Node.js线程池配置入手排查，这两个是高并发压力测试下最容易触发问题的点，再逐步验证其他方向。

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