Big Packet lose in K8s (二)_scsi virtio blk cirrus drm kms helper syscopyarea-程序员宅基地

技术标签： flannel networks Kubernetes network

新的征程

在第一篇定位 K8s环境中打包丢失的问题的时候，我们定位到 eth0收到了No.9 报文，但是 flannel.1 中丢失了No.9 报文。
那么在 eth0 到 flannel.1 之间，到底经过了什么处理，为什么丢包了呢？
因为我们配置K8s的 nodeport service 将外部30063端口转换为内部 3000端口，而service 的功能是由iptables实现的，所以我们将所有的矛头都指向了iptables

问题分析

1. 先看一下K8s 是怎么利用iptables 来进行端口映射的 `30063 -> 3000`

ps: iptables的语法规则真TMD繁琐， K8s在里面又增加了百来条的规则

以上是从浩如烟海的规则中抽取出来的几条，可以看出利用 iptables的 DNAT 方法，将所有收到的 dport = 30063的报文，都转换为 10.244.1.17:3000
从规则中没看出任何毛病，理论上iptables也不应该会有 小包通过，大包不过 的情况发生
但实在没有头绪，只能硬着头皮看看有没有iptabels 的debug手段了

2. Trace iptables

一通Google操作，还真找到了Debug iptables 的方法
细节不赘述了，可以参考后面链接

iptables -t raw -A OUTPUT -d 10.244.1.17 -j TRACE 
iptables -t raw -A PREROUTING -d 10.244.1.17 -j TRACE

modprobe ipt_LOG 
modprobe nf_log_ipv4 
sysctl net.netfilter.nf_log.2=nf_log_ipv4

2.1 小包日志日志


Jul 21 00:28:06 10-10-99-144 kernel: TRACE: raw:PREROUTING:policy:2 IN=cni0 OUT= PHYSIN=vethe57aa284 MAC=0a:58:0a:f4:00:01:0a:58:0a:f4:00:1a:08:00 SRC=10.244.0.26 DST=10.244.2.207 LEN=149 TOS=0x00 PREC=0x00 TTL=64 ID=64398 DF PROTO=UDP SPT=53 DPT=48865 LEN=129

Jul 21 00:28:06 10-10-99-144 kernel: TRACE: filter:FORWARD:rule:1 IN=cni0 OUT=flannel.1 PHYSIN=vethe57aa284 MAC=0a:58:0a:f4:00:01:0a:58:0a:f4:00:1a:08:00 SRC=10.244.0.26 DST=10.244.2.207 LEN=149 TOS=0x00 PREC=0x00 TTL=63 ID=64398 DF PROTO=UDP SPT=53 DPT=48865 LEN=129

Jul 21 00:28:06 10-10-99-144 kernel: TRACE: filter:KUBE-FORWARD:rule:2 IN=cni0 OUT=flannel.1 PHYSIN=vethe57aa284 MAC=0a:58:0a:f4:00:01:0a:58:0a:f4:00:1a:08:00 SRC=10.244.0.26 DST=10.244.2.207 LEN=149 TOS=0x00 PREC=0x00 TTL=63 ID=64398 DF PROTO=UDP SPT=53 DPT=48865 LEN=129

Jul 21 00:28:06 10-10-99-144 kernel: TRACE: raw:PREROUTING:policy:2 IN=cni0 OUT= PHYSIN=vethe57aa284 MAC=0a:58:0a:f4:00:01:0a:58:0a:f4:00:1a:08:00 SRC=10.244.0.26 DST=10.244.2.207 LEN=111 TOS=0x00 PREC=0x00 TTL=64 ID=64399 DF PROTO=UDP SPT=53 DPT=48865 LEN=91

Jul 21 00:28:06 10-10-99-144 kernel: TRACE: filter:FORWARD:rule:1 IN=cni0 OUT=flannel.1 PHYSIN=vethe57aa284 MAC=0a:58:0a:f4:00:01:0a:58:0a:f4:00:1a:08:00 SRC=10.244.0.26 DST=10.244.2.207 LEN=111 TOS=0x00 PREC=0x00 TTL=63 ID=64399 DF PROTO=UDP SPT=53 DPT=48865 LEN=91

Jul 21 00:28:06 10-10-99-144 kernel: TRACE: filter:KUBE-FORWARD:rule:2 IN=cni0 OUT=flannel.1 PHYSIN=vethe57aa284 MAC=0a:58:0a:f4:00:01:0a:58:0a:f4:00:1a:08:00 SRC=10.244.0.26 DST=10.244.2.207 LEN=111 TOS=0x00 PREC=0x00 TTL=63 ID=64399 DF PROTO=UDP SPT=53 DPT=48865 LEN=91

2.2 大包日志


Jul 21 00:30:09 10-10-99-144 kernel: ------------[ cut here ]------------

Jul 21 00:30:09 10-10-99-144 kernel: WARNING: CPU: 1 PID: 0 at net/core/dev.c:2496 skb_warn_bad_offload+0xcd/0xda

Jul 21 00:30:09 10-10-99-144 kernel: : caps=(0x00003021001b5889, 0x0000000000000000) len=1464 data_len=1336 gso_size=1398 gso_type=5 ip_summed=1

Jul 21 00:30:09 10-10-99-144 kernel: Modules linked in: nf_log_ipv4 nf_log_common xt_TRACE xt_LOG iptable_raw xt_statistic binfmt_misc nfnetlink_queue nfnetlink_log bluetooth loop cfg80211 rfkill nf_conntrack_netlink veth vxlan ip6_udp_tunnel udp_tunnel xt_nat xt_recent ipt_REJECT nf_reject_ipv4 ip_set nfnetlink xt_comment xt_mark ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype iptable_filter xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc overlay(T) sunrpc joydev sg ppdev virtio_balloon parport_pc i2c_piix4 parport pcspkr ip_tables xfs libcrc32c sr_mod cdrom ata_generic pata_acpi virtio_net virtio_console virtio_scsi virtio_blk cirrus drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix libata virtio_pci virtio_ring serio_raw

Jul 21 00:30:09 10-10-99-144 kernel: floppy i2c_core virtio dm_mirror dm_region_hash dm_log dm_mod

Jul 21 00:30:09 10-10-99-144 kernel: CPU: 1 PID: 0 Comm: swapper/1 Tainted: G W ------------ T 3.10.0-693.el7.x86_64 #1

Jul 21 00:30:09 10-10-99-144 kernel: Hardware name: Red Hat KVM, BIOS seabios-1.7.5-11.el7 04/01/2014

Jul 21 00:30:09 10-10-99-144 kernel: ffff88043fc439a0 a3eaaf6a30ee44fa ffff88043fc43950 ffffffff816a3d91

Jul 21 00:30:09 10-10-99-144 kernel: ffff88043fc43990 ffffffff810879c8 000009c0a6fd2cb2 ffff8803e6346100

Jul 21 00:30:09 10-10-99-144 kernel: ffff88041e2fa000 0000000000000005 0000000000000001 0000000000000004

Jul 21 00:30:09 10-10-99-144 kernel: Call Trace:

Jul 21 00:30:09 10-10-99-144 kernel: <IRQ> [<ffffffff816a3d91>] dump_stack+0x19/0x1b

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff810879c8>] __warn+0xd8/0x100

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff81087a4f>] warn_slowpath_fmt+0x5f/0x80

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff81329233>] ? ___ratelimit+0x93/0x100

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff816a6004>] skb_warn_bad_offload+0xcd/0xda

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff81588c25>] __skb_gso_segment+0x105/0x150

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff81589025>] validate_xmit_skb.isra.102.part.103+0x135/0x2e0

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff815897f0>] __dev_queue_xmit+0x4b0/0x550

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff815898a0>] dev_queue_xmit+0x10/0x20

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff815cfd3e>] ip_finish_output+0x52e/0x780

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff815d0293>] ip_output+0x73/0xe0

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff815cf810>] ? __ip_append_data.isra.48+0xa00/0xa00

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff815cbcf6>] ip_forward_finish+0x66/0x80

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff815cc08c>] ip_forward+0x37c/0x480

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff815cbc90>] ? ip_frag_mem+0x40/0x40

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff815c9cda>] ip_rcv_finish+0x8a/0x350

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff815ca666>] ip_rcv+0x2b6/0x410

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff815c9c50>] ? inet_del_offload+0x40/0x40

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff81586f22>] __netif_receive_skb_core+0x572/0x7c0

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff810ea8ca>] ? __getnstimeofday64+0x3a/0xd0

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff81587188>] __netif_receive_skb+0x18/0x60

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff81587210>] netif_receive_skb_internal+0x40/0xc0

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff81588318>] napi_gro_receive+0xd8/0x130

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffffc008d505>] virtnet_poll+0x265/0x750 [virtio_net]

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff8158799d>] net_rx_action+0x16d/0x380

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff81090b3f>] __do_softirq+0xef/0x280

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff816b6a5c>] call_softirq+0x1c/0x30

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff8102d3c5>] do_softirq+0x65/0xa0

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff81090ec5>] irq_exit+0x105/0x110

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff816b75f6>] do_IRQ+0x56/0xe0

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff816ac1ed>] common_interrupt+0x6d/0x6d

Jul 21 00:30:09 10-10-99-144 kernel: <EOI> [<ffffffff816ab4a6>] ? native_safe_halt+0x6/0x10

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff816ab33e>] default_idle+0x1e/0xc0

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff81035006>] arch_cpu_idle+0x26/0x30

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff810e7bca>] cpu_startup_entry+0x14a/0x1c0

Jul 21 00:30:09 10-10-99-144 kernel: [<ffffffff81051af6>] start_secondary+0x1b6/0x230

Jul 21 00:30:09 10-10-99-144 kernel: ---[ end trace 1d38ab13aa011722 ]---

在日志中，我们看到了有内核的报错. PS: 该报错之前在/var/log/message 中也有打印，但奈何该套环境错误日志太多，每秒上千条的日志量， mmp 某宇
确认No.9 报文丢失和该报错有关系

3. Error Message Analysis

从上面的log中可以看到以下几个关键点：
* skb_warn_bad_offload
* __skb_gso_segment
* ip_forward
* virtio_net

通过这些关键字进行Google，我们找到了N多的方案，一一尝试最终确认为网卡的 large-receive-offload 功能导致, 通过 ethtool -K eth0 lro off 解决问题。 — 世界都安静了

Tips：
之前认为报文从eth0 到 flannel.1 之间，中间只剩下了iptables。但是其实在iptables 做完了DNAT之后，将报文交给flannel.1之前，需要kernel 的协议栈的参与，需要协议栈对报文进行解析，然后根据router tables 将报文 forward 到对应的网口上。这也就是为什么会触发 ip_foward()调用的原因。因此 /proc/sys/net/ipv4/ip_forward 也必然等于1。

过程中的坑

1. 坑一

主机和虚拟机网络过于复杂，在确认LRO 与该问题有关系后，未能一把将全部物理机的全部网卡都修改到位，导致反复寻找原因

2. 坑二

之前测试过程中发现 APP网络访问有问题，但 CLS 网络访问没有问题，将一部分排查方向转移到了两者间的报文路径上
但其实是 APP网络用的是1GB网卡，默认LRO是关闭的，而cls网络用的10GB网卡，默认LRO是开启的

3. 坑三

在另外一台物理机上进行了模拟，开启LRO之后，确实会导致大包丢包，与K8s环境下的表现一致。但却没有发现相同的内核报错信息
现在怀疑是不同的操作系统版本问题，导致并没有报错日志

4. 坑四

在Redhat 官网上找到了同样的内核报错，同样的在虚拟化环境中跑docker。点我
但Redhat 官方解释是：这个报错只是一个警告，并没有其他恶劣的影响，将在redhat 7.6版本中修复。 wtf，老子丢包啊

智能推荐

INT 10H功能_int10 颜色背景-程序员宅基地

文章浏览阅读1.2k次。INT 10H 是由 BIOS 对屏幕及显示器所提供的服务程序，而后倚天公司针对倚天中文提供了许多服务程序，这些服务程序也加挂在 INT 10H 内。使用 INT 10H 中断服务程序时，先指定 AH 寄存器为下表编号其中之一，该编号表示欲调用的功用，而其他寄存器的详细说明，参考表后文字，当一切设定好之后再调用 INT 10H。底下是它们的说明：AH_int10 颜色背景

本机MySQL数据库安装_mysql本地安装-程序员宅基地

文章浏览阅读823次。本机MySQL数据库安装比较简单，但坑比较多，很容易出现安装好了但是在某些时候不能使用的情况；另外在卸载的时候，也容易出现卸载不干净，造成二次安装失败的情况，所以在安装前，一定要检查清楚，本地是否已经安装了MySQL。_mysql本地安装

QGIS二次开发(C++/Qt)：栅格计算器_qgis二次开发 c++-程序员宅基地

文章浏览阅读652次，点赞15次，收藏6次。编写一个具有加、减、乘、除、对数、指数计算功能的栅格图层计算工具，计算结果以tiff格式的栅格文件输出。思路：1.自行设计界面，逐个实现计算功能；2.调用QGIS原生栅格计算器。本文使用第二种方法，直接调用QGIS的栅格计算器。_qgis二次开发 c++

记一次 java.io.IOException: Attempted read from closed stream-程序员宅基地

文章浏览阅读4.4k次，点赞6次，收藏2次。在一次项目问题排查过程中，发现总是报错 java.io.IOException: Attempted read from closed stream，根据异常的堆栈分析，定位到了问题的根源。问题示例如下：public class Main { public static void main(String[] args) throws ClientProtocolException,..._java.io.ioexception: attempted read from closed stream.

Python中数据清洗缺失值，重复值和异常值的处理_df_replace_outliers = df.replace( df['a'],np.nan, -程序员宅基地

文章浏览阅读2.1k次。1 缺失值的处理1.1 常规缺失值的处理np.nan,NaN,None，NaT(时间数据类型的缺失值)等df.isnull()1.判断每一个df中的数据是否为缺失值，是则返回True,否则返回False2.可以利用True为1，False为0的特性，sum()即为缺失值数量df.notnull()判断每个df中的值是否不为缺失值，是不为缺失值返回True,不是不为缺失值则返回Falsedf.dropna() 1.删除缺失值，可以指定axis来控制删除出现缺失值的行或者列 2.使用dropna_df_replace_outliers = df.replace( df['a'],np.nan, )

SQLite3 极简教程 & Go 使用 SQLite 内存模式操作数据结构_golang sqlite 内存数据库附加-程序员宅基地

文章浏览阅读1.1w次。SQLite 简介关键词: RDBMS (embedded), CSQLite is a database engine written in the C language. It is not a standalone app; rather, it is a library that software developers embed in their apps...._golang sqlite 内存数据库附加

随便推点

golang unicode转utf-8_golang unicode转utf8-程序员宅基地

文章浏览阅读4.5k次。golang unicode转utf-8Unicode和utf-8的区别具体转换代码Unicode和utf-8的区别参考文章具体转换代码func handleResponse(resp *http.Response) (string, error) { respBytes, err := ioutil.ReadAll(resp.Body) defer resp.Body.Close()..._golang unicode转utf8

【全解析 | PTA】浙大版《Python 程序设计》题目集-第三章_len('3//11//2018'.split('/'))的结果是_____。-程序员宅基地

文章浏览阅读5.2k次，点赞52次，收藏111次。Python/PTA/浙大版/Python程序设计/题解_len('3//11//2018'.split('/'))的结果是_____。

成功粉碎北信源监控程序vrvedp_m.exe ,vrvrf_c64.exe,svchost.exe,vrvrf_c.exe-程序员宅基地

文章浏览阅读1.7w次，点赞4次，收藏12次。公司安装了北信源的监控软件，用360粉碎了大部分北信源的程序文件，但是有几个程序进程始终开机启动，进程无法杀死，一度成了我的一块心病！后来不知咋的灵光一闪，彻底将其粉碎的毛都不剩，现将成功经验分享给大家；电脑基本环境：win10 专业版，360安全卫士粉碎操作步骤（因我电脑已经粉碎了北信源，所以图片以其他文件做示范）：找到北信源残余卸载不到的程序文件所在的位置（就是这些东西vr..._vrvedp_m.exe

码云托管小项目-本地笔记文件管理系统_学习文档笔记托管码云-程序员宅基地

文章浏览阅读3.2k次。项目描述这是一个很简单的类博客系统，旨在方便管理本地笔记文档，整体采用spring+springmvc+angularjs+bootstrap+markdown实现，主要包括分类、查看、搜索等功能。项目背景由于记忆有限，学的东西难免忘记，因此就需要一定的笔记来帮助记忆。之前基本都是在CSDN用博客，或者有道云笔记，或者直接本地文件系统的文档来充当笔记。这些方式都有他们的优势..._学习文档笔记托管码云

.Net 连接 Mysql 8.0.29-30版本异常： Character set utf8mb3 is not supported by .Net Framework_character set 'utf8mb3' is not supported by .net f-程序员宅基地

文章浏览阅读8.9k次，点赞3次，收藏8次。Character set utf8mb3 is not supported by .Net Framework 解决方法_character set 'utf8mb3' is not supported by .net framework.

Python之(18)ctypes使用-程序员宅基地

文章浏览阅读1.1k次，点赞22次，收藏25次。ctypes是一个 Python 标准库，它提供了和 C 语言库交互的能力。利用ctypes，你可以在 Python 中加载动态链接库（DLLs 或在 Unix-like 系统中的 shared objects），并且可以调用这些库中的函数。这使得Python可以使用已经编译好的代码，这通常是为了性能或者重用现有的C代码。要使用ctypes然后，你可以加载一个库，调用其中的函数，传递参数，以及获取返回值。# 对于 Windows DLL# 对于 Unix-like 系统上的 shared object。_ctypes使用