OpenYurt 如何 「0 侵入」 攻破雲邊融合難點

做者 | 何淋波
來源|阿里巴巴雲原生公衆號

隨着 5G、IoT、直播、CDN 等行業和業務的發展，愈來愈多的算力和業務開始下沉到距離數據源或者終端用戶更近的位置，以期得到很好的響應時間和成本，這是一種明顯區別於傳統中心模式的計算方式——邊緣計算。

然而，在邊緣計算的規模、複雜度正逐日攀升的同時，短缺的運維手段和運維能力也終於開始不堪重負。在這個背景下，「雲、邊、端一體化運維協同」已經開始成爲一種架構共識。經過雲原生加持，雲邊融合的進程也正在被急劇加速。在這樣的趨勢下，引入雲原生理念、全面轉型邊緣應用的運維管理模式成爲亟需解決的問題。

本文整理自做者阿里雲容器服務技術專家，OpenYurt 做者 & 初創人員之一何淋波（新勝）於 1 月 26 日在阿里雲開發者社區「週二開源日」的直播分享，將站在實際落地場景的角度，探索雲原生技術和邊緣計算的融合挑戰，詳細介紹基於 OpenYurt 的雲原生邊緣計算平臺架構和行業實踐。

點擊回看完整視頻：https://developer.aliyun.com/live/246066

什麼是邊緣計算（Edge Computing)

邊緣計算是相對傳統集中通用計算而言，指將工做負載部署在邊緣的一種計算方式。最近幾年，邊緣計算很是火熱，主要是由於 5G、IoT 等業務和場景發展愈來愈快，包括智能終端設備愈來愈多，形成對邊緣計算業務的下沉訴求愈來愈多。若是全部的處理所有放在中心，很難知足大規模邊緣智能設備的增加。邊緣計算目前在各行各業都開始大規模使用，例如汽車、運輸、能源等。總結來講，邊緣計算就是讓計算離用戶或者離數據源更近。

1. 邊緣計算頂層架構

業界定義的邊緣計算的分層結構，主要引用 Gartner、IDC。

Gartner 定義的分層結構以下圖所示：Endpoint > Near edge > Far edge > Cloud > Enterprise。

• Near Edge ：非標準服務器或設備，在距離端側最近的地方。

• Far Edge ：標準的 IDC，能夠分三種類型：IDC（爲主）、MEC、CDN 等；相對來講，計算能力比較強，好比運營商的機房、雲服務提供商的級聯機房等等。

• Cloud ：公共雲或專有元服務，特徵爲資源集中、中心化管理。

IDC 定義的分層結構以下圖所示：

• Heavy Edge：數據中心維度；集中式計算平臺；CDN，自建 IDC。

• Light Edge：低功耗計算平臺，適用於工業控制，數據處理、傳輸等物聯網場景。

  由上圖能夠看出，Gartner 定義與 IDC 定義實際上是相互依存，相互關聯的。另外，邊緣計算與雲計算不是替代關係，而是相互補充、相互關聯的關係。

2. 邊緣計算行業趨勢

邊緣計算行業趨勢能夠從如下三個方面（維度）來說：第一是行業的業務，第二是行業的架構，第三是行業的規模與變化。

趨勢一：AI 、IoT 與邊緣計算的融合

近幾年來，邊緣計算和 AI、IoT 的結合很是多，邊緣智能設備的數量增長以後，包括全部的數據或視頻所有回傳到雲端去處理，整個成本與效率都很是不合適，因此直接靠近設備這一側進行 AI 處理或 IoT 處理的需求愈來愈多。好比 AI，會在雲上或在中心雲作訓練，而後在邊緣作推理，有很是多這種形式。調查顯示：

• 到 2024  年，有 50%  的計算機視覺和語音識別模型將在邊緣運行。

• 到 2023 年，近 20% 用於處理 AI 工做負載的服務器部署在邊緣側。

• 到 2023 年，中國 70 ％ 的物聯網項目將包含 AI 功能，追求實時性、下降帶寬、數據合規。

• 到 2023 年，中國 75 ％ 的企業將在網絡邊緣對物聯網數據進行處理。

趨勢二：雲延伸，IT 去中心化，設施自治，邊緣託管

邊緣計算跟雲計算是相互補充、相互依賴的關係。再延伸一步說，邊緣計算實際上是雲計算往邊緣的一個延伸，把雲上的一些能力往邊緣上延伸。一是要求 IT業務在邊緣這一側去中心化，另外由於邊緣業務或設施是自治的，雲和邊之間網絡斷開的狀況下，有必定控制能力，再有邊緣託管能力。將來架構趨勢將向雲延伸、IT 中心化、設施自治、邊緣託管的發展路線演進：

• 混合雲 - 到 2023 年， 10% 的企業負載將運行位於本地數據中心和邊緣資源上。

• 去中心化 - 到 2023 年，超過 30% 新基礎架構將部署在邊緣位置。

• 設施自治 - 到 2024 年，50% 核心企業數據中心和 75% 主要邊緣 IT 站點將改變運維方式。

• 邊緣託管 - 到 2022 年，50% 的公司將依靠託管服務來提升基於邊緣人工智能的性能和投資回報率。

趨勢三：5G 與邊緣計算引爆新增加

最近幾年，5G 的快速發展，對邊緣計算是一個新的增加引爆點。預計到 2024 年,邊緣應用程序的數量將增加 800% ，能夠想象這個行業後面會是什麼樣的增加狀況。典型應用場景將包括車聯網（自動駕駛/車路協同）、智能電網（設備巡檢/精準負荷控制）、工業生產控制、智慧醫療（遠程B超/遠程會診）等。

3. 邊緣計算現狀

邊緣雲促使管理的複雜性迅速上升

隨着邊緣計算的形態、規模、複雜度的日益增加，邊緣計算領域的運維手段、運維能力愈來愈難以知足邊緣業務的創新速度；而「將來企業都在全力追求超規模、超高速、超鏈接」，又進一步加重運維管理的複雜度。邊緣雲促使管理的複雜性迅速上升，主要來自如下四個方面：

• 第一，互聯網智能終端設備數量的急劇增長；數據、業務下沉的訴求增多。

• 第二，邊緣計算規模和業務複雜度提高，邊緣智能、邊緣實時計算、邊緣分析等新型業務不斷涌現。傳統雲計算中心集中存儲、計算的模式已經沒法知足邊緣設備對於時效、容量、算力的需求。

• 第三，雲邊端協同難度大，缺乏統一的交付、運維、管控標準，且邊緣服務和邊緣數據的安全風險控制難度較高。

• 第四，異構資源支持困難，對不一樣硬件架構、硬件規格、通訊協議的支持，以及基於異構資源、網絡、規模等差別化提供標準統一的服務能力的挑戰。

雲邊一體的邊緣雲原生

1. 什麼是雲原生？

雲原生的定義：雲原⽣是一套開放、標準的技術體系。基於雲原生技術體系，能夠爲用戶敏捷的構建和運行高彈性、容錯性好、易於管理的一套業務系統。整個技術體系有不少熱門技術，如 Cloud Native、Serverless、Kubernetes、Container、Docker 等等，業界普遍使用的這些技術。

如今各大雲廠商、雲服務提供商都在大力投入雲原生，雲原生也愈來愈成爲廣大用戶使用雲計算能力的入口。雲原生技術體系可以幫助企業最大化利⽤雲的能⼒，最大化發揮雲的價值。

2. 豐富的雲原生產品家族

以阿里云爲例，雲原生產品家族主要分三塊，以下圖所示：

• 第一塊是新的應用負載，包括：數據&智能、分佈式應用、DevOps，如今都是經過雲原生承載業務。

• 第二塊包括：Serverless、容器編排，是一個新的業務系統。

• 第三塊包括：公共雲、專有云、邊緣雲是一個新的資源承載系統。

3. 雲邊一體雲原生基礎設施

雲邊一體雲原生基礎設施，是在雲端作管控、邊緣自治的雲原生系統。以下圖所示：

在中心這一側，能夠提供原生的雲中心的管控能力和產品化能力，例如利用 Kubernetes+存儲/+AI/+大數據等能力能夠在中心提供出來；中心的這些能力經過管控通道，下沉到邊緣計算，好比標準化的 CDN、 Infrastructure 、Edge、ENS，或者是上圖右邊的智慧工廠、智慧園區、樓宇、機場等等的設備網關；在邊緣，能夠就近接入各類設備，好比傳感器、視頻、控制器等等，能夠支持各類通信設備接入。這樣便造成了雲邊端一體化的雲原生基礎設施。

雲計算擅長鬚要海量可擴展存儲能力，非實時且週期相對較長的數據處理和分析，而邊緣計算脫胎於雲計算，它擅長的是局部短週期數據的實時處理和分析，雲計算與邊緣計算之間不是替代關係，而是互相協同的關係，兩者之間緊密結合才能更好地知足各類需求場景的匹配。

4. 雲邊一體價值

雲原生的概念最先是在 2013 年被提出，通過這幾年的發展，尤爲是從 2015 年 Google 牽頭成立 CNCF 以來，雲原生技術開始進入公衆的視線並逐漸演變成包括 DevOps、持續交付、微服務、容器、基礎設施，Serverless，FaaS 等一系列的技術，實踐和方法論集合。雲原生加速了多雲、雲邊融合，雲邊一體的價值是：

• 一是能夠爲用戶在任何基礎設施上提供和雲上一致的功能和體驗，實現雲邊端一體化的應用。

• 二是能夠利用容器的隔離性，利用系統的流量控制、網絡策略等能力，保證運行在邊緣上業務的安全性。

• 三是經過容器化，經過容器和資源之間的解耦，對異構資源的支持上可以有很好的適配。

5. 雲原生與邊緣計算融合難點

隨着邊緣計算的形態、規模、複雜度的日益增加，邊緣計算領域的運維手段、運維能力愈來愈難以知足邊緣業務的創新速度；而將來企業都在全力追求「超規模、超高速、超鏈接」，又進一步加重運維管理的複雜度。

雲原生與邊緣計算融合要解決什麼問題？在實際的解決問題的過程當中，總結出如下 4 個關鍵點：

第一點：邊緣計算規模和業務複雜，邊緣資源的分散在不一樣地域，各個區域內部的邊緣應用的生命週期管理，升級，擴縮容，區域內部流量閉環都面臨挑戰。

舉個例子，好比 CDN 場景，全國各地可能有成百上千個機房，每一個機房的資源或者機器可能都不同，機器上面運行的業務承載的流量可能也不太同樣。這時若是是用原生 Kubernetes 的 workload 來管理是很是不足的，會造成很是大的挑戰，容易出錯，整個運維效率很是低。

第二點：雲邊網絡鏈接不可靠。一般狀況下，雲和邊之間會經過公網鏈接，在一些客觀因素的影響下，雲邊之間的網絡可能出現斷聯，對邊緣業務的持續運行造成很大挑戰。由於網絡斷開的狀況下，節點會脫離雲端管控，在原生K8s下會對該Pod進行驅逐。但實際狀況下不管是業務重啓仍是機器重啓，都須要保證邊緣業務能夠持續運行。所以邊緣須要必定的自治能力。

第三點：雲邊端運維協同難度大，因爲邊緣的機器是部署用戶防火牆內部的，公網沒法主動鏈接。所以，一些須要從中心拉取數據的K8s原生運維能力就沒法使用，造少缺乏統一的交付、運維、管控標準，且邊緣服務和邊緣數據的安全風險控制難度較高。

第四點：異構資源支持困難，對不一樣硬件架構、硬件規格、通訊協議的支持，以及基於異構資源、網絡、規模等差別化提供標準統一力的挑戰。

OpenYurt 邊緣計算雲原平生臺

CNCF 邊緣雲項目 OpenYurt：延伸原生 Kubernetes 到邊緣計算的智能開放平臺。

1. 邊緣自治、中心（雲）管控

OpenYurt 架構是很是簡潔的雲邊的一體化的架構，如上圖所示，雲上有藍色和橙色兩部分，藍色部分是原生 K8s 的一些組件，而後橙色部分是 OpenYurt 的組件；邊緣的每一個節點上，Edge Note 上每一個節點上也有藍色的部分和橙色的部分,藍色部分也是原生的 K8s 的組件，或者設置的一些雲原生的一些組件，橙色部分是 OpenYurt 的組件。

你們能看到 OpenYurt 對 K8s 或者對雲原生的這種原生的架構是 0 修改、非侵入式的，OpenYurt 項目是業界首個非侵入式加強 K8s 的一個邊緣計算雲原平生臺。其餘的邊緣計算雲原生項目，或多或少可能都對 K8s 作了必定的修改或者裁剪，這也是 OpenYurt 最大的區別，所以也就保證了 OpenYurt 的標準化。

• OpenYurt 能夠緊跟 Kubernetes 版本升級節奏。

• 非侵入式的理念，OpenYurt 與雲原生主流技術，如 ServeiceMesh、Serverless 等，能夠同步衍進。

OpenYurt 在 2020 年 9 月份進入 CNCF sandbox，是一個很是中立的項目，一是技術、架構上的中立，二是這個項目運營上的中立。

OpenYurt 的品質和穩定性也是有保障的，在阿里集團內部，使用很是普遍，已經管理數百萬核的規模。

2. OpenYurt 如何解決原生與邊緣計算融合難點

• 第一，邊緣單元化。大規模業務下，由於邊緣單元分比較分散，所以經過邊緣單元化，對單元內業務進行一個單元化的管理以及流量閉環的管理。

• 第二，邊緣自治能力。爲了應對雲邊網絡不可靠，經過給邊緣增長一個自治的能力，雲邊網絡斷開的狀況下，也能夠保證的業務能夠持續運行。

• 第三，無縫轉換。主要是爲了下降 OpenYurt 的使用門檻，經過提供一個無縫轉換的能力，使 K8s 與 OpenYurt 集羣之間能夠一鍵式切換，一條命令能夠把一個標準的 K8s 集羣轉換成 OpenYurt 集羣，反向切換也能夠，這也是業界獨創的能力。

• 第四：是解決雲端訪問主動訪問邊緣的問題，提供了雲邊協同的能力來解決運維的難題。

下面，針對每個能力具體介紹。

1）單元化能力

提供邊緣場景下應用模型能力，主要包括如下三點：

• NodePool 能夠對節點作單元化批量管理。

• 流量管理支持原生 service 的流量拓撲管理。

• UnitedDeployment 提供原生 APPs 模型單元化部署。

單元化主要是提供邊緣場景下應用模型的能力，在資源這塊提節點池，能夠對每個地域的一個節點，進行一個池化的管理，如上圖邊緣單元一，假如是北京的一個機房，這些節點均可以放到北京池裏面，能夠對這些節點進行一個批量化的標籤等功能統一的管理，這樣就相同的一批機器總體特性管理操做起來就很是方便。UnitedDeployment 這個資源是基於節點池，以節點池爲單元，對節點池的業務進行部署管理。

根據上圖舉例，單元一部署兩個實例，單元二部署三個實例，把配置提交給 OpenYurt 集羣以後，就能夠自動把部署信息下發到邊緣，而後能夠啓動相對應的實例數，這就解決了單元管理的時每一個單元獨立去操做的問題，經過一個統一的視角，UnitedDeployment 能夠管理各個單元。

2）邊緣自治能力

爲邊緣業務持續運行護航，具體包括如下兩點：

• YurtHub 緩存雲端的數據，雲邊斷網時，全部系統組件均從 YurtHub 獲取數據。

• Yurt-Controller-Manager 解決雲邊網絡鏈接不穩定時形成的邊緣業務驅逐問題。

邊緣自治能力爲邊緣業務持續運行護航，在雲邊網絡斷聯的狀況下，也能夠保證邊緣業務持續運行。主要涉及到兩個組件，一個是 YurtHub，一個是 Yurt-Controller-Manager。

YurtHub 是部署在邊緣節點上，每一個節點上以容器化的形式部署的一個組件， 經過上圖，瞭解處理流程，從請求 Kubelet、KubeProxy、Flannel 這種原生組件，以前都是直接連的雲端 APIServer，如今調整爲先連 YurtHub 再把請求轉發給 APIServer。

這樣的優勢就是當請求過來以後，雲邊網絡沒有斷開的狀況下，有一個 health check 模塊，會檢測雲邊網絡的連通性，若是雲邊網絡正常，請求就直接到負載均衡模塊，而後選擇一個雲端服務器轉發過去，結果返回，一個是能夠返回一個請求端，另一個結果數據緩存在本地磁盤，持續化在本地磁盤。

若是雲邊網絡斷開了，節點要重啓，網絡斷開的狀況下，它能夠經過 local proxy 把本地緩實際化的數據提取出來，返回一個請求方，從而恢復邊緣的業務，保證邊緣業務的一個持續運行。

3）無縫轉換能力

無縫轉換能力是用 yurtctlconvert 組件完成。主要用於標準 K8s 和 OpenYurt 集羣之間的一鍵式轉換；目前支持 minikube，kubeadm，ack 等工具部署的集羣。

當轉換的狀況下，由於集羣裏面有不少節點，每一個節點要轉成邊緣節點，就往邊緣上部一些 yurthub static pod 組件，kubelet 參數修改等。以下圖所示：

經過阿里另一個雲原生開源項目 OpenKruise 的 broadcastJob，能夠保證在每一個節點上運行 pod 這樣一個 job，來完成每一個節點到節點的轉換。目前咱們 Yurtctl 工具，在 minikube，kubeadm，ACK 等工具部署的集羣上，進行了比較完整的驗證，後續會支持更多類型的集羣，也歡迎更多感興趣的同窗在社區作貢獻。

4）雲邊協同能力

以下圖所示：

在雲端部署 YurttunnelServer 組件，邊緣每一個節點會部署一個 Yurttunnel Agent，Yurttunnel Agent 啓動時由裏面的 ANP Proxy Agent 模塊，經過公網雲端與 ANP Proxy server 模塊創建雙向認證的加密通道。這個通道是 gRPC 協議來作的。

通道創建以後，雲端訪問節點的時候，Yurttunnel Server 裏面的 iptable manager 會把節點訪問的請求流量導入到 Yurttunnel Server 上，request Interceptor 攔截器模塊會把請求攔截過來，要轉化成 gRPC 通訊協議格式，而後把這個請求轉發給邊緣端的 TunnelAgent，TunnelAgent 再把請求轉發給 Kubelet 或者 pod。這樣的話，就打通了雲邊運維協同能力。使原生的 Kubernetes 運維操做能力，均可以無感知地運行在 OpenYurt 集羣或雲邊場景上。另外雲邊運維通道基於 gRPC 種協議，經過壓縮 Tunnel 帶寬能夠大大下降成本，相比原生 TCP 通訊最大減小 40% 流量。

OpenYurt 案例介紹

案例一：邊緣 AI

第一個案例是邊緣 AI 場景，這個是盒馬鮮生的新零售線下業務。

盒馬鮮生基於阿里雲容器服務 ACK@Edge 產品爲底座，進行了雲原生的轉型升級，構建了一個「人貨場」數字化全鏈路的雲、邊、端一體化協同的天眼 AI 系統。首先在雲上有一個雲端的控制面，而後在邊緣離門店比較近的區域，購買了 ENS 節點服務，這樣就不用本身爲門店構建機房，而後經過雲邊一體系統把門禁控制系統或者建模系統，部署到邊緣的 ENS 服務上，以後跟門店裏面的監控視頻流推送，而後業務承載以後進行分析，獲得結果，在控制業務系統這邊，把計算的結果返回到雲端作分析。

基公雲於雲+邊緣的形式，低成本的實現了雲端天眼系統、阿里雲邊緣匯聚節點 ENS、盒馬門店物理場的業務架構，具有強大的彈性能力、混合資源管理能力、以及雲原生的運維能力。實現新門店開服效率提高 70%，和 50% 以上的資源成本節省；共享算力。以下圖所示：

案例二：視頻上雲

視頻上雲案例，如今全國各地用的特別多，如圖所示：

從下往上看，好比在高速上，輕量型網關或標準型網關，會有一些視頻拍攝流，把這些視頻拍好以後，傳到離邊緣比較近的 ENS 或 CDN 服務器上，作視頻監控，好比一些省級、市縣級的機房裏面處理，作視頻管理、匯聚轉發等處理以後，把最後結果再上傳到中心雲上的雲控平臺。而後在雲控平臺能夠作不少處理，好比能夠跟高德地圖來作一些事件的發佈，或信息通知等等，造成雲邊端一體化的服務管理平臺。

經過雲邊端一體化的服務管理平臺包括：應用部署/配置、設備/應用狀態、結構化數據上雲的實現，使整個運維效率、管控效率都大大提高。

以上就是本次關於 OpenYurt 的分享，若是你們對 OpenYurt 感興趣，歡迎掃碼加入咱們的社區交流羣，以及訪問 OpenYurt 官網和 GitHub 項目地址：

• OpenYurt 官網：
  https://openyurt.io

• GitHub 項目地址：
  https://github.com/openyurtio/openyurt