1. 邊緣計算
邊緣特指計算資源在地理分布上更加靠近設備，而遠離雲數據中心的資源節點，可以理解為是近場計算。典型的邊緣計算分為物聯網（智慧城市，智能家居等）和非物聯網（CDN 等）場景。
1. 物聯網場景
隨着互聯網智能終端設備數量的急劇增加，以及 5G 和物聯網時代的到來，傳統雲計算中心集中存儲、計算的模式已經無法滿足終端設備對於時效、容量、算力的需求。將雲計算的能力下沉到邊緣側、設備側，並通過中心進行統一交付、運維、管控，將是雲計算的重要發展趨勢。
2. 非物理網場景（以CDN為例）
CDN的全稱是ContentDelivery Network，即內容分發網絡。CDN是構建在現有網絡基礎之上的智能虛擬網絡，依靠部署在各地的邊緣服務器，通過中心平台的負載均衡、內容分發、調度等功能模塊，使用戶就近獲取所需內容，降低網絡擁塞，提高用戶訪問響應速度和命中率。CDN的關鍵技術主要有內容存儲和分發技術。簡單的說CDN就是用空間換時間，空間的話就是分部在離終端用戶較近的邊緣節點，時間上就是終端用戶直接從邊緣節點直接獲取資源，這樣就不需要直接訪問源站，從而提升用戶體驗。
邊緣計算的主要計算節點以及應用分布式部署在靠近終端的數據中心，這使得在服務的響應性能、還有可靠性方面都高於傳統中心化的雲計算概念，而CDN的節點正好可以充分復用起來，提供計算服務。
3. 思考
隨着雲計算的崛起,K8S已經升入人心,強大的容器編排能力讓人眼前一亮,隨着5G網絡的橫空出世，IOT借着5G開始大力發展，我們自然而然的就會思考，在一些算力資源並不那么足夠的情況下能否將k8s的容器編排能力賦予上去，例如做到計算下沉,在某些遠離雲數據中心的場景下（這里特指物理距離），邊緣能夠做出及時的響應實時計算就很重要。於是，華為的KubeEdge就由此誕生了。華為的KubeEdge前生是華為的IEF，KubeEdge也就是基於IEF的某一個時候的分支分化出來的，華為決定開源，就有了現在的KubeEdge。
2. KubeEdge
KubeEdge是一個開源系統，用於將容器化應用程序編排功能擴展到Edge的主機。它基於kubernetes構建，並為網絡應用程序提供基礎架構支持。雲和邊緣之間的部署和元數據同步。
從上面的架構圖可以很好的看出KubeEdge分為雲和邊兩部分組成。雲端即Cloud，邊緣即Edge。這里順便講一下KubeEdge和K8s的關系，KubeEdge是依托K8s運行的，脫離k8s,KubeEdge是沒有意義的，因為KubeEdge無非也就是定義了幾個自己的CRD，搞了幾個controller然后實現雲邊通信balabala...其實這東西沒這么復雜。剝開KubeEdge的源碼你會發現，里面竟然用到了client-go,這就更加說明了沒有k8s，kubeedge其實啥也不是。唯一和k8s不同的是，在一個部署了KubeEdge的集群中，如果想要加入負載節點，不需要像k8s這樣加入，從上面的架構圖中可以很明顯的看到，邊緣端即Edge完全就沒有kubelet這種東西，取而代之的是一個叫Edged的組件，這兩個東西雖然名字不一樣，不過功能是類似的，只不過因為邊緣節點的資源實在是有限，所以Edged其實就是一個裁剪閹割版的kubelet。還是沒有弄明白的話看下面的文章吧，我講kubeedge部署的時候你就大概能看明白了，如果這樣還是沒有弄明白k8s與KubeEdge的關系的話，直接在下面的評論區留言，我和你好好掰扯掰扯。
1. Cloud
EdgeController & DeviceController & Cloud Hub
Cloud的核心組件是Cloudcore,這只是一個二進制而已，剛剛我也說了，核心就是controller，這里有兩個controller，一個是EdgeController還有一個是DeviceController。其實這倆controller的作用從字面上就能看出來了。EdgeController是負責管控邊緣Edge的，另一個DeviceController，就是負責管理設備相關的啦。KubeEdge的一大亮點就是本身自己就支持接入物聯網的硬件設備。當然這也是KubeEdge定義了兩個特殊的設備CRD，一個叫Device一個叫DeviceModel,然后邊緣端部署Mapper(數據采集的應用，Mapper是KubeEdge的叫法)然后邊緣到雲的數據采集。這我只是說了一個大概，內部還有一些細節，具體的細節還是等我之后文章的寫吧，我敢保證我輸出的這些，在KubeEdge與IOT結合的場景下，也就是和設備相關的場景，如果你用KubeEdge，我輸出的干貨，不管是Google還是百度，在全球范圍內搜索你都搜不到如此詳細的實踐細節與理論介紹，喝水不往挖井人，還是要感謝浙大SEL實驗室,華為KubeEdge社區以及HarmonyCloud的支持。ok，回到正題，介紹完了controller，還剩下一個Cloud hub，這個組件就是Cloudcore和Edgecore交互的核心組件，edgecore通過websocket或者是quic接入cloudcore的cloudhub。
2. Edge
Edge的核心組件就是edgecore，和cloudcore一樣也是一個二進制文件,edgecore相對於cloudcore而言，組件要多很多。
1. MetaManager
MetaManager模塊后端對應一個本地的數據庫（sqlLite），所有其他模塊需要與cloud端通信的內容都會被保存到本地DB種一份，當需要查詢數據時，如果本地DB中存在該數據，就會從本地獲取，這樣就避免了與cloud端之間頻繁的網絡交互；同時，在網絡中斷的情況下，本地的緩存的數據也能夠保障其穩定運行（比如你的智能汽車進入到沒有無線信號的隧道中），在通信恢復之后，重新同步數據。
2. Edged
之前提到過kubernetes的kubelet，它相當於k8s的核心。這塊其實簡單做了一些裁剪，去掉一些用不上的功能，然后就成為Edged模塊，該模塊就是保障cloud端下發的pod以及其對應的各種配置、存儲（后續會支持函數式計算）能夠在edge端穩定運行，並在異常之后提供自動檢測、故障恢復等能力。當然，由於k8s本身運行時的發展，該模塊對應支持各種CRI應該也比較容易。
3. EventBus/ServiceBus/Mappper
前面講到的模塊都與k8s直接或間接相關，接下來說下與設備（或者說真正IOT業務）相關的設備管理側。外部設備的接入當前支持MQTT和Rest-API，這里分別對應EventBus和ServiceBus。EventBus就是一個MQTT broker的客戶端，主要功能是將edge端各模塊通信的message與設備mapper上報到MQTT的event做轉換的組件；而ServiceBus就是對應當外部是Rest-API接入時的轉換組件。說道這里，就有必要提一下MQTT broker，其實搞互聯網的基本都用過類似於rabbitmq、activeMQ之類的消息中間件，其實他們就支持MQTT協議啦（可以理解為AMQP的精簡版）。IOT的各種設備可能直接支持MQTT，但有的只支持藍牙或者其他近場通信的協議。沒關系，Mappper可以實現將各種協議轉換為對MQTT的訂閱與發布，從而實現與edge端的通信。當然，ServiceBus對應就適用於支持http協議的服務了。
4. DeviceTwin
edge端最后就剩下一個DeviceTwin模塊了，要理解這個名詞，就得提一下數字孿生這個概念。這里來科幻一下，假設人類要實現乾坤大挪移，但是有點難度的是，這下是要把你移到火星上。怎么辦？這里有一個解決方案：在地球上通過掃描你的所有生物信息，生成擁有你完整生物特征的數據包之后，然后在地球上就把你毀滅了。再將描述你完整信息的數據包通過電波光速發送到火星上，讓火星的設備再使用接收到的生物特征造出一個你。是不是挺可行！_ 回個頭來，我們要說的數字孿生就是那個用來傳輸到火星的用於描述你所有生物特征的數據包；當然，這里對應就是接入設備信息。所以，DeviceTwin就是將這些信息保存到本地DB中，並處理基於cloud端的操作來修改device的某些屬性（也就是操作設備）；同時，將設備基於eventBus上報的狀態信息同步到本地DB和cloud端的中間人。
3. Mapper
Mapper不是EdgeCore的組件,但是和Edgecore有着密不可分的關系,Mapper是一個抽象的概念,在KubeEdge中專門指采集應用的程序，而且是以Container的形式運行在edgecore的Docker中(當然你可能用的並不是不是Docker,也可能是containerd等的別的CRI容器運行時)。Mapper是專門為KubeEdge在IOT場景下設計的，配合之前我提到過的Device和DeviceModel等等的CRD，簡單的理解就在在傳統的IOT工作的方式上加上容器編排部署的功能，這也就是KubeEdge的核心。截止到當前KubeEdge社區當前實現了Bluetooth和Modbus(RTU和TCP)的Mapper,CRD中還定義了OPCUA協議的相關字段，當前還沒開發相關的Mapper。如果你有別的協議，比如是NB啊Lora啊要實現這些的Mapper，需要自己動手去開發，CRD中有預留字段給新的協議的。關於Mapper這東西具體咋玩的，后續我會在博客中更新，等着我更新就行。
4. 總結
整個KubeEdge的架構設計已經大概宏觀的講了一遍,Kubeedge一直在更新迭代，我現在寫這篇文章的時候ke是v1.5.0版本，該版本實現了雲邊隧道,可以和k8s一樣實現exec和log的功能。在邊緣計算領域，ke相對而言是一個開源比較早的邊緣計算框架，相比於Rancher的k3s 阿里巴巴的openyurt和騰訊的superedge這些項目而言，從實際的落地場景和社區的活躍度，ke都是比較健壯的，朝着一個良性的方向發展，而且在2020年已經成為了CNCF的孵化項目，筆者自己本身也是ke開源社區的貢獻者，所以還是比較看好以后在邊緣計算領域ke的發展，希望可以早日從CNCF畢業。