本文主要是介绍生产环境k8s偶发超时问题排查及解决,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
前言: 凡是有明确报错的问题,都是能很快解决的,真正难以解决和排查的,是偶发且笼统报错的问题。 这里记录整个解决的过程,期间有走过弯路,有思维局限,但庆幸最终找到了原因,正常把我们系统上线到 k8s 平台了。
问题表现:
生产某套应用访问时,偶尔会报 timed out 。相同的配置在 开发、测试、预生产都能正常运行。
排查思路:
1、 首先,因为这个问题是偶发性的,因此这个问题很可能是由于某部分服务器网络不通畅导致;
2、 由于开发、测试、预生产是相同的 k8s yaml 文件,因此排除因为部署导致该问题的可能;
3、 不排除由于生产环境 k8s 平台本身导致该问题的可能,因为在平台上运行的另一个系统在当月 12 日也发生过超时问题。
针对第一点,我通过 以下方法进行监控:
1、 shell 脚本 for 循环ping集群各个节点IP,验证集群网络的稳定性;
#!/bin/bash
for ((i=0;i<=43200;i++)); do
sleep 2time=$(date "+%Y-%m-%d %H:%M:%S")echo $time >> /app/test/xx3.txt
echo $time >> /app/test/xx4.txt
echo $time >> /app/test/xx5.txt
echo $time >> /app/test/xx6.txt
echo $time >> /app/test/xx7.txt
echo $time >> /app/test/xx8.txt
echo $time >> /app/test/xx9.txt
echo $time >> /app/test/xx0.txt
echo $time >> /app/test/xx1.txt
echo $time >> /app/test/xx6.txt
echo $time >> /app/test/xx7.txtping -c1 -w2 10.28.x.xx3 >> /app/test/xx3.txt
ping -c1 -w2 10.28.x.xx4 >> /app/test/xx4.txt
ping -c1 -w2 10.28.x.xx5 >> /app/test/xx15.txt
ping -c1 -w2 10.28.x.xx6 >> /app/test/xx6.txt
ping -c1 -w2 10.28.x.xx7 >> /app/test/xx7.txt
ping -c1 -w2 10.28.x.xx8 >> /app/test/xx8.txt
ping -c1 -w2 10.28.x.xx9 >> /app/test/xx9.txt
ping -c1 -w2 10.28.x.xx0 >> /app/test/xx0.txt
ping -c1 -w2 10.28.x.xx1 >> /app/test/xx1.txt
ping -c1 -w2 10.28.x.xx6 >> /app/test/xx6.txt
ping -c1 -w2 10.28.x.xx7 >> /app/test/xx7.txtecho "\n" >> /app/test/xx3.txt
echo "\n" >> /app/test/xx4.txt
echo "\n" >> /app/test/xx5.txt
echo "\n" >> /app/test/xx6.txt
echo "\n" >> /app/test/xx7.txt
echo "\n" >> /app/test/xx8.txt
echo "\n" >> /app/test/xx9.txt
echo "\n" >> /app/test/xx0.txt
echo "\n" >> /app/test/xx1.txt
echo "\n" >> /app/test/xx6.txt
echo "\n" >> /app/test/xx7.txt
done
脚本中的几个IP是我需要部署应用所使用到的主节点及其物理机IP,每两秒ping所有地址,将结果记录到txt文档中,因为我遇到的网络timed out 时间比较长,大概有几十秒没有响应,因此我统计各个IP对应的txt文档中,零点几秒的记录和总数做对比,来确定超时的请求数量。
当然有更好的脚本可以实现监控网络,我这里有点偷懒,随便写的,大家随便参考。
实际的监控结果是,集群内部物理机之间网络很稳定。
针对第三点,结合当天发生超时的日志,发现是由于服务重启时,域名缓存导致。
具体原因如下:
1、 前端通过nginx进行发布并跳转后端应用,后端应用的域名使用 k8s 内部域名;
2、后端应用删除了svc,并更新了内部域名对用的 ClusterIP;
3、 nginx中缓存的内部域名记录的还是老 ClusterIP ,导致访问 timed out;
针对这一点,我们优化了发布应用的流程及脚本解决了。
解决以上两点问题后,决定重新上线看是否还会出现超时的问题,结果发现超时的问题还是时有发生。
在没有找到其他问题的情况下,我在想是否是集群本身出现了问题:
查看kubelet的日志,发现了以下报错:
W0701 15:05:59.697391 9931 watcher.go:87] Error while processing event ("/sys/fs/cgroup/devices/libcontainer_34389_systemd_test_default.slice": 0x40000100 == IN_CREATE|IN_ISDIR): inotify_add_watch /sys/fs/cgroup/devices/libcontainer_34389_systemd_test_default.slice: no such file or directory
该问题是由于docker的引擎与k8s的引擎不一致导致,解决办法参考我的这一片博客:
《修复由于docker、k8s的引擎不一致导致的报错: 调整为cgroups》
https://blog.csdn.net/Jerry_Pan1990/article/details/103233485
问题解决后,kubelet不报错了,但是超时的问题还是继续,当时的心情真实崩溃的,上线的时间马上到了,急地我嘴角长泡。
遇到问题,还是得冷静下来,重新分析问题:
既然当前条件已经没有新的已知条件了,那么为什么不引入新的变量进行观察?
我将另外一个系统迁移到这个k8s环境进行验证,发现该系统运行竟然是良好的!!!
那么说明什么问题呢?
k8s环境是良好的,至少对于新引入的系统是这样的。
但另一个问题就是:为什么对原系统来说,会偶发timed out 的问题?需要知道 timed out 就是网络超时导致的。为什么有时候可以网络通畅,有时候又不通?超时的触发条件是什么?
在这里我又一次走了弯路,当时我在想会不会是coredns导致?
查看 coredns 日志没有发现异常。
因此我又在超时的调用者 A 容器中,添加了 新的监控,监控 curl B-service 的某个接口,查看是否出现了超时,结果是完全正常!!! 但是调用另外一个接口就会出现超时的情况。
到这里,可以确定,超时只是出现在程序中某些应用某部分接口。
叫开发同学来一起看,他们完全没有头绪,只是告诉我代码是一样的,好吧,还是得我来搞定。
没办法,我就在想,能否进行抓包来分析?
第一步当然是安装tcpdump工具,可以参考我这篇文章:
《封装一个带有tcpdump工具的镜像,在容器中使用tcp抓包》
https://blog.csdn.net/Jerry_Pan1990/article/details/103234441
抓包后,使用wireshark进行分析:
发生超时,会出现 TCP Retranmision 超时。
进一步分析得知,原来是应用访问的数据库在 6 网段,而我的k8s集群部署在 8 网段,
在建立数据库连接时,应用的jdbc会进行tcp握手,具体的网络路由如下:
容器内应用 ---> 宿主机物理网卡 (畅通)
宿主机物理网卡 ----> 数据库IP:8066 (偶尔阻塞)
物理机发送tcp连接时,使用的是动态端口是通过如下文件指定的:
vi /proc/sys/net/ipv4/ip_local_port_range
而网络上 8 网段物理机 到 6 网段物理机 部分端口是没有开通入站规则的。
这就导致在 32768 - 60999 动态端口范围内,如果刚好落在开通的端口范围内,则可以访问通畅,如果落在未开通的端口范围,则会出现数据连接超时,从而导致应用访问超时。
解决方法:
调整 ip_local_port_range 到指定开通的端口范围;
这篇关于生产环境k8s偶发超时问题排查及解决的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!