EMQX在K8S中的扩缩容测试与雪崩

EMQX在K8S中的扩缩容测试与雪崩

背景

emqx使用statefulset的方式部署3-5个pod ,设备认证采用redis的方式

测试步骤

测试目的 测试步骤 测试结果
1 搭建emqx环境,pod数量为3
2 确认emqx的负载均衡功能 通过python编写mqtt连接代码,
连接99个client,检查99个client的分布情况
平均分布在3个pod上,每个pod上连接了33个client。
多个pod能实现负载均衡。
3 增加emqx的数量,检查连接是否发生变化 通过rancher,修改pod的数量为5,
检查新pod启动之后,99个client的分布情况
新增的2个pod,不会自动分担之前连接的client,原来的
99个client 还是连接到之前的3个pod上。扩容不会影响现有连接。
4 增加客户端的数量,检查服务端负载情况。
看是否能出现削峰平谷,让新连接的pod多负载
一些连接
通过python编写mqtt连接代码,
增加50个client,检查99+50个client的分布情况
每一个pod的连接数量,平摊了10个。两个新的pod变成了10个连接数
原来的3个pod从33个连接变成了43个连接。
新增的客户端也会平均分配到各个pod上,但是分配的方法也是完全平均的,不会考虑emqx当前已经连接的数量。
没有出现削峰平谷的现象。
5 全部重连150个客户端,检查服务端负载情况。
看是否会全部平均分配到5个pod上
断掉之前的连接。
通过python编写mqtt连接代码,
一次性连接150个client,检查他们的分布情况
每个pod分摊30个连接,扩容之后,重新连接的client能够负载均衡
6 缩小emqx的数量,检查连接情况 通过rancher,修改pod的数量为3 消失的2个pod会导致相连客户端断开连接,剩余的3个pod连接的客户端无影响
7 给客户端加上掉线重连功能,再次缩小emqx的数量 通过python编写mqtt连接代码,加上自动重连功能 ,缩小emqx的数量 所有的客户端都会连接到那个1个pod上,虽然客户端产生了掉线,但是不会影响后续使用

结论

1.我们自己实现的mqtt客户端要有重连机制,如果无重连机制,会在缩容或者重启之后与emqx失去连接
2.只要资源充裕,emqx或者redis重启,不会产生太大的影响,顶多是emqx重启的那几秒钟会丢数据
3.emqx的扩容要提前扩容,不能等出现即将出现故障的时候在扩容,因为扩容之后的数据虽然是均摊了,但是前面的2个emqx的连接数还是没有减少
假设每个emqx能容纳100个client,当达到80个client的时候,我们才进行扩容,虽然后面再连上的是负载均衡了,但是在极端情况下还是有可能出现雪崩,如下图

除非此时断开emqx与外部的连接,等待emqx3个实例全部启动之后,再允许emqx的外部连接。
这样每个节点都到82%,没有雪崩


苏ICP备18047533号-2