李夢超，史運濤，孫衛(wèi)兵

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

0 引言

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

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

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

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

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

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

■1.2 云平臺設(shè)計

云平臺Kubernetes集群中各個節(jié)點主要分為兩類，Master節(jié)點和Node節(jié)點[6]。

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

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

■1.3 邊緣計算節(jié)點設(shè)計

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

2 風(fēng)險評估模型API的開發(fā)與應(yīng)用流程

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

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

過程如圖1所示。

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

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

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

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

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

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

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

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

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

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

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

■4.1 實驗準(zhǔn)備

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

表1 節(jié)點信息

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

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

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

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

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

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

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

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

圖5 返回結(jié)果

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

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

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

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

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

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

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

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

■4.6 實驗結(jié)果分析

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

5 結(jié)論

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