Loading [MathJax]/jax/input/TeX/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >kubernetes 中 ipvs 连接复用引发的系列问题

kubernetes 中 ipvs 连接复用引发的系列问题

原创
作者头像
imroc
修改于 2023-12-14 06:59:45
修改于 2023-12-14 06:59:45
4.2K0
举报

本文摘自 kubernetes 学习笔记

背景

Kubernetes 社区里面有一个讨论已久的 bug (#81775),这个问题是当 client 对 service 发起大量新建 TCP 连接时,新的连接被转发到 Terminating 或已完全销毁的旧 Pod 上,导致持续丢包 (报错 no route to host),其根因是内核 ipvs 连接复用引发,本文来详细掰扯下。

conn_reuse_mode 简介

在介绍原因之前,我们先介绍下 conn_reuse_mode 这个内核参数,它是以下两个 patch 引入的:

  1. year 2015 d752c364571743d696c2a54a449ce77550c35ac5
  2. year 2016 f719e3754ee2f7275437e61a6afd520181fdd43b

其目的是:

  1. client ip:client port 复用发生时,对于 TIME_WAIT 状态下的 ip_vs_conn,进行重新调度,使得 connection 在 rs 上的分布更均衡,以提高性能。
  2. 如果该 mode 是 0,则会复用旧 ip_vs_conn 里的 rs,使得连接更不均衡。

所以当 conn_reuse_mode 为 0 表示启用 ipvs 连接复用,为 1 表示不复用,是不是有点反直觉?这个确实也比较有争议。

conn_reuse_mode=1 的 bug

开启这个内核参数 (conn_reuse_mode=1) 本意是为了提高新建的性能,实际结果是大幅度降低了性能,实际测试中发现 cps 从 3w 降低到了 1.5K,这也表明内核社区的一些 patch 没有经过严格的性能测试

开启这个内核参数实际就表示 ipvs 转发时不做连接复用,每次新建的连接都会重新调度 rs 并新建 ip_vs_conn,但它的实现有个问题: 在新建连接时 (SYN 包),如果 client ip:client port 匹配到了 ipvs 旧连接 (TIME_WIAT 状态),且使用了 conntrack,就会丢掉第一个 SYN 包,等待重传后 (1s) 才能成功建连,从而导致建连性能急剧下降。

Kubernetes 社区也发现了这个 bug,所以当 kube-proxy 使用 ipvs 转发模式时,默认将 conn_reuse_mode 置为 0 来规避这个问题,详见 PR #71114 与 issue #70747

conn_reuse_mode=0 引发的问题

由于 Kubernetes 为了规避 conn_reuse_mode=1 带来的性能问题,在 ipvs 模式下,让 kube-proxy 在启动时将 conn_reuse_mode 置为了 0 ,即使用 ipvs 连接复用的能力,但 ipvs 连接复用有两个问题:

  1. 只要有 client ip:client port 匹配上 ip_vs_conn (发生复用),就直接转发给对应的 rs,不管 rs 当前是什么状态,即便 rs 的 weight 为 0 (通常是 TIME_WAIT 状态) 也会转发,TIME_WAIT 的 rs 通常是 Terminating 状态已销毁的 Pod,转发过去的话连接就必然异常。
  2. 高并发下大量复用,没有为新连接没有调度 rs,直接转发到所复用连接对应的 rs 上,导致很多新连接被 "固化" 到部分 rs 上。

业务中实际遇到的现象可能有很多种:

  1. 滚动更新连接异常。 被访问的服务滚动更新时,Pod 有新建有销毁,ipvs 发生连接复用时转发到了已销毁的 Pod 导致连接异常 (no route to host)。
  2. 滚动更新负载不均。 由于复用时不会重新调度连接,导致新连接也被 "固化" 在某些 Pod 上了。
  3. 新扩容的 Pod 接收流量少。 同样也是由于复用时不会重新调度连接,导致很多新连接被 "固化" 在扩容之前的这些 Pod 上了。

规避方案

我们知道了问题原因,那么在 ipvs 转发模式下该如何规避呢?我们从南北向和东西向分别考虑下。

南北向流量

  1. 使用 LB 直通 Pod。对于南北向流量,通常依赖 NodePort 来暴露,前面的负载均衡器将流量先转到 NodePort 上,然后再通过 ipvs 转发到后端 Pod。现在很多云厂商都支持 LB 直通 Pod,这种模式下负载均衡器直接将请求转发到 Pod,不经过 NodePort,也就没有 ipvs 转发,从而在流量接入层规避这个问题。
  2. 使用 ingress 转发。在集群中部署 ingress controller (比如 nginx ingress),流量到达 ingress 再向后转时 (转发到集群内的 Pod),不会经过 service 转发,而是直接转发到 service 对应的 Pod IP:Port,也就绕过了 ipvs。Ingress controller 本身结合使用前面所说的 LB 直通 Pod 方式部署,效果更佳。

东西向流量

集群内的服务间调用 (东西向流量),默认还是会走 ipvs 转发。对于有这种高并发场景的业务,我们可以考虑使用 Serivce Mesh (如 istio) 来治理流量,服务间转发由 sidecar 代理,并且不会经过 ipvs。

终极方案: 内核修复

conn_reuse_mode=1 引发性能急需下降的 bug,目前在腾讯云提供的 TencentOS-kernel 开源内核已修复,对应 PR #17TKE 上的解决方案就是使用这个内核 patch,依赖禁用 ipvs 连接复用 (conn_reuse_mode=1),这样同时也就解决了 ipvs 连接复用引发的系列问题,且经过了大规模生产验证。

不过以上修复并未直接合并到 linux 社区,当前已有两个相关 patch 合并到了 linux 内核主干 (自 v5.9),分别解决 conn_reuse_mode 为 0 和 1 时的上述 bug,其中一个也是借鉴了腾讯云修复的思路,详见 k8s issue #93297

如果你使用了 v5.9 以上的内核,理论上就没有本文所述的问题了。既然 v5.9 以上的内核已修复上述 bug,那么 kube-proxy 就无需显式去设置 conn_reuse_mode 这个内核参数了,这也是 PR #102122 所做的事。不过值得注意的是,社区 patch 目前并未看到有大规模的生产验证,试用有风险。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
(38)STM32——NRF24L01无线通信
        在Enhanced ShockBurstTM收发模式下,NRF24L01 自动处理字头和CRC校验码。在接收数据时,自动把字头和CRC校验码移去。在发送数据时,自动加上字头和CRC校验码,在发送模式下,置CE为高,至少10us, 将使能发送过程。
小点点
2022/12/12
1.7K0
(38)STM32——NRF24L01无线通信
51单片机对无线模块nRF24L01简单的控制收发程序
这段代码主要先看全局变量,通过对IO口的赋值(如按键、led、无线模块的端口CE/IRQ等)可以知道电路图的绘制。
啊源股
2019/09/11
2.6K0
详解nRF24L01无线收发模块设计(附完整源码)
*******************************************
飞哥
2020/07/10
10.3K0
详解nRF24L01无线收发模块设计(附完整源码)
多协议模块-Bayang协议(NRF24L01芯片)
这个东西,是个芯片,在飞控里面 https://datasheet.lcsc.com/szlcsc/XN297L_C88025.pdf
云深无际
2021/11/15
1.9K0
多协议模块-Bayang协议(NRF24L01芯片)
基于nRF24L01的一对多节点通信(一收多发)
Jack_Cui
2017/12/28
1.5K0
被低估的NRF240L1模块,伪双工下的双向通信?
对很多单片机初学者或者爱好者来说,NRF24L01这个模块应该是比较熟悉了。如果你看过我的51视频就知道,我还在里面粗略的讲过,分享了两个简单的收发程序。
MCU起航
2021/09/24
1.5K0
一次小模块的使用过程-LC12S无线模块介绍
最近帮人做了个小设备,使用了无线模块、触摸芯片,主要功能就是把触摸按键的信号无线传到控制继电器输出,MCU是STM8系列的芯片,其中使用过程中调试无线模块LC21S觉得挺好用的,就写了这篇文章。
良知犹存
2021/02/06
5580
一次小模块的使用过程-LC12S无线模块介绍
工程监测多通道振弦模拟信号采集仪VTN的AABB 通讯协议
AABB 通讯协议是一种非标准自定义协议, 相较于 MODBUS 通讯协议,结构更简单,指令生成方法更容易,便于进行快速测试。 AABB 通讯协议支持单寄存器读写两种指令。
河北稳控科技
2023/02/20
3250
工程监测多通道振弦模拟信号采集仪VTN的AABB 通讯协议
关于G-MAXTEX GS881的接收机
比较nrf24l01的数据手册和BK2423数据手册很多内容(包括寄存器库)完全相同,不同的大概是nrf24l01的datasheet更详细。所以,以下内容通用。都是使用的SPI接口 datasheet里的“channel”:信道,信息的通道。当然,实际上芯片是向四面八方发射电磁波的。
云深无际
2022/02/09
1.4K0
关于G-MAXTEX GS881的接收机
自制SBUS接收端代码分析.上
看这篇文章前先看下面这篇 自制S-Bus接收器(控制dji EP车) 我们继续看这个,这个是发射端的数结构包 使用这段代码发送出去 接收端的代码,多了一个舵机的库 int ch_width_1 = 0, ch_width_2 = 0, ch_width_3 = 0, ch_width_4 = 0, ch_width_5 = 0, ch_width_6 = 0; 这里使用int的类型,声明几个通道 Servo ch1; Servo ch2; Servo ch3; Servo ch4; Ser
云深无际
2021/09/14
9500
自制SBUS接收端代码分析.上
无线键鼠的监听、劫持与防护
键盘连接到计算机有多种方式,有线键盘鼠标在生活中最常见,适用范围也很广泛,但有线连接不仅对操作距离有限制,而且给携带造成了不便。不仅如此,繁杂的线缆还很容易把桌面弄得凌乱不堪。无线键鼠非常好地解决了上述问题。无线键鼠又分为蓝牙类型和2.4GHz 类型,文中所指的无线鼠标一般指2.4GHz 类型。值得注意的是,虽然蓝牙键鼠的工作频段也是2.4GHz 频段,使用的却是蓝牙通信协议,符合蓝牙标准。而2.4GHz 类型的键鼠主要指利用专属无线协议开发的无线产品。2.4GHz 类型的无线键鼠,一般在计算机的USB 接口处插上一个适配器,鼠标和键盘通过电池供电。
博文视点Broadview
2020/06/11
1.9K0
工程监测多通道振弦模拟信号采集仪VTN的MODBUS 通讯协议
在 MODBUS 协议下,所有寄存器被定义为“保持寄存器” (详见 MODBUS 通讯协议标准说明), 设备支持基于 MODBUS 协议的多个连续寄存器读取、单个寄存器写入两种指令码, 对应指令码分别为 0x03、 0x06。
河北稳控科技
2023/02/17
4490
工程监测多通道振弦模拟信号采集仪VTN的MODBUS 通讯协议
电容触摸屏GT911、GT928、GT9147的使用
GT911、GT928、GT9147都属于GT9系列非单层多点触控芯片,他们支持的触控点数不同(GT928支持10个点、GT911支持5个点)、驱动和感应通道也可能不同。可是他们的寄存器和IIC通讯时序是相同的,也就是说驱动程序是兼容的。
全栈程序员站长
2022/09/07
6.2K0
基于STM32的RC522模块读写数据块以及电子钱包充值扣款系统的设计
本人也是正在学习单片机知识的萌新一枚,在这里记录下自己完成这个小设计的过程跟大家分享一下,也请大家指出我哪里还有不足可以改进的地方。秉着和大家一起学习进步发布了这篇文章
全栈程序员站长
2022/10/02
3K2
基于STM32的RC522模块读写数据块以及电子钱包充值扣款系统的设计
STM32+MFRC522完成IC卡号读取、密码修改、数据读写
完整工程源码下载: https://download.csdn.net/download/xiaolong1126626497/18905806
DS小龙哥
2022/01/17
4.6K0
STM32+MFRC522完成IC卡号读取、密码修改、数据读写
从0开始编写VS1053音频解码芯片的底层驱动代码(适用于任何单片机)
VS1053是一个高性能的音频解码器芯片,它是干什么的? 他有两个功能:()用来解码音频文件播放音乐的。(2)将麦克风听到的声音编码成音频文件数据,配合单片机可以保存到SD卡。
DS小龙哥
2025/05/27
2270
从0开始编写VS1053音频解码芯片的底层驱动代码(适用于任何单片机)
AS608指纹模块
AS608 指纹识别模块主要是指采用了杭州晟元芯片技术有限公司(Synochip)的 AS608 指纹识别芯片 而做成的指纹模块,模块厂商只是基于该芯片设计外围电路,集成一个可供2次开发的指纹模块;所以,只要是基于AS608芯片的指纹模块,其控制电路及控制协议几乎是一样的,只是厂家和性能不同而已。
跋扈洋
2021/02/02
2.1K0
AS608指纹模块
工程监测多通道振弦模拟信号采集仪VTN的$字符串通讯协议
VTN208-432是多通道振弦、温度、模拟传感信号系列数据采集仪,可对32通道振弦频率、32通道热敏电阻或DS18B20温度传感器、32通道模拟量传感器(电流或电压)进行实时在线采集或全自动定时采集存储工作;预留一路可调电源输出为模拟传感器定时供电;程控多路DAC输出,可以用于将振弦频率信号实时转换为模拟信号输出。设备支持RS485数据接口(支持Modbus或自定义AABB简单通讯协议)可以直接接入测控系统(如PLC、无线数据传输设备等)。
河北稳控科技
2023/02/21
3210
工程监测多通道振弦模拟信号采集仪VTN的$字符串通讯协议
RC522(RFID模块)实践总结
此次使用RC522模块和S50卡实现近场通讯功能(开发板与RC522通讯方式为硬件SPI),就实践过程中的一些知识点进行总结:
全栈程序员站长
2022/07/22
3.5K0
RC522(RFID模块)实践总结
Linux驱动开发-编写RFID-RC522射频刷卡模块驱动
MFRC522是应用于13.56MHz非接触式通信中高集成度的读写卡芯片,针对“三表”应用推出的一款低电压、低成本、体积小的非接触式读写卡芯片,是智能仪表和便携式手持设备研发的较好选择。便携式手持设备研发的较好选择。MFRC522利用了先进的调制和解调概念,集成了在13.56MHz下所有类型的被动非接触式通信方式和协议。支持14443A兼容应答器信号。数字部分处理ISO14443A帧和错误检测。此外,还支持快速CRYPTO1加密算法,用语验证MIFARE系列产品。MFRC522支持MI FARE系列更高速的非接触式通信,双向数据传输速率高达424kbit/s。作为13.56MHz高集成度读写卡系列芯片族的新成员,MFRC522与MF RC500和MFRC530有不少相似之处,同时也具备许多特点和差异。它与主机间通信采用SPI模式,有利于减少连线,缩小PCB板体积,降低成本。
DS小龙哥
2022/04/08
3K0
Linux驱动开发-编写RFID-RC522射频刷卡模块驱动
推荐阅读
相关推荐
(38)STM32——NRF24L01无线通信
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档