生产环境k8s偶发超时问题排查及解决

本文主要是介绍生产环境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 日志没有发现异常。