压测iptables规则条数的限制

Lateautumn_Lin · · 995 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

前言

今天在使用k8s的时候,由于运用到了calico这个cni插件和k8s自带的NetworkPolicy的功能,就需要考虑到一个性能方面的问题,怎么解释了,由于calico底层使用了iptables来做网络规则的限制,所以每当我们向k8s增加了一个NetworkPolicy的对象的时候,我们就是通过PolicyControllercalicoetcd存储里增加记录,然后每个node节点上的calico felix客户端就会读取里面的记录,并对应修改自己的iptables的规则,于是到了这里就会有一个问题抛出来,当我们增加了大量的网络规则之后,我们的iptables的规则数必然会成倍的增加,我们每次查询扫整个iptables表的速度也是下降,那么我们如何保证calico网络的使用效率呢,我们本篇文章先来看看iptables的压测数据是怎么样的。

测试环境:

集群环境

  • 机器配置:56 核 128G内存
  • 主机数:497 台
  • 测试程序:通过golang编写一个简单的限流应用,限制qps在2000,突发不超过3000的应用,程序返回512B的数据包
  • 测试工具:ab

单个实例

部署以后先测试单个实例的场景。 通过ab测试

# ab -c 100 -n 10000 10.52.136.35:30088/say                                                                                

Requests per second:    2021.38 [#/sec] (mean)       

测试结果表面单个实例下的并发大约在2000左右。

3个实例测试

# ab -c 100 -n 100000 10.52.136.35:30088/say                                                                               

Requests per second:    6094.68 [#/sec] (mean)   

当三个实例时,qps达到6000左右,iptables转发正常

10个实例测试

# ab -c 100 -n 100000 10.52.136.35:30088/say                                                                                                                                                                                                                                                                                                                                                                                                     

Requests per second:    20969.03 [#/sec] (mean)  

此时是2w的qps,iptables转发正常

50 个实例的测试

ab -c 100 -n 100000 10.52.136.35:30088/say                                                                               

Requests per second:    36969.03 [#/sec] (mean)        

单机四万的qps的上限,测试多台机器都能保持这个数值,即便在同时执行的情况下

5000个实例测试

ab -c 300 -n 500000 10.52.136.36:30088/say                                                                               

Requests per second:    43663.46 [#/sec] (mean)       

单机和多机同时执行效果相同,单机是4w的qps上线,iptables转发正常
测试的iptables中DNAT条数为

$ sudo iptables-save |grep DNAT|wc -l
10014

目前看规则条数一万条,性能并没有很大影响

增加iptables 规则

创建一个应用开通三个端口,增加副本数

$ sudo iptables-save |grep DNAT|wc -l

25014

规则扩容到2.5w条 测试

# ab -c 200 -n 500000 10.52.136.40:30088/say                                                                               

Requests per second:    39805.81 [#/sec] (mean)                 

性能稍有下降,多次测试变化不大

修改应用,将应用睡眠500毫秒,返回保持512字节

容器内直接访问,测试应用

# ab -c 1000 -n 50000  172.3.48.3:8080/say                                                                                 

Requests per second:    1916.45 [#/sec] (mean)   

还是2000的qps限流

此时需要注意,由于服务需要500毫秒后返回,ab的并行度不能太低,否则会导致达不到压力测试的效果
例如下面:

# ab -c 200 -n 50000  172.3.48.3:8080/say                                                                                  

Requests per second:    396.19 [#/sec] (mean)    

# ab -c 2000 -n 500000 10.52.136.40:30089/say                                                                              

Requests per second:    3972.39 [#/sec] (mean)        

客户端忙不过来,每个线程,每秒只能处理2个请求,所以是并行度的2倍。将副本数调至5000,
此时DNAT条数

sudo iptables-save |grep DNAT|wc -l
25014

测试结果

# ab -c 3000 -n 500000 10.52.136.40:30089/say                                                                              

Requests per second:    5929.59 [#/sec] (mean)                                                                                                 


# ab -c 5000 -n 500000 10.52.136.40:30089/say                                                                              

Requests per second:    9780.42 [#/sec] (mean)                                                                                                 

ab -c 10000 -n 500000 10.52.136.40:30089/say                                                                             

Requests per second:    18781.43 [#/sec] (mean)  

基本达到了c(线程数)的两倍的(0.5s导致)的qps,瓶颈是客户端

# ab -c 20000 -n 500000 10.52.136.40:30089/say                                                                             

Requests per second:    28246.95 [#/sec] (mean)      

此时单机的qps大约3w,iptables转发正常。

增加规则条数
$ sudo iptables-save |grep DNAT|wc -l
40011

测试

# ab -c 20000 -n 500000 10.52.136.36:30089/say                                                                             

Requests per second:    30260.00 [#/sec] (mean)      

对性能没有特别的影响

此时再创建的多个svc。7w条规则

sudo iptables-save |grep DNAT|wc -l
70032

测试

# ab -c 20000 -n 500000 10.52.136.38:30089/say                                                                             

Requests per second:    26942.21 [#/sec] (mean)        

继续增加到10w条

 sudo iptables-save |grep DNAT|wc -l
100035

测试

ab -c 20000 -n 500000 10.52.136.38:30089/say                                                                             

Requests per second:    26903.19 [#/sec] (mean)        

性能只有很少的变化(3w –> 2.7w)。在我们当前的生产环境的场景中。
假设一个没有应用有2000个副本,运行50个应用是没有任何问题的。

增加的15w条。

# ab -c 20000 -n 500000 10.52.136.38:30089/say
Requests per second:    26708.98 [#/sec] (mean) 

增加的18w条

# ab -c 20000 -n 500000 10.52.136.35:30089/say
Requests per second:    25686.32 [#/sec] (mean) 

增加到20w条

# ab -c 20000 -n 500000 10.52.136.35:30089/say
Requests per second:    26654.24 [#/sec] (mean)

没有明显变化。所以当我们当前的生产环境中使用它是是足够的。


有疑问加站长微信联系(非本文作者)

本文来自:简书

感谢作者:Lateautumn_Lin

查看原文:压测iptables规则条数的限制

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

995 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传