为了降低EMQX在Kubernetes上的部署、运维成本,我们将一些日常运维能力进行总结、抽象并整合到代码中,以EMQX Kubernetes Operator的方式帮助用户实现EMQX的自动化部署和运维。
此前,EMQX Kubernetes Operator v1beta1、v1beta2、v1beta3的升级策略均为滚动升级,相关升级流程如下:
升级流程示意图
滚动升级在生产环境中可能会面临以下问题:
升级过程中会逐个销毁旧的节点再创建新的节点,因此可能导致客户端多次断连(最糟糕的情况下断连次数与节点数量一致),从而影响用户体验。
当集群处于较高连接的情况下,一个节点被销毁,那么该节点上面的连接会在瞬间断开,由客户端重试逻辑来进行重连;当单节点连接数较大时,如果大量客户端进行重连,则可能会给服务端造成压力导致过载。
升级完成后,各节点间的负载不均衡(如上图:emqx-ee-0在升级过程中,客户端可能会进行重连,此时由于emqx-ee-0还未就绪,因此可能连接到emqx-ee-1或者emqx-ee-2,升级完成后emqx-ee-0上可能只有较少负载或者无负载),从而打破业务容量模型的规划,可能影响到服务。
由于使用StatefulSets进行部署,在升级过程中提供服务的节点会比实际节点要少一个(影响到用户的业务模型),这可能会增加服务端的一些压力。
如果上面几个步骤的问题叠加(多次断连与大量断连的客户端不停的重试连接),则可能会放大客户端重连的规模,从而造成服务端过载或雪崩。
下图是在现有升级模式下连接数的监控图(在不同的业务中会存在差异,比如后端依赖的不同资源、服务器配置、客户端重连或重试策略等,均会带来一些不同的影响)。其中:
sum:总的连接数,图中最上面的一条线
emqx-ee-a:前缀表示的是升级前3个EMQX节点
emqx-ee-b:前缀表示的是升级后3个EMQX节点
在上图中,当我们开始执行滚动升级时,首先emqx-ee-a-emqx-ee-2进行销毁,并创建新的emqx-ee-b-emqx-ee-2,此时仅有emqx-ee-a-emqx-ee-1、emqx-ee-a-emqx-ee-0能够提供服务,当客户端进行重连时,LB会将流量转移到emqx-ee-a-emqx-ee-0、emqx-ee-a-emqx-ee-1上面,因此我们能够看到emqx-ee-a-emqx-ee-1、emqx-ee-a-emqx-ee-0有明显的流量上升,当后面更新这两个pod时,意味着客户端可能多次断连。由于新pod建立的过程存在着时间差,以上图为例,emqx-ee-a-emqx-ee-0最后升级,当升级完成后,可能客户端已经完成重试、重连,此时主要连接已经被另两个pod接纳,因此会导致pod之间流量不均衡,从而影响到用户业务模型的评估,或者影响到服务。
为了方便展示,我们未压测大量连接模拟重连、导致服务端过载的场景(在实际生产环境中可能遇到,TPS超过云端规划的容量模型),但从连接数监控图上,我们依然看到一个大缺口,说明对业务产生了较大影响。因此我们需制定一种方案来规避以上几个问题,保障升级过程中的平滑稳定。
目标
升级过程中实现连接数可控迁移(可根据服务端处理能力设置相应的迁移速率)。
升级过程中减少连接断开的次数(一次断连)。
在整个升级的过程中始终保持预期的节点来提供服务。
升级完成后,不需要集群负载重平衡,各节点间的连接相对均衡(与LB调度策略有一定关系)。
方案设计
蓝绿发布是一种同时运行两个版本应用的发布策略。EMQX Kubernetes Operator近日在2.1.0版本中实现了EMQX Enterprise的蓝绿发布,即从现有的EMQX Enterprise集群开始,创建一套新版本的EMQX Enterpriser集群,在这一过程中不停止掉老版本,等新版本集群运行起来后,再将流量逐步平滑切换到新版本上。
从4.4.12版本开始,EMQX企业版本支持节点疏散功能。节点疏散功能允许用户在关闭节点之前强制将连接和会话以一定速率迁移到其他节点,以避免节点关闭带来的会话数据丢失。
在Kubernetes上我们通过模拟蓝绿发布以及结合节点疏散功能,实现了连接可控迁移,极大减少了断连的次数(仅断连一次)。相关升级流程图如下:
整个升级流程大致可分为以下几步:
升级时(镜像、Pod相关资源修改调整)我们会先创建一个同规格的节点加入到现有集群中。
当新节点全部就绪后,我们将service全部指向新创建的节点,此时新节点开始接受新的连接请求。
将旧节点从service中摘出,此时旧节点不再接收新的连接请求。
通过EMQX节点疏散功能,逐个对节点上的连接进行可控迁移,直至连接全部完成迁移,再对节点进行销毁。
操作流程
节点疏散是EMQX Enterpriser 4.4.12开始支持的新特性,EMQX Kubernetes Operator在2.1版本中对该能力进行适配,如需使用该能力,请将EMQX升级到企业版v4.4.12,EMQX Kubernetes Operator升级到v2.1。
升级过程中连接数监控图如下(本次测试以10万连接进行):
sum:总的连接数,图中最上面的一条线
emqx-ee-86d7758868:前缀表示的是升级前的3个EMQX节点
emqx-ee-745858464d:前缀表示升级后的3个EMQX节点
如上图,我们通过EMQX Kubernetes Operator的蓝绿发布在Kubernetes中实现了优雅升级,通过该方案升级,总连接数未出现较大抖动(取决于迁移速率、服务端能够接收的速率、客户端重连策略等),能够极大程度保障升级过程的平滑,有效防止服务端过载,减少业务感知,从而提升服务的稳定性。
*注:由于升级后的集群,三个节点负载较平均,因此上图三条线重叠在了一起。
通过采用节点疏散功能结合模拟蓝绿发布,本文所提供的方案解决了普通升级导致的多次断连和可能的服务过载与负载不均问题,实现了在Kubernetes上的优雅升级。
作为一个自动化管理工具,EMQX Kubernetes Operator旨在帮助用户轻松创建和管理EMQX集群,充分享受EMQX的强大产品能力。通过本文方案完成EMQX的升级,用户可以进一步体验EMQX的最新特性,构建创新物联网应用。
2023-04-07 EMQ 映云科技发布了 《EMQ&阿里云Lindorm联合方案:解决物联网关键业务场景数据处理难题》的文章
2023-03-24 EMQ 映云科技发布了 《来2023全球边缘计算大会与EMQ探讨云边协同落地实践》的文章
2023-03-20 EMQ 映云科技发布了 《EMQ&南洋万邦|深度激活工业数据潜力,加速绿色制造数智化转型升级》的文章
2023-02-24 EMQ 映云科技发布了 《EMQX在Kubernetes中如何进行优雅升级》的文章
2023-02-24 EMQ 映云科技发布了 《EMQX Cloud Serverless正式上线:实现三秒部署的MQTT Serverless云服务》的文章