一波四折——记一次K8S集群应用故障排查_pod name or service not known-优快云博客

本文链接：https://blog.youkuaiyun.com/EdwardSoftWare/article/details/112098311

本文详述了一次K8S集群应用遇到的DNS解析和数据库连接超时问题的排查过程。从Pod的日志分析，确认问题出在CoreDNS Pod上，发现是由于网络问题导致CoreDNS Pod异常，最终定位到云主机弹性网卡识别问题。在修复DNS问题后，又面临应用调用响应慢的情况，通过深入分析发现是数据库慢查询和OSS文件传输延迟所致。通过对数据库进行优化和修正DNS解析配置，问题最终得到解决。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一波四折——记一次K8S集群应用故障排查

part1 初露端倪

一个周四的下午，客户的报障打破了微信群的平静。“我们部署在自建K8S集群上的应用突然无法正常访问了，现在业务受到了影响！”收到客户的报障，我们立刻响应，向客户了解了问题现象和具体报错信息。客户反馈K8S集群部署在云主机上，K8S的应用pod example-app通过访问外部域名example-api.com调用接口，同时访问云数据库做数据查询后将结果返回客户端。客户排查应用pod日志，日志中有如下报错在这里插入图片描述
可以看到最关键的信息是Name or service not known。该报错一般为域名无法解析导致的。由于客户的应用pod只访问example-api.com这一个外部域名，因此判断应该是pod解析该域名时出现异常。为了进一步验证，我们执行kubectl exec -it example-app /bin/sh命令进入pod内执行ping example-api.com命令，果然出现了相同的报错。
在这里插入图片描述
因此可以确认应用日志中的报错是域名解析失败导致的。
执行kubectl get pod example-app -o yaml|grep dnsPolicy查看pod的dns策略，是ClusterFirst模式，也就是pod使用K8S集群的kube-dns服务做域名解析。
执行命令kubectl get svc kube-dns -n kube-system，确认kube-dns服务的clusterIP是192.168.0.10 查看pod内的/etc/resolv.conf文件，nameserver设置的正是该IP。
再执行kubectl describe svc kube-dns -n kube-system|grep Endpoints，可以看到dns服务关联了一个coredns pod作为后端。
执行kubectl get pods -n kube-system|grep coredns看到kube-dns关联的coredns pod处于running状态。
再执行kubectl logs coredns –n kube-system，看到pod日志中有大量和客户配置的外部dns服务器IP地址通讯超时的报错
在这里插入图片描述
10.16.16.16和172.16.16.16为客户自建DNS服务器的IP地址。为了确认是否是DNS服务器有问题，我们在example-app pod中分别执行nslookup example-api.com 10.16.16.16和nslookup example-api.com 172.16.16.16，均能解析出正确的IP地址。因此判断问题应该出在coredns pod上。此时我们发现，coredns pod的状态变成了crashloobbackoff，稍后又变成了runni