作者：趙震，深信服雲端計算開發工程師，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 專案！