作者 | 張杰

來源 |?分布式實(shí)驗(yàn)室

現(xiàn)在開源邊緣計(jì)算正在經(jīng)歷其業(yè)界最具活力的發(fā)展階段。如此多的開源平臺(tái)，如此多的整合以及如此多的標(biāo)準(zhǔn)化舉措！這顯示了構(gòu)建更好平臺(tái)的強(qiáng)大動(dòng)力，以便將云計(jì)算帶到邊緣以滿足不斷增長(zhǎng)的需求。

同時(shí)Kubernetes現(xiàn)在已經(jīng)成為容器編排的事實(shí)標(biāo)準(zhǔn)，在云原生領(lǐng)域大放異彩，能否可以將Kubernetes應(yīng)用于邊緣計(jì)算領(lǐng)域？具有哪些優(yōu)勢(shì)，又有哪些挑戰(zhàn)？

什么是邊緣計(jì)算

邊緣計(jì)算(Edge Computing)是一種在物理上靠近數(shù)據(jù)源頭的網(wǎng)絡(luò)邊緣側(cè)來融合網(wǎng)絡(luò)、計(jì)算、存儲(chǔ)、應(yīng)用核心能力的開放平臺(tái)。

為終端用戶提供實(shí)時(shí)、動(dòng)態(tài)和智能的服務(wù)計(jì)算，邊緣計(jì)算會(huì)將計(jì)算推向更接近用戶的實(shí)際現(xiàn)場(chǎng)，這與需要在云端進(jìn)行計(jì)算的傳統(tǒng)云計(jì)算有著本質(zhì)的區(qū)別，而這些區(qū)別主要表現(xiàn)在帶寬負(fù)載、資源浪費(fèi)、安全隱私保護(hù)以及異構(gòu)多源數(shù)據(jù)處理上。

這里有一個(gè)非常典型的例子， 就是章魚，章魚在捕獵時(shí)它們動(dòng)作非常靈巧迅速，腕足之間高度配合，從來不會(huì)纏繞和打結(jié)。這是因?yàn)檎卖~的神經(jīng)元的分布是40%集中在他的頭部，60%的神經(jīng)元分布在他的觸角上，是“多個(gè)小腦+一個(gè)大腦”的構(gòu)造，類似于分布式計(jì)算。而邊緣計(jì)算也是一種分布式計(jì)算，這種分布的好處呢，就是大部分重復(fù)的，低級(jí)的操作，都有觸角來完成，是減輕了中央章魚大腦的功耗，而讓中央大腦只處理一些核心的數(shù)據(jù)。

隨著5G，萬(wàn)物互聯(lián)時(shí)代的到來，整個(gè)網(wǎng)絡(luò)設(shè)備接入的數(shù)量，以及靠近設(shè)備端產(chǎn)生的數(shù)據(jù)會(huì)爆發(fā)式增長(zhǎng)。這就遇到一個(gè)問題，如果所有數(shù)據(jù)處理都放到集中式數(shù)據(jù)中心，帶寬，實(shí)時(shí)性，能耗，隱私等等都會(huì)面臨很大的挑戰(zhàn)。但采用邊緣計(jì)算，就可以就近處理海量數(shù)據(jù)，大量設(shè)備可以實(shí)現(xiàn)高效協(xié)同工作，諸多問題迎刃而解。

因此邊緣計(jì)算有著它獨(dú)特的價(jià)值：

連接的廣泛性， 因?yàn)樗叨确稚?#xff0c;能夠覆蓋到用戶的實(shí)際現(xiàn)場(chǎng)各個(gè)終端。

是數(shù)據(jù)帶寬的優(yōu)化，可以將部分業(yè)務(wù)下沉到數(shù)據(jù)的產(chǎn)生源頭，這樣大部分的數(shù)據(jù)并沒有經(jīng)過骨干網(wǎng)，這對(duì)于整體網(wǎng)絡(luò)的帶寬是一個(gè)極大的優(yōu)化，通過本地?cái)?shù)據(jù)預(yù)處理，可以極大減少傳輸帶寬的需求，這里面最典型的例子就是CDN，通過就近拉取視頻流，這樣骨干網(wǎng)絡(luò)只有中心站點(diǎn)到CDN站點(diǎn)幾份的數(shù)據(jù)傳輸。但是每個(gè)CDN站點(diǎn)的訪客可能數(shù)以萬(wàn)計(jì)或者百萬(wàn)計(jì)。

是邊緣的自治性，整個(gè)業(yè)務(wù)下沉到邊緣，高度分散之后，邊緣跟中心云的網(wǎng)絡(luò)不能很好的保障，這就需要在骨干網(wǎng)絡(luò)質(zhì)量不能保證的情況下，需要邊緣具備一定的自治性。這樣才能更好的服務(wù)終端業(yè)務(wù)的請(qǐng)求。

從端到端的體驗(yàn)來說，主要體現(xiàn)的是業(yè)務(wù)的實(shí)時(shí)性，因?yàn)榇蟛糠值臉I(yè)務(wù)請(qǐng)求都在邊緣處理， 整體的業(yè)務(wù)請(qǐng)求可以縮小到10ms以內(nèi)。

最后一點(diǎn)， 因?yàn)閷?shí)施邊緣計(jì)算以后，可以減少大量不必要的敏感數(shù)據(jù)的跨網(wǎng)傳輸，可以在邊緣做數(shù)據(jù)的預(yù)處理或者匿名化處理，把最敏感的數(shù)據(jù)處理放在邊緣，這樣可以大大的增強(qiáng)數(shù)據(jù)的安全性和隱私保護(hù)。

其實(shí)邊緣計(jì)算這個(gè)概念已經(jīng)出現(xiàn)了很長(zhǎng)時(shí)間， 那么為什么近幾年會(huì)快速發(fā)展呢，其中一方面是因?yàn)榫W(wǎng)絡(luò)技術(shù)的快速發(fā)展，以及5G時(shí)代的到來，萬(wàn)物互聯(lián)，一切連接皆有可能。從關(guān)鍵因素上來來，主要是4大點(diǎn)：

低時(shí)延，很多新興的業(yè)務(wù)快速發(fā)展，包括自動(dòng)駕駛，AI，VR等等，這些都對(duì)時(shí)延有非常苛刻的要求。

是隨著接入到網(wǎng)絡(luò)的設(shè)備數(shù)量大量增多， 導(dǎo)致數(shù)據(jù)爆發(fā)式增長(zhǎng)， 這也是對(duì)邊緣計(jì)算的一個(gè)很大的推動(dòng)力。

是隱私安全，像現(xiàn)在人工智能， 以及對(duì)應(yīng)的人臉，指紋識(shí)別等，但是這些最原始的指紋或者人臉的隱私信息， 我們不希望在公網(wǎng)傳輸被被人去盜取或者篡改數(shù)據(jù)，如果用邊緣計(jì)算呢， 我們可以避免這種問題。

最后一點(diǎn)呢， 就是邊緣的業(yè)務(wù)要具備自治能力，如果跟云端的網(wǎng)絡(luò)請(qǐng)求斷開，或者網(wǎng)絡(luò)質(zhì)量不高的情況下， 邊緣業(yè)務(wù)要在出現(xiàn)故障時(shí)候，自我恢復(fù)。

這是推動(dòng)邊緣計(jì)算的四大主要因素。

基于Kubernetes構(gòu)建邊緣計(jì)算平臺(tái)

那么需要什么框架去構(gòu)建邊緣計(jì)算平臺(tái)呢？我們可能首先想到的就是現(xiàn)在大火的Kubernetes。

對(duì)Kubernetes來說，它的核心功能基本上趨于成熟。現(xiàn)如今Kubernetes已經(jīng)日益成為公有云/企業(yè)IT系統(tǒng)的基礎(chǔ)設(shè)施，不僅大多數(shù)新興的云原生負(fù)載是構(gòu)建在Kubernetes上的，我們還將看到傳統(tǒng)應(yīng)用和負(fù)載也在以更快的速度向Kubernetes遷移，人們趨向于使用Kubernetes。而且Kubernetes 在朝著大規(guī)模，復(fù)雜場(chǎng)景的方向延伸，與AI、大數(shù)據(jù)、IoT、以及垂直行業(yè)等領(lǐng)域的結(jié)合越來越緊密。近來，越來越多圍繞Kubernetes生態(tài)圈的創(chuàng)新，正在這些領(lǐng)域發(fā)生著。

與其他的新技術(shù)出世的情景類似，目前的邊緣計(jì)算也是一片炙熱的景象，多種技術(shù)形式出現(xiàn)，大家都在爭(zhēng)奪這個(gè)領(lǐng)域。而且邊緣計(jì)算的發(fā)展空間顯然是無限的，實(shí)現(xiàn)的方式也是無限的，多種多樣。這使得靈活性成為了非常重要的關(guān)鍵點(diǎn)。如果打算讓下一代服務(wù)能夠繼續(xù)與傳統(tǒng)IT進(jìn)行交互操作，兼容傳統(tǒng)IT，就要去邊緣計(jì)算技術(shù)盡量能夠在任何類型的架構(gòu)（邊緣、云或集中式硬件）中部署和擴(kuò)展，去兼容異構(gòu)的架構(gòu)，而這更Kubernetes的設(shè)計(jì)理念有點(diǎn)類似。

Kubernetes項(xiàng)目源自于Google的borg項(xiàng)目，天生站在巨人的肩膀上，自2014年6月開源以來，Kubernetes在眾多廠商和開源愛好者的共同努力下迅速崛起。現(xiàn)在已經(jīng)基本成為容器編排的事實(shí)標(biāo)準(zhǔn)。而且越來越多的公司和組織加入CNCF，眾多的開源愛好者參與Kubernetes社區(qū)開發(fā)，現(xiàn)在，Kubernetes已經(jīng)成為容器編排領(lǐng)域的事實(shí)標(biāo)準(zhǔn)。超過80家廠商都已經(jīng)提供了經(jīng)過認(rèn)證的標(biāo)準(zhǔn)的Kubernetes服務(wù)。除此之外，還有很多公司都在使用Kubernetes的服務(wù)。而且圍繞Kubernetes的云原生版圖也是越來越豐富。

那么在邊緣計(jì)算場(chǎng)景下使用Kubernetes ，具有哪些優(yōu)勢(shì)呢？

這里首先要從Kubernetes的架構(gòu)說起。了解Kubernetes的同學(xué)對(duì)Kubernetes已經(jīng)很熟悉了，這里我再簡(jiǎn)單介紹一下：

從架構(gòu)層面，Kubernetes是一種比較先進(jìn)的松耦合的架構(gòu)。控制層面有：API server，controller-manager，Scheduler，集群的狀態(tài)都存在etcd中，數(shù)據(jù)面有：kubelet和kube-proxy安裝在每個(gè)計(jì)算節(jié)點(diǎn)，用來管理Pod生命周期和網(wǎng)絡(luò)的處理。

它所有的組件都是用過API server來進(jìn)行訪問的，這樣可以保證數(shù)據(jù)訪問的過程是可以被鑒權(quán)和認(rèn)證的。同時(shí)所有組件之間，沒有耦合關(guān)系， 他們都跟API server做交互，只依賴于API server，他的API是聲明式設(shè)計(jì)的。同時(shí)在具體的應(yīng)用聲明周期的管理過程中呢， 他是通過多個(gè)API對(duì)象，彼此互不，和組合來實(shí)現(xiàn)解耦。

其次由于容器有輕量級(jí)、安全性、秒級(jí)啟動(dòng)等優(yōu)秀的特性，容器天然的輕量化和可移植性，對(duì)應(yīng)用進(jìn)行容器化封裝，使用容器本身的特性，充分使用build once，run anywhere的優(yōu)勢(shì)，輕量化基礎(chǔ)鏡像，降低資源的占用，非常適合邊緣計(jì)算的場(chǎng)景，這一點(diǎn)邊緣計(jì)算的廠家和開發(fā)者們都心知肚明。而且鑒于Kubernetes已經(jīng)成為云原生編排的事實(shí)標(biāo)準(zhǔn)，因此攜手Kubernetes進(jìn)入邊緣將很有可能結(jié)束邊緣計(jì)算當(dāng)前混沌的狀態(tài)，并定義云端和邊緣統(tǒng)一的應(yīng)用部署和管理的標(biāo)準(zhǔn)。

最后在邊緣計(jì)算場(chǎng)景下，有著大量的異構(gòu)設(shè)備，每種設(shè)備都有自己獨(dú)特的特征屬性，我們可以充分利用Kubernetes提供的擴(kuò)展的API資源：CRD功能，對(duì)這些設(shè)備進(jìn)行數(shù)據(jù)建模，數(shù)據(jù)抽象，從而進(jìn)行統(tǒng)一管理。

但是，Kubernetes不是天生為邊緣計(jì)算而生的， 他是從集中式數(shù)據(jù)中心的場(chǎng)景里誕生出來的技術(shù)，因此在邊緣計(jì)算場(chǎng)景下，Kubernetes也遇到了很多挑戰(zhàn)：

為了減輕API server的訪問壓力以及集群狀態(tài)的快速同步，Kubernetes優(yōu)先使用事件監(jiān)聽（list-watch）方式而不是輪訓(xùn)方式來處理。這也是一個(gè)很大的亮點(diǎn)。這種情況比較適合于網(wǎng)絡(luò)質(zhì)量較好的數(shù)據(jù)中心去部署。

但是呢反過來講，這會(huì)對(duì)邊緣計(jì)算場(chǎng)景帶來挑戰(zhàn)。Master和Node通信是通過list watch機(jī)制，它沒有辦法在邊緣場(chǎng)景這種受限的網(wǎng)絡(luò)下很好的工作，本身list watch實(shí)現(xiàn)也是假設(shè)的是數(shù)據(jù)中心的網(wǎng)絡(luò)，整體網(wǎng)絡(luò)質(zhì)量相對(duì)比較好的情況下。

另外Kubernetes節(jié)點(diǎn)是沒有自治能力的，如何在網(wǎng)絡(luò)質(zhì)量不穩(wěn)定的情況下，對(duì)邊緣節(jié)點(diǎn)實(shí)現(xiàn)離線自治，這也是個(gè)問題。

Kubernetes各個(gè)組件其實(shí)是比較耗資源的，當(dāng)然這種組件對(duì)資源的占用，相對(duì)于集中式數(shù)據(jù)中心的資源來說是微不足道的，但是在邊緣，資源有限的場(chǎng)景下，Kubernetes是很難很好的工作的。一個(gè)kubelet啟動(dòng)大概就占用上百兆的內(nèi)存，整個(gè)Kubernetes如果附上HA的能力，實(shí)際上會(huì)占用相當(dāng)多的資源。如果你想你的應(yīng)用跑在一些IOT網(wǎng)關(guān)或者設(shè)備上，他們可能只有幾百兆的內(nèi)存，或許一個(gè)原生kubelet都跑不起來。

還有就是，在邊緣計(jì)算場(chǎng)景下，它有很多異構(gòu)的邊緣設(shè)備，支持的工業(yè)協(xié)議也不一樣，那么這些邊緣設(shè)備怎么管理，怎么讓邊緣應(yīng)用通過比較解耦的方式與這些設(shè)備交互，這是Kubernetes本身沒有提供的。我們只能充分利用Kubernetes 的CRD資源進(jìn)行二次抽象。

還有一個(gè)問題是在邊緣計(jì)算場(chǎng)景下，應(yīng)用和節(jié)點(diǎn)的監(jiān)控和報(bào)警問題，是在邊端進(jìn)行數(shù)據(jù)的監(jiān)控報(bào)警，還是在云端統(tǒng)一進(jìn)行收集，這也是一個(gè)很大的挑戰(zhàn)，另一個(gè)問題，是在Kubernetes的架構(gòu)選型上，我們到底采用哪種場(chǎng)景和架構(gòu)。

第一種是將整個(gè)Kubernetes集群跑在邊緣，第二種是將Kubernetes的控制層面跑在云端，去管理邊緣的計(jì)算節(jié)點(diǎn)。這是很多在Kubernetes構(gòu)建邊緣計(jì)算平臺(tái)時(shí)候，所面臨的問題。

實(shí)際上在Kubernetes IOT EDGE這個(gè)working group調(diào)查中顯示，兩者比例是30%的人更傾向于把整個(gè)Kubernetes集群跑在邊緣，這種場(chǎng)景更多的是一些近場(chǎng)的邊緣，就是相對(duì)來說，靠近邊緣的網(wǎng)絡(luò)位置上的這種邊緣計(jì)算，要求呢就是計(jì)算能力相對(duì)要高一點(diǎn)，首先要能夠承載Kubernetes本身組件的運(yùn)行。

還有70%更多的人，更傾向于這種現(xiàn)場(chǎng)的邊緣計(jì)算，這種邊緣是一種更輕量，更極致的邊緣計(jì)算追求。在這種情況下， 沒有太多的跨節(jié)點(diǎn)的調(diào)度，或者應(yīng)用動(dòng)態(tài)遷移的訴求，很多應(yīng)用都會(huì)跟某個(gè)設(shè)備做綁定。

基于Kubernetes的開源邊緣計(jì)算項(xiàng)目

其實(shí)現(xiàn)在基于Kubernetes平臺(tái)的開源邊緣計(jì)算項(xiàng)目已經(jīng)有很多個(gè)了，這里列出來了三個(gè)：

• K3s：https://github.com/rancher/k3s

• Microk8s：

  https://github.com/ubuntu/microk8s

• KubeEdge：

  https://github.com/kubeedge/kubeedge

當(dāng)然還有其他的開源項(xiàng)目，有興趣的大家可以自行查找。K3s定位是在邊緣端輕量化的Kubernetes集群。

刪除了Kubernetes一些alpha的feature，專門針對(duì)ARM環(huán)境進(jìn)行了發(fā)布，為了處理Node節(jié)點(diǎn)在內(nèi)網(wǎng)的場(chǎng)景，專門增加tunnel proxy的組件，來傳遞像exec 或者logs這些命令請(qǐng)求。對(duì)于Kubernetes的核心代碼邏輯沒有大的改動(dòng)。

在資源占用上，已經(jīng)比原生Kubernetes小了不少。Server在480M，Agent是120M。

由于Server和Agent主要還是通過List-watch來通信，還是很適合于純邊緣側(cè)部署一整套Kubernetes集群，不適合云邊協(xié)同的場(chǎng)景，只能運(yùn)行在邊緣側(cè)。社區(qū)這塊，有Rancher開發(fā)和管理。

Mincrok8s也是輕量級(jí)的Kubernetes發(fā)行版。

Mincrok8s和K3s在應(yīng)用場(chǎng)景上差不多，比較適合純邊緣的環(huán)境，也是缺少云邊協(xié)同的解決方案。支持ARM/Win10/macOS安裝，Kubelet占用大約80M內(nèi)存，Master占用大約600M內(nèi)存，K3s對(duì)Kubernetes的部分核心代碼做了修改，但是Mincrok8s并沒有做修改。

KubeEdge呢，由華為開源，2019年3月捐給CNCF基金會(huì)。

同時(shí)也是Kubernetes IOT Edge working group的關(guān)鍵參考架構(gòu)之一。

主要是針對(duì)邊緣側(cè)做了優(yōu)化：包括邊緣惻節(jié)點(diǎn)的離線狀態(tài)自治，云邊消息傳輸默認(rèn)使用WebSocket。支持云邊協(xié)同，同時(shí)支持云端集群和邊緣端集群的管理。

在邊緣側(cè)節(jié)點(diǎn)Edgecore的內(nèi)存暫用率大約是70M，同時(shí)兼容Kubernetes的核心API功能，現(xiàn)在大約有超過250個(gè)貢獻(xiàn)者參與其中。

每個(gè)開源項(xiàng)目都有它的側(cè)重點(diǎn)，各有優(yōu)勢(shì)，大家在技術(shù)選型時(shí)候可以根據(jù)自己的業(yè)務(wù)場(chǎng)景選擇不同的開源項(xiàng)目。

在這里主要著重講一下KubeEdge。

KubeEdge詳解

KubeEdge主打三個(gè)核心理念，首先是云邊協(xié)同，邊是云的延伸，用戶的邊可能位于私有網(wǎng)絡(luò)，因此需要穿透私有網(wǎng)絡(luò)，通過云來管理私有節(jié)點(diǎn)，KubeEdge默認(rèn)采用WebSocket+消息封裝來實(shí)現(xiàn)，這樣只要邊緣網(wǎng)絡(luò)能訪問外網(wǎng)情況下，就能實(shí)現(xiàn)雙向通信，這就不需要邊端需要一個(gè)公網(wǎng)的IP。同時(shí)呢，KubeEdge也優(yōu)化了原生Kubernetes中不必要的一些請(qǐng)求，能夠大幅減少通信壓力，高時(shí)延狀態(tài)下仍可以工作。

KubeEdge第二個(gè)核心理念是，做到節(jié)點(diǎn)級(jí)的元數(shù)據(jù)的持久化，比如Pod，ConfigMap等基礎(chǔ)元數(shù)據(jù)，按照每個(gè)節(jié)點(diǎn)持久化在他的設(shè)備上，邊緣的節(jié)點(diǎn)離線之后，它仍可以通過本地持久化的元數(shù)據(jù)來管理這些應(yīng)用。熟悉Kubernetes的同學(xué)應(yīng)該知道，當(dāng)kubelet重啟后， 它首先要向Master做一次list watch獲取全量的數(shù)據(jù)，然后再進(jìn)行應(yīng)用管理工作，如果這時(shí)候邊和云端的網(wǎng)絡(luò)斷開，是無法獲得全量的基礎(chǔ)元數(shù)據(jù)，也不能進(jìn)行故障恢復(fù)。KubeEdge做了元數(shù)據(jù)的持久化后，可以直接從本地獲得這些元數(shù)據(jù)，保障故障恢復(fù)的能力，保證服務(wù)的快速ready。

另外一個(gè)理念是極致的輕量化：在大多數(shù)邊緣計(jì)算場(chǎng)景下，節(jié)點(diǎn)的資源是非常有限的，KubeEdge采用的方式是重組kubelet組件，移除了內(nèi)置了面向于云廠商的驅(qū)動(dòng)，通過CSI介入，去掉了static Pod，同時(shí)支持CRI，支持多種container runtime。

在空載時(shí)候，內(nèi)存占用率很低。

這是KubeEdge整體架構(gòu)，KubeEdge對(duì)原生Kubernetes的架構(gòu)侵入比較小，都是旁路設(shè)計(jì)。

• 云上：主要是通過旁路設(shè)計(jì)開發(fā)的CloudCore組件，邊緣節(jié)點(diǎn)的同步和維護(hù)是通過CloudCore來維護(hù)，CloudCore通過list watch來跟Kubernetes集群做信息同步。而CloudCore里面內(nèi)置的CloudHub模塊和邊端內(nèi)置的EdgeHub模塊，構(gòu)建了一個(gè)WebSocket消息通道，通過結(jié)構(gòu)化的消息封裝，來同步Kubernetes的基礎(chǔ)元數(shù)據(jù)，比如Pod，ConfigMap等等。另外CloudCore里面還包含edgecontroler和devicecontroller模塊，這兩個(gè)模塊分別用來管理Kubernetes的元數(shù)據(jù)以及跟Device相關(guān)的CRD資源。

• 邊端：Edgecore，做到了持久化存儲(chǔ)，edged相當(dāng)于一個(gè)精簡(jiǎn)版的kubelet，支持CRI，底層可以對(duì)接多種container runtime，deviceTwin和DEventBus主要是做設(shè)備的元數(shù)據(jù)管理以及MQTT協(xié)議的訂閱和發(fā)布。主要是跟終端設(shè)備通信用。

• 在終端設(shè)備這里：現(xiàn)實(shí)場(chǎng)景里， 設(shè)備終端會(huì)有多種多樣的訪問協(xié)議，當(dāng)然比較新興的一些設(shè)備可能會(huì)直接支持MQTT協(xié)議，但是對(duì)于一些專用的設(shè)備或者工控的領(lǐng)域呢，會(huì)有他們專用的協(xié)議，KubeEdge呢采用了Mapper的設(shè)計(jì)，可以將這些專有的設(shè)備的協(xié)議轉(zhuǎn)換成MQTT協(xié)議，來實(shí)現(xiàn)邊緣的應(yīng)用和云上的設(shè)備數(shù)據(jù)的同步和管理，當(dāng)然KubeEdge最新版本還有SyncController，用來負(fù)責(zé)可靠性消息傳輸?shù)耐絾栴}，大家有興趣的可以自行查看KubeEdge的源碼。

那么在云端的核心組件CloudCore，主要由下面幾部分組成：

• Edge Controller主要是來負(fù)責(zé)邊緣節(jié)點(diǎn)元數(shù)據(jù)的同步和管理，主要是Pod，ConfigMap等應(yīng)用相關(guān)的元數(shù)據(jù)。

• Device Controller是引入來管理邊緣設(shè)備的模塊，還有一套對(duì)應(yīng)的CRD的定義，擴(kuò)展的Kubernetes API，用來管理邊緣設(shè)備。

• CloudHub模塊，上文也簡(jiǎn)單講過了，主要是管理與邊緣端EdgeHub的websocket的連接， 下發(fā)云端發(fā)來的數(shù)據(jù)，和上傳邊緣發(fā)來數(shù)據(jù)跟云端同步。

• CSI Driver是為了實(shí)現(xiàn)標(biāo)準(zhǔn)的CSI方案而做的適配器。

• Admission webhook主要用來給擴(kuò)展性API做一些合法性的校驗(yàn)。

KubeEdge邊端的核心組件Edgecore主要由下面幾個(gè)模塊組成：

• EdgeHub：主要是跟云端交互，它跟云端的CloudHub是對(duì)等的，首先由EdgeHub發(fā)起云端的WebSocket連接。

• MetaManager：本地持久化數(shù)據(jù)管理，KubeEdge的離線自治的能力主要是由這個(gè)模塊實(shí)現(xiàn)的，簡(jiǎn)單來說每個(gè)Node用到了哪些Pod，哪些ConfigMap，Secret，都會(huì)通過MetaManager寫入邊緣本地的持久化數(shù)據(jù)庫(kù)中，現(xiàn)在當(dāng)前用的SQLite。

• DeviceTwin和EventBus：主要是設(shè)備管理，比如說設(shè)備狀態(tài)的上報(bào)，以及設(shè)備控制指令的下發(fā)，而EventBus相當(dāng)于MQTT的一個(gè)client。

• Edged：是一個(gè)非常輕量化裁剪過的kubelet，使用了應(yīng)用生命周期管理中最關(guān)鍵的幾個(gè)模塊，去掉了云存儲(chǔ)的驅(qū)動(dòng)。支持CRI接口，適配多個(gè)container runtime。

整體KubeEdge比較適合于云邊協(xié)同，邊緣側(cè)離線自治，通知對(duì)邊緣側(cè)資源要求比較苛刻的場(chǎng)景。如果您的場(chǎng)景需求跟這個(gè)比較類似， 建議嘗試一下KubeEdge，來管理邊緣集群。

同時(shí)呢，社區(qū)也有一些demo案例， 比如KubeEdge控制樹莓派led，或者交通燈等等，可以讓同學(xué)們能快速上手，對(duì)KubeEdge和邊緣計(jì)算有個(gè)初步了解，有興趣的同學(xué)可以研究一下。https://github.com/kubeedge/examples

關(guān)于社區(qū)參與

KubeEdge在19年6月發(fā)布了1.0版本，現(xiàn)在最新版本是1.2.1，支持?jǐn)?shù)據(jù)可靠性傳輸，Component API，邊緣節(jié)點(diǎn)自動(dòng)注冊(cè)，適配Kubernetes 1.17版本等核心功能，計(jì)劃今年的5月份，我們發(fā)布1.3版本，主要包括kubectl exec/logs的支持，CloudCore的HA，Edgemesh，云端監(jiān)控?cái)?shù)據(jù)收集等功能。也歡迎有興趣的同學(xué)參與社區(qū)開發(fā)。

最后

邊緣計(jì)算還有很廣闊的發(fā)展前景，Kubernetes在邊緣計(jì)算領(lǐng)域還有許多路要走，我相信基于Kubernetes的邊緣計(jì)算開源項(xiàng)目也會(huì)不斷完善，更好的解決邊緣用戶的需求。

Q&A

Q：邊緣計(jì)算的邊在哪里？網(wǎng)絡(luò)的邊緣到底是指什么，如何具象化？如何確定邊的位置？邊的位置和應(yīng)用的關(guān)系？所謂的邊與端的區(qū)別是什么？比如說攝像頭算是邊還是端？邊緣網(wǎng)關(guān)算是邊還是端？這個(gè)概念如何判斷？

A：邊緣計(jì)算的邊具體在哪里，其實(shí)沒有很明確的概念，一般主要看你的業(yè)務(wù)場(chǎng)景。網(wǎng)絡(luò)邊緣一般是指靠近客戶現(xiàn)場(chǎng)一側(cè)的網(wǎng)絡(luò)邊緣，在邊緣計(jì)算場(chǎng)景下，應(yīng)用是部署在邊側(cè)，就近計(jì)算，一般情況下攝像頭我們可以是認(rèn)為是端，但是如果攝像頭自己有計(jì)算能力，有網(wǎng)絡(luò)接入，能夠部署應(yīng)用，我們也可以理解是是邊側(cè)的計(jì)算節(jié)點(diǎn)。

Q：云邊同步怎么做的？

A：KubeEdge云邊同步主要通過EdgeHub和CloudHub這兩個(gè)模塊構(gòu)建的WebSocket連接進(jìn)行Kubernetes資源的同步的，連接請(qǐng)求首先由Edge端發(fā)起，一旦WebSocket建立后，云端就可以向邊緣側(cè)傳遞數(shù)據(jù)。

Q：如何保證云邊狀態(tài)的統(tǒng)一？Docker形式的邊緣應(yīng)用的優(yōu)缺點(diǎn)有哪些？

A：KubeEdge最新版支持可靠性消息傳輸。云端的Kubernetes資源狀態(tài)發(fā)生變化后，會(huì)默認(rèn)通過WebSocket通道進(jìn)行下發(fā)，如果這時(shí)候網(wǎng)絡(luò)斷開或者網(wǎng)絡(luò)質(zhì)量不高，會(huì)進(jìn)行重傳。但是這里為了防止資源狀態(tài)數(shù)據(jù)的積壓導(dǎo)致內(nèi)存占用率過高，Kubeedge充分利用了Kubernetes的去重隊(duì)列，對(duì)資源數(shù)據(jù)進(jìn)行去重處理。

Q：Kubernetes Master，Kubernetes Node，KubeEdge Edge節(jié)點(diǎn)三者是什么關(guān)系？在Master上部署CloudCore去管理Edge節(jié)點(diǎn)，那Kubernetes Node是否參與其中？是不是說Edge節(jié)點(diǎn)只需要跟Master節(jié)點(diǎn)上的CloudCore進(jìn)行通信，不關(guān)心Node；Node也只在Kubernetes集群內(nèi)通信，不關(guān)心Edge？

A：Kubernetes Node和KubeEdge Edge節(jié)點(diǎn)沒有本質(zhì)區(qū)別，Kubernetes的Node是由kubelet像API server進(jìn)行注冊(cè)的，而KubeEdge Edge節(jié)點(diǎn)是KubeEdge通過云邊協(xié)同機(jī)制通過CloudCore進(jìn)行注冊(cè)的。通過kubectl get node看到都是Node，區(qū)別在于Edge Node會(huì)有專門的標(biāo)簽。

Q：在Kubernetes中，云和終端節(jié)點(diǎn)如何通訊的，全雙工還是半雙工的？實(shí)時(shí)還是輪詢的？IPv6和5G是否應(yīng)用其中？如何連接其中節(jié)點(diǎn)的？對(duì)于大量節(jié)點(diǎn)之間如何規(guī)劃網(wǎng)域？是否存在安全問題？如何解決安全隔離問題？

A：Kubernetes中，Master和Node是用過list-watch機(jī)制進(jìn)行通信的，Node上的kubelet啟動(dòng)后，會(huì)首先進(jìn)行l(wèi)ist獲取全量的數(shù)據(jù)，之后進(jìn)行watch，只watch變化的數(shù)據(jù)。對(duì)于Kubernetes的容器網(wǎng)絡(luò)來說，社區(qū)都有比較成熟的CNI插件，Flannel，Calico等等，可以根據(jù)自己具體的業(yè)務(wù)需求來使用不同的網(wǎng)絡(luò)插件。如果對(duì)于安全隔離要求很高，可以讓Kubernetes跑在VM上，使用VM本身的隔離性。

再問：我說的安全問題是，因?yàn)榭紤]節(jié)點(diǎn)之間的自治勢(shì)必存在節(jié)點(diǎn)互通情況，比如這種場(chǎng)景：我和我家鄰居冰箱都用同一個(gè)Cloud服務(wù)，會(huì)不會(huì)出現(xiàn)對(duì)方通過節(jié)點(diǎn)之間的通訊，hack訪問到我的冰箱。

A：這種我覺得應(yīng)該是稱作為SaaS服務(wù)會(huì)比較合適，雖然你和你家鄰居的冰箱感覺是在邊緣側(cè)，但是這種應(yīng)該不屬于邊緣計(jì)算場(chǎng)景，而且節(jié)點(diǎn)自治和節(jié)點(diǎn)互通也沒啥關(guān)系。

Q：KubeEdge和EdgeX能結(jié)合使用嗎？

A：我個(gè)人沒有應(yīng)用實(shí)踐過。KubeEdge是Kubernetes在云端向邊端的延伸。如果你如果曾經(jīng)將Kubernetes和EdgeX結(jié)合使用過，理論上KubeEdge也是可以的。

Q：完全是KubEedge新手的話，該從哪里入手呢?

A：https://kubeedge.io/zh/，另外有什么問題可以在KubeEdge社區(qū)里提issue或者slack里提問。另外KubeEdge社區(qū)每?jī)芍苤苋挛鐣?huì)有社區(qū)例會(huì)，相關(guān)連接可以查看：https://github.com/kubeedge/kubeedge。

Q：KubeEdge當(dāng)前應(yīng)用于哪些商業(yè)場(chǎng)景？

A：最典型的是攝像頭類場(chǎng)景，比如汽車保養(yǎng)門店，園區(qū)人臉識(shí)別入園，車牌識(shí)別等等。把AI計(jì)算類應(yīng)用部署在客戶現(xiàn)場(chǎng)一側(cè)（比如汽車門店或者園區(qū)），直接就進(jìn)圖像識(shí)別。

Q：KubeEdge現(xiàn)在有支持哪些終端直接跑Node？除了前面提到的樹莓派、交通燈。

A: 樹莓派一般是用于開發(fā)測(cè)試場(chǎng)景。有興趣的可以嘗試一下華為的atlas開發(fā)者套件。一般ARM架構(gòu)的服務(wù)器都可以。

Q：請(qǐng)問KubeEdge實(shí)際部署中遇到哪些問題？如何解決的? 現(xiàn)今面臨的主要挑戰(zhàn)是什么？

A：主要是邊緣場(chǎng)景下，客戶對(duì)云原生，Kubernetes的理解程度不一樣，需要時(shí)間。這就跟最開始Kubernetes誕生以后，對(duì)傳統(tǒng)觀念是一個(gè)沖擊。

Q：KubeEdge對(duì)關(guān)鍵功能是否有監(jiān)控？監(jiān)控方案是如何做的？報(bào)警規(guī)則分別有哪些？

A：KubEedge 1.3版本計(jì)劃提供Metric功能，可以使用開源Prometheus去監(jiān)控報(bào)警。

同時(shí)，歡迎所有開發(fā)者掃描下方二維碼填寫《開發(fā)者與AI大調(diào)研》，只需2分鐘，便可收獲價(jià)值299元的「AI開發(fā)者萬(wàn)人大會(huì)」在線直播門票!

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。