什麼是邊緣計算node
邊緣計算（Edge computing）是一種在物理上靠近數據源頭的網絡邊緣側來融合網絡、計算、存儲、應用核心能力的開放平臺。爲終端用戶提供實時、動態和智能的服務計算，邊緣計算會將計算推向更接近用戶的實際現場，這與須要在雲端進行計算的傳統雲計算有着本質的區別，而這些區別主要表如今帶寬負載、資源浪費、安全隱私保護以及異構多源數據處理上。
這裏有一個很是典型的例子， 就是章魚，章魚在捕獵時它們動做很是靈巧迅速，腕足之間高度配合，歷來不會纏繞和打結。這是由於章魚的神經元的分佈是40%集中在他的頭部，60%的神經元分佈在他的觸角上，是「多個小腦+一個大腦」的構造，相似於分佈式計算。而邊緣計算也是一種分佈式計算，這種分佈的好處呢，就是大部分重複的，低級的操做，都有觸角來完成，是減輕了中央章魚大腦的功耗，而讓中央大腦只處理一些核心的數據。
隨着5G，萬物互聯時代的到來，整個網絡設備接入的數量，以及靠近設備端產生的數據會爆發式增加。這就遇到一個問題，若是全部數據處理都放到集中式數據中心，帶寬，實時性，能耗，隱私等等都會面臨很大的挑戰。但採用邊緣計算，就能夠就近處理海量數據，大量設備能夠實現高效協同工做，諸多問題迎刃而解。
所以邊緣計算有着它獨特的價值：
鏈接的普遍性， 由於他高度分散，可以覆蓋到用戶的實際現場各個終端。git
是數據帶寬的優化，能夠將部分業務下沉到數據的產生源頭，這樣大部分的數據並無通過骨幹網，這對於總體網絡的帶寬是一個極大的優化，經過本地數據預處理，能夠極大減小傳輸帶寬的需求，這裏面最典型的例子就是CDN，經過就近拉取視頻流，這樣骨幹網絡只有中心站點到CDN站點幾份的數據傳輸。可是每一個CDN站點的訪客可能數以萬計或者百萬計。github
是邊緣的自治性，整個業務下沉到邊緣，高度分散以後，邊緣跟中心雲的網絡不能很好的保障，這就須要在骨幹網絡質量不能保證的狀況下，須要邊緣具有必定的自治性。這樣才能更好的服務終端業務的請求。web
從端到端的體驗來講，主要體現的是業務的實時性，由於大部分的業務請求都在邊緣處理， 總體的業務請求能夠縮小到10ms之內。數據庫
最後一點， 由於實施邊緣計算之後，能夠減小大量沒必要要的敏感數據的跨網傳輸，能夠在邊緣作數據的預處理或者匿名化處理，把最敏感的數據處理放在邊緣，這樣能夠大大的加強數據的安全性和隱私保護。ubuntu
其實邊緣計算這個概念已經出現了很長時間， 那麼爲何近幾年會快速發展呢，其中一方面是由於網絡技術的快速發展，以及5G時代的到來，萬物互聯，一切鏈接皆有可能。從關鍵因素上來來，主要是4大點：
低時延，不少新興的業務快速發展，包括自動駕駛，AI，VR等等，這些都對時延有很是苛刻的要求。安全
是隨着接入到網絡的設備數量大量增多， 致使數據爆發式增加， 這也是對邊緣計算的一個很大的推進力。服務器
是隱私安全，像如今人工智能， 以及對應的人臉，指紋識別等，可是這些最原始的指紋或者人臉的隱私信息， 咱們不但願在公網傳輸被被人去盜取或者篡改數據，若是用邊緣計算呢， 咱們能夠避免這種問題。websocket
最後一點呢， 就是邊緣的業務要具有自治能力，若是跟雲端的網絡請求斷開，或者網絡質量不高的狀況下， 邊緣業務要在出現故障時候，自我恢復。網絡
這是推進邊緣計算的四大主要因素。
基於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是一種比較先進的鬆耦合的架構。控制層面有：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也遇到了不少挑戰：
爲了減輕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 IOT EDGE這個working group調查中顯示，二者比例是30%的人更傾向於把整個Kubernetes集羣跑在邊緣，這種場景更多的是一些近場的邊緣，就是相對來講，靠近邊緣的網絡位置上的這種邊緣計算，要求呢就是計算能力相對要高一點，首先要可以承載Kubernetes自己組件的運行。
還有70%更多的人，更傾向於這種現場的邊緣計算，這種邊緣是一種更輕量，更極致的邊緣計算追求。在這種狀況下， 沒有太多的跨節點的調度，或者應用動態遷移的訴求，不少應用都會跟某個設備作綁定。
基於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第二個核心理念是，作到節點級的元數據的持久化，好比Pod，ConfigMap等基礎元數據，按照每一個節點持久化在他的設備上，邊緣的節點離線以後，它仍能夠經過本地持久化的元數據來管理這些應用。熟悉Kubernetes的同窗應該知道，當kubelet重啓後， 它首先要向Master作一次list watch獲取全量的數據，而後再進行應用管理工做，若是這時候邊和雲端的網絡斷開，是沒法得到全量的基礎元數據，也不能進行故障恢復。KubeEdge作了元數據的持久化後，能夠直接從本地得到這些元數據，保障故障恢復的能力，保證服務的快速ready。
另一個理念是極致的輕量化：在大多數邊緣計算場景下，節點的資源是很是有限的，KubeEdge採用的方式是重組kubelet組件，移除了內置了面向於雲廠商的驅動，經過CSI介入，去掉了static Pod，同時支持CRI，支持多種container runtime。
在空載時候，內存佔用率很低。
雲上：主要是經過旁路設計開發的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，主要由下面幾部分組成：
Edge Controller主要是來負責邊緣節點元數據的同步和管理，主要是Pod，ConfigMap等應用相關的元數據。
Device Controller是引入來管理邊緣設備的模塊，還有一套對應的CRD的定義，擴展的Kubernetes API，用來管理邊緣設備。
CloudHub模塊，上文也簡單講過了，主要是管理與邊緣端EdgeHub的websocket的鏈接， 下發雲端發來的數據，和上傳邊緣發來數據跟雲端同步。
CSI Driver是爲了實現標準的CSI方案而作的適配器。
Admission webhook主要用來給擴展性API作一些合法性的校驗。
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在19年6月發佈了1.0版本，如今最新版本是1.2.1，支持數據可靠性傳輸，Component API，邊緣節點自動註冊，適配Kubernetes 1.17版本等核心功能，計劃今年的5月份，咱們發佈1.3版本，主要包括kubectl exec/logs的支持，CloudCore的HA，Edgemesh，雲端監控數據收集等功能。也歡迎有興趣的同窗參與社區開發。
最後
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去監控報警。