基于Kubernetes及KubeEdge的社区燃气风险评估预警系统架构的探索

李梦超，史运涛，孙卫兵

（北方工业大学，北京，100144）

0 引言

作为社区安全中的重要一环，社区燃气事故具有严重性、突发性、复杂性、易于引发二次事故的特点，是重点防范的事故类型[1]。燃气事故的主要原因可以归结为人为因素、设备因素、客观操作原因等[2]。可由此建立静态或动态的评估模型对燃气事故发生的可能性进行评估，进而根据评估结果做出预警。目前燃气管理信息系统是以信息数据的采集和可视化展示为主要功能，基于统计分析及机器学习等动静态风险评估模型由于开发及部署复杂并没有整合到信息系统中。另外，在燃气事故告警处理环节上，从发出警报到处置设备响应的中间环节复杂且易受人员的主客观影响，缺乏云边协同技术的应用，由此造成事故处理不及时的现象大有存在。基于上述情况，本文探索了基于Kubernetes及KubeEdge的社区燃气风险评估预警架构。

1 架构设计

■1.1 整体架构设计

本文的社区燃气风险评估预警系统采用以Kubernetes及KubeEdge为基础的“云-边-端”架构。

云指云平台。平台通过搭建Kubernetes集群来运行燃气风险评估相关的容器应用，比如开发的前端应用、后端应用、燃气风险评估模型API、数据库等。采用Kubernetes部署云端应用是因为以Docker为代表的容器技术在软件部署与应用中越来越广泛[3]，而Kubernetes正是目前主流的容器编排工具，它为容器管理提供了完善的自动化机制与工具[4]，这些机制与工具涵盖了开发、部署、测试、运维监控的各个环节[5]。比如，服务注册和服务发现、负载均衡、健康检查、服务滚动升级和在线扩容等大大简化了燃气信息系统开发与运维的难度。

边指边缘计算节点。节点上运行基于Docker的轻量级应用，用于对接预警处置设备，如燃气电磁阀，告警灯等。边缘计算节点通过部署KubeEdge来将云平台Kubernetes的容器管理能力从云平台侧拓展到边缘侧，从而使得Kubernetes不仅能够管理云平台资源还可以管理底层的预警处置设备。

■1.2 云平台设计

云平台Kubernetes集群中各个节点主要分为两类，Master节点和Node节点[6]。

Master节点作为集群管理者，运行着kube-apiserver、kube-scheduler、kube-controller-manager、etcd、Pod网络等Kubernetes Master组件[7]，其中kube-apiserver为外界提供Kubernetes集群资源管理的API接口。Master上保存资源定义文件，这些资源定义文件包括燃气风险评估模型API的Development及Service文件、边缘应用Develpoment文件以及基于Kubernetes CRD 扩展的自定义资源的DeviceModel及DeviceInstance文件等，这些文件可由命令行工具kubectl命令提交给kube-apiserver作为应用的配置信息，并可重复利用。

Node节点是云端集群运行Pod的地方，由于云端的资源相对于边缘计算节点充裕，可以运行边缘计算节点难以胜任的高资源需求应用。本文架构中云端Node上主要运行的应用有数据库、前端应用、后端应用以及燃气风险评估模型API。各个应用服务可以根据微服务思想进行开发与部署，服务之间通过Kubernetes的Service进行访问。除此之外，可以为云端Kubernetes集群配置第三方外部存储来为容器提供独立于Pod与Node的数据卷，从而实现应用数据的持久化存储，常见的第三方存储有AWS EBS、Ceph、NFS等。

■1.3 边缘计算节点设计

边缘计算节点主要是运行轻量级的容器应用，又叫Mapper。该容器应用通过驱动来对接预警处置设备。Mapper可以是Kubernetes的Develpoment资源，生命周期可由云端Kuberneters集群中的Master节点管理。本文架构中预警处置设备可以是燃气告警装置或者燃气管道电磁阀等设备，这些设备往往采用不同的通信协议，因此Mapper的一个重要的作用是协议转换，将设备所用协议与MQTT协议之间进行转换（KubeEdge支持MQTT协议）。Mapper能订阅或推送MQTT协议数据到边缘计算节点部署的MQTT代理服务器—Mosquitto。KubeEdge的Edge部分组件能够作为MQTT客户端通过MQTT代理服务器订阅来自Mapper的消息或向Mapper发布消息，从而实现KubeEdge与Mapper的数据通信。

2 风险评估模型API的开发与应用流程

社区燃气评估模型主要涉及到的是统计分析类及深度学习类的模型，这些模型需要利用Web框架来封装成RESTful API接口，在这个过程使用的语言、工具、框架等具有多样性，由此导致模型API在运行环境配置及模型升级等过程面临困难。采用Docker可以将风险评估模型API程序及其运行依赖打包成一个可移植的镜像并且可以在任何安装Docker的操作系统上运行，将大大降低模型应用的难度。打包后的模型API镜像将存储在私有镜像仓库中以保证隐私性。

Kubernetes集群从私有的镜像仓库中拉取模型API镜像并启动为Pod中的Docker容器。Pod是Kubernetes最小的工作单位，通常不会被直接管理而是根据服务特性通过相应的Controller管理。风险评估模型API采用Deployment作 为 其Controller。Service是Kubernetes资源的一种，定义了外界访问服务的方式并且能够为Pod提供负载均衡的功能[8]。Service针对不同的使用场景有多种类型，集群内部访问Service使用ClusterIP型，集群外部访问Service使用NodePort型。

过程如图1所示。

图1 模型开发到应用的流程

3 燃气风险评估预警架构中的云边协同机制

社区燃气风险评估预警架构云边协同机制是基于Kubernetes与KubeEdge的云边协同机制。社区燃气风险评估预警云边协同的过程如图2所示。

图2 云边协同机制

云边协同的过程如下：

(1)云端根据资源定义文件创建云平台node节点及边缘计算节点的应用程序，云平台node节点应用程序主要是燃气风险评估相关的程序，比如API调用程序、算法模型API、提供模型输入数据的数据库、风险处理程序等。边缘计算节点的应用程序主要是与设备交互的Mapper应用。

(2)云端API调用程序调用数据库中的数据并带入算法模型API中，得出的燃气风险可能性等级将会发送到风险处理程序。

(3)风险处理程序根据风险等级向Kubernetes的apiserver发送HTTP请求，比如PUT或者PATCH请求，更改边缘端Mapper的属性的期望值。

(4)云端的控制指令(更改属性期望值)通过组件Cloud Hub及Edge Hub下发到边缘KubeEdge的DeviceTwin(设备孪生)，DeviceTwin会维护设备属性的期望值与实际值，如果期望值与实际值不一致则通过EventBus这个MQTT客户端向MQTT代理服务器指定的主题发送更改设备属性的实际值为期望值的控制指令。

(5)Mapper应用运行MQTT客户端的模块，不同设备由不同的Mapper控制，MQTT主题也不相同。接受到MQTT代理服务器推送消息的Mapper会操作边缘设备进行相应的操作，比如燃气电磁阀关闭等。

4 燃气风险评估预警架构模拟实验

■4.1 实验准备

为了验证基于Kubernetes及KubeEdge架构的燃气风险评估及预警的可行性，本文对该架构进行了模拟实验。实验配置信息如表1所示。

表1 节点信息

■4.2 风险评估模型API的制作与应用

首先采用AHP(层次分析法)构建了燃气风险评估模型，并利用PythonFlask框架实现其RESTfulAPI。其次使用Dockerfile文件方式打包成Docker镜像。最后编写API程序的Deployment资源定义文件及Service资源定义文件并通过Helm Charts软件包管理工具进行部署。

deployment.yaml文件内容如下：

service.yaml文件内容如下：

另外values.yaml文件内容如下：

在Kubernetes中helm install启动模型API应用后，查看对外暴露的端口为30934如图3所示，然后通过Postman接口测试工具进行测试，如图4、图5所示。

图3 模型API对外暴露应用

图4 模型API输入数据

图5 返回结果

■4.3 创建边缘应用设备模型与实例

首先抽象出边缘设备的属性并创建模板，实验中假设该设备仅有一个属性mydevieStatus， 用于描述设备的开关状态，可以被读写，资源定义文件mydevicemodel.yaml如下所示：

之后根据之前设备的模板创建设备的实例deviceins tance1，并通过nodeSelectorTerms将该实例绑定到边缘节点myedge1，资源定义文件mydeviceinstance.yaml如下所示：

■4.4 调用设备API发送指令更改设备属性

创建的设备实例deviceinstance1其在Kubernetes中 的API为https://192.168.6.130:6443/apis/devices.kubeedge.io/v1alpha1/namespaces/default/devices/deviceinstance1，编写风险处理程序，当燃气风险评估的等级达到设定的级别时调用deviceinstance1的API发送PATCH请求，更改设备的mydevieStatus属性为off，即向边缘计算节点下发控制指令。实验中使用Python语言编写相关程序其关键代码如下：

■4.5 边缘计算节点获取下发的控制指令

边缘计算节点中的KubeEdge组件中运行的DeviceTwin检测到云端下发的期望值off与设备的实际值on不一致，就会通过EventBus组件向MQTT代理服务器的主题$hw/events/device/deviceinstance1/twin/update/document发送消息，本实验中通过编写MQTT订阅程序订阅该主题程序获取到的消息如图6所示。

图6 订阅设备主题收到的消息

■4.6 实验结果分析

本实验通过在云端调用燃气风险评估模型API得出风险等级并根据风险等级触发调用预警处理设备的Kubernetes API向其发送控制指令，在边缘Node节点上订阅到了云端发往该设备的MQTT消息，从而说明了基于Kubernetes及KubeEdge燃气风险评估预警系统架构在云边协同机制上具有可行性。

5 结论

本文从燃气事故事前预警的角度出发，根据目前燃气信息管理系统面临集成基于统计分析及机器学习的风险评估模型困难以及发出预警到做出处置中间环节多的现象，提出了基于Kubernerts及KubeEdge燃气风险评估预警架构。通过探索基于此架构的模型API制作及部署流程以及云边协同机制的验证，证明了该架构在燃气风险评估预警系统应用前景上的可行性，在现实应用中使用该架构需要结合具体实际场景来作进一步的探索。