基于Kubernetes及KubeEdge的社區(qū)燃?xì)怙L(fēng)險(xiǎn)評(píng)估預(yù)警系統(tǒng)架構(gòu)的探索

李夢(mèng)超，史運(yùn)濤，孫衛(wèi)兵

（北方工業(yè)大學(xué)，北京，100144）

0 引言

作為社區(qū)安全中的重要一環(huán)，社區(qū)燃?xì)馐鹿示哂袊?yán)重性、突發(fā)性、復(fù)雜性、易于引發(fā)二次事故的特點(diǎn)，是重點(diǎn)防范的事故類型[1]。燃?xì)馐鹿实闹饕蚩梢詺w結(jié)為人為因素、設(shè)備因素、客觀操作原因等[2]。可由此建立靜態(tài)或動(dòng)態(tài)的評(píng)估模型對(duì)燃?xì)馐鹿拾l(fā)生的可能性進(jìn)行評(píng)估，進(jìn)而根據(jù)評(píng)估結(jié)果做出預(yù)警。目前燃?xì)夤芾硇畔⑾到y(tǒng)是以信息數(shù)據(jù)的采集和可視化展示為主要功能，基于統(tǒng)計(jì)分析及機(jī)器學(xué)習(xí)等動(dòng)靜態(tài)風(fēng)險(xiǎn)評(píng)估模型由于開(kāi)發(fā)及部署復(fù)雜并沒(méi)有整合到信息系統(tǒng)中。另外，在燃?xì)馐鹿矢婢幚憝h(huán)節(jié)上，從發(fā)出警報(bào)到處置設(shè)備響應(yīng)的中間環(huán)節(jié)復(fù)雜且易受人員的主客觀影響，缺乏云邊協(xié)同技術(shù)的應(yīng)用，由此造成事故處理不及時(shí)的現(xiàn)象大有存在。基于上述情況，本文探索了基于Kubernetes及KubeEdge的社區(qū)燃?xì)怙L(fēng)險(xiǎn)評(píng)估預(yù)警架構(gòu)。

1 架構(gòu)設(shè)計(jì)

■1.1 整體架構(gòu)設(shè)計(jì)

本文的社區(qū)燃?xì)怙L(fēng)險(xiǎn)評(píng)估預(yù)警系統(tǒng)采用以Kubernetes及KubeEdge為基礎(chǔ)的“云-邊-端”架構(gòu)。

云指云平臺(tái)。平臺(tái)通過(guò)搭建Kubernetes集群來(lái)運(yùn)行燃?xì)怙L(fēng)險(xiǎn)評(píng)估相關(guān)的容器應(yīng)用，比如開(kāi)發(fā)的前端應(yīng)用、后端應(yīng)用、燃?xì)怙L(fēng)險(xiǎn)評(píng)估模型API、數(shù)據(jù)庫(kù)等。采用Kubernetes部署云端應(yīng)用是因?yàn)橐訢ocker為代表的容器技術(shù)在軟件部署與應(yīng)用中越來(lái)越廣泛[3]，而Kubernetes正是目前主流的容器編排工具，它為容器管理提供了完善的自動(dòng)化機(jī)制與工具[4]，這些機(jī)制與工具涵蓋了開(kāi)發(fā)、部署、測(cè)試、運(yùn)維監(jiān)控的各個(gè)環(huán)節(jié)[5]。比如，服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)、負(fù)載均衡、健康檢查、服務(wù)滾動(dòng)升級(jí)和在線擴(kuò)容等大大簡(jiǎn)化了燃?xì)庑畔⑾到y(tǒng)開(kāi)發(fā)與運(yùn)維的難度。

邊指邊緣計(jì)算節(jié)點(diǎn)。節(jié)點(diǎn)上運(yùn)行基于Docker的輕量級(jí)應(yīng)用，用于對(duì)接預(yù)警處置設(shè)備，如燃?xì)怆姶砰y，告警燈等。邊緣計(jì)算節(jié)點(diǎn)通過(guò)部署KubeEdge來(lái)將云平臺(tái)Kubernetes的容器管理能力從云平臺(tái)側(cè)拓展到邊緣側(cè)，從而使得Kubernetes不僅能夠管理云平臺(tái)資源還可以管理底層的預(yù)警處置設(shè)備。

■1.2 云平臺(tái)設(shè)計(jì)

云平臺(tái)Kubernetes集群中各個(gè)節(jié)點(diǎn)主要分為兩類，Master節(jié)點(diǎn)和Node節(jié)點(diǎn)[6]。

Master節(jié)點(diǎn)作為集群管理者，運(yùn)行著kube-apiserver、kube-scheduler、kube-controller-manager、etcd、Pod網(wǎng)絡(luò)等Kubernetes Master組件[7]，其中kube-apiserver為外界提供Kubernetes集群資源管理的API接口。Master上保存資源定義文件，這些資源定義文件包括燃?xì)怙L(fēng)險(xiǎn)評(píng)估模型API的Development及Service文件、邊緣應(yīng)用Develpoment文件以及基于Kubernetes CRD 擴(kuò)展的自定義資源的DeviceModel及DeviceInstance文件等，這些文件可由命令行工具kubectl命令提交給kube-apiserver作為應(yīng)用的配置信息，并可重復(fù)利用。

Node節(jié)點(diǎn)是云端集群運(yùn)行Pod的地方，由于云端的資源相對(duì)于邊緣計(jì)算節(jié)點(diǎn)充裕，可以運(yùn)行邊緣計(jì)算節(jié)點(diǎn)難以勝任的高資源需求應(yīng)用。本文架構(gòu)中云端Node上主要運(yùn)行的應(yīng)用有數(shù)據(jù)庫(kù)、前端應(yīng)用、后端應(yīng)用以及燃?xì)怙L(fēng)險(xiǎn)評(píng)估模型API。各個(gè)應(yīng)用服務(wù)可以根據(jù)微服務(wù)思想進(jìn)行開(kāi)發(fā)與部署，服務(wù)之間通過(guò)Kubernetes的Service進(jìn)行訪問(wèn)。除此之外，可以為云端Kubernetes集群配置第三方外部存儲(chǔ)來(lái)為容器提供獨(dú)立于Pod與Node的數(shù)據(jù)卷，從而實(shí)現(xiàn)應(yīng)用數(shù)據(jù)的持久化存儲(chǔ)，常見(jiàn)的第三方存儲(chǔ)有AWS EBS、Ceph、NFS等。

■1.3 邊緣計(jì)算節(jié)點(diǎn)設(shè)計(jì)

邊緣計(jì)算節(jié)點(diǎn)主要是運(yùn)行輕量級(jí)的容器應(yīng)用，又叫Mapper。該容器應(yīng)用通過(guò)驅(qū)動(dòng)來(lái)對(duì)接預(yù)警處置設(shè)備。Mapper可以是Kubernetes的Develpoment資源，生命周期可由云端Kuberneters集群中的Master節(jié)點(diǎn)管理。本文架構(gòu)中預(yù)警處置設(shè)備可以是燃?xì)飧婢b置或者燃?xì)夤艿离姶砰y等設(shè)備，這些設(shè)備往往采用不同的通信協(xié)議，因此Mapper的一個(gè)重要的作用是協(xié)議轉(zhuǎn)換，將設(shè)備所用協(xié)議與MQTT協(xié)議之間進(jìn)行轉(zhuǎn)換（KubeEdge支持MQTT協(xié)議）。Mapper能訂閱或推送MQTT協(xié)議數(shù)據(jù)到邊緣計(jì)算節(jié)點(diǎn)部署的MQTT代理服務(wù)器—Mosquitto。KubeEdge的Edge部分組件能夠作為MQTT客戶端通過(guò)MQTT代理服務(wù)器訂閱來(lái)自Mapper的消息或向Mapper發(fā)布消息，從而實(shí)現(xiàn)KubeEdge與Mapper的數(shù)據(jù)通信。

2 風(fēng)險(xiǎn)評(píng)估模型API的開(kāi)發(fā)與應(yīng)用流程

社區(qū)燃?xì)庠u(píng)估模型主要涉及到的是統(tǒng)計(jì)分析類及深度學(xué)習(xí)類的模型，這些模型需要利用Web框架來(lái)封裝成RESTful API接口，在這個(gè)過(guò)程使用的語(yǔ)言、工具、框架等具有多樣性，由此導(dǎo)致模型API在運(yùn)行環(huán)境配置及模型升級(jí)等過(guò)程面臨困難。采用Docker可以將風(fēng)險(xiǎn)評(píng)估模型API程序及其運(yùn)行依賴打包成一個(gè)可移植的鏡像并且可以在任何安裝Docker的操作系統(tǒng)上運(yùn)行，將大大降低模型應(yīng)用的難度。打包后的模型API鏡像將存儲(chǔ)在私有鏡像倉(cāng)庫(kù)中以保證隱私性。

Kubernetes集群從私有的鏡像倉(cāng)庫(kù)中拉取模型API鏡像并啟動(dòng)為Pod中的Docker容器。Pod是Kubernetes最小的工作單位，通常不會(huì)被直接管理而是根據(jù)服務(wù)特性通過(guò)相應(yīng)的Controller管理。風(fēng)險(xiǎn)評(píng)估模型API采用Deployment作 為 其Controller。Service是Kubernetes資源的一種，定義了外界訪問(wèn)服務(wù)的方式并且能夠?yàn)镻od提供負(fù)載均衡的功能[8]。Service針對(duì)不同的使用場(chǎng)景有多種類型，集群內(nèi)部訪問(wèn)Service使用ClusterIP型，集群外部訪問(wèn)Service使用NodePort型。

過(guò)程如圖1所示。

圖1 模型開(kāi)發(fā)到應(yīng)用的流程

3 燃?xì)怙L(fēng)險(xiǎn)評(píng)估預(yù)警架構(gòu)中的云邊協(xié)同機(jī)制

社區(qū)燃?xì)怙L(fēng)險(xiǎn)評(píng)估預(yù)警架構(gòu)云邊協(xié)同機(jī)制是基于Kubernetes與KubeEdge的云邊協(xié)同機(jī)制。社區(qū)燃?xì)怙L(fēng)險(xiǎn)評(píng)估預(yù)警云邊協(xié)同的過(guò)程如圖2所示。

圖2 云邊協(xié)同機(jī)制

云邊協(xié)同的過(guò)程如下：

(1)云端根據(jù)資源定義文件創(chuàng)建云平臺(tái)node節(jié)點(diǎn)及邊緣計(jì)算節(jié)點(diǎn)的應(yīng)用程序，云平臺(tái)node節(jié)點(diǎn)應(yīng)用程序主要是燃?xì)怙L(fēng)險(xiǎn)評(píng)估相關(guān)的程序，比如API調(diào)用程序、算法模型API、提供模型輸入數(shù)據(jù)的數(shù)據(jù)庫(kù)、風(fēng)險(xiǎn)處理程序等。邊緣計(jì)算節(jié)點(diǎn)的應(yīng)用程序主要是與設(shè)備交互的Mapper應(yīng)用。

(2)云端API調(diào)用程序調(diào)用數(shù)據(jù)庫(kù)中的數(shù)據(jù)并帶入算法模型API中，得出的燃?xì)怙L(fēng)險(xiǎn)可能性等級(jí)將會(huì)發(fā)送到風(fēng)險(xiǎn)處理程序。

(3)風(fēng)險(xiǎn)處理程序根據(jù)風(fēng)險(xiǎn)等級(jí)向Kubernetes的apiserver發(fā)送HTTP請(qǐng)求，比如PUT或者PATCH請(qǐng)求，更改邊緣端Mapper的屬性的期望值。

(4)云端的控制指令(更改屬性期望值)通過(guò)組件Cloud Hub及Edge Hub下發(fā)到邊緣KubeEdge的DeviceTwin(設(shè)備孿生)，DeviceTwin會(huì)維護(hù)設(shè)備屬性的期望值與實(shí)際值，如果期望值與實(shí)際值不一致則通過(guò)EventBus這個(gè)MQTT客戶端向MQTT代理服務(wù)器指定的主題發(fā)送更改設(shè)備屬性的實(shí)際值為期望值的控制指令。

(5)Mapper應(yīng)用運(yùn)行MQTT客戶端的模塊，不同設(shè)備由不同的Mapper控制，MQTT主題也不相同。接受到MQTT代理服務(wù)器推送消息的Mapper會(huì)操作邊緣設(shè)備進(jìn)行相應(yīng)的操作，比如燃?xì)怆姶砰y關(guān)閉等。

4 燃?xì)怙L(fēng)險(xiǎn)評(píng)估預(yù)警架構(gòu)模擬實(shí)驗(yàn)

■4.1 實(shí)驗(yàn)準(zhǔn)備

為了驗(yàn)證基于Kubernetes及KubeEdge架構(gòu)的燃?xì)怙L(fēng)險(xiǎn)評(píng)估及預(yù)警的可行性，本文對(duì)該架構(gòu)進(jìn)行了模擬實(shí)驗(yàn)。實(shí)驗(yàn)配置信息如表1所示。

表1 節(jié)點(diǎn)信息

■4.2 風(fēng)險(xiǎn)評(píng)估模型API的制作與應(yīng)用

首先采用AHP(層次分析法)構(gòu)建了燃?xì)怙L(fēng)險(xiǎn)評(píng)估模型，并利用PythonFlask框架實(shí)現(xiàn)其RESTfulAPI。其次使用Dockerfile文件方式打包成Docker鏡像。最后編寫API程序的Deployment資源定義文件及Service資源定義文件并通過(guò)Helm Charts軟件包管理工具進(jìn)行部署。

deployment.yaml文件內(nèi)容如下：

service.yaml文件內(nèi)容如下：

另外values.yaml文件內(nèi)容如下：

在Kubernetes中helm install啟動(dòng)模型API應(yīng)用后，查看對(duì)外暴露的端口為30934如圖3所示，然后通過(guò)Postman接口測(cè)試工具進(jìn)行測(cè)試，如圖4、圖5所示。

圖3 模型API對(duì)外暴露應(yīng)用

圖4 模型API輸入數(shù)據(jù)

圖5 返回結(jié)果

■4.3 創(chuàng)建邊緣應(yīng)用設(shè)備模型與實(shí)例

首先抽象出邊緣設(shè)備的屬性并創(chuàng)建模板，實(shí)驗(yàn)中假設(shè)該設(shè)備僅有一個(gè)屬性mydevieStatus， 用于描述設(shè)備的開(kāi)關(guān)狀態(tài)，可以被讀寫，資源定義文件mydevicemodel.yaml如下所示：

之后根據(jù)之前設(shè)備的模板創(chuàng)建設(shè)備的實(shí)例deviceins tance1，并通過(guò)nodeSelectorTerms將該實(shí)例綁定到邊緣節(jié)點(diǎn)myedge1，資源定義文件mydeviceinstance.yaml如下所示：

■4.4 調(diào)用設(shè)備API發(fā)送指令更改設(shè)備屬性

創(chuàng)建的設(shè)備實(shí)例deviceinstance1其在Kubernetes中 的API為https://192.168.6.130:6443/apis/devices.kubeedge.io/v1alpha1/namespaces/default/devices/deviceinstance1，編寫風(fēng)險(xiǎn)處理程序，當(dāng)燃?xì)怙L(fēng)險(xiǎn)評(píng)估的等級(jí)達(dá)到設(shè)定的級(jí)別時(shí)調(diào)用deviceinstance1的API發(fā)送PATCH請(qǐng)求，更改設(shè)備的mydevieStatus屬性為off，即向邊緣計(jì)算節(jié)點(diǎn)下發(fā)控制指令。實(shí)驗(yàn)中使用Python語(yǔ)言編寫相關(guān)程序其關(guān)鍵代碼如下：

■4.5 邊緣計(jì)算節(jié)點(diǎn)獲取下發(fā)的控制指令

邊緣計(jì)算節(jié)點(diǎn)中的KubeEdge組件中運(yùn)行的DeviceTwin檢測(cè)到云端下發(fā)的期望值off與設(shè)備的實(shí)際值on不一致，就會(huì)通過(guò)EventBus組件向MQTT代理服務(wù)器的主題$hw/events/device/deviceinstance1/twin/update/document發(fā)送消息，本實(shí)驗(yàn)中通過(guò)編寫MQTT訂閱程序訂閱該主題程序獲取到的消息如圖6所示。

圖6 訂閱設(shè)備主題收到的消息

■4.6 實(shí)驗(yàn)結(jié)果分析

本實(shí)驗(yàn)通過(guò)在云端調(diào)用燃?xì)怙L(fēng)險(xiǎn)評(píng)估模型API得出風(fēng)險(xiǎn)等級(jí)并根據(jù)風(fēng)險(xiǎn)等級(jí)觸發(fā)調(diào)用預(yù)警處理設(shè)備的Kubernetes API向其發(fā)送控制指令，在邊緣Node節(jié)點(diǎn)上訂閱到了云端發(fā)往該設(shè)備的MQTT消息，從而說(shuō)明了基于Kubernetes及KubeEdge燃?xì)怙L(fēng)險(xiǎn)評(píng)估預(yù)警系統(tǒng)架構(gòu)在云邊協(xié)同機(jī)制上具有可行性。

5 結(jié)論

本文從燃?xì)馐鹿适虑邦A(yù)警的角度出發(fā)，根據(jù)目前燃?xì)庑畔⒐芾硐到y(tǒng)面臨集成基于統(tǒng)計(jì)分析及機(jī)器學(xué)習(xí)的風(fēng)險(xiǎn)評(píng)估模型困難以及發(fā)出預(yù)警到做出處置中間環(huán)節(jié)多的現(xiàn)象，提出了基于Kubernerts及KubeEdge燃?xì)怙L(fēng)險(xiǎn)評(píng)估預(yù)警架構(gòu)。通過(guò)探索基于此架構(gòu)的模型API制作及部署流程以及云邊協(xié)同機(jī)制的驗(yàn)證，證明了該架構(gòu)在燃?xì)怙L(fēng)險(xiǎn)評(píng)估預(yù)警系統(tǒng)應(yīng)用前景上的可行性，在現(xiàn)實(shí)應(yīng)用中使用該架構(gòu)需要結(jié)合具體實(shí)際場(chǎng)景來(lái)作進(jìn)一步的探索。