作者 | lanliang

來源 | 邊緣計(jì)算社區(qū)

頭圖 | 下載于視覺中國

隨著Kubernetes已經(jīng)成為容器編排和調(diào)度的事實(shí)標(biāo)準(zhǔn)，各大公有云廠商都已經(jīng)基于Kubernetes提供了完善的Kubernetes云上托管服務(wù)。同時(shí)也看到越來越多的企業(yè)、行業(yè)開始在生產(chǎn)中使用Kubernetes, 擁抱云原生。在各行各業(yè)數(shù)字化轉(zhuǎn)型和上云過程中，公有云廠商也在主動擁抱傳統(tǒng)線下環(huán)境，在思考各種各樣的解決方案使云上能力向邊緣(或線下)延伸。

而Kubernetes由于屏蔽了底層架構(gòu)的差異性，可以幫助應(yīng)用平滑地運(yùn)行在不同的基礎(chǔ)設(shè)施上的特性，云上的Kubernetes服務(wù)也在考慮拓展其服務(wù)邊界，云原生和邊緣計(jì)算結(jié)合的想法自然就呼之欲出了。

目前國內(nèi)各個(gè)公有云廠商也都開源了各自基于Kubernetes的邊緣計(jì)算云原生項(xiàng)目。如華為云的KubeEdge，阿里云的OpenYurt，騰訊云的SuperEdge。目前網(wǎng)上很少有從技術(shù)視角來介紹這幾個(gè)項(xiàng)目優(yōu)缺點(diǎn)的文章，本文試著從技術(shù)視角，從開源視角來分析這幾個(gè)項(xiàng)目，希望可以給大家做項(xiàng)目選型時(shí)提供一些借鑒。

比較思路

這幾個(gè)項(xiàng)目都是云邊一體，云邊協(xié)同的架構(gòu)，走的是Kubernetes和邊緣計(jì)算結(jié)合的路數(shù)，因此決定從以下幾點(diǎn)比較:

（1） 各個(gè)項(xiàng)目的開源狀況：比如開源項(xiàng)目的背景、開源的時(shí)間、是否進(jìn)入了CNCF等；

（2）Kubernetes架構(gòu):

• 先對比與Kubernetees的架構(gòu)差異：主要關(guān)注是否修改Kubernetes，和；Kubernetes一鍵式轉(zhuǎn)換等

• 根據(jù)架構(gòu)差異對比和Kubernetes的能力增強(qiáng)點(diǎn)；主要關(guān)注邊緣自治，邊緣單元化，輕量化等能力

• 最后看一下架構(gòu)差異可能帶來的影響: 主要關(guān)注運(yùn)維監(jiān)控能力，云原生生態(tài)兼容性，系統(tǒng)穩(wěn)定性等方面

（3）對邊緣計(jì)算場景支持能力:

• 主要關(guān)注是否具備端設(shè)備的管理能力

接下來以項(xiàng)目的開源順序，從上述幾個(gè)方面來介紹各個(gè)項(xiàng)目。

邊緣云原生開源項(xiàng)目對比

2.1?KubeEdge

（1）開源狀況

KubeEdge是華為云于2018年11月份開源的，目前是CNCF孵化項(xiàng)目。其架構(gòu)如下:

（2）與Kubernetes的架構(gòu)差異

首先從架構(gòu)圖可以看到，云端(k8s master)增加了Cloud Hub組件和各類controller，而在邊緣端(k8s worker)沒有看到原生的kubelet和kube-proxy，而是一個(gè)對原生組件進(jìn)行重寫了EdgeCore組件。

從架構(gòu)圖看EdgeCore是基于kubelet重構(gòu)的，為了保證輕量化，裁剪了原生kubelet的部分能力，同時(shí)也增加了很多適配邊緣場景的能力。具體如下:

• Cloud Hub+EdgeHub模塊: 拋棄了原生kubernetes 的組件間數(shù)據(jù)同步list/watch機(jī)制，改成基于websocket/quic協(xié)議從云端往邊緣推送模式。

• 節(jié)點(diǎn)元數(shù)據(jù)緩存模塊(MetaManager): 把節(jié)點(diǎn)維度的數(shù)據(jù)持久化在本機(jī)的SQLite數(shù)據(jù)庫中，當(dāng)云邊網(wǎng)絡(luò)不穩(wěn)定時(shí)Edged模塊將從本地?cái)?shù)據(jù)庫中獲取數(shù)據(jù)用于業(yè)務(wù)的生命周期管控。

• DeviceController+設(shè)備管理模塊(DeviceTwin): 把設(shè)備管理能力直接集成到EdgeCore中，為用戶提供原生的設(shè)備管理能力。

上述的架構(gòu)設(shè)計(jì)，對比Kubernetes的能力增強(qiáng)點(diǎn)主要有：

• 邊緣自治：通過增加節(jié)點(diǎn)元數(shù)據(jù)緩存，可以規(guī)避云邊斷網(wǎng)狀態(tài)下，邊緣業(yè)務(wù)或者節(jié)點(diǎn)重啟時(shí)，邊緣組件可以利用本地緩存數(shù)據(jù)進(jìn)行業(yè)務(wù)恢復(fù)，這就帶來了邊緣自治的好處。

• 輕量化: 削減了部分kubelet功能(如CSI，CNI等)，從而使邊緣EdgeCore組件相比原生kubelet組件更加輕量。同時(shí)因?yàn)楣?jié)點(diǎn)上增加了SQLite數(shù)據(jù)庫，所以節(jié)點(diǎn)維度相比原生節(jié)點(diǎn)是否輕量待確認(rèn)，歡迎熟悉的同學(xué)提供數(shù)據(jù)。

架構(gòu)差異可能帶來的影響：

• 云原生生態(tài)兼容性不足：

跟隨社區(qū)同步演進(jìn)挑戰(zhàn)大: 由于對Kubernetes系統(tǒng)的侵入式修改，后續(xù)跟隨Kubernetes社區(qū)的演進(jìn)將會遇到很大挑戰(zhàn)。

邊緣節(jié)點(diǎn)無法運(yùn)行Operator：因?yàn)樵七呁ㄐ艡C(jī)制的修改，Cloud Hub只能往邊緣推送有限的幾種資源(如Pod，ConfigMap等)。而Operator既需要自定義CRD資源，又需要list/watch云端獲取關(guān)聯(lián)資源，因此社區(qū)的Operator無法運(yùn)行的KubeEdge的邊緣節(jié)點(diǎn)上。

邊緣節(jié)點(diǎn)不適合運(yùn)行需要list/watch云端的應(yīng)用: 因?yàn)樵七呁ㄐ艡C(jī)制的修改，導(dǎo)致原來需要使用list/watch機(jī)制訪問kube-apiserver的應(yīng)用，都無法通過hub tunnel 通道訪問kube-apiserver，導(dǎo)致云原生的能力在邊緣側(cè)大打折扣。

• 運(yùn)維監(jiān)控能力支持有限：

  因?yàn)槟壳霸七呁ㄐ沛溌肥莐ube-apiserver --> controller --> Cloud Hub -->EdgeHub -->MetaManager等，而原生Kubernetes運(yùn)維操作(如kubectl proxy/logs/exec/port-forward/attch等)是kube-apiserver直接請求kubelet。目前KubeEdge社區(qū)最新版本也僅支持kubectl logs/exec/metric，其他運(yùn)維操作目前還不支持。

• 系統(tǒng)穩(wěn)定性提升待確定:

基于增量數(shù)據(jù)的云邊推送模式：可以解決邊緣watch失敗時(shí)的重新全量list從而引發(fā)的kube-apiserver 壓力問題，相比原生Kubernetes架構(gòu)可以提升系統(tǒng)穩(wěn)定性。

Infra管控?cái)?shù)據(jù)和業(yè)務(wù)管控?cái)?shù)據(jù)耦合：Kubernetes集群的管控?cái)?shù)據(jù)(如Pod，ConfigMap數(shù)據(jù))和邊緣業(yè)務(wù)數(shù)據(jù)(設(shè)備管控?cái)?shù)據(jù))使用同一條websocket鏈路，如果邊緣管理大量設(shè)備或者設(shè)備更新頻率過高，大量的業(yè)務(wù)數(shù)據(jù)將可能影響到集群的正常管控，從而可能降低系統(tǒng)的穩(wěn)定性。

邊緣計(jì)算場景支持能力

• 設(shè)備管理能力: 這個(gè)能力直接集成在edged中，給iot用戶提供了一定的原生設(shè)備管理能力。

2.2 OpenYurt

（1）開源狀況

OpenYurt是阿里云于2020年5月份開源的，目前是CNCF沙箱項(xiàng)目。架構(gòu)如下:

（2）與Kubernetes的架構(gòu)差異

OpenYurt的架構(gòu)設(shè)計(jì)比較簡潔，采用的是無侵入式對Kubernetes進(jìn)行增強(qiáng)。在云端(K8s Master)上增加Yurt Controller Manager, Yurt App Manager以及Tunnel Server組件。而在邊緣端(K8s Worker)上增加了YurtHub和Tunnel Agent組件。從架構(gòu)上看主要增加了如下能力來適配邊緣場景：

• YurtHub: 代理各個(gè)邊緣組件到K8s Master的通信請求，同時(shí)把請求返回的元數(shù)據(jù)持久化在節(jié)點(diǎn)磁盤。當(dāng)云邊網(wǎng)絡(luò)不穩(wěn)定時(shí)，則利用本地磁盤數(shù)據(jù)來用于邊緣業(yè)務(wù)的生命周期管控。同時(shí)云端的Yurt Controller Manager會管控邊緣業(yè)務(wù)Pod的驅(qū)逐策略。

• Tunnel Server/Tunnel Agent: 每個(gè)邊緣節(jié)點(diǎn)上的Tunnel Agent將主動與云端Tunnel Server建立雙向認(rèn)證的加密的gRPC連接，同時(shí)云端將通過此連接訪問到邊緣節(jié)點(diǎn)及其資源。

• Yurt App Manager：引入的兩個(gè)CRD資源: NodePool 和 UnitedDeployment. 前者為位于同一區(qū)域的節(jié)點(diǎn)提供批量管理方法。后者定義了一種新的邊緣應(yīng)用模型以節(jié)點(diǎn)池維度來管理工作負(fù)載。

上述的架構(gòu)設(shè)計(jì)，對比Kubernetes的能力增強(qiáng)點(diǎn)主要有：

• 邊緣單元化：通過Yurt App Manager組件，從單元化的視角，管理分散在不同地域的邊緣資源，并對各地域單元內(nèi)的業(yè)務(wù)提供獨(dú)立的生命周期管理，升級，擴(kuò)縮容，流量閉環(huán)等能力。且業(yè)務(wù)無需進(jìn)行任何適配或改造。

• 邊緣自治: 因?yàn)槊總€(gè)邊緣節(jié)點(diǎn)增加了具備緩存能力的透明代理YurtHub，從而可以保障云邊網(wǎng)絡(luò)斷開，如果節(jié)點(diǎn)或者業(yè)務(wù)重啟時(shí)，可以利用本地緩存數(shù)據(jù)恢復(fù)業(yè)務(wù)。

• 云邊協(xié)同(運(yùn)維監(jiān)控)：通過Tunnel Server/Tunnel Agent的配合，為位于防火墻內(nèi)部的邊緣節(jié)點(diǎn)提供安全的云邊雙向認(rèn)證的加密通道，即使邊到云網(wǎng)絡(luò)單向連通的邊緣計(jì)算場景下，用戶仍可運(yùn)行原生kubernetes運(yùn)維命令(如kubectl proxy/logs/exec/port-forward/attach等)。同時(shí)中心式的運(yùn)維監(jiān)控系統(tǒng)(如prometheus, metrics-server等)也可以通過云邊通道獲取到邊緣的監(jiān)控?cái)?shù)據(jù)。

• 云原生生態(tài)兼容:

所有功能均是通過Addon或者controller形式來增強(qiáng)Kubernetes，因此保證來對Kubernetes以及云原生社區(qū)生態(tài)的100%兼容。

另外值得一提的是：OpenYurt項(xiàng)目還提供了一個(gè)YurtCtl工具，可以用于原生Kubernetes和OpenYurt集群的一鍵式轉(zhuǎn)換，

架構(gòu)差異可能帶來的影響：

• 原生Kubernetes帶來的系統(tǒng)穩(wěn)定性挑戰(zhàn)：因?yàn)镺penYurt沒有修改Kubernetes，所以這個(gè)問題也是原生Kubernetes在邊緣場景下的問題。當(dāng)云邊長時(shí)間斷網(wǎng)再次恢復(fù)時(shí)，邊緣到云端會產(chǎn)生大量的全量List請求，從而對kube-apiserver造成比較大的壓力。邊緣節(jié)點(diǎn)過多時(shí)，將會給系統(tǒng)穩(wěn)定性帶來不小的挑戰(zhàn)。

• 邊緣無輕量化解決方案: 雖然OpenYurt沒有修改Kubernets，但是在邊緣節(jié)點(diǎn)上增加YurtHub和Tunnel Agent組件。目前在最小的1C1G的系統(tǒng)上運(yùn)行成功，更小規(guī)格機(jī)器待驗(yàn)證。

邊緣計(jì)算場景

• 無設(shè)備管理能力：OpenYurt目前沒有提供設(shè)備管理的相關(guān)能力，需要用戶以workload形式來運(yùn)行自己的設(shè)備管理解決方案。雖然不算是架構(gòu)設(shè)計(jì)的缺點(diǎn)，但是也算是一個(gè)邊緣場景的不足點(diǎn)。

2.3 SuperEdge

（1）開源狀況

SuperEdge是騰訊云于2020年12月底開源的，目前還是開源初期階段。其架構(gòu)如下：

（2）與Kubernetes的架構(gòu)差異

SuperEdge的架構(gòu)設(shè)計(jì)比較簡潔，也是采用的無侵入式對Kubernetes進(jìn)行增強(qiáng)。在云端(K8s Master)上增加Application-Grid Controller, Edge-Health Admission以及Tunnel Cloud組件。而在邊緣端(K8s Worker)上增加了Lite-Apiserver和Tunnel Edge，Application-Grid Wrapper組件。從架構(gòu)上看主要增加了如下能力來適配邊緣場景：

• Lite-Apiserver: 代理各個(gè)邊緣組件到K8s Master的通信請求，同時(shí)把請求返回的元數(shù)據(jù)持久化在節(jié)點(diǎn)磁盤。當(dāng)云邊網(wǎng)絡(luò)不穩(wěn)定時(shí)，則利用本地磁盤數(shù)據(jù)來用于邊緣業(yè)務(wù)的生命周期管控。同時(shí)基于邊緣Edge-Health上報(bào)信息，云端的Edge-Health Admission會管控邊緣業(yè)務(wù)Pod的驅(qū)逐策略。

• Tunnel Cloud/Tunnel Edge: 每個(gè)邊緣節(jié)點(diǎn)上的Tunnel Edge將主動與云端Tunnel Cloud建立雙向認(rèn)證的加密的gRPC連接，同時(shí)云端將通過此連接訪問到邊緣節(jié)點(diǎn)及其資源。

• Application-Grid Controller：引入的兩個(gè)CRD資源: ServiceGrids和 DeploymentGrids. 前者為位于同一區(qū)域的業(yè)務(wù)流量提供閉環(huán)管理。后者定義了一種新的邊緣應(yīng)用模型以節(jié)點(diǎn)池為單位來管理工作負(fù)載。

與OpenYurt對比

• 從SuperEdge的架構(gòu)以及功能分析下來，發(fā)現(xiàn)SuperEdge從架構(gòu)到功能和OpenYurt基本一致。這也從側(cè)面印證，邊緣計(jì)算云原生這個(gè)領(lǐng)域，各大廠商都在如火如荼的投入。

• SuperEdge與Kubernetes的對比分析可以參照OpenYurt的分析，這里我們從代碼角度分析SuperEdge和OpenYurt的差異：

• YurtHub和Lite-Apiserver: YurtHub采取了完善的證書管理機(jī)制和本地?cái)?shù)據(jù)緩存設(shè)計(jì)，而Lite-Apiserver使用的是節(jié)點(diǎn)kubelet證書和數(shù)據(jù)簡單緩存。

• Tunnel組件：OpenYurt的Tunnel組件是基于Kubernetes社區(qū)的開源項(xiàng)目ANP(github.com/kubernetes-s)，同時(shí)實(shí)現(xiàn)了完善的證書管理機(jī)制。而SuperEdge的Tunnel組件同樣也是使用節(jié)點(diǎn)證書，同時(shí)請求轉(zhuǎn)發(fā)是基于自行封裝的gRPC連接。OpenYurt底層的ANP相比原生gRPC，會更好適配kube-apiserver的演進(jìn)。

• 單元化管理組件: OpenYurt單元化管理支持Deployment和StatefulSet,而SuperEdge的單元化管理只支持Deployment。另外OpenYurt的NodePool和UnitedDeployment的API定義是標(biāo)準(zhǔn)云原生的設(shè)計(jì)思路，而SuperEdge的ServiceGrids和 DeploymentGrids的API定義顯得隨意一些。

• 邊緣狀態(tài)檢測，這個(gè)能力OpenYurt未實(shí)現(xiàn)，SuperEdge的設(shè)計(jì)需要kubelet監(jiān)聽節(jié)點(diǎn)地址用于節(jié)點(diǎn)間互相訪問，有一定安全風(fēng)險(xiǎn)。同時(shí)東西向流量也有不少消耗在健康檢查上。期待這個(gè)部分后續(xù)的優(yōu)化。

2.4?對比結(jié)果一覽

根據(jù)上述的對比分析，結(jié)果整理如下表所示：

項(xiàng)目	華為KubeEdge	阿里OpenYurt	騰訊SuperEdge
是否CNCF項(xiàng)目	是(孵化項(xiàng)目)	是(沙箱項(xiàng)目)	否
開源時(shí)間	2018.11	2020.5	2020.12
侵入式修改Kubernetes	是	否	否
和Kubernetes無縫轉(zhuǎn)換	無	有	未知
邊緣自治能力	有(無邊緣健康檢測能力)	有(無邊緣健康檢測能力)	有(安全及流量消耗待優(yōu)化)
邊緣單元化	不支持	支持	支持(只支持Deployment)
是否輕量化	是(節(jié)點(diǎn)維度待確認(rèn))	否	否
原生運(yùn)維監(jiān)控能力	部分支持	全量支持	全量支持(證書管理及連接管理待優(yōu)化)
云原生生態(tài)兼容	部分兼容	完整兼容	完整兼容
系統(tǒng)穩(wěn)定性挑戰(zhàn)	大(接入設(shè)備數(shù)量過多)	大(大規(guī)模節(jié)點(diǎn)并且云邊長時(shí)間斷網(wǎng)恢復(fù))	大(大規(guī)模節(jié)點(diǎn)并且云邊長時(shí)間斷網(wǎng)恢復(fù))
設(shè)備管理能力	有(有管控流量和業(yè)務(wù)流量耦合問題)	無	無

各個(gè)開源項(xiàng)目，整體比較下來的發(fā)現(xiàn)

KubeEdge和OpenYurt/SuperEdge的架構(gòu)設(shè)計(jì)差異比較大，相比而言O(shè)penYurt/SuperEdge的架構(gòu)設(shè)計(jì)更優(yōu)雅一些。而OpenYurt和SuperEdge架構(gòu)設(shè)計(jì)相似，SuperEdge的開源時(shí)間晚于OpenYurt，項(xiàng)目成熟度稍差。

如果打算選擇一個(gè)邊緣計(jì)算云原生項(xiàng)目用于生產(chǎn)，我會從以下角度考慮：

• 如果需要內(nèi)置設(shè)備管理能力，而對云原生生態(tài)兼容性不在意，建議選擇KubeEdge

• 如果從云原生生態(tài)兼容和項(xiàng)目成熟度考慮，而不需要設(shè)備管理能力或者可以自建設(shè)備管理能力，建議選擇OpenYurt

點(diǎn)擊關(guān)注我們，記得標(biāo)星哦~~~

更多閱讀推薦

• 都在說云原生，它的技術(shù)圖譜你真的了解嗎？
  

• SRE 是如何保障穩(wěn)定性的
  

• 如何寫出讓 CPU 跑得更快的代碼？

• 俯瞰云原生，這便是供應(yīng)層
  

• 13種重要的云原生工具，讓交付過程更快
  

• 一目了然的 Docker 環(huán)境配置指南

總結(jié)

以上是生活随笔為你收集整理的从开源视角分析，搞定边缘计算云原生方案选型的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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