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。
