服务器环境以及配置

【机型】

处理器：	Intel 32核
内存：	128G
整机类型/架构：	x86_64虚拟机

【内核版本】

4.19.90-25.22.v2101.kylin.x86_64

【OS镜像版本】

银河麒麟高级服务器操作系统V10 SP2（kylin server V10 SP2）

【第三方软件】

开阳k8s

现象描述

前端机器访问后端容器超时，业务中断。

现象分析

网络环境拓扑

centos前端访问腾讯负载均衡CLB的9083端口，CLB从k8s集群的20个节点中选择一台将前端的访问请求转发到其30170端口，转发节点再将前端的访问请求转发到提供所需服务的worker node，由worker node的pod为前端提供服务。

网络数据包文件分析一

hive.n920e1nodap0050.0220.pcap为2月20日复现问题时在转发节点n920e1nodap0050捕获的网络数据包文件。

转发节点n920e1nodap0050的ip为10.209.34.80，tcp stream 171为前端和后端之间的TCP连接。

前端发送给转发节点的783号包的seq为2879，tcp data len为4。

图 2

前端发送给转发节点的784号包的tcp data len为1398, IP首部带有不允许分片的flag。

图 3

图 4

前端发送给转发节点的785号包的tcp data len为1307。

图 5

转发节点发送给前端的786号包的ack为2883，这正好是783号的seq+len。说明，后端pod收到了783号包，786号包是对783包的ack。

图 6

786号包带有TCP选项SACK，向发送端（前端）报告了一个空缺，后端pod还未收到seq为2883到4280（长度为1398）的数据，即784号包，就已经收到了seq为4281到5587（长度为1307）的数据，即785号包。

图 7

前端收到786号包后，了解到后端pod已经收到了785号包，但是没有收到784号包，于是重传784号包，重传多次，均未收到后端pod对该包的ack，最终导致TCP连接中断。

图 8

图 9

网络数据包文件分析二

n920e1infap0001.0229.pcap为2月29日复现问题时在转发节点n920e1infap0001捕获的网络数据包文件。

图 10

转发节点发送给后端pod的864号包包含seq从2939到2942长度为4的tcp data。

图 11

转发节点发送给后端pod的865号包包含seq从4341到5073长度为733的tcp data。还未发送seq为2943到4340长度为1398的tcp data，就已经发送了seq从4341到5073长度为733的tcp data。因次，wireshark给865号包打上了”TCP Previous segment not captured”的提示。和2月20日的情形一致，后端pod均未收到长度为1398的tcp data。

图 12

长度为1398的tcp data丢包原因分析

由分析可知，后端转发节点的eth0网卡收到了frame len为1464，tcp len为1398的tcp数据包，但是后端pod并未收到。由分析可知，后端转发节点的eth0网卡并未将tcp len为1398的tcp数据包转发给后端pod。

后端转发节点的eth0网卡收到前端发送的数据包之后，在转发给后端pod前，会先交给后端转发节点的tunl0网卡处理（设置IP头部数据等）。

因此，tcp len为1398的tcp数据包是在转发节点的tunl0网卡的接收或者转发过程中丢失的。

小包可以成功接收，但收不到大包，一个常见的原因是IP数据报的长度超过了网卡的mtu。

tcp len为1398的tcp数据包的IP数据报的长度为20（IP首部长度）+32(TCP首部长度)+1398（应用数据）=1450。

图 13

k8s集群节点的tunl0网卡的mtu为1440，小于tcp len为1398的IP数据报的长度1450。由图 4可知，前端发送的数据包IP首部带有不允许分片的flag。因此，该数据包会在转发节点的tunl0网卡接收过程中被drop掉。

图 14

分析结果

前端机器访问后端容器超时的原因是： 前端发送的长度超过后端转发节点的tunl0网卡的mtu的IP数据报在传输过程中被后端转发节点的tunl0网卡drop，前端多次重传，均收不到对该类包的ack，最终导致TCP连接中断。

后续计划与建议

建议联系k8s厂商或客户侧k8s环境管理员，适当调整集群节点的tunl0网卡的mtu。