KubeEdge在國家工業互聯網大數據中心的架構設計與應用

項目背景

在18年時候，工信部開展了一個叫國家創新發展工程，這個工程中提出了要建立一個國家工業大數據中心，中國移動在其中承擔了邊緣協同與數據采集相關功能的研發。

一、問題與挑戰

需求

從工廠采集生產、運行數據，匯總云端

云端進行統一控制：采什么數據、數據怎么處理

挑戰

只能邊主動連云，云不可以主動連邊（邊緣沒有公網IP）

足夠通用，靈活適應各類工業設備與協議

具備邊緣自治能力，在網絡不穩定時，邊緣能夠自治

具備邊緣計算能力，能夠在邊緣節點運行各類應用

占用資源少，功耗低

二、技術選型

技術選型其實也是從我們的實際需求出發的，首先是EdgeX，其實在做這個項目之前，我們一直是用EdgeX做數據采集和管理的，EdgeX在數據采集和管理上做的還是比較完善的，功能也比較強，但是它也缺少一些能力，比如云邊協同能力，我認為它是一個純的邊緣自治架構，不具備和云的一個同步能力，當然我們也有一些方案，比如從EdgeX的節點上撥一個VPN撥到我們的中心云上，但是VPN這種方案的擴展性還是比較差一點的；

備注：圖片來自互聯網

第二就是K3S/K8S，K3S/K8S第一個問題也是不具備云邊協同能力，第二點是尤其是K8s占用的資源太大了，不太適合放在我們的工廠，K3s占用的資源已經少了不少，但一方面缺少云邊協同的能力，另一方面也缺少設備管理能力；

第三個是OpenNESS，它是非常通用的框架，但對我們來說太通用了，不論做什么，都需要寫適配器，去底層對接Kubernetes都可以，有點太靈活，開發工作量相對比較大，缺乏設備管理的能力；

第四個是OpenYurt，這個從功能描述上和KubeEdge比較像，但出現的比較晚，而當時我們的項目已經進行了一半了，目前看起來它整體的成熟度還是比KubeEdge差一些；

最后是KubeEdge。它具有云邊協同能力、資源開銷比較小，它還具有設備管理能力，我認為它還是比較有特色的，尤其是云邊協同能力和設備管理能力，可能市面上很少找到同時具備這兩種能力的。

架構設計

整體框架

這個是我們實際在國家工業互聯網大數據中心中用到的架構，其實最核心的就是我們的KubeEdge，它其實就起到了一個設備管理、應用管理的作用；我的云端肯定首先會有一個K8s集群，我們會部署KubeEdge所謂的Cloud Core，所有的數據包括管理數據都是保存在云端的K8s中，邊緣側是運行在我們所謂的工控機或工業網關上，它運行的Kube Edge的Edge Core進程，它是負責在邊緣側運行我們的容器化應用，包括做設備管理、數據采集的一些應用；

Edge Core再往下就是Mapper,它是社區定義的一個標準，專門用來做設備管理和數據采集的，Mapper社區目前是提供了Modbus和藍牙，比如我想管理一個攝像頭，一個自己的設備，那我需要按照社區的規范去寫Mapper，再往上看是我們封裝那一層，通過Java和Spring Cloud封裝了一層管理服務，為什么要做這一層封裝呢？如果我們直接把KubeEdge或K8s的API暴露給用戶，會有一些安全上的隱患，因為這個接口還是比較開放的，可能涉及到一些數據隔離性和K8s集群本身的一些功能，如果我們一旦把這個API暴露，用戶可能會做一些破壞性的操作，所以我們對外還封裝了一層業務邏輯。

最后我們還做了一個工業APP集市，做這個的原因主要是我們社區其實是定了一個標準，我個人開發者或者廠商其實我可以按照這個標準去做Mapper應用，做完之后它可以發布到我們的應用市場，我們可以收費或者免費分享給其他用戶，其實這樣我們也是希望建立這樣一個生態來鼓勵大家基于KubeEdge去做Mapper,希望做Mapper的開發者也能得到收益，這是我們的一個考慮。

數據采集

我們在項目過程中對KubeEdge的一些改進：

（1)支持更廣泛的工業設備與協議

其實我們在剛做項目的時候發現KubeEdge支持的協議是有限的，只支持藍牙、Modbus，而且它的CRD中把這個東西已經固定了，我們沒有辦法進行修改，所以我們要增加自己的協議就很不靈活，我們需要對代碼層做一些改動，考慮到工業上協議非常多，而且有些是私有的東西，所以我們為了更好的支持這些協議，就允許做一些自定義擴展，一個是擴展現有的協議，比如說大家同樣都是用Modbus協議，不同的設備可能有一些額外的配置，這個時候就可以用到我們新加的CustomizedValue字段，可以自定義的去配一些字段；第二種是完全就不用社區的協議，這個時候可以完全用我們的CustomizedProtocol，完全自定義自己的協議。

（2)支持更便捷的設備采集配置

其實工業上和我們有些IT思路還是不太一樣，我們做IT的一般是先定義模板，再定義實例，但是工業上有所不同，一般是先定義實例，將實例復制修改里面的內容，但其實他們這么做也是考慮到現實情況的，舉個例子，我有10個溫度傳感器，它是一模一樣的，接到了同一個工業總線上，但是它所謂的屬性都是一樣的，唯一的區別是它在Modbus上的偏移量不一樣，所以說我只要把Instance中的偏移量改了就可以了，所以基于這種考慮我們把原來Device model中的PropertyVisitor移動到DeviceInstance中，然后也加入了一些更靈活的配置項，比如整個采集周期是不可以配置的，工業中不同測點它是可以配置不同的采集周期，比如溫度中周期可能是一小時一次，那像能耗數據可能就不需要這么高的頻率了，所以這就需要一個更靈活的采集周期的一個配置，我們還做了增加CollectCycle等配置項到PropertyVisitor中以及抽取串口、TCP配置到公共部分。

（3)優化孿生屬性的下發

（4)支持旁路數據配置

旁路數據處理

支持Mapper推送時序數據至邊緣MQTT broker（EdgeCore不處理）,具體推送到哪個Topic中也是可以定義的

與EMQX Kuiper進行集成，Kuiper支持從DeviceProfile中讀取元數據

清洗規則由KubeEdge下發給Kuiper

第三方應用直接從邊緣MQTT中獲取數據

狀態監控

其實要做一個商用的產品，狀態監控是非常重要的，其實我覺得KubeEdge目前在監控這塊還是有些缺失，社區提供了一個叫Cloud Stream的通道，這個通道可以配合MetricServer，也可以配合Prometheus，但是需要配置iptables來將流量攔截下來；還有一個是我如果一配就將整個流量攔截下來了，所以這塊是有些問題的。

所以我們也做了另外一個方案：在邊緣節點起了一個定時任務容器，這個定時任務做的事情也很簡單，比如每5秒從我邊緣的NodeExporter拉一次數據，把本地的數據拉完之后推到PushGateway上，PushGateway是普羅米修斯官方的一個組件，這個PushGateway是放在云上的，那通過這種方式我們可以實現整個監控。

三、其他項目中遇到的一些問題

多租戶共享

其實K8s本身是有多租戶的設計的，但KubeEdge在做的時候我們的Device沒有考慮Namespace的問題，所以我們如果現在在Device中用Namespace是有bug的,所以現在KUbeEdge原身是沒有辦法把不同的設備放在不同的Namespace下，這個我們只能從業務層的業務邏輯做封裝，比如給Device打一些標簽，通過標簽去做篩選；邊緣node工作節點也是沒有辦法歸屬Namespace的，但是在我們的場景下，某個節點是屬于某個租戶的，是由這個租戶獨享的，這個時候我們可以通過和上層業務邏輯進行封裝。

IP地址限制

其實按照我們現在的設計，我們每個租戶會給他們一個K8s集群，會去連它的一個邊緣設備，這種的方式其實云端的集群要求有一個公網IP,IP資源其實還是比較緊張的，怎么在地址有限的情況下比如說我們做一個項目給你200個公網IP,但我可能有1000個用戶，那怎么去解決？

1）IPv6是最徹底的解決方案：目前社區給的答案是支持，但我們現在還沒試過

2）端口復用：其實kubeEdge需要使用的端口比較少，默認是10003，最多也就4-5個端口，其實一個公網IP是可以給多個kubeEdge實例去復用的

高可用方案：這個其實社區是有的，其實是復用了kubernetes自有的功能，Service+Deployment與狀態檢查?應用案例

案例一：OPC-UA數據采集與處通過我們的放到了我們的應用超市，用戶訂購了以后OPC-UA mapper下發到邊緣的網關上，再通過我們的一個頁面配置就可以實現從

從邊緣的工業設備上去采集數據，比如說：

OPC-UA mapper采集溫度數據

邊緣節點告警應用直接從邊緣獲取數據

超過閾值觸發告警，暫停設備

KubeEdge對閾值進行調整

案例二：工業視頻安防

這個是一個偏邊緣自治的一個應用，其實和云目前的交互比較少，它下發到邊緣側可以獨立運行，主要在邊緣側做AI推理，那如果要它和云結合起來，我們會把模型的訓練放到云上，把訓練完成的模型再通過KubeEdge推送到邊緣，主要有：

KubeEdge管理邊緣節點上的視頻安防應用配置

邊緣視頻安防應用在邊緣節點自治運行

攝像頭中取流，AI推理

安全帽、工作服佩戴檢測

危險區域禁入檢測

四、總結

（1）基于KubeEdge工業數據采集

當前通過CustomizedProtocol與CustomizedValue，已能支持各類工業協議

通過ConfigMap可以實現云端對邊緣數據應用（Mapper）的控制

旁路數據（Spec/Data）為時序數據的處理提供了更便捷的支持

（2）KubeEdge的產品化

多租戶方案

多種監控方案

高可用方案

公網IP復用方案

大數據 工業智能體 邊緣數據中心管理 EDCM

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。