目錄
KubeEdge由華爲開源，2019年3月捐給CNCF基金會
現在開源邊緣計算正在經歷其業界最具活力的發展階段。如此多的開源平臺，如此多的整合以及如此多的標準化舉措！這顯示了構建更好平臺的強大動力，以便將雲計算帶到邊緣以滿足不斷增長的需求。同時Kubernetes現在已經成爲容器編排的事實標準，在雲原生領域大放異彩，能否可以將Kubernetes應用於邊緣計算領域？具有哪些優勢，又有哪些挑戰？
什麼是邊緣計算
邊緣計算（Edge computing）是一種在物理上靠近數據源頭的網絡邊緣側來融合網絡、計算、存儲、應用核心能力的開放平臺。爲終端用戶提供實時、動態和智能的服務計算，邊緣計算會將計算推向更接近用戶的實際現場，這與需要在雲端進行計算的傳統雲計算有着本質的區別，而這些區別主要表現在帶寬負載、資源浪費、安全隱私保護以及異構多源數據處理上。
這裏有一個非常典型的例子， 就是章魚，章魚在捕獵時它們動作非常靈巧迅速，腕足之間高度配合，從來不會纏繞和打結。這是因爲章魚的神經元的分佈是40%集中在他的頭部，60%的神經元分佈在他的觸角上，是“多個小腦+一個大腦”的構造，類似於分佈式計算。而邊緣計算也是一種分佈式計算，這種分佈的好處呢，就是大部分重複的，低級的操作，都有觸角來完成，是減輕了中央章魚大腦的功耗，而讓中央大腦只處理一些核心的數據。
隨着5G，萬物互聯時代的到來，整個網絡設備接入的數量，以及靠近設備端產生的數據會爆發式增長。這就遇到一個問題，如果所有數據處理都放到集中式數據中心，帶寬，實時性，能耗，隱私等等都會面臨很大的挑戰。但採用邊緣計算，就可以就近處理海量數據，大量設備可以實現高效協同工作，諸多問題迎刃而解。
邊緣的價值
因此邊緣計算有着它獨特的價值：
連接的廣泛性， 因爲他高度分散，能夠覆蓋到用戶的實際現場各個終端。
是數據帶寬的優化，可以將部分業務下沉到數據的產生源頭，這樣大部分的數據並沒有經過骨幹網，這對於整體網絡的帶寬是一個極大的優化，通過本地數據預處理，可以極大減少傳輸帶寬的需求，這裏面最典型的例子就是CDN，通過就近拉取視頻流，這樣骨幹網絡只有中心站點到CDN站點幾份的數據傳輸。但是每個CDN站點的訪客可能數以萬計或者百萬計。
是邊緣的自治性，整個業務下沉到邊緣，高度分散之後，邊緣跟中心雲的網絡不能很好的保障，這就需要在骨幹網絡質量不能保證的情況下，需要邊緣具備一定的自治性。這樣才能更好的服務終端業務的請求。
從端到端的體驗來說，主要體現的是業務的實時性，因爲大部分的業務請求都在邊緣處理， 整體的業務請求可以縮小到10ms以內。
最後一點， 因爲實施邊緣計算以後，可以減少大量不必要的敏感數據的跨網傳輸，可以在邊緣做數據的預處理或者匿名化處理，把最敏感的數據處理放在邊緣，這樣可以大大的增強數據的安全性和隱私保護。
推動邊緣計算的四大主要因素
其實邊緣計算這個概念已經出現了很長時間， 那麼爲什麼近幾年會快速發展呢，其中一方面是因爲網絡技術的快速發展，以及5G時代的到來，萬物互聯，一切連接皆有可能。從關鍵因素上來來，主要是4大點：
低時延，很多新興的業務快速發展，包括自動駕駛，AI，VR等等，這些都對時延有非常苛刻的要求。
是隨着接入到網絡的設備數量大量增多， 導致數據爆發式增長， 這也是對邊緣計算的一個很大的推動力。
是隱私安全，像現在人工智能， 以及對應的人臉，指紋識別等，但是這些最原始的指紋或者人臉的隱私信息， 我們不希望在公網傳輸被被人去盜取或者篡改數據，如果用邊緣計算呢， 我們可以避免這種問題。
最後一點呢， 就是邊緣的業務要具備自治能力，如果跟雲端的網絡請求斷開，或者網絡質量不高的情況下， 邊緣業務要在出現故障時候，自我恢復。
這是推動邊緣計算的四大主要因素。
基於Kubernetes構建邊緣計算平臺
那麼需要什麼框架去構建邊緣計算平臺呢？我們可能首先想到的就是現在大火的Kubernetes。
對Kubernetes來說，它的核心功能基本上趨於成熟。現如今Kubernetes已經日益成爲公有云/企業IT系統的基礎設施，不僅大多數新興的雲原生負載是構建在Kubernetes上的，我們還將看到傳統應用和負載也在以更快的速度向Kubernetes遷移，人們趨向於使用Kubernetes。而且Kubernetes 在朝着大規模，複雜場景的方向延伸，與AI、大數據、IoT、以及垂直行業等領域的結合越來越緊密。近來，越來越多圍繞Kubernetes生態圈的創新，正在這些領域發生着。
與其他的新技術出世的情景類似，目前的邊緣計算也是一片炙熱的景象，多種技術形式出現，大家都在爭奪這個領域。而且邊緣計算的發展空間顯然是無限的，實現的方式也是無限的，多種多樣。這使得靈活性成爲了非常重要的關鍵點。如果打算讓下一代服務能夠繼續與傳統IT進行交互操作，兼容傳統IT，就要去邊緣計算技術儘量能夠在任何類型的架構（邊緣、雲或集中式硬件）中部署和擴展，去兼容異構的架構，而這更Kubernetes的設計理念有點類似。
Kubernetes項目源自於Google的borg項目，天生站在巨人的肩膀上，自2014年6月開源以來，Kubernetes在衆多廠商和開源愛好者的共同努力下迅速崛起。現在已經基本成爲容器編排的事實標準。而且越來越多的公司和組織加入CNCF，衆多的開源愛好者參與Kubernetes社區開發，現在，Kubernetes已經成爲容器編排領域的事實標準。超過80家廠商都已經提供了經過認證的標準的Kubernetes服務。除此之外，還有很多公司都在使用Kubernetes的服務。而且圍繞Kubernetes的雲原生版圖也是越來越豐富。
邊緣計算場景下：Kubernetes的優勢
那麼在邊緣計算場景下使用Kubernetes ，具有哪些優勢呢？
這裏首先要從Kubernetes的架構說起。
瞭解Kubernetes的同學對Kubernetes已經很熟悉了，這裏我再簡單介紹一下：
從架構層面，Kubernetes是一種比較先進的松耦合的架構。控制層面有：API server，controller-manager，Scheduler，集羣的狀態都存在etcd中，數據面有：kubelet和kube-proxy安裝在每個計算節點，用來管理Pod生命週期和網絡的處理。
它所有的組件都是用過API server來進行訪問的，這樣可以保證數據訪問的過程是可以被鑑權和認證的。同時所有組件之間，沒有耦合關係， 他們都跟API server做交互，只依賴於API server，他的API是聲明式設計的。同時在具體的應用聲明週期的管理過程中呢， 他是通過多個API對象，彼此互不，和組合來實現解耦。
其次由於容器有輕量級、安全性、秒級啓動等優秀的特性，容器天然的輕量化和可移植性，對應用進行容器化封裝，使用容器本身的特性，充分使用build once，run anywhere的優勢，輕量化基礎鏡像，降低資源的佔用，非常適合邊緣計算的場景，這一點邊緣計算的廠家和開發者們都心知肚明。而且鑑於Kubernetes已經成爲雲原生編排的事實標準，因此攜手Kubernetes進入邊緣將很有可能結束邊緣計算當前混沌的狀態，並定義雲端和邊緣統一的應用部署和管理的標準。
最後在邊緣計算場景下，有着大量的異構設備，每種設備都有自己獨特的特徵屬性，我們可以充分利用Kubernetes提供的擴展的API資源：CRD功能，對這些設備進行數據建模，數據抽象，從而進行統一管理。
邊緣計算場景下：Kubernetes的挑戰
但是，Kubernetes不是天生爲邊緣計算而生的， 他是從集中式數據中心的場景裏誕生出來的技術，因此在邊緣計算場景下，Kubernetes也遇到了很多挑戰：
- 爲了減輕API server的訪問壓力以及集羣狀態的快速同步，Kubernetes優先使用事件監聽（list-watch）方式而不是輪詢方式來處理。這也是一個很大的亮點。這種情況比較適合於網絡質量較好的數據中心去部署。但是反過來講，這會對邊緣計算場景帶來挑戰。Master和Node通信是通過list watch機制，它沒有辦法在邊緣場景這種受限的網絡下很好的工作，本身list watch實現也是假設的是數據中心的網絡，整體網絡質量相對比較好的情況下。
- 另外Kubernetes節點是沒有自治能力的，如何在網絡質量不穩定的情況下，對邊緣節點實現離線自治，這也是個問題。
- Kubernetes各個組件其實是比較耗資源的，當然這種組件對資源的佔用，相對於集中式數據中心的資源來說是微不足道的，但是在邊緣，資源有限的場景下，Kubernetes是很難很好的工作的。一個kubelet啓動大概就佔用上百兆的內存，整個Kubernetes如果附上HA的能力，實際上會佔用相當多的資源。如果你想你的應用跑在一些IOT網關或者設備上，他們可能只有幾百兆的內存，或許一個原生kubelet都跑不起來。
- 還有就是，在邊緣計算場景下，它有很多異構的邊緣設備，支持的工業協議也不一樣，那麼這些邊緣設備怎麼管理，怎麼讓邊緣應用通過比較解耦的方式與這些設備交互，這是Kubernetes本身沒有提供的。我們只能充分利用Kubernetes 的CRD資源進行二次抽象。
- 還有一個問題是在邊緣計算場景下，應用和節點的監控和報警問題，是在邊端進行數據的監控報警，還是在雲端統一進行收集，這也是一個很大的挑戰，另一個問題，是在Kubernetes的架構選型上，我們到底採用哪種場景和架構。
邊緣計算場景下：Kubernetes的架構選型
第一種是將整個Kubernetes集羣跑在邊緣，第二種是將Kubernetes的控制層面跑在雲端，去管理邊緣的計算節點。
這是很多在Kubernetes構建邊緣計算平臺時候，所面臨的問題。
實際上在Kubernetes IOT EDGE這個working group調查中顯示，兩者比例是30%的人更傾向於把整個Kubernetes集羣跑在邊緣，這種場景更多的是一些近場的邊緣，就是相對來說，靠近邊緣的網絡位置上的這種邊緣計算，要求呢就是計算能力相對要高一點，首先要能夠承載Kubernetes本身組件的運行。
還有70%更多的人，更傾向於這種現場的邊緣計算，這種邊緣是一種更輕量，更極致的邊緣計算追求。在這種情況下， 沒有太多的跨節點的調度，或者應用動態遷移的訴求，很多應用都會跟某個設備做綁定。
基於Kubernetes的開源邊緣計算項目
其實現在基於Kubernetes平臺的開源邊緣計算項目已經有很多個了，這裏列出來了三個：
K3s：https://github.com/rancher/k3s
Microk8s：https://github.com/ubuntu/microk8s
KubeEdge：https://github.com/kubeedge/kubeedge
當然還有其他的開源項目，有興趣的大家可以自行查找。
K3s定位是在邊緣端輕量化的Kubernetes集羣。
刪除了Kubernetes一些alpha的feature，專門針對ARM環境進行了發佈，爲了處理Node節點在內網的場景，專門增加tunnel proxy的組件，來傳遞像exec 或者logs這些命令請求。對於Kubernetes的核心代碼邏輯沒有大的改動。
在資源佔用上，已經比原生Kubernetes小了不少。Server在480M，Agent是120M。
由於Server和Agent主要還是通過List-watch來通信，還是很適合於純邊緣側部署一整套Kubernetes集羣，不適合雲邊協同的場景，只能運行在邊緣側。社區這塊，有Rancher開發和管理。
Mincrok8s是輕量級的Kubernetes發行版
Mincrok8s和K3s在應用場景上差不多，比較適合純邊緣的環境，也是缺少雲邊協同的解決方案。支持ARM/Win10/macOS安裝，Kubelet佔用大約80M內存，Master佔用大約600M內存，K3s對Kubernetes的部分核心代碼做了修改，但是Mincrok8s並沒有做修改。
KubeEdge由華爲開源，2019年3月捐給CNCF基金會
同時也是Kubernetes IOT Edge working group的關鍵參考架構之一。
主要是針對邊緣側做了優化：包括邊緣惻節點的離線狀態自治，雲邊消息傳輸默認使用WebSocket。支持雲邊協同，同時支持雲端集羣和邊緣端集羣的管理。
在邊緣側節點Edgecore的內存暫用率大約是70M，同時兼容Kubernetes的核心API功能，現在大約有超過250個貢獻者參與其中。
每個開源項目都有它的側重點，各有優勢，大家在技術選型時候可以根據自己的業務場景選擇不同的開源項目。
在這裏主要着重講一下KubeEdge。
KubeEdge詳解
KubeEdge三個核心理念
KubeEdge主打三個核心理念，首先是雲邊協同，邊是雲的延伸，用戶的邊可能位於私有網絡，因此需要穿透私有網絡，通過雲來管理私有節點，KubeEdge默認採用WebSocket+消息封裝來實現，這樣只要邊緣網絡能訪問外網情況下，就能實現雙向通信，這就不需要邊端需要一個公網的IP。同時呢，KubeEdge也優化了原生Kubernetes中不必要的一些請求，能夠大幅減少通信壓力，高時延狀態下仍可以工作。
KubeEdge第二個核心理念是，做到節點級的元數據的持久化，比如Pod，ConfigMap等基礎元數據，按照每個節點持久化在他的設備上，邊緣的節點離線之後，它仍可以通過本地持久化的元數據來管理這些應用。熟悉Kubernetes的同學應該知道，當kubelet重啓後， 它首先要向Master做一次list watch獲取全量的數據，然後再進行應用管理工作，如果這時候邊和雲端的網絡斷開，是無法獲得全量的基礎元數據，也不能進行故障恢復。KubeEdge做了元數據的持久化後，可以直接從本地獲得這些元數據，保障故障恢復的能力，保證服務的快速ready。
另外一個理念是極致的輕量化：在大多數邊緣計算場景下，節點的資源是非常有限的，KubeEdge採用的方式是重組kubelet組件，移除了內置了面向於雲廠商的驅動，通過CSI介入，去掉了static Pod，同時支持CRI，支持多種container runtime。在空載時候，內存佔用率很低。
這是KubeEdge整體架構，KubeEdge對原生Kubernetes的架構侵入比較小，都是旁路設計。
雲上：主要是通過旁路設計開發的CloudCore組件，邊緣節點的同步和維護是通過CloudCore來維護，CloudCore通過list watch來跟Kubernetes集羣做信息同步。而CloudCore裏面內置的CloudHub模塊和邊端內置的EdgeHub模塊，構建了一個WebSocket消息通道，通過結構化的消息封裝，來同步Kubernetes的基礎元數據，比如Pod，ConfigMap等等。另外CloudCore裏面還包含edgecontroler和devicecontroller模塊，這兩個模塊分別用來管理Kubernetes的元數據以及跟Device相關的CRD資源。
邊端：Edgecore，做到了持久化存儲，edged相當於一個精簡版的kubelet，支持CRI，底層可以對接多種container runtime，deviceTwin和DEventBus主要是做設備的元數據管理以及MQTT協議的訂閱和發佈。主要是跟終端設備通信用。
在終端設備這裏：現實場景裏， 設備終端會有多種多樣的訪問協議，當然比較新興的一些設備可能會直接支持MQTT協議，但是對於一些專用的設備或者工控的領域呢，會有他們專用的協議，KubeEdge呢採用了Mapper的設計，可以將這些專有的設備的協議轉換成MQTT協議，來實現邊緣的應用和雲上的設備數據的同步和管理，當然KubeEdge最新版本還有SyncController，用來負責可靠性消息傳輸的同步問題，大家有興趣的可以自行查看KubeEdge的源碼。
雲端的核心組件CloudCore
那麼在雲端的核心組件CloudCore，主要由下面幾部分組成：
Edge Controller：主要是來負責邊緣節點元數據的同步和管理，主要是Pod，ConfigMap等應用相關的元數據。
Device Controller：是引入來管理邊緣設備的模塊，還有一套對應的CRD的定義，擴展的Kubernetes API，用來管理邊緣設備。
CloudHub模塊：上文也簡單講過了，主要是管理與邊緣端EdgeHub的websocket的連接， 下發雲端發來的數據，和上傳邊緣發來數據跟雲端同步。
CSI Driver：是爲了實現標準的CSI方案而做的適配器。
Admission webhook：主要用來給擴展性API做一些合法性的校驗。
KubeEdge邊端的核心組件Edgecore
KubeEdge邊端的核心組件Edgecore主要由下面幾個模塊組成：
EdgeHub：主要是跟雲端交互，它跟雲端的CloudHub是對等的，首先由EdgeHub發起雲端的WebSocket連接。
MetaManager：本地持久化數據管理，KubeEdge的離線自治的能力主要是由這個模塊實現的，簡單來說每個Node用到了哪些Pod，哪些ConfigMap，Secret，都會通過MetaManager寫入邊緣本地的持久化數據庫中，現在當前用的SQLite。
DeviceTwin和EventBus：主要是設備管理，比如說設備狀態的上報，以及設備控制指令的下發，而EventBus相當於MQTT的一個client。
Edged：是一個非常輕量化裁剪過的kubelet，使用了應用生命週期管理中最關鍵的幾個模塊，去掉了雲存儲的驅動。支持CRI接口，適配多個container runtime。
整體KubeEdge比較適合於雲邊協同，邊緣側離線自治，通知對邊緣側資源要求比較苛刻的場景。如果您的場景需求跟這個比較類似， 建議嘗試一下KubeEdge，來管理邊緣集羣。
同時呢，社區也有一些demo案例， 比如KubeEdge控制樹莓派led，或者交通燈等等，可以讓同學們能快速上手，對KubeEdge和邊緣計算有個初步瞭解，有興趣的同學可以研究一下。https://github.com/kubeedge/examples
KubeEdge社區參與
KubeEdge在19年6月發佈了1.0版本，現在（2020年3月份）最新版本是1.2.1，支持數據可靠性傳輸，Component API，邊緣節點自動註冊，適配Kubernetes 1.17版本等核心功能，計劃2020年的5月份，我們發佈1.3版本，主要包括kubectl exec/logs的支持，CloudCore的HA，Edgemesh，雲端監控數據收集等功能。也歡迎有興趣的同學參與社區開發。
邊緣計算還有很廣闊的發展前景，Kubernetes在邊緣計算領域還有許多路要走，我相信基於Kubernetes的邊緣計算開源項目也會不斷完善，更好的解決邊緣用戶的需求。
Q&A
Q：邊緣計算的邊在哪裏？網絡的邊緣到底是指什麼，如何具象化？如何確定邊的位置？邊的位置和應用的關係？所謂的邊與端的區別是什麼？比如說攝像頭算是邊還是端？邊緣網關算是邊還是端？這個概念如何判斷？
A：邊緣計算的邊具體在哪裏，其實沒有很明確的概念，一般主要看你的業務場景。網絡邊緣一般是指靠近客戶現場一側的網絡邊緣，在邊緣計算場景下，應用是部署在邊側，就近計算，一般情況下攝像頭我們可以是認爲是端，但是如果攝像頭自己有計算能力，有網絡接入，能夠部署應用，我們也可以理解是是邊側的計算節點。
Q：雲邊同步怎麼做的？
A：KubeEdge雲邊同步主要通過EdgeHub和CloudHub這兩個模塊構建的WebSocket連接進行Kubernetes資源的同步的，連接請求首先由Edge端發起，一旦WebSocket建立後，雲端就可以向邊緣側傳遞數據。
Q：如何保證雲邊狀態的統一？Docker形式的邊緣應用的優缺點有哪些？
A：KubeEdge最新版支持可靠性消息傳輸。雲端的Kubernetes資源狀態發生變化後，會默認通過WebSocket通道進行下發，如果這時候網絡斷開或者網絡質量不高，會進行重傳。但是這裏爲了防止資源狀態數據的積壓導致內存佔用率過高，Kubeedge充分利用了Kubernetes的去重隊列，對資源數據進行去重處理。
Q：Kubernetes Master，Kubernetes Node，KubeEdge Edge節點三者是什麼關係？在Master上部署CloudCore去管理Edge節點，那Kubernetes Node是否參與其中？是不是說Edge節點只需要跟Master節點上的CloudCore進行通信，不關心Node；Node也只在Kubernetes集羣內通信，不關心Edge？
A：Kubernetes Node和KubeEdge Edge節點沒有本質區別，Kubernetes的Node是由kubelet像API server進行註冊的，而KubeEdge Edge節點是KubeEdge通過雲邊協同機制通過CloudCore進行註冊的。通過kubectl get node看到都是Node，區別在於Edge Node會有專門的標籤。
Q：在Kubernetes中，雲和終端節點如何通訊的，全雙工還是半雙工的？實時還是輪詢的？IPv6和5G是否應用其中？如何連接其中節點的？對於大量節點之間如何規劃網域？是否存在安全問題？如何解決安全隔離問題？
A：Kubernetes中，Master和Node是用過list-watch機制進行通信的，Node上的kubelet啓動後，會首先進行list獲取全量的數據，之後進行watch，只watch變化的數據。對於Kubernetes的容器網絡來說，社區都有比較成熟的CNI插件，Flannel，Calico等等，可以根據自己具體的業務需求來使用不同的網絡插件。如果對於安全隔離要求很高，可以讓Kubernetes跑在VM上，使用VM本身的隔離性。
===》再問：我說的安全問題是，因爲考慮節點之間的自治勢必存在節點互通情況，比如這種場景：我和我家鄰居冰箱都用同一個Cloud服務，會不會出現對方通過節點之間的通訊，hack訪問到我的冰箱。
===》A：這種我覺得應該是稱作爲SaaS服務會比較合適，雖然你和你家鄰居的冰箱感覺是在邊緣側，但是這種應該不屬於邊緣計算場景，而且節點自治和節點互通也沒啥關係。
Q：KubeEdge和EdgeX能結合使用嗎？
A：我個人沒有應用實踐過。KubeEdge是Kubernetes在雲端向邊端的延伸。如果你如果曾經將Kubernetes和EdgeX結合使用過，理論上KubeEdge也是可以的。
Q：完全是KubEedge新手的話，該從哪裏入手呢?
A：https://kubeedge.io/zh/，另外有什麼問題可以在KubeEdge社區裏提issue或者slack裏提問。另外KubeEdge社區每兩週週三下午會有社區例會，相關連接可以查看：https://github.com/kubeedge/kubeedge。
Q：KubeEdge當前應用於哪些商業場景？
A：最典型的是攝像頭類場景，比如汽車保養門店，園區人臉識別入園，車牌識別等等。把AI計算類應用部署在客戶現場一側（比如汽車門店或者園區），直接就進圖像識別。
Q：KubeEdge現在有支持哪些終端直接跑Node？除了前面提到的樹莓派、交通燈。
A: 樹莓派一般是用於開發測試場景。有興趣的可以嘗試一下華爲的atlas開發者套件。一般ARM架構的服務器都可以。
Q：請問KubeEdge實際部署中遇到哪些問題？如何解決的? 現今面臨的主要挑戰是什麼？
A：主要是邊緣場景下，客戶對雲原生，Kubernetes的理解程度不一樣，需要時間。這就跟最開始Kubernetes誕生以後，對傳統觀念是一個衝擊。
Q：KubeEdge對關鍵功能是否有監控？監控方案是如何做的？報警規則分別有哪些？
A：KubEedge 1.3版本計劃提供Metric功能，可以使用開源Prometheus去監控報警。