作者：趙震，深信服云計(jì)算開發(fā)工程師，OpenYurt 社區(qū) Member

編者案：在 5G、物聯(lián)網(wǎng)等新技術(shù)的持續(xù)推動(dòng)下，邊緣計(jì)算產(chǎn)業(yè)已然走向大風(fēng)口，未來越來越多的種類，越來越大的規(guī)模和越來越復(fù)雜的應(yīng)用和工作負(fù)載都會(huì)被部署到邊緣側(cè)。本文基于深信服云計(jì)算工程師趙震在由 CNCF 和阿里云聯(lián)合舉辦的云原生容器領(lǐng)域開發(fā)者沙龍 KubeMeet 中的分享整理，介紹了邊緣計(jì)算落地的機(jī)遇與挑戰(zhàn)，以及邊緣容器開源項(xiàng)目 OpenYurt 在企業(yè)生產(chǎn)環(huán)境下的實(shí)踐方案。

本次分享是偏重于實(shí)踐的案例，主要是關(guān)于 OpenYurt 產(chǎn)品在真實(shí)落地情況下的方案是怎么部署的。

主要從 4 個(gè)方面來進(jìn)行，首先是關(guān)于邊緣計(jì)算遇到的機(jī)遇和挑戰(zhàn)都有哪些，第二部分就是深信服平臺(tái)針對(duì)這些挑戰(zhàn)做了哪些解決方案，可以讓用戶更好地使用邊緣計(jì)算的東西。第三部分是方案和 OpenYurt 的落地結(jié)合，有哪些要點(diǎn)要去做落實(shí)的。最后一部分是針對(duì)整個(gè)行業(yè)的未來展望，以及社區(qū)未來發(fā)展做一些期許。

邊緣計(jì)算的機(jī)遇與挑戰(zhàn)

伴隨著 5G 的到來以及直播和物聯(lián)網(wǎng)的產(chǎn)生，越來越多的邊緣設(shè)備已經(jīng)被大家所使用，產(chǎn)生的數(shù)據(jù)也非常龐大。比如智能終端的一個(gè) 1080p 的視頻監(jiān)控頭，每分鐘就會(huì)產(chǎn)生 10GB 的數(shù)據(jù)。在一個(gè)中小型城市，這種攝像頭有 100 到 150 萬個(gè)，而且還在不斷增加。在這樣一個(gè)邊緣場(chǎng)景下，它的數(shù)據(jù)應(yīng)用是非常龐大的。

萬物互聯(lián)的時(shí)代，產(chǎn)生了很多智能家居，它們除了簡(jiǎn)單的接入網(wǎng)關(guān)之外，還有很多數(shù)據(jù)需要處理，這部分也是邊緣側(cè)的應(yīng)用場(chǎng)景。

以上都是我們遇到的機(jī)遇，那挑戰(zhàn)是什么？

對(duì)于一些傳統(tǒng)行業(yè)而言，他們的云計(jì)算可能是很小的，比如市面上有很多私有云場(chǎng)景、政府專有云場(chǎng)景，他們不足以做到像大廠商那些云計(jì)算一樣無限的擴(kuò)容來做很多計(jì)算處理。目前的市場(chǎng)環(huán)境下，云和端的環(huán)境非常不理想，主要原因有以下幾個(gè)方面。

第一，因?yàn)槎藗?cè)數(shù)據(jù)采集的設(shè)備普及率較低，導(dǎo)致很多有用的數(shù)據(jù)沒有辦法采集上來供云端的大腦進(jìn)行分析操作。

第二，采集數(shù)據(jù)的維度低、功能單一，會(huì)漏掉一部分有價(jià)值的數(shù)據(jù)。

第三，前端設(shè)備的維保非常難。以攝像頭為例，我們沒辦法對(duì)每一個(gè)攝像頭進(jìn)行嚴(yán)密的監(jiān)控和維護(hù)。出事故以后去追溯問題，可能已經(jīng)過了好幾天了。在這種情況下，這部分?jǐn)?shù)據(jù)就會(huì)丟失。

第四，行業(yè)的數(shù)據(jù)標(biāo)準(zhǔn)不一樣。設(shè)備一直在更新迭代，數(shù)據(jù)的標(biāo)準(zhǔn)也在不斷更新。市面上有很多不同類型的設(shè)備，把這些設(shè)備的數(shù)據(jù)統(tǒng)一集中到云端去做處理，云端的能力也跟不上。

傳統(tǒng)云端的主要瓶頸就是資源和效率問題。一個(gè) 1080p 的攝像頭可能每分鐘就會(huì)產(chǎn)生 10GB 的數(shù)據(jù)，而云端和邊端的帶寬非常有限，僅僅一個(gè)攝像頭可能就會(huì)把整個(gè)網(wǎng)絡(luò)的帶寬占滿，導(dǎo)致別的服務(wù)沒法使用。再一個(gè)是效率限制，很多私有云的能力并不強(qiáng)，對(duì)于數(shù)據(jù)的處理就達(dá)不到理想的效果，也就沒辦法做及時(shí)的響應(yīng)。對(duì)于一些要求低延時(shí)的行業(yè)，這是非常危險(xiǎn)的。

同時(shí)，傳統(tǒng)意義上的端和云鏈路是不可控的，比如端因?yàn)榫W(wǎng)絡(luò)抖動(dòng)和云失去聯(lián)系，云端的指令不能及時(shí)下發(fā)到邊端上，這也會(huì)帶來一定的風(fēng)險(xiǎn)。

再者，傳統(tǒng)上意義上端的設(shè)備更新是很緩慢的，一次性部署以后很長(zhǎng)時(shí)間都不會(huì)有迭代。但是在一些新興行業(yè)的場(chǎng)景下，比如智慧路口，它的 AI 算法是需要不斷地進(jìn)行模型訓(xùn)練的。它們部署下去之后會(huì)采集一些數(shù)據(jù)，這些數(shù)據(jù)上傳到云端之后對(duì)模型進(jìn)行訓(xùn)練，得到一個(gè)更優(yōu)化的版本，然后把這更優(yōu)化的版本再推到端上面去，進(jìn)行更智能化的操作。這部分就是軟件不停更新迭代的過程，這個(gè)也是傳統(tǒng)意義上的云端不能做到的。

深信服智能邊緣平臺(tái)解決方案

針對(duì)以上這些問題，我們給用戶提供了解決方案。先看一下解決方案的整體架構(gòu)。它是從兩個(gè)方面來進(jìn)行的——邊緣側(cè)和中心側(cè)。

首先，我們采取的是云端一體化架構(gòu)。在邊端給用戶部署一個(gè)云邊一體機(jī)，也可以理解成是一個(gè)小型的服務(wù)器，它可以和終端設(shè)備放在同一個(gè)地方。于是他們之間會(huì)整體形成一個(gè)獨(dú)立的小網(wǎng)絡(luò)。這樣邊端的設(shè)備就可以把數(shù)據(jù)發(fā)給云邊一體機(jī)，數(shù)據(jù)就可以得到盡快的處理和響應(yīng)。

其次，即使在云邊斷網(wǎng)的情況下，端側(cè)可以和邊側(cè)一體機(jī)進(jìn)行網(wǎng)絡(luò)訪問，我們可以內(nèi)置一些 AI 算法進(jìn)去，使特定場(chǎng)合下的指令也可以得到響應(yīng)。

最后就是關(guān)于數(shù)據(jù)的處理。云邊側(cè)的網(wǎng)絡(luò)帶寬是有限的，我們可以先將數(shù)據(jù)收集在一體機(jī)里，先做一輪處理，把一些有效的數(shù)據(jù)處理出來。再將這些數(shù)據(jù)通過的 SD-WAN 網(wǎng)絡(luò)匯報(bào)到中心側(cè)進(jìn)行處理，這樣一方面減輕了帶寬的壓力，另一方面提高了中心側(cè)的數(shù)據(jù)處理能力。

云邊斷網(wǎng)情況下的邊緣自治能力其實(shí)是根據(jù)我們和社區(qū)的 OpenYurt 進(jìn)行結(jié)合，將云邊運(yùn)維通道、邊緣端的自治以及單元化部署都有機(jī)結(jié)合到了一起，形成了這樣一個(gè)邊緣計(jì)算的架構(gòu)圖。

云邊一體機(jī)的最終目標(biāo)是為智能化改造打通最后一公里。

它里面提供了很多功能，包括控制面板，AI 算法的平臺(tái)，以及監(jiān)控日志的收集，當(dāng)然還有最重要的安全網(wǎng)絡(luò)管理，以及一些視頻的解碼編碼。同時(shí)這個(gè)盒子也是支持硬件適配的，比如 arm 架構(gòu)、x86 架構(gòu)，還包括不同的網(wǎng)絡(luò) GPU 的配合、底層數(shù)據(jù)操作系統(tǒng)適配。

完成了底層硬件的適配、AI 算法的適配、網(wǎng)絡(luò)設(shè)備和視頻解碼的適配以后，把整體的方案交給用戶，就可以幫助用戶更快地實(shí)現(xiàn)業(yè)務(wù)的容器化部署，這大大提高了產(chǎn)品智能化改造的效率。

技術(shù)方案與 OpenYurt 落地結(jié)合

邊緣計(jì)算比較重要的一個(gè)使用場(chǎng)景就是智慧路口。城市里每個(gè)路口的策略不一樣。比如在一些車流量非常龐大的路口，它的重點(diǎn)更在于流量管控。由于車輛密集，紅綠燈可能來不及做相應(yīng)，就需要通過 AI 算法來支持。

再比如，在人流量非常密集的情況下，一些公安系統(tǒng)重點(diǎn)關(guān)注的有犯罪記錄的人經(jīng)過，這個(gè)時(shí)候要通過 AI 算法的人臉識(shí)別功能來及時(shí)通知周圍民警，提醒他們注意防范。

還有很多的城市道路會(huì)和村道進(jìn)行結(jié)合，這種城鄉(xiāng)結(jié)合道路不光需要流量的管控，還需要交通安全的管控。我們要對(duì) AI 算法植入一些智能語音服務(wù)的喊話系統(tǒng)，結(jié)合動(dòng)態(tài)告警功能，可以避免交通事故的發(fā)生。

以上這些都是智慧路口關(guān)于 AI 算法的接入場(chǎng)景，這些 AI 算法可以根據(jù)不同的區(qū)域范圍來做智能化的注入，這其實(shí)就利用了邊緣計(jì)算 OpenYurt 的單元化管理，我們給它設(shè)置不同的單元化場(chǎng)景，連接到網(wǎng)絡(luò)之后就可以根據(jù)當(dāng)前的這一個(gè)區(qū)域來推送不同的 AI 算法。

說了這么多關(guān)于真實(shí)業(yè)務(wù)落地場(chǎng)景，后面將會(huì)結(jié)合整個(gè)平臺(tái)的架構(gòu)來講解我們的改造思路。

KubeManager（KM）架構(gòu)是我們公司自研的一個(gè)產(chǎn)品， 它是一個(gè)容器管理平臺(tái)，底層是由多個(gè) K8s 集群管理構(gòu)建起來的，集成了多個(gè)應(yīng)用商店和軟件?，還有一些數(shù)據(jù)的采集和監(jiān)控、給用戶的可視化展示。

它主要分為兩個(gè)大的模塊，上圖左下方是管理集群，前文提到的一系列內(nèi)容都是在管理集群里去承接的。用戶集群可以通過接入層來進(jìn)行數(shù)據(jù)接入，然后將 API 的數(shù)據(jù)發(fā)送到 API 業(yè)務(wù)層，再把這些數(shù)據(jù)存儲(chǔ)到原生 K8s 的 etcd 里面去。

我們做改造的部分主要是針對(duì)用戶集群這一塊，跟 OpenYurt 做結(jié)合。在改造落地的過程中也出現(xiàn)了很多問題。

在有多個(gè) master 的情況下，需要與 Tunnel 流量做適配，用戶自己去做適配的過程非常麻煩。所以我們已經(jīng)跟社區(qū)對(duì)接完成，把他們?nèi)咳谌氲狡脚_(tái)的里面去，用戶可以直接使用，不用考慮各種適配的問題。

用戶集群接入到 km 集群之后，需要從 K8s 集群轉(zhuǎn)換成邊緣集群，我們也提供了一個(gè)自動(dòng)化轉(zhuǎn)換。

OpenYurt 是基于原生 K8s 來做的，由于搭建方式不同，在后面的平臺(tái)對(duì)接過程中會(huì)出現(xiàn)一些差異，比如證書的自動(dòng)管控和輪詢操作、下發(fā)，這些都是需要在前期對(duì)接過程中解決，然后才能使用 OpenYurt。

改造之后，用戶集群架構(gòu)就從上圖左邊這切換到了右邊的狀態(tài)。這里面的改造主要有以下幾點(diǎn)：

第一，對(duì) YurtControlManager 組件做了改動(dòng)，以前它是個(gè) deployment，它的副本數(shù)是 1。現(xiàn)在把它改成了 DaemonSet，會(huì)隨著 master 數(shù)量的變化自動(dòng)擴(kuò)縮容，這是一個(gè)。

第二，因?yàn)檎w流量是通過 Nginx 找不同的 APS server 做代理，所以 YurtHub 其實(shí)不是直接訪問 APIserver，而是通過 Nginx。但它現(xiàn)在這樣也可以達(dá)到邊緣集群和 OpenYurt 的結(jié)合之后想要的效果——比如流量過濾和邊緣自治。

行業(yè)未來展望以及社區(qū)發(fā)展期許

最后說一下關(guān)于整個(gè)行業(yè)的發(fā)展和未來的期望。

從上圖可以看到，邊緣設(shè)備的成長(zhǎng)是一個(gè)不斷累積的過程。整個(gè)行業(yè)的發(fā)展對(duì)邊緣設(shè)備會(huì)有非常多的需求，這么大的需求會(huì)帶動(dòng)整個(gè)行業(yè)的發(fā)展，行業(yè)的發(fā)展也離不開邊緣社區(qū)，包括 OpenYurt 社區(qū)的貢獻(xiàn)。希望每一個(gè)用戶在使用 OpenYurt 的時(shí)候可以更加邊緣化、安全化和智能化。

如果您有興趣也可以釘釘搜索群號(hào)：31993519，加入 OpenYurt 項(xiàng)目釘釘群。

戳??此處??，立即了解 OpenYurt 項(xiàng)目！

總結(jié)

以上是生活随笔為你收集整理的深信服智能边缘计算平台与 OpenYurt 落地方案探索与实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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