摘要：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消息吞吐
點選關注，第一時間了解華為雲新鮮技術~