几个容器网络问题实战解析
容器云平台和容器网络紧密结合，共同构建了容器化应用程序的网络基础设施，实现了容器之间的通信、隔离和安全性。文中容器云平台采用的容器网络组件是 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 的结果上来分析，所有 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)偶发性异常。相关业务日志
抓包分析-通过对比正常号码充值与异常号码充值的网络包
既然是偶发性异常，那么一定是存在正常的业务流程与异常的业务流程；接下来大的思路就是对比正常业务流程下的业务收/发包与异常流程下收/发包，然后比较差异。
首先重点从业务日志中找出关键的数据包中必传输的关键字信息，比如本例中充值号码："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 有多次的断链，按以往经验来看，之前没有发生过断链，都是长链接。项目上关于多次断链有点担心，怕存在隐患。
问题表现
相关日志
由于是线上环境，首先要考虑的是对线上业务的影响。从日志中评估出每小时发生的概率不高，因此，可以实施抓包。
初步抓握手包-观察断链及规律
特别强调一下，为了最大程度地不影响线上环境，只抓少量的包，且只抓建链、断链的包，即 3 次握手、4 次握手。此次抓包不同于前面的直接基于 IP 与端口抓包，会加一些稍显复杂的过滤条件，尽可能减少线上环境的影响，只抓 1000 个包，只在网关节点上抓包
基于抓包文件分析-取片段：
在实际的分析中是取了多个片段进行分析的，总体发现一个规律 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 版本开始，代码实现上加入了超时断开的功能
经过反复测试，断链的问题清楚，不用担心，可以忽略，属于正常机制
版权声明: 本文为 InfoQ 作者【鲸品堂】的原创文章。
原文链接:【http://xie.infoq.cn/article/54558b9edf0dcab7f6529eb67】。文章转载请联系作者。
全球领先的数字化转型专家 2021-03-16 加入
鲸品堂专栏，一方面将浩鲸精品产品背后的领先技术，进行总结沉淀，内外传播，用产品和技术助力通信行业的发展；另一方面发表浩鲸专家观点，品读行业、品读市场、品读趋势，脑力激荡，用远见和创新推动通信行业变革。
评论