日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 云知道 > >

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

云知道邊緣計算


  • 輕量化: 削減了部分kubelet功能(如CSI ， CNI等) ， 從而使邊緣EdgeCore組件相比原生kubelet組件更加輕量 。同時因為節(jié)點上增加了SQLite數(shù)據(jù)庫 ， 所以節(jié)點維度相比原生節(jié)點是否輕量待確認 ， 歡迎熟悉的同學提供數(shù)據(jù) 。
    • 架構(gòu)差異可能帶來的影響：
    • 云原生生態(tài)兼容性不足：
    1. 跟隨社區(qū)同步演進挑戰(zhàn)大: 由于對Kubernetes系統(tǒng)的侵入式修改 ， 后續(xù)跟隨Kubernetes社區(qū)的演進將會遇到很大挑戰(zhàn) 。
    2. 邊緣節(jié)點無法運行Operator：因為云邊通信機制的修改 ， Cloud Hub只能往邊緣推送有限的幾種資源(如Pod ， ConfigMap等) 。而Operator既需要自定義CRD資源 ， 又需要list/watch云端獲取關聯(lián)資源 ， 因此社區(qū)的Operator無法運行的KubeEdge的邊緣節(jié)點上 。
    3. 邊緣節(jié)點不適合運行需要list/watch云端的應用: 因為云邊通信機制的修改 ， 導致原來需要使用list/watch機制訪問kube-apiserver的應用 ， 都無法通過hub tunnel 通道訪問kube-apiserver ， 導致云原生的能力在邊緣側(cè)大打折扣 。
    • 運維監(jiān)控能力支持有限：
      因為目前云邊通信鏈路是kube-apiserver –> controller –> Cloud Hub –>EdgeHub –>MetaManager等 ， 而原生Kubernetes運維操作(如kubectl proxy/logs/exec/port-forward/attch等)是kube-apiserver直接請求kubelet 。目前KubeEdge社區(qū)最新版本也僅支持kubectl logs/exec/metric ， 其他運維操作目前還不支持 。
    • 系統(tǒng)穩(wěn)定性提升待確定:
    1. 基于增量數(shù)據(jù)的云邊推送模式：可以解決邊緣watch失敗時的重新全量list從而引發(fā)的kube-apiserver 壓力問題 ， 相比原生Kubernetes架構(gòu)可以提升系統(tǒng)穩(wěn)定性 。
    2. Infra管控數(shù)據(jù)和業(yè)務管控數(shù)據(jù)耦合：Kubernetes集群的管控數(shù)據(jù)(如Pod ， ConfigMap數(shù)據(jù))和邊緣業(yè)務數(shù)據(jù)(設備管控數(shù)據(jù))使用同一條websocket鏈路 ， 如果邊緣管理大量設備或者設備更新頻率過高 ， 大量的業(yè)務數(shù)據(jù)將可能影響到集群的正常管控 ， 從而可能降低系統(tǒng)的穩(wěn)定性 。
    邊緣計算場景支持能力
    • 設備管理能力: 這個能力直接集成在edged中 ， 給iot用戶提供了一定的原生設備管理能力 。
    2.2OpenYurt（1）開源狀況 OpenYurt是于2020年5月份開源的 ， 目前是CNCF沙箱項目 。架構(gòu)如下:

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


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