作者：趙震，深信服云計算開發工程師，OpenYurt 社區 Member

編者案：在 5G、物聯網等新技術的持續推動下，邊緣計算產業已然走向大風口，未來越來越多的種類，越來越大的規模和越來越復雜的應用和工作負載都會被部署到邊緣側。本文基于深信服云計算工程師趙震在由 CNCF 和阿里云聯合舉辦的云原生容器領域開發者沙龍 KubeMeet 中的分享整理，介紹了邊緣計算落地的機遇與挑戰，以及邊緣容器開源項目 OpenYurt 在企業生產環境下的實踐方案。

本次分享是偏重于實踐的案例，主要是關于 OpenYurt 產品在真實落地情況下的方案是怎么部署的。

主要從 4 個方面來進行，首先是關于邊緣計算遇到的機遇和挑戰都有哪些，第二部分就是深信服平臺針對這些挑戰做了哪些解決方案，可以讓用戶更好地使用邊緣計算的東西。第三部分是方案和 OpenYurt 的落地結合，有哪些要點要去做落實的。最后一部分是針對整個行業的未來展望，以及社區未來發展做一些期許。

邊緣計算的機遇與挑戰

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

萬物互聯的時代，產生了很多智能家居，它們除了簡單的接入網關之外，還有很多數據需要處理，這部分也是邊緣側的應用場景。

以上都是我們遇到的機遇，那挑戰是什么？

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

第一，因為端側數據采集的設備普及率較低，導致很多有用的數據沒有辦法采集上來供云端的大腦進行分析操作。

第二，采集數據的維度低、功能單一，會漏掉一部分有價值的數據。

第三，前端設備的維保非常難。以攝像頭為例，我們沒辦法對每一個攝像頭進行嚴密的監控和維護。出事故以后去追溯問題，可能已經過了好幾天了。在這種情況下，這部分數據就會丟失。

第四，行業的數據標準不一樣。設備一直在更新迭代，數據的標準也在不斷更新。市面上有很多不同類型的設備，把這些設備的數據統一集中到云端去做處理，云端的能力也跟不上。

傳統云端的主要瓶頸就是資源和效率問題。一個 1080p 的攝像頭可能每分鐘就會產生 10GB 的數據，而云端和邊端的帶寬非常有限，僅僅一個攝像頭可能就會把整個網絡的帶寬占滿，導致別的服務沒法使用。再一個是效率限制，很多私有云的能力并不強，對于數據的處理就達不到理想的效果，也就沒辦法做及時的響應。對于一些要求低延時的行業，這是非常危險的。

同時，傳統意義上的端和云鏈路是不可控的，比如端因為網絡抖動和云失去聯系，云端的指令不能及時下發到邊端上，這也會帶來一定的風險。

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

深信服智能邊緣平臺解決方案

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

首先，我們采取的是云端一體化架構。在邊端給用戶部署一個云邊一體機，也可以理解成是一個小型的服務器，它可以和終端設備放在同一個地方。于是他們之間會整體形成一個獨立的小網絡。這樣邊端的設備就可以把數據發給云邊一體機，數據就可以得到盡快的處理和響應。

其次，即使在云邊斷網的情況下，端側可以和邊側一體機進行網絡訪問，我們可以內置一些 AI 算法進去，使特定場合下的指令也可以得到響應。

最后就是關于數據的處理。云邊側的網絡帶寬是有限的，我們可以先將數據收集在一體機里，先做一輪處理，把一些有效的數據處理出來。再將這些數據通過的 SD-WAN 網絡匯報到中心側進行處理，這樣一方面減輕了帶寬的壓力，另一方面提高了中心側的數據處理能力。

云邊斷網情況下的邊緣自治能力其實是根據我們和社區的 OpenYurt 進行結合，將云邊運維通道、邊緣端的自治以及單元化部署都有機結合到了一起，形成了這樣一個邊緣計算的架構圖。

云邊一體機的最終目標是為智能化改造打通最后一公里。

它里面提供了很多功能，包括控制面板，AI 算法的平臺，以及監控日志的收集，當然還有最重要的安全網絡管理，以及一些視頻的解碼編碼。同時這個盒子也是支持硬件適配的，比如 arm 架構、x86 架構，還包括不同的網絡 GPU 的配合、底層數據操作系統適配。

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

技術方案與 OpenYurt 落地結合

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

再比如，在人流量非常密集的情況下，一些公安系統重點關注的有犯罪記錄的人經過，這個時候要通過 AI 算法的人臉識別功能來及時通知周圍民警，提醒他們注意防范。

還有很多的城市道路會和村道進行結合，這種城鄉結合道路不光需要流量的管控，還需要交通安全的管控。我們要對 AI 算法植入一些智能語音服務的喊話系統，結合動態告警功能，可以避免交通事故的發生。

以上這些都是智慧路口關于 AI 算法的接入場景，這些 AI 算法可以根據不同的區域范圍來做智能化的注入，這其實就利用了邊緣計算 OpenYurt 的單元化管理，我們給它設置不同的單元化場景，連接到網絡之后就可以根據當前的這一個區域來推送不同的 AI 算法。

說了這么多關于真實業務落地場景，后面將會結合整個平臺的架構來講解我們的改造思路。

KubeManager（KM）架構是我們公司自研的一個產品， 它是一個容器管理平臺，底層是由多個 K8s 集群管理構建起來的，集成了多個應用商店和軟件?，還有一些數據的采集和監控、給用戶的可視化展示。

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

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

在有多個 master 的情況下，需要與 Tunnel 流量做適配，用戶自己去做適配的過程非常麻煩。所以我們已經跟社區對接完成，把他們全部融入到平臺的里面去，用戶可以直接使用，不用考慮各種適配的問題。

用戶集群接入到 km 集群之后，需要從 K8s 集群轉換成邊緣集群，我們也提供了一個自動化轉換。

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

改造之后，用戶集群架構就從上圖左邊這切換到了右邊的狀態。這里面的改造主要有以下幾點：

第一，對 YurtControlManager 組件做了改動，以前它是個 deployment，它的副本數是 1。現在把它改成了 DaemonSet，會隨著 master 數量的變化自動擴縮容，這是一個。

第二，因為整體流量是通過 Nginx 找不同的 APS server 做代理，所以 YurtHub 其實不是直接訪問 APIserver，而是通過 Nginx。但它現在這樣也可以達到邊緣集群和 OpenYurt 的結合之后想要的效果——比如流量過濾和邊緣自治。

行業未來展望以及社區發展期許

最后說一下關于整個行業的發展和未來的期望。

從上圖可以看到，邊緣設備的成長是一個不斷累積的過程。整個行業的發展對邊緣設備會有非常多的需求，這么大的需求會帶動整個行業的發展，行業的發展也離不開邊緣社區，包括 OpenYurt 社區的貢獻。希望每一個用戶在使用 OpenYurt 的時候可以更加邊緣化、安全化和智能化。

如果您有興趣也可以釘釘搜索群號：31993519，加入 OpenYurt 項目釘釘群。

戳??此處??，立即了解 OpenYurt 項目！

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。