KubeEdge邊緣自治設計原理

這一篇內容主要是KubeEdge中邊緣節點組件EdgeCore的原理介紹。

KubeEdge架構—EdgeCore

 

 上圖中深藍色的都是kubeedg本身實現的組件，亮藍色是k8s社區原生組件。這篇主要內容是黃色框框的這三個組件。有一個值得注意的是，這些藍色框的組件其實都是一個模塊，都是在一個進程edgecore裏的。

Module間通訊

 

這裏Process至關於EdgeCore，是一個進程，這個進程裏面分爲多個Module模塊（EdgeHub、MetaManager、EdgeD）。

它們之間是經過一個BeehiveContext進行通訊的，首先模塊起來以後會在BeehiveContext中進行註冊，每一個模塊會有一個對應的channel，這個channel是根據Modeule name放到一個map裏面。加入模塊B要給模塊A發送消息，它就會根據模塊A的名字將要發送的消息塞到對應的channel隊列裏，模塊A一直在監聽，有數據時就會去讀出來。這就是一個進程裏面Module間通訊的原理。

ModeuleContext是模塊註冊相關接口

MessageContext是發送數據相關接口，好比send(module stirng,message model.Message)函數，第一個參數表示要發送給哪一個模塊，第二個message的類型和以前雲邊通訊的message是同一種，也就是說kubeedge裏面全部的通訊包括雲邊協同的通訊、進程間各個模塊之間的通訊，消息的結構都是統一的。

 

EdgeHub

edgehub是邊緣節點用來收發數據的模塊，與之相對應的是雲端的cloudhub。

上行——經過EdgeHub刷新狀態

 

 

上行的數據包括：edged管理的node、pod的狀態信息，它先報到MetaManager這邊，MetaManager在傳到EdgeHub，通過edgehub把數據同步到雲上。這樣就實現了node、pod狀態的上報。關於設備的信息這篇內容不纖細展開。

下行——經過EdgeHub下發元數據

 

這裏的MessageDispatcher的做用和雲上的有點區別：這個是分發到不一樣的模塊，雲上是分發到不一樣的邊緣節點。若是是pod的元數據，就推給metamanager->Edged去拉起相應容器；若是是設備信息，就推給DeviceTwin->EventBus。

 

MetaManager

 

MetaManager的做用是在EdgeHub和Edged之間作持久化，它會把原數據先持久化，注意：這裏若是持久化失敗的話，它會從新存或者發送失敗的消息給雲端，直到持久化成功後纔會把數據傳到Edged等相應模塊。

EdgeD 

 

EdgeD是裁剪的輕量化kubelet，保留了應用生命週期管理的相關模塊，去掉了一些沒必要要的東西，好比第三方存儲這些在邊緣暫時不須要的。這裏也集成了CNI/CSI/CRI，如今CNI裏的東西都放在CRI裏面去調用了，因此從代碼裏面看不到CNI的東西。

MetaClient是EdgeD新加的東西，MetaClient是直接跟MetaManager通訊的，原生的kubelet裏面KubeClient是跟api-server通訊的。這裏改了之後呢EdgeD掛掉重啓以後拿到的數據是經過MetaClient到MetaManager那邊去數據庫裏去拿，原生的KubeClient會去從ApiServer裏面去拿。

 

邊緣自治原理

雲邊鏈接斷開

 

第一種狀況是 雲邊鏈接斷開後，邊緣業務可穩定運行。原生k8s中斷連後，節點上的資源信息會被調度到其餘節點。

還有一種狀況是雲邊鏈接斷開後，邊緣節點重啓。原生k8s中，kubelet拿到的數據是保存在內存中的，若是鏈接斷開，節點重啓後，內存緩存的東西就會丟失，服務不可恢復。在KubeEdge中，邊緣節點重啓後會從本地數據庫中拿到相應數據進行服務恢復。

管理邊緣的完整集羣

 

 

目前邊緣自治的特性只適合單節點，邊緣集羣的自治可能會在後續版本中支持，也是目前我想要作的方向。若是邊緣資源充足的話能夠跑K8s集羣，若是不充足的話用KubeEdge支持的EdgeSite。