作者 | 張杰

來源 |?分布式實驗室

現在開源邊緣計算正在經歷其業界最具活力的發展階段。如此多的開源平臺，如此多的整合以及如此多的標準化舉措！這顯示了構建更好平臺的強大動力，以便將云計算帶到邊緣以滿足不斷增長的需求。

同時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是一種比較先進的松耦合的架構。控制層面有：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的開源邊緣計算項目

其實現在基于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默認采用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，主要由下面幾部分組成：

• 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，云端監控數據收集等功能。也歡迎有興趣的同學參與社區開發。

最后

邊緣計算還有很廣闊的發展前景，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去監控報警。

同時，歡迎所有開發者掃描下方二維碼填寫《開發者與AI大調研》，只需2分鐘，便可收獲價值299元的「AI開發者萬人大會」在線直播門票!

推薦閱讀：如何成功構建大規模 Web 搜索引擎架構？ “出道” 5 年采用率達 78%，Kubernetes 的成功秘訣是什么？ 一群阿里人如何用 10 年自研洛神云網絡平臺？技術架構演進全揭秘！拿下 Gartner 容器產品第一，阿里云打贏云原生關鍵一戰！ 大話卷積神經網絡CNN，小白也能看懂的深度學習算法教程，全程干貨建議收藏！ 朱廣權李佳琦直播掉線，1.2 億人在線等 “抗疫”新戰術：世衛組織聯合IBM、甲骨文、微軟構建了一個開放數據的區塊鏈項目！ 真香，朕在看了！

總結

以上是生活随笔為你收集整理的详析 Kubernetes 在边缘计算领域的发展的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。