• <thead id="cw2a7"><del id="cw2a7"></del></thead>
    <optgroup id="cw2a7"><del id="cw2a7"></del></optgroup>
    <thead id="cw2a7"><s id="cw2a7"></s></thead>
  • <object id="cw2a7"><option id="cw2a7"></option></object>

    應用

    技術

    物聯網世界 >> 物聯網新聞 >> 物聯網熱點新聞
    企業注冊個人注冊登錄

    邊緣計算云原生開源方案選型比較

    2021-03-02 01:26 邊緣計算社區

    導讀:隨著Kubernetes已經成為容器編排和調度的事實標準,各大公有云廠商都已經基于Kubernetes提供了完善的Kubernetes云上托管服務。

    隨著Kubernetes已經成為容器編排和調度的事實標準,各大公有云廠商都已經基于Kubernetes提供了完善的Kubernetes云上托管服務。同時也看到越來越多的企業、行業開始在生產中使用Kubernetes, 擁抱云原生。在各行各業數字化轉型和上云過程中,公有云廠商也在主動擁抱傳統線下環境,在思考各種各樣的解決方案使云上能力向邊緣(或線下)延伸。

    而Kubernetes由于屏蔽了底層架構的差異性,可以幫助應用平滑地運行在不同的基礎設施上的特性,云上的Kubernetes服務也在考慮拓展其服務邊界,云原生和邊緣計算結合的想法自然就呼之欲出了。

    目前國內各個公有云廠商也都開源了各自基于Kubernetes的邊緣計算云原生項目。如華為云的KubeEdge,阿里云的OpenYurt,騰訊云的SuperEdge。目前網上很少有從技術視角來介紹這幾個項目優缺點的文章,本文試著從技術視角,從開源視角來分析這幾個項目,希望可以給大家做項目選型時提供一些借鑒。

    01比較思路

    這幾個項目都是云邊一體,云邊協同的架構,走的是Kubernetes和邊緣計算結合的路數,因此決定從以下幾點比較:

    (1) 各個項目的開源狀況:比如開源項目的背景、開源的時間、是否進入了CNCF等;

    (2)Kubernetes架構:

    先對比與Kubernetees的架構差異:主要關注是否修改Kubernetes,和;Kubernetes一鍵式轉換等根據架構差異對比和Kubernetes的能力增強點;主要關注邊緣自治,邊緣單元化,輕量化等能力最后看一下架構差異可能帶來的影響: 主要關注運維監控能力,云原生生態兼容性,系統穩定性等方面

    (3)對邊緣計算場景支持能力:

    主要關注是否具備端設備的管理能力

    接下來以項目的開源順序,從上述幾個方面來介紹各個項目。

    02邊緣云原生開源項目對比

    2.1KubeEdge

    (1)開源狀況

    KubeEdge是華為云于2018年11月份開源的,目前是CNCF孵化項目。其架構如下:

    (2)與Kubernetes的架構差異

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

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

    Cloud Hub+EdgeHub模塊: 拋棄了原生kubernetes 的組件間數據同步list/watch機制,改成基于websocket/quic協議從云端往邊緣推送模式。節點元數據緩存模塊(MetaManager): 把節點維度的數據持久化在本機的SQLite數據庫中,當云邊網絡不穩定時Edged模塊將從本地數據庫中獲取數據用于業務的生命周期管控。DeviceController+設備管理模塊(DeviceTwin): 把設備管理能力直接集成到EdgeCore中,為用戶提供原生的設備管理能力。

    上述的架構設計,對比Kubernetes的能力增強點主要有:

    邊緣自治:通過增加節點元數據緩存,可以規避云邊斷網狀態下,邊緣業務或者節點重啟時,邊緣組件可以利用本地緩存數據進行業務恢復,這就帶來了邊緣自治的好處。輕量化: 削減了部分kubelet功能(如CSI,CNI等),從而使邊緣EdgeCore組件相比原生kubelet組件更加輕量。同時因為節點上增加了SQLite數據庫,所以節點維度相比原生節點是否輕量待確認,歡迎熟悉的同學提供數據。

    架構差異可能帶來的影響:

    云原生生態兼容性不足:跟隨社區同步演進挑戰大: 由于對Kubernetes系統的侵入式修改,后續跟隨Kubernetes社區的演進將會遇到很大挑戰。邊緣節點無法運行Operator:因為云邊通信機制的修改,Cloud Hub只能往邊緣推送有限的幾種資源(如Pod,ConfigMap等)。而Operator既需要自定義CRD資源,又需要list/watch云端獲取關聯資源,因此社區的Operator無法運行的KubeEdge的邊緣節點上。邊緣節點不適合運行需要list/watch云端的應用: 因為云邊通信機制的修改,導致原來需要使用list/watch機制訪問kube-apiserver的應用,都無法通過hub tunnel 通道訪問kube-apiserver,導致云原生的能力在邊緣側大打折扣。運維監控能力支持有限:

    因為目前云邊通信鏈路是kube-apiserver --> controller --> Cloud Hub -->EdgeHub -->MetaManager等,而原生Kubernetes運維操作(如kubectl proxy/logs/exec/port-forward/attch等)是kube-apiserver直接請求kubelet。目前KubeEdge社區最新版本也僅支持kubectl logs/exec/metric,其他運維操作目前還不支持。

    系統穩定性提升待確定:基于增量數據的云邊推送模式:可以解決邊緣watch失敗時的重新全量list從而引發的kube-apiserver 壓力問題,相比原生Kubernetes架構可以提升系統穩定性。Infra管控數據和業務管控數據耦合:Kubernetes集群的管控數據(如Pod,ConfigMap數據)和邊緣業務數據(設備管控數據)使用同一條websocket鏈路,如果邊緣管理大量設備或者設備更新頻率過高,大量的業務數據將可能影響到集群的正常管控,從而可能降低系統的穩定性。

    邊緣計算場景支持能力

    設備管理能力: 這個能力直接集成在edged中,給iot用戶提供了一定的原生設備管理能力。

    2.2OpenYurt

    (1)開源狀況

    OpenYurt是阿里云于2020年5月份開源的,目前是CNCF沙箱項目。架構如下:

    (2)與Kubernetes的架構差異

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

    YurtHub: 代理各個邊緣組件到K8s Master的通信請求,同時把請求返回的元數據持久化在節點磁盤。當云邊網絡不穩定時,則利用本地磁盤數據來用于邊緣業務的生命周期管控。同時云端的Yurt Controller Manager會管控邊緣業務Pod的驅逐策略。Tunnel Server/Tunnel Agent: 每個邊緣節點上的Tunnel Agent將主動與云端Tunnel Server建立雙向認證的加密的gRPC連接,同時云端將通過此連接訪問到邊緣節點及其資源。Yurt App Manager:引入的兩個CRD資源: NodePool 和 UnitedDeployment. 前者為位于同一區域的節點提供批量管理方法。后者定義了一種新的邊緣應用模型以節點池維度來管理工作負載。

    上述的架構設計,對比Kubernetes的能力增強點主要有:

    邊緣單元化:通過Yurt App Manager組件,從單元化的視角,管理分散在不同地域的邊緣資源,并對各地域單元內的業務提供獨立的生命周期管理,升級,擴縮容,流量閉環等能力。且業務無需進行任何適配或改造。邊緣自治: 因為每個邊緣節點增加了具備緩存能力的透明代理YurtHub,從而可以保障云邊網絡斷開,如果節點或者業務重啟時,可以利用本地緩存數據恢復業務。云邊協同(運維監控):通過Tunnel Server/Tunnel Agent的配合,為位于防火墻內部的邊緣節點提供安全的云邊雙向認證的加密通道,即使邊到云網絡單向連通的邊緣計算場景下,用戶仍可運行原生kubernetes運維命令(如kubectl proxy/logs/exec/port-forward/attach等)。同時中心式的運維監控系統(如prometheus, metrics-server等)也可以通過云邊通道獲取到邊緣的監控數據。云原生生態兼容:所有功能均是通過Addon或者controller形式來增強Kubernetes,因此保證來對Kubernetes以及云原生社區生態的100%兼容。另外值得一提的是:OpenYurt項目還提供了一個YurtCtl工具,可以用于原生Kubernetes和OpenYurt集群的一鍵式轉換,

    架構差異可能帶來的影響

    原生Kubernetes帶來的系統穩定性挑戰:因為OpenYurt沒有修改Kubernetes,所以這個問題也是原生Kubernetes在邊緣場景下的問題。當云邊長時間斷網再次恢復時,邊緣到云端會產生大量的全量List請求,從而對kube-apiserver造成比較大的壓力。邊緣節點過多時,將會給系統穩定性帶來不小的挑戰。邊緣無輕量化解決方案: 雖然OpenYurt沒有修改Kubernets,但是在邊緣節點上增加YurtHub和Tunnel Agent組件。目前在最小的1C1G的系統上運行成功,更小規格機器待驗證。

    邊緣計算場景

    無設備管理能力:OpenYurt目前沒有提供設備管理的相關能力,需要用戶以workload形式來運行自己的設備管理解決方案。雖然不算是架構設計的缺點,但是也算是一個邊緣場景的不足點。

    2.3SuperEdge

    (1)開源狀況

    SuperEdge是騰訊云于2020年12月底開源的,目前還是開源初期階段。其架構如下:

    (2)與Kubernetes的架構差異

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

    Lite-Apiserver: 代理各個邊緣組件到K8s Master的通信請求,同時把請求返回的元數據持久化在節點磁盤。當云邊網絡不穩定時,則利用本地磁盤數據來用于邊緣業務的生命周期管控。同時基于邊緣Edge-Health上報信息,云端的Edge-Health Admission會管控邊緣業務Pod的驅逐策略。Tunnel Cloud/Tunnel Edge: 每個邊緣節點上的Tunnel Edge將主動與云端Tunnel Cloud建立雙向認證的加密的gRPC連接,同時云端將通過此連接訪問到邊緣節點及其資源。Application-Grid Controller:引入的兩個CRD資源: ServiceGrids和 DeploymentGrids. 前者為位于同一區域的業務流量提供閉環管理。后者定義了一種新的邊緣應用模型以節點池為單位來管理工作負載。

    與OpenYurt對比

    從SuperEdge的架構以及功能分析下來,發現SuperEdge從架構到功能和OpenYurt基本一致。這也從側面印證,邊緣計算云原生這個領域,各大廠商都在如火如荼的投入。SuperEdge與Kubernetes的對比分析可以參照OpenYurt的分析,這里我們從代碼角度分析SuperEdge和OpenYurt的差異:YurtHub和Lite-Apiserver: YurtHub采取了完善的證書管理機制和本地數據緩存設計,而Lite-Apiserver使用的是節點kubelet證書和數據簡單緩存。Tunnel組件:OpenYurt的Tunnel組件是基于Kubernetes社區的開源項目ANP(github.com/kubernetes-s),同時實現了完善的證書管理機制。而SuperEdge的Tunnel組件同樣也是使用節點證書,同時請求轉發是基于自行封裝的gRPC連接。OpenYurt底層的ANP相比原生gRPC,會更好適配kube-apiserver的演進。單元化管理組件: OpenYurt單元化管理支持Deployment和StatefulSet,而SuperEdge的單元化管理只支持Deployment。另外OpenYurt的NodePool和UnitedDeployment的API定義是標準云原生的設計思路,而SuperEdge的ServiceGrids和 DeploymentGrids的API定義顯得隨意一些。邊緣狀態檢測,這個能力OpenYurt未實現,SuperEdge的設計需要kubelet監聽節點地址用于節點間互相訪問,有一定安全風險。同時東西向流量也有不少消耗在健康檢查上。期待這個部分后續的優化。

    2.4對比結果一覽

    根據上述的對比分析,結果整理如下表所示:

    03總結

    各個開源項目,整個比較下來自己的感受是:

    KubeEdge和OpenYurt/SuperEdge的架構設計差異比較大,相比而言OpenYurt/SuperEdge的架構設計更優雅一些。而OpenYurt和SuperEdge架構設計相似,SuperEdge的開源時間晚于OpenYurt,項目成熟度稍差。

    如果打算選擇一個邊緣計算云原生項目用于生產,我會從以下角度考慮:

    如果需要內置設備管理能力,而對云原生生態兼容性不在意,建議選擇KubeEdge如果從云原生生態兼容和項目成熟度考慮,而不需要設備管理能力或者可以自建設備管理能力,建議選擇OpenYurt