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

举报
jiangxl 发表于 2022/08/06 00:46:23 2022/08/06
【摘要】 K8S集群中Pod资源与其他服务连接超时排查思路 文章目录 K8S集群中Pod资源与其他服务连接超时排查思路1.Pod与其他服务连接超时的现象2.Pod服务连接超时的排查过程2.1.问题1:Po...

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

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。