K8S集群中Pod资源与其他服务连接超时排查思路

1.Pod与其他服务连接超时的现象

在K8S集群中，经常也会遇到Pod与其他服务连接超时的现象，例如Pod与Pod之间的服务请求超时、Pod与K8S集群之外的其他服务连接超时、Pod与Node节点之间连接超时。

• Pod与Pod之间网络连接超时：
  • Pod中的容器中提供的服务可能会与多个系统之间进行调用，应用程序都是以Pod的形式运行的，可能会由于网络的原因，导致Pod与Pod之间无法正常调用，从而影响系统的使用。
• Pod与虚拟机中的服务连接超时：
  • 一般来说，应用程序都会部署在K8S集群以Pod的方式运行，而一些服务依赖的中间件则是在虚拟机环境或者物理机环境部署的，也会因为某种原因导致Pod与虚拟机中的服务连接超时。
• Pod与Node节点连接超时：
  • Pod可能由于网络原因会与Node节点连接超时，此时Pod中的应用程序将无法对外提供服务。

2.Pod服务连接超时的排查过程

2.1.问题1：Pod中的容器无法上网导致服务连接超时

Pod中的容器有需要上网的需求，例如容器中的服务是转码服务，那么就需要上网去连接OSS存储转码前后的文件，如果容器不能上网，那么就会导致转码服务异常，从而影响应用程序的使用。

排查思路：

1）首先在Node节点上ping百度的域名，验证Node节点是否可以上网，如果不可以ping通，可以尝试ping 114.114.114.114这个地址，域名ping不同不代表不可用上网，也可能是DNS解析的问题，如果公网地址可以ping通，那就表示可以上网，此方法也可以在容器中进行测试排查。

2）如果Node节点依旧不可用上网，那么就需要排查Node主机的网络问题了。

3）如果Node节点可以上网，那么就检查一下网络是否开启了桥接模式，容器中上网是和宿主机的网卡有关联的，查看/proc/sys/net/bridge/bridge-nf-call-iptables文件中的值是不是1，如果不是1，则将值改成1，问题就会得到解决。

2.2.问题2：Pod中的容器与集群外的其他服务连接超时

在生产环境中，可能会遇到Pod中容器的服务与其他外部的服务连接超时，例如数据库服务、缓存服务等等，可能是网络原因，也可能是中间件的配置原因，导致Pod资源连接超时。

排查思路：

1）排查容器中服务连接中间件的地址是否配置正确。

2）在Node节点尝试Telnet中间件的地址，验证是否可以进行TCP连接，然后进入容器中也使用Telnet的方式测试能否正常连接。

3）如果Node节点上也连接不上中间件的地址，那么可能是网络通信问题，也可能是中间件服务配置的问题，这时就可以去中间件服务器上进行测试，如果可以连接，那么久可以判定为是网络问题。

4）如果Node节点可以连接上中间件的地址，容器中无法连接，可能就是由于K8S网络组件异常导致的，可以去排查网络组件的日志进行分析。

5）如果Node节点和容器都无法连接中间件，那么也可能是由于中间件配置了某些策略导致，需要去排查策略的设定。

2.3.问题3：Node节点与Pod连接超时

K8S集群运行一段时间后，发现Pod资源中的服务无法对外提供服务了，并且在Node节点上也无法ping通Pod的地址，这时就有可能是K8S网络出现了问题，具体需要去排查网络组件、Apiserver、Kubelet等组件的日志，进行分析。

2.4.问题总结

当出现Pod资源网络连接超时时，都可以按照如上思路镜像排查和分析。

如果还是无法解决问题，可以试着在目标端抓包然后进行分析。

抓包分析可能会发现的问题：

在目标端进行抓包时会发现请求的源IP都是K8S Node节点的地址，没有Pod资源的IP，这时因为Pod在请求集群之外的服务时，会将IP通过NAT方式转换成Node节点的IP，由Node节点去请求对应的服务。

此时可能就不是网络通信的问题了，也可能是K8S连接到目标服务的方式有问题，在TCP连接中为了将端口快速回收，会对连接进行时间戳的检查，如果发现后续的请求中时间戳小于缓存的时间戳，就会被视为无效，就会将数据包丢弃。

每一次TCP连接请求都会有一个时间戳，Pod访问外部服务时，会将地址转换成Node节点的地址，一个应用程序会有很多个Pod资源，第一个Pod请求目标服务时，将该请求的时间戳写入到了缓存中，第二个Pod来请求时，TCP会发现来自同一个地址请求的时间戳与缓存中的时间戳不匹配，此时就会将数据包丢弃。

抓包后发现异常的解决思路：

检查目标服务的内核参数配置，观察net.ipv4.tcp_tw_recycle和net.ipv4.tcp_timestamps参数是不是同时设置为1，如果是，那么就可能导致丢包的现象。需要将net.ipv4.tcp_tw_recycle设置为0关闭，就可以解决此问题。

对于目标服务来说，请求的源地址是Node节点IP，所以在该服务看来，不同的Pod请求经过NAT的转发，会被认为是同一个连接，加上Pod请求的时间可能不一样，所以就会出现时间戳错乱的现象。

3.Pod连接超时的排查思路

1）首先排查网络组件Calico或者Flannel的状态是否是Running，如果状态存在异常，则从日志中提取中心信息进行分析。

2）检查Pod的网络环境，测试Pod与Pod之间的连通性，再测试Pod与Node之间的连通性

3）抓包检测是否存在异常的状态。

文章来源: jiangxl.blog.csdn.net，作者：Jiangxl~，版权归原作者所有，如需转载，请联系作者。

原文链接：jiangxl.blog.csdn.net/article/details/126177482