基于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制作及部署流程以及云邊協同機制的驗證，證明了該架構在燃氣風險評估預警系統應用前景上的可行性，在現實應用中使用該架構需要結合具體實際場景來作進一步的探索。