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，老子丢包啊

智能推荐

软件测试流程包括哪些内容？测试方法有哪些？_测试过程管理中包含哪些过程-程序员宅基地

文章浏览阅读2.9k次，点赞8次，收藏14次。测试主要做什么？这完全都体现在测试流程中，同时测试流程是面试问题中出现频率最高的，这不仅是因为测试流程很重要，而是在面试过程中这短短的半小时到一个小时的时间，通过测试流程就可以判断出应聘者是否合适，故在测试流程中包含了测试工作的核心内容，例如需求分析，测试用例的设计，测试执行，缺陷等重要的过程。..._测试过程管理中包含哪些过程

政府数字化政务的人工智能与机器学习应用：如何提高政府工作效率-程序员宅基地

文章浏览阅读870次，点赞16次，收藏19次。1.背景介绍政府数字化政务是指政府利用数字技术、互联网、大数据、人工智能等新技术手段，对政府政务进行数字化改革，提高政府工作效率，提升政府服务质量的过程。随着人工智能(AI)和机器学习(ML)技术的快速发展，政府数字化政务中的人工智能与机器学习应用也逐渐成为政府改革的重要内容。政府数字化政务的人工智能与机器学习应用涉及多个领域，包括政策决策、政府服务、公共安全、社会治理等。在这些领域，人工...

ssm+mysql+微信小程序考研刷题平台_mysql刷题软件-程序员宅基地

文章浏览阅读219次，点赞2次，收藏4次。系统主要的用户为用户、管理员，他们的具体权限如下：用户：用户登录后可以对管理员上传的学习视频进行学习。用户可以选择题型进行练习。用户选择小程序提供的考研科目进行相关训练。用户可以进行水平测试，并且查看相关成绩用户可以进行错题集的整理管理员：管理员登录后可管理个人基本信息管理员登录后可管理个人基本信息管理员可以上传、发布考研的相关例题及其分析，并对题型进行管理管理员可以进行查看、搜索考研题目及错题情况。_mysql刷题软件

根据java代码描绘uml类图_Myeclipse8.5下JAVA代码导成UML类图-程序员宅基地

文章浏览阅读1.4k次。myelipse里有UML1和UML2两种方式，UML2功能更强大，但是两者生成过程差别不大1.建立Test工程，如下图，uml包存放uml类图package com.zz.domain;public class User {private int id;private String name;public int getId() {return id;}public void setId(int..._根据以下java代码画出类图

Flume自定义拦截器-程序员宅基地

文章浏览阅读174次。需求：一个topic包含很多个表信息，需要自动根据json字符串中的字段来写入到hive不同的表对应的路径中。发送到Kafka中的数据原本最外层原本没有pkDay和project，只有data和name。因为担心data里面会空值，所以根同事商量，让他们在最外层添加了project和pkDay字段。pkDay字段用于表的自动分区，proejct和name合起来用于自动拼接hive表的名称为 ..._flume拦截器自定义开发 kafka

java同时输入不同类型数据,Java Spring中同时访问多种不同数据库-程序员宅基地

文章浏览阅读380次。原标题：Java Spring中同时访问多种不同数据库多样的工作要求，可以使用不同的工作方法，只要能获得结果，就不会徒劳。开发企业应用时我们常常遇到要同时访问多种不同数据库的问题，有时是必须把数据归档到某种数据仓库中，有时是要把数据变更推送到第三方数据库中。使用Spring框架时，使用单一数据库是非常容易的，但如果要同时访问多个数据库的话事件就变得复杂多了。本文以在Spring框架下开发一个Sp..._根据输入的不同连接不同的数据库