鲸品堂|几个容器网络问题实战解析

2024-04-30 202

容器云平台和容器网络紧密结合,共同构建了容器化应用程序的网络基础设施,实现了容器之间的通信、隔离和安全性。文中容器云平台采用的容器网络组件是calico,这个是业界普遍采用的一种方案,性能及安全性在同类产品中都是比较好的。本篇就笔者在近期项目上所涉及的几个容器网络问题,依据真实案例,分享如何通过网络抓包进行问题的解析与处理


实战一、因基础网络层MTU不一致引发的应用访问偶发性超时


MTU,即Maximum Transmission Unit(最大传输单元),此值设定TCP/IP协议传输数据报时的最大传输单元,单位字节。传统的网络模式下,如果此值设置得太小,网络性能会受影响;如果设置得太大可能触发“部分网站打不开”等问题。


在容器环境下,容器网络借助于IAAS层网络传输来达到分布式服务间的网络通讯。容器环境下的典型特征是:服务都是多实例的、分布式的、跨网段的、跨多网络区域、甚至跨VPC的。再加上容器网络本身也是一层虚拟化,特别是在overlay模式下,会额外嵌入一层协议,更增加了容器网络问题分析的复杂性。特别是当IAAS较复杂的组网模式时,如果MTU不合理,可能导致以下问题:



大包阻塞(Jumbo Frames):如果不同网段的设备或路由器的MTU设置不一致,可能会导致大于某个网络段MTU的数据包无法通过。这可能导致大包阻塞,因为在路径上的某个点上,数据包将被分片或被丢弃。



丢包:当数据包在跨越网络段时被分片,而某个网络段无法容纳整个分片时,会导致分片的丢失。这可能会引起通信中的丢包情况,降低网络性能。



性能下降:分片和重组数据包会增加网络设备的负担,可能导致性能下降。特别是在高负载情况下,这可能会对容器间的通信产生显著的影响。

问题背景


某项目前端页面上出现个别菜单偶发性超时,但是如果重新点击又正常了。这种现象出现多次,且近期出现的次数更加明显。


应用的通讯架构可以抽象为如下:

图片关键词


问题表现



前端页面上出现个别菜单偶发性超时图片关键词

图片关键词



在前端浏览器上F12调试-504图片关键词

图片关键词



从调用链测发现调用有失败

平台的调用链引擎是pinpoint,业界很多厂商也是基于此技术栈实现分布式应用的调用拓扑、调用性能的分析。我们从调用链上可以看到前端与后端的请求中,有少数请求是超时的,可以明确看到Socket("message:"Read timeout..")的网络接收数据超时。从这里可以初步感受到问题是出在网络通讯上。图片关键词

图片关键词

调用与被调用的容器间的ping包都是正常的;做一些简单的curl也是正常的。


由于从调用链上能够得到的信息是出在网络上,而在容器环境下业务间的通讯是容器网络,于是首先从最基本的检查做起,理清前端、后端间的相关容器的节点分布情况,写脚本探测容器之间的网络稳定性,看看是不是会出现网络抖动或ping丢包。


最基本检查可以通过ping脚本来评估网络的稳定性,选取不同的节点上调度的容器,分别在前、后端容器内执行长时间的ping探测,并收集ping结果进行分析,脚本如下:




#长ping脚本,带时间戳,可以直接塞入相关被探测的容器中 #!/bin/bash for i in 100.80.95.XX 100.80.174.YY 100.80.90.ZZ 100.80.76.MM ... ;do ping $i | awk '{ print $0"\t" strftime("%Y-%m-%d %H:%M:%S",systime()); fflush()}' >> ./PingpodTopod.log & done


经过几个小时的探测(确保这个期间业务有偶发性超时问题发生),从ping的结果上来分析,所有ping的req包都有回包,没有丢包,且延时都非常低,从这里至少可以说明网络链路层是没有问题的。


那进一步做tcp层通讯的基本检查,从业务侧获取一些涉及tcp通讯且不会对生产环境产生任何影响的接口调用,在前端容器内对后端容器实行实施多次curl调用检查,从多对容器以及多次的抓取中可以看到所有的curl都是能够快速应答,且没有超时发生。


从最基本的链路层检测及tcp通讯的检测上来看,容器网络没有明显的问题。那么问题会出现在哪里?接下来对相关容器实施网络抓包,从网络包上看看能不能发现端倪。


容器网络抓包分析


限于篇幅,长言短叙,随便挑一对发生问题的异常容器,然后实施抓包分析。服务端抓包可以采取最常见的基于ip与port的过滤器来抓网络包。特别注意要分别在服务端与客户端进行抓包,好处是可以基于时间点及sequence来相互印证,找出有问题的包,然后对比分析,重点查看发出去的包有没有到达对端,对端的回包自己有没有收到、有没有重传等等,从异常中找出问题的线索。


在下图中:服务端容器100.80.95.126 、客户端容器100.80.174.53, 可以很明显地看到在问题发生的时间点有多次重传(TCP Retransmission), 进一步分析发现属于典型的丢包现象。具体分析细节见图注说明。图片关键词

图片关键词


客户端抓包分析

图片关键词


从客户端与服务端抓包的多个包的对比中,得出以下结论


客户端、服务端正常建链,客户端正常发送请求


服务端收到客户端请求后,客户端未收到服务端的回包


未收到的回包属于大包,大包(长度 >=6000 或者7000的包,服务端发了,但是客户端收不到)


再加上客户端容器、服务端容器主要在跨宿主机网段的的机器上,这些特点符合MTU的问题,因此,下一步调整MTU。一般来说,应该要检查一下IAAS层的网络设备的MTU的配置,但是IAAS资源都是局方的,而且也分属于不同部门,协调起来比较困难。因此,考虑在容器侧调整MTU,在经过客户的允许后,在夜晚调小了线上环境的容器网络的MTU,问题解决。


再次抓包,可以看到大的数据包也都可以正常传输了,见下图:图片关键词

图片关键词


从调用链上反馈也是正常的啦。图片关键词

图片关键词


结论


通过分析收发包的特点,找出异常数据包的发送情况,主要特征是:多发生在跨网段间的主机上,核心是小包能正常通讯,大包通讯上有问题,大包无法到达对端,典型的MTU配置不当的表现。


知道问题的原因了,那么解决问题的办法就很简单了,可以直接调小一点容器层面的MTU,从而可以规避此问题。


实战二、基于协议回包特点反推服务端的逻辑问题


在容器场景下,不仅要在容器平面进行MESH方式的通讯,常常容器还需要与外部通讯,甚至与第3方的厂家进行业务交互,困难点在于你无法清晰知道第3方服务的逻辑、也无法登录第3方环境,无法知道网络架构、网络安全配置等。这样的背景下,当业务出现异常且排除自己业务代码的问题层面之后,那么可借助网络抓包来进行分析,通过解析数据的的交互同时比对正常情况下的TCP流与异常情况下的TCP流的差异、同时基于业务采用具体业务协议下本来应该是个什么样的,从而来发现问题。


这种问题本质上不是网络问题,网络层面的通讯都是正常的,是业务逻辑上有潜在的问题,比如业务代码条件判断不够精确,误判走了不同的流程,回传了不需要的数据包。


问题背景


某项目上线期间发现API发起VC充值业务( CGMMLClient调用第三方的的MML接口 QUERY VC INFO)偶发性异常。相关业务日志








APPLICATION|ERROR|192.168.12.243|20|2022-12-15 12:39:38:971||70802003|ConnectorCacheHandler.java:86|postHandle|7083012|245|||Message is timeout, and handled. message [beginTime=2022-12-15 12:39:23.969,timeout=15000,interval=15002 : server channel=[1], channel=[/192.168.12.243:58034], channel=[/10.16.76.5:8124] adapter=[SocketClient-MML],sequence=[SocketClient-00018915], status=[REMOTING_TIMEOUT], lastHandlingObject=[com.ztesoft.zsmart.cg.service.binder.ServiceBindingRuleIntrp@2c881e0], command=[QUERY VC INFO] field list: {"OPTYPE":"1","transId":"000024f3","totalLen":{"_endPos_":8,"_value_":"0068","_startPos_":4},"sessionId":"00000000","terminal":"CCB00000","serviceName":"PPSPHS","version":"1.00","msgBeginFlag":"`SC`","transRemain":"FFFF","checkSum":"AA8A9495","COMMAND":"QUERY VC INFO","transControl":"TXBEG ","Body":{"_endPos_":112,"_startPos_":8},"sessionControl":"DLGCON","CARDNO":"516683732197360540","sessionRemain":"FFFF"} variable list: {"protocol":"MML","reomoteHost":"10.16.76.5","cg":"SocketClient-MML","resultCode":"REMOTING_TIMEOUT","__cost__":0,"command":"QUERY VC INFO","status":"REMOTING_TIMEOUT"} param list: {"arg0":{"opType":1,"class":"com.ztesoft.zsmart.bss.payment.orange.smartfren.bc.service.mml.QueryVcCardRequest","cardNumber":"516683732197360540"}} buffer=[。。。。。。] ]


抓包分析-通过对比正常号码充值与异常号码充值的网络包


既然是偶发性异常,那么一定是存在正常的业务流程与异常的业务流程;接下来大的思路就是对比正常业务流程下的业务收/发包与异常流程下收/发包,然后比较差异。


首先重点从业务日志中找出关键的数据包中必传输的关键字信息,比如本例中充值号码:"cardNumber":"516683732197360540"。


容器内抓包


容器内基于IP与port端口进行抓包,首先针对异常号码充值包分析,在业务容器内进行抓包,同时从业务侧获取问题发生期间的充值异常的号码,例如:CARDNO":"516683732197360540 ,基于此号码分析网络包。


现在的wireshark功能比较强大,可以通过match添加过滤条件,从TCP包中找出异常号码"cardNumber":"516683732197360540"对应的通讯链路,然后再逐一分析这个TCP流。

图片关键词图片关键词


另外,取正常号码充值包分析 ,比如正常的号码 CRD 160588272651221图片关键词

图片关键词


从比对中发现问题-第3方的服务端


从包中比对


包的主要特点:

1) 长链接; 

2) 整个网络流比较正常,第一次抓取的包,是在一个容器内做的;10万个包中真正发生重传的次数也就10来次,比率相当低的;且重传后都能得到及时响应,不存在网络丢包; 

3) 问题触发时,并不发生在包的重传上;

4) 整个单纯的TCP层面的通讯上没有明显问题;

5) 根据apig发包以及服务端的回应来看,收到的不是预想的包-这是重点。


从比对中发现,每次发生异常时,apig 正常发送了vc query请求包,没有收到vc qeury的应答包;而正常的充值的号码都是收到了应答包。因此服务端存在偶发性的回包问题,而服务端是局方管理的第3方公司提供的;之后经由与局方面对面沟通,同时比照务端业务日志的查看,问题确实在第3方公司的服务端。后经第3方公司核查完自己的服务端代码,发现一处条件的判断逻辑有问题,后经处理完服务端,该问题得到解决。


[要点] 分别找出正常充值时的TCP数据流与异常充值时的数据流,通过对比正常充值与异常充值的数据包,从而发现差异、介定异常。


实战三、websocket协议断链-大量断链包中发现规律+源码求证


WebSocket是一种在单个TCP连接上提供全双工通信的协议,它允许在客户端和服务器之间进行实时、双向的数据传输。WebSocket通讯的优点很多,以下重点提2个:



全双工通信:WebSocket允许双向通信,客户端和服务器可以同时发送和接收数据。这使得实时性应用程序的开发更为简便,例如在线聊天、实时协作和实时更新的Web应用程序。



持久连接:WebSocket连接是持久的,一旦建立连接,它可以保持打开状态,允许任何时候双方都能发送数据。这降低了频繁建立和断开连接相关的开销。


简单地说,基于websocket协议通讯的业务,都倾向于长时通讯,一般情况下不会去主动断开;如果项目上碰到websocket通讯有频发断链的情况,要引起注意,请明确这属于逻辑上设置的主动断链,还是异常断链;特别是在不了解背后实现逻辑的情况下,可以通过抓包,重点抓取3次握手与4次握手,来发现断链的规律、由谁发起的、属于主动断链、还是丢包导致的锻炼,有条件的要将抓包与源码进行比对分析,从而解决问题。


问题背景


业务网关与k8s APIServer之间websocket有多次的断链,按以往经验来看,之前没有发生过断链,都是长链接。项目上关于多次断链有点担心,怕存在隐患。


问题表现


相关日志











00:54:34:463|||WatcherWebSocketListener.java:66|onClose||43||||WebSocket close received. code: 1000, reason: k8s.log:APPLICATION|DEBUG|||2023-05-19 00:54:35:468|||WatchConnectionManager.java:60|closeWebSocket||475||||Closingwebsocket io.fabric8.kubernetes.client.okhttp.OkHttpWebSocketImpl@46de5f80 k8s.log:APPLICATION|DEBUG|||2023-05-19 00:54:35:468|||WatchConnectionManager.java:63|closeWebSocket||475||||Websocket already closed io.fabric8.kubernetes.client.okhttp.OkHttpWebSocketImpl@46de5f80 k8s.log:APPLICATION|DEBUG|||2023-05-19 01:52:47:876|||WatcherWebSocketListener.java:66|onClose||43||||WebSocket close received. code: 1000, reason: k8s.log:APPLICATION|DEBUG|||2023-05-19 01:52:48:880|||WatchConnectionManager.java:60|closeWebSocket||487||||Closingwebsocket io.fabric8.kubernetes.client.okhttp.OkHttpWebSocketImpl@7de2a21a k8s.log:APPLICATION|DEBUG|||2023-05-19 01:52:48:880|||WatchConnectionManager.java:63|closeWebSocket||487||||Websocket already closed ...(略) ...
抓包分析
抓包分析


由于是线上环境,首先要考虑的是对线上业务的影响。从日志中评估出每小时发生的概率不高,因此,可以实施抓包。


- 初步抓握手包-观察断链及规律


特别强调一下,为了最大程度地不影响线上环境,只抓少量的包,且只抓建链、断链的包,即3次握手、4次握手。此次抓包不同于前面的直接基于IP与端口抓包,会加一些稍显复杂的过滤条件,尽可能减少线上环境的影响,只抓1000个包,只在网关节点上抓包




sudo nohuptcpdump -i eth0 host XXX and port 6443 and \('tcp[tcpflags] == tcp-rst' or'tcp[tcpflags] == tcp-syn' or 'tcp[tcpflags] == tcp-fin' or 'tcp[13] & 1 != 0'\)-c 1000 -nn -vv -w ./host195-2-socket-esta-or-close-01.pcap &


基于抓包文件分析-取片段:

图片关键词


在实际的分析中是取了多个片段进行分析的,总体发现一个规律

1)服务端发起的断链

2)每个链接保持时长都在 (30分钟 60分钟)这个区间内,这一点很重要,这为我们后面在规定时间内抓取数据包提供很大的价值。


- 进一步抓数据包


为了不影响生产环境,在同版本的测试环境上进行同样方式抓包,同样具有此特点,后续就直接转到测试环境上进行分析...


按前面的规律,半小时至1小时内必然发生断链,因此,考虑抓取数据包。由于websocket是基于TLS的通讯,为了探索出到底是什么数据带来的影响,更进一步的措施做TLS数据包的解析。方便解包,仿照网关逻辑,写了一个golang的websocket测试程序,在测试环境上进行多轮测试。从抓包及websocket TLS解包中来看,是服务端正常的断开,服务发送了一个TLS Aller_message 21,解包中得出是 Close_notify,由此可以明确知道问题该从服务端查起。

图片关键词


如果不解析包,会是什么情况?可以看到全部是加密的数据,不是太好分析,举例

图片关键词


- 从k8s master源码分析


从k8s master源码分析,发现k8s master有个配置项,RequestTimeout,基本上从来没有用。限于篇幅,略去中间的摸索过程,见代码如下图片关键词

图片关键词


- 定位原因-版本差异


通过辛苦的版本比对及调试验证,最后找到是k8s高版本做了超时的修复,具体来说是k8s 1.15.0-alpha1,直接上个图:

图片关键词


由此可以看出,从1.15.0-alpha1版本开始,都是这样子的。后经与研发一起讨论,认为这个断链是正常的,不会有实质性的影响。


【要点】


从抓包中确认有websocket 断链发生,且是服务端发起的

抓取足够量的建链、断链,发现规律每(30分钟、60分钟)发生一次断链

通过以上2点确认排查方向是从k8s master服务端做起

结合TLS解包,确认这个断是TLS 21 消息,属于正常的断链包,排除了网络层面的影响

结合k8s master的启动项及源码发现高版本的源码中就是这样的设计逻辑

源代码层面,通过比对低版本与高版本的websocket处的实现,发现从1.15.0-alpha1版本开始,代码实现上加入了超时断开的功能

经过反复测试,断链的问题清楚,不用担心,可以忽略,属于正常机制


官方微信公众号

浩鲸云计算科技股份有限公司 版权所有 2003-2023

苏ICP备10224443号-6       苏公网安备 32011402011374号