摘要：KubeEdge 是一個開源的邊緣計算平臺，它在Kubernetes原生的容器編排和調度能力之上，擴展實現了 雲邊協同、計算下沉、海量邊緣設備管理、邊緣自治等能力。KubeEdge還將通過插件的形式支持5G MEC、AI雲邊協同等場景，目前在很多領域都已落地應用。
在邊緣的流失處理產品Kuiper
Kuiper是從2019年初開始做的，在2019年10月份，發佈了第一個版本，一直持續迭代到現在，它的整個架構是一個比較經典的流式處理架構。
產品設計目標：在雲端運行的流式處理，像Spark與Flink可以運行在邊緣端
Kuiper架構圖
整體架構可分爲3部分，左側爲sources,代表數據來源的位置，數據來源可能是KubeEdge裏面有個邊緣端的MQTT macOS broker，也可能是文件、窗口、數據庫；
右側爲Sinks，代表數據處理完成後所要存儲的位置，也就是目標系統，目標可以是MQTT，可以將其存到文件、數據庫裏面，也可以調用HTTP service；
中間部分分成了這幾層，最上層爲數據業務邏輯處理，這個層面提供了SQL statement、Rule Parser，SQL processors進行處理後並將其轉化成SQL plan；下面層爲Streaming runtime和SQL runtime, 運行最終執行出來的 plan；最底層爲storage，用來存儲有些消息流出。
Kuiper使用場景
流式處理：實現在邊緣端的實時流式處理
規則引擎：靈活定義規則引擎，實現告警和消息轉發
數據格式與協議轉換：實現邊緣與雲端不同類型的數據格式與異構協議之間靈活轉換，實現IT&OT融合
KubeEdge與Kuiper集成
部分架構圖
Kuiper是裝在 KubeEdge MQTT Broker後面，整個都運行在邊緣端，底下爲不同的Mapper，也就是接入各種各樣不同的協議。邊緣MQTT Broker用來交換消息。
數據處理的類型：
從設備模型文件定義中獲取類型定義
將數據轉換爲Kuiper的數據類型
創建流時，可使用schema-less流定義
支持的數據類型有int、string、bool、float
KubeEdge模型文件和配置
下圖爲部分配置文件，包括設備的名稱、屬性、name、data type、Description等。
部分配置文件
保存設備模型文件
在ect/mqtt_source.yaml中配置模型文件信息
- KubeEdgeVersion:目前未使用，爲適配將來不同的版本模型文件預留
- KubeEdgeModelFile：模型文件路徑
通過config-map下發配置，保存到相關目錄下
Kuiper使用過程
1）定義流：類似餘數據庫中表格的定義
DATASOURCE=”$hw/events/device/+/twin/update”爲KubeEdge裏定義好的topic
2）定義並提交規則
用SQL實現業務邏輯，並將運行結果發送到指定目標
支持的SQL
SELECT/FROM/WHERE/ORDER
JOIN/GROUP/HAVING
4類時間窗口+1個計數窗口
60+SQL函數
3）運行
KubeEdge中部署Kuiper規則
1）運用Kuiper-Kubernetes-tool
2）該程序爲一個工具類，單獨運行在容器中，執行通過config-map下發的命令配置文件
配置文件中用於指定kuiper服務所在的地址和端口等信息
命令文件所在的目錄
3）通過config-map下發命令執行文件，該工具定期自動掃描文件，然後執行命令
Kuiper manager-雲邊協同管理控制檯
另外一種方式是通過管理控制檯來管理很多Kuiper節點，因爲Kuiper可以運行在很多節點上。
比如Kuiper可以運行在車聯網的盒子裏面，車聯網有很多車，可以通過Kuiper-manager把所有的實例都接入進來，統一對其進行規則更新。
第一步是安裝插件，我們提供了一些插件的知識，比如要接入不同的源，如果我們這邊的源不支持，則可以自己寫個插件，將插件進行安裝，安裝上去之後我們提供安卓插件界面，就可以使用了。
接下來爲創建流定義
下圖爲數據存儲的位置，下圖所示爲將數據保存到文件系統，進行路徑的指定。
下圖爲可視化的編輯界面，可以進行規則的編寫。
應用案例：國家工業互聯網大數據中心
該案例是一個非常典型的使用場景。K8s+CloudCore部署在雲端，將規則通過管理通道下放到Kuiper，Kuiper的位置是放在MQTT broker，會將數據定義，實現數據的清洗。目前通道有兩條，第一條是將處理完的消息發往Cloud MQTT broker，第二條通道比如本地要做數據持久化，可將其存到Influxdb這個持續數據庫，我們在邊緣發生的一些第三方應用可以直接去調Influxdb裏面的數據，做一些展示可視化等。底層是通過Mapper把不同的數據給接上來。
Kuiper裏規則引擎的使用場景
LF EdgeX Foundry內置規則引擎，於2020年4月Geneva版本中已經正式發佈。
應用案例：異構系統對接數據格式轉換
實現與ERP、MES等IT系統數據交換，我們提供了一個非常靈活的擴展能力，包括異構數據通過擴展插件採集後，可以利用SQL內置函數或者擴展函數進行快速、靈活處理；第二點是拿到數據處理結果後，通過sink的數據模板可以對分析結果進行轉換，靈活適配各類目標系統所需的數據格式和協議，比如同樣一條溫度大於30度的規則，如果要去發送控制設備的指令，並且要發到微信上。這兩個不同的目標系統，它所需要的接口和數據是不一樣的，但對於這個規則是一樣的，那麼可以在 data裏面，根據同一條規則觸發兩個不同的操作，你可以指定不同的 topic，數據即可發送，不需再進行復雜的編程；第三點是利用SAP NetWeaver RFC SDK,實現從SAP中讀取數據，處理並轉換後發送到別的異構系統。
性能數據
Kuiper 支持併發運行數千條規則
8000規則*0.1消息/秒/規則，共計的TPS爲800條/秒
規則定義
源：MQTT
SQL:select temperature from source where temperature＞20（90%數據被過濾）
目標：日誌
配置
AWS:2core*4GB
Ubuntu
資源使用
Memory:89%~72%;0.4MB/rule
GPU:25%
AWS t2.micro 配置10k+/s消息吞吐
