前言： 凡是有明确报错的问题，都是能很快解决的，真正难以解决和排查的，是偶发且笼统报错的问题。 这里记录整个解决的过程，期间有走过弯路，有思维局限，但庆幸最终找到了原因，正常把我们系统上线到 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 到指定开通的端口范围；