压测iptables规则条数的限制

前言

今天在使用k8s的时候，由于运用到了calico这个cni插件和k8s自带的NetworkPolicy的功能，就需要考虑到一个性能方面的问题，怎么解释了，由于calico底层使用了iptables来做网络规则的限制，所以每当我们向k8s增加了一个NetworkPolicy的对象的时候，我们就是通过PolicyController往calico的etcd存储里增加记录，然后每个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)

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