生产环境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 2

time=$(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.txt

ping -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.txt

echo "\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 到指定开通的端口范围；