大家好 我是來自CooperAge社區的Maintainer 徐飛下面由我跟來自Docloud的Maintainer政策來給大家介紹一下CooperAge社區大家好 我是Docloud的BNG 算團隊的技術負責人政策同時也是CooperAge社區的Maintainer本人長期活躍於各大餘願生開源項目上目前主要專注於願生和BNG算方向本次分享將介紹CooperAge的相關能力及架構接著還會給大家分享一些基於CooperAge落地的一些BN場景案例之後再介紹CooperAge最近的一些新功能以及社區的動態最後是未來的一些規劃及展望為什麼要使用BNG算呢BNG算有以下幾個特點低延遲 海量數據 隱私安全 邊緣自製邊緣側的設備在傳統的LOT架構下它需要把自己的產生的消息先發送到雲端做出響應之後再返回到邊緣端的設備上這個過程它的延遲會比較高如果我們通過邊緣計算在邊緣端部署一套應用來直接處理設備產生的消息我們就不需要去訪問雲端大大降低了它的延遲另外邊緣端介入的設備會不斷地產生數據海量的數據上雲成本非常高如果在本地優先處理數據做一些數據分析和過濾可以大大的節省網絡貸款根據行業特性的不同在邊緣端可能涉及到一些隱私數據它不應該被發送到雲端使用邊緣計算的話可以在邊緣測直接處理這些敏感的個人隱私數據或者說業務隱私數據來保護生產和業務的安全邊緣自治當邊緣端和雲端連接斷開始邊緣端可以保證在離線的情況下邊緣節點上面的應用可以正常運行如果應用因為某些原因出現異常的話也可以快速地恢復庫貝爾紙是一套基於K8S構建的邊緣計算平台基於K8S來構建邊緣計算平台有哪些好處呢首先應用容器化容器化的應用它實現了本地與雲端的環境完全一致做到了真正的一次構建水處運行升級和回滾的話只需要切換到對應的鏡像版本就可以了而且K8S還抽象了一套通用的應用定義在庫貝爾紙中它的邊緣測的應用定義和K8S雲端使用的是相同的標準它們可以無縫對解我們可以通過K8S CRD的方式去擴展K8S上面的能力庫貝爾紙就可以就通過這種方式輕鬆地去擴展了這部分功能當然基於K8S來構建邊緣計算平台還有一些挑戰邊緣節點資源有限即使只有一個庫貝爾納它的資源都是十分緊張的更不要說是一套標準的K8S邊緣節點的網絡十分不穩定邊緣節點常常處在一個私有網絡中它的貸寬有限延遲也比較高而且在邊緣的場景中它通常是需要邊緣自製的能力的因為邊緣端可能隨時都會離線斷網當網絡斷開的時候邊緣端需要保證應用正常穩定的運行即使邊緣節點出現了一些異常比如說因為過熱導致了重啟這個時候邊緣節點也需要能夠快速的恢復之前在這個節點上運行的一些應用我們需要支持很多不同種類的設備比如說如果我們要採集溫度的話就需要溫度傳感器或者溫溼度傳感器還有一些像藍牙設備圖像採集的攝像頭PLC之類的所以我們邊緣端還需要支持一套設備管理來將這些設備管理起來下面來給大家介紹一下Coobrage的主要功能Coobrage兼容K8s原生的API它可以運行在任何K8s集群中包括各個廠商的K8s產品用戶在雲上自建的K8s集群都可以很方便地使用Coobrage基於相同的應用定義Coobrage支持雲邊無縫的對接可以在邊緣側輕鬆地把應用管理起來邊緣自製是Coobrage核心的能力Coobrage在邊緣端的話使用的是一個輕量化的容器應用管理服務它大大減少了資源的開銷Coobrage還簡化了設備的通信邊緣端的一些其他設備比如說藍牙設備攝像頭它可以通過MQTT的方式來對接到整個Coobrage平台當中最後在雲端也可以通過Coobrage來查看所有節點的一些監控指標我們來看一下Coobrage的整體架構Coobrage的架構分為三個部分雲端 邊端 設備端雲端的Cloud Core它主要是同步K8s的相關資源像Nordepod這些資源到邊緣端的AZ Core當中邊緣端的AZ Core接收到了這些資源會先保存到節點上做持久化然後根據這些資源去管理相應的應用以及配置設備端的話接入我們是通過一個Mapper層就是接入各個不同的驅動比如說藍牙驅動我們需要將這種藍牙的收上來的數據通過Mapper的方式把它轉換成MQTT接入到Coobrage的整體框架當中位置是如何部署一個應用到邊緣端的呢首先當一個Pod被創建的時候ETCD會推送Pod的創建事件K8s的Scheduler它接收到Pod的創建事件之後根據它內部的一些調度算法執行調度並且選擇一個合適的邊緣節點綁定到這個Pod上然後通過API Server來更新Pod的信息更新完了之後ETCD會把Pod的更新事件推送到Cloud CoreCloud Core接收到Pod的更新事件之後會將Pod的信息發送到Pod關聯的一個邊緣節點上這個節點接收到Pod的信息之後會先將Pod的信息持久化到這個節點上即使這個節點異常啟動也可以通過本地存儲快速的將Pod恢復最後再通知ETCD就是輕量化的Cloud來將Pod創建出來這就是Coobrage部署應用到邊緣端的整體流程Coobrage的雲端部份就是Cloud Cob我們看一下它對接EdgeNode的邊緣節點部份這邊有一個Cloud Hub它是一個Websocket的服務端主要負責監聽雲端的資源變化並且緩存和發送這些信息到邊緣端的Edge Hub中EdgeController它主要是管理邊緣節點上關聯的一些遠數據資源比如說Node節點信息Pod音韻信息ConfigMap 配置文件以及Securator密號信息它還需要確保這些信息能夠傳遞到指定的邊緣節點上而不丟失XController這是一個設備管理控制器它管理邊緣節點上所有的設備信息並且確保設備信息 設備狀態在雲河邊的同步SyncController它會同步邊緣端與雲端不一致的資源信息保持邊緣端運行的狀態是雲端期望的狀態CubeEdge 本身提供了ConfigMap、Securator、Hospass、BundWord API這些Volume在此基礎上 它又集成了容器存儲接口 CSI可以讓用戶直接使用KBS標準的存儲方案CubeEdge CSI Driver 是CubeEdge自帶的一個 CSI驅動實現主要負責將存儲信息同步到邊緣側以及調用外部插件來管理存儲券The Mason Webhawk這是KBS中用來做API擴展教驗的一個組件CubeEdge 通過這種方式來去做的一個應用的邊緣資質防止在節點離線的時候應用被KBS調度到其他節點上面在CubeEdge的邊緣端 也就是HCore這一側H Hub 它是一個Webersocket的客戶端主要負責與雲端的Cloud Hub交互並且將雲端同步過來的資源存儲下來報告邊緣節點的狀態和設備狀態的變化Metal Manager 是邊緣端的一個元數據存儲它主要做了資源的一個持久化存儲它裡面有一個Metal Server 模塊Metal Server 模塊就是可以簡單的理解為邊緣端的一個輕量的API Server我們可以通過訪問KBSAPI的方式來訪問Metal Server獲取KBS集群中的一些資源HD 這是CubeEdge的一個輕量版的容器應用管理服務簡單來說就是一個輕量的CubeEdge它用來管理POD的全生命週期Device Twin 它用來存儲所有的設備信息並且將這些設備的狀態同步到雲它還為應用程序可以通過MQTT的方式來查詢這個節點上的相關設備的信息EventBus 就是橋接Device Twin和MQTT Broker的一個MQTT ClientCubeEdge當中它還有一個Router的能力Router的話就是一個消息通道或者說一個消息路由就是支持用戶可以通過定義Router來將雲端的消息下發到邊緣端或者把邊緣端的信息傳送到雲端當然目前的話邊緣端EventBus它只支持MQTT所以它的出口 邊緣端的出口和入口的話它都是MQTT協議的雲端的話是以Rest方式去暴露的API接口下面由我為大家介紹一下我們社區的其他的一些用戶案例和一些新特性以及社區的一些更新還有未來的一些計畫以及我們社區的一些資料大家看到這個用戶case是來自天意雲的他們主要用CubeEdge來管理他們的CDN節點大家可以從那個圖上看到他們的整個架構圖分三部分第一部分是中心雲第二部分是他們的region第三部分是CDN的節點他們在就是他CDN是一個分散的架構他們在每個region佈了一個CubeEdge集群這個集群管理了他們region對應的CDN節點他們目前在每個region的規模大概有幾千的節點所以他們這個是一個很大規模的CDN落地他們在一個中心雲上又把他們region去這些集群管理起來就在上面的Pass Platform裡面做了各種管理監控這個是一個天意雲的一個大規模落地的案例下面一個是我們一個上氣的上氣就是我們它在車裡面使用了CubeEdge大家可以從這個架構圖裡看到我們的上氣它也是分為雲邊段雲上就是我們的雲上總控部分其實它的邊根端其實都統一到它的車裡了它在它的汽車裡面裝了我們CubeEdge的EdgeCore以及我們的Maple管理了它汽車上的好多傳感器這樣的話就是可以實現從我們雲上來管理跑在路上的汽車來裝在裡面進行一些監控以及一些控制這個案例的規模也是很大我們的車可以可能有幾十萬輛車通過我們的CubeEdge集群結上來然後最後通過中心雲給它納管起來然後管控起來它這個項目的幾個特點我在右邊列出來了它一個是大規模這一個就是因為它車裡的自圓是比較有限的所以說它需要我們在邊緣上輕量化的架構第三個就是一些良好的一些擴展性比如說它因為幾十萬輛車需要多幾群還有一些需要定制的我們雲邊消息通信以及我們的設備控制最後還有一些邊緣自製其他的一些特性然後來支撐它們大規模的案例這個也是一個很有代表性的案例這個是兩個比較有代表性的案例下面我來介紹一下就是我們整個21年社區做的一些新特性第一個就是我們的Cloud Cloud多實力就是H&A這個多實力也是支撐了我們幾個客戶的大規模落地第二個就是我們Mapper framework的一個更新Mapper的更新也是個人便捷與我們社區的用戶開發者來開發他們自定義的Mapper第三個就是我們的邊緣自定義消息支撐了HTDP這個也是我們的一個比較有特性下面一個就是我們EdgeMesh整個架構升級首先它出我們的AgeCore其實玻璃出去是一個獨立的庫然後後面它也支持了這種跨執往的通信以及這種邊邊和雲邊這種通信最後一個就是我們的Device Management Interface這個是我們提出的一個在邊緣就是設備接入的一套標準接口後續我們會基於這個標準然後來接入各種設備以及就是兼容各個平台這個就是今年的一些大特性下面就是我在簡單介紹一下Corepage社區我們是一個開源社區我們Corepage社區十到一八年開源並在19年3月份成為一個CCEF的Sidebox項目並且在我們去年2020年的9月份成功進身為伺服化項目目前我們的SDA有4.6K然後FOC是1.3K下面還有800家的貢獻者以及60家的企業合作夥伴包括我們現在也圍繞場景有了一系列的CIG比如說我們的CIG AI還有Device IoT MEC還有CIG機器人馬上也會推出還有我們的Wireless Walking Group大家如果有興趣可以到我們的GateHop主頁上來了解一下下面這個是列了一些我們的合作夥伴大家看到目前的合作夥伴也是很多包括一些像AMM三星以及我們國內的連通沃雲移動電信運營商還有一些像浪潮這種企業還有一些像我們的華爾雲Docklaude時數雲Coupsier這些雲廠商最後就是像我們的這些新同學這家大學這家實驗室電子科大等等的這種科研單位下面就是這個小系列了我們目前的社區的一些CIGCIG像CIG AICIG MEC我剛才講過了像CIG VS IoTCIG那個機器人還有一些子項目比如說我們CIG AI下面的Satna子項目以及我們的HMesh子項目大家有興趣都可以關注一下這個就是一個Satna項目的一個展開的介紹Satna項目就是主要專注於邊緣AI邊緣AI然後邊緣AI它裡面又會做邊緣協同的AI比如說我們一些模型在雲上訓練然後動態的傳道邊緣然後做一些推理這種就是邊緣協同起來不像我們傳統的就是雲上訓練然後再傳道邊緣我們這個系統只在就是實現自動化的這種雲邊協同訓練或者推理大家如果對這方面感興趣也可以瞭解一下我們這個Satna項目下面一個就是這個是我們新成立的Sag就是機器人的Sag它主要就是專注於機器人這一塊用Cube Edge來控制機器人目前是剛成立的一個Sag它主要專注於比如說我們的一些技術討論機器人的API定義以及我們的一些架構一些實現然後就是給以後的一些機器人用Cube Edge做一些音樂聲的升級基於我們雲邊協同的框架提高它就是機器人的效率和執行的性能大家如果有興趣也可以加入我們這個Sag下面我也列出了就是我們這個Sag的一個地址大家可以詳細的瞭解一下我們Sag的詳情下面一個就是我們Sag Device IoT的一個最新的進展就是我們提出了Drives Management Interface簡稱就是DMIDMI就是它只在就是定義我們邊緣設備介入和管理的這個標準接口下面我們也可以列出了它裡面的一些就是要管理的比如說像創建更新刪除我們的設備以及List或者是一些Health Check還有這個設備的一些監控包括就是我們設備數據的一些比如說闡述處理了還有一些最後設備的一些就是控制設備升級最後還有我們DMI本身的一些這個目前我們仍然處於討論設計簡短大家如果有興趣也可以加入到我們社區的立會或者是我們社區其實現在也有相關的依守大家可以參考一下如果有興趣可以加入我們討論裡面講完了我們目前的一些進展下面就是一個未來的規劃為了規劃我們主要還是設計兩方面一個就是我們技術方面還有就是我們社區方面的技術方面比如說我們設計到邊緣的存儲還有我們邊緣的安全還有我們的邊緣應用的安全安全在我們邊緣是一個很重要的課題這個我們後面也是會自社區加強下面可能就是我們邊緣設備的一個管理以及兼容性還有我們這就是一個應用性或者用戶的一個比如說應用容易開發設備的一個驅動DMI後面我們也是會大力發展最後一個就是管理我們的邊緣的集群這個也講了很久其實有些用戶他可能有訴求在邊緣管他的邊緣集群這些就是我們列了一些工作重點這個不是全部的重點後面的話就是我們根據需求可能會有調整大家有什麼需求也可以給我們社區提一修都可以後面一個就是我們那個社區社區主要就是建設一些比如說我們貢獻著體驗包括我們更多的貢獻著活動比如一些Metab新鮮交流或者線上直播對大家更提供一個交流的平台還有一個就是我們更多的一些跨社區合作