這一篇內容主要是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。