云計算發(fā)展史，就是虛擬化技術(shù)的發(fā)展史。近 20 年來云計算與互聯(lián)網(wǎng)相互促進高速發(fā)展，中心云技術(shù)成為全社會通用的基礎設施。隨著物聯(lián)網(wǎng)、人工智能等技術(shù)的不斷發(fā)展，尤其是產(chǎn)業(yè)互聯(lián)網(wǎng)發(fā)展落地，中心云計算開始相形見絀，分散式邊緣計算在當下被重新寄予厚望。如果中心云計算是由技術(shù)創(chuàng)新驅(qū)動的，那么邊緣計算一定是業(yè)務價值驅(qū)動的。

那到底什么是邊緣計算?邊緣計算有哪些分類?邊緣計算與中心云的關(guān)系是什么?本文將抽絲剝繭，深入淺出，詳細闡述對邊緣計算與云原生的理解與思考。

一、 邊緣計算的理解與思考

1. 邊緣計算的定義

邊緣計算當前沒有準確定義，從 IT 云計算領(lǐng)域視角，邊緣計算被看作中心云計算的拓展。邊緣計算產(chǎn)業(yè)聯(lián)盟對邊緣計算的定義：“在靠近物或數(shù)據(jù)源頭的網(wǎng)絡邊緣側(cè)，融合網(wǎng)絡、計算、存儲、應用核心能力的開放平臺，就近提供邊緣智能服務，滿足行業(yè)數(shù)字化在敏捷連接、實時業(yè)務、數(shù)據(jù)優(yōu)化、應用智能、安全與隱私保護等方面的關(guān)鍵需求”。從 CT 電信領(lǐng)域視角，邊緣計算最初也被稱為移動邊緣計算(MEC)。歐洲電信標準協(xié)會(ETSI)對 MEC 的定義：“移動邊緣計算在移動網(wǎng)絡的邊緣、無線接入網(wǎng)(RAN)的內(nèi)部以及移動用戶的近處提供了一個 IT 服務環(huán)境以及云計算能力”。

邊緣計算的定義各有側(cè)重，但核心思想基本一致——邊緣計算是基于云計算核心技術(shù)，構(gòu)建在邊緣基礎設施之上的新型分布式計算形式，在邊緣端靠近最終用戶提供計算能力，是一種靠近數(shù)據(jù)源的現(xiàn)場云計算。

中心云計算憑借其強大的數(shù)據(jù)中心，為業(yè)務應用提供大規(guī)模池化，彈性擴展的計算、存儲、網(wǎng)絡等基礎設施服務，更適用于非實時、長周期數(shù)據(jù)、業(yè)務決策場景;邊緣計算則聚焦在實時性、短周期數(shù)據(jù)、本地決策等業(yè)務場景，比如當下熱門的音視頻直播、IoT、產(chǎn)業(yè)互聯(lián)網(wǎng)、虛擬現(xiàn)實甚至元宇宙等，將工作負載下沉至離終端設備或者靠近最終用戶的地方，以此實現(xiàn)更低的網(wǎng)絡延遲，提升用戶的使用體驗。

2. “章魚式”邊緣計算

邊緣是相對中心式計算的邊緣分散式計算。邊緣計算的核心目標是快速決策，將中心云的計算能力拓展至“最后一公里”。因此它不能獨立于中心云，而是在云-邊-端的整體架構(gòu)之下，有中心式管控決策，也有分散式邊緣自主決策，即章魚式邊緣計算。

如上圖漫畫中所示，章魚全身神經(jīng)元中心式腦部占 40%，其余 60% 在分散式腿部，形成 1 個大腦總控協(xié)調(diào) + N 個小腦分散執(zhí)行的結(jié)構(gòu)。1 個大腦擅長全局調(diào)度，進行非實時、長周期的大數(shù)據(jù)處理與分析;N 個小腦側(cè)重局部、小規(guī)模數(shù)據(jù)處理，適用于現(xiàn)場級、實時、短周期的智能分析與快速決策。

章魚式邊緣計算采用中心云+邊緣計算的分布式云邊一體化架構(gòu)，海量終端采集到數(shù)據(jù)后，在邊緣完成小規(guī)模局部數(shù)據(jù)的實時決策處理，而復雜大規(guī)模的全局性決策處理則匯總至中心云深入分析處理。

3. 邊緣計算的位置

邊緣計算位于中心云及終端之間，將云計算能力由中心下沉到邊緣，通過云邊協(xié)同的架構(gòu)解決特定的業(yè)務需求，能最大程度降低傳輸時延，這也是邊緣計算的核心價值。但中心云與終端之間的網(wǎng)絡傳輸路徑經(jīng)由接入網(wǎng)(距離 30 公里，延遲 5 到10 毫秒)，匯聚網(wǎng)，城際網(wǎng)(距離 50 到 100 公里，延遲 15 到 30 毫秒)到骨干網(wǎng)(距離 200 公里，延遲 50 毫秒)，最后才到數(shù)據(jù)中心(假定數(shù)據(jù)中心 IDC 都在骨干網(wǎng))，耗時數(shù)據(jù)是正常網(wǎng)絡擁塞的撥測統(tǒng)計值，即業(yè)務側(cè)感知的實際延遲數(shù)據(jù)，雖不是非常精確，但足夠輔助架構(gòu)決策。

云計算能力由中心逐步下沉到邊緣，節(jié)點數(shù)量增多，覆蓋范圍縮小，運維服務成本快速增加。根據(jù)國內(nèi)網(wǎng)絡(國內(nèi)有多張骨干網(wǎng)，分別是電信 CHINANET 與 CN2，聯(lián)通 CNCNET 以及移動 CMNET)現(xiàn)狀，骨干網(wǎng)節(jié)點，城際網(wǎng)節(jié)點，匯聚網(wǎng)節(jié)點，接入網(wǎng)節(jié)點，以及數(shù)以萬計的業(yè)務現(xiàn)場計算節(jié)點都可以安置邊緣計算，因此范圍太廣難以形成統(tǒng)一標準。因此我們說中心云計算由技術(shù)定義，邊緣計算由網(wǎng)絡與業(yè)務需求定義。

邊緣計算生態(tài)參與者眾多，云廠商、設備廠商、運營商三大關(guān)鍵服務商方以及一些新型 AI 服務商等，都是從各自現(xiàn)有優(yōu)勢延伸，拓展更多客戶及市場空間。設備商借助物聯(lián)網(wǎng)逐漸構(gòu)建單一功能的專業(yè)云;云廠商從中心化的公有云開始下沉，走向分布式區(qū)域云，區(qū)域云之間通過云聯(lián)網(wǎng)打通，形成一個覆蓋更大的云。運營商在互聯(lián)網(wǎng)時代被公有云及繁榮的移動應用完全屏蔽只能充當管道，但在邊緣計算時代，業(yè)務及網(wǎng)絡定義邊緣計算，運營商重新回歸焦點，不可替代。

4. 邊緣計算的類型

(1)網(wǎng)絡定義的邊緣計算：

通過優(yōu)化終端與云中心網(wǎng)絡路徑，將中心云能力逐漸下沉至靠近終端，實現(xiàn)業(yè)務就近接入訪問。從中心到邊緣依次分為區(qū)域云/中心云，邊緣云/邊緣計算，邊緣計算/本地計算三大類型：

• 區(qū)域云/中心云：將中心云計算的服務在骨干網(wǎng)拓展延伸，將中心化云能力拓展至區(qū)域，實現(xiàn)區(qū)域全覆蓋，解決在骨干網(wǎng)上耗時，將網(wǎng)絡延遲優(yōu)化至 30ms 左右，但邏輯上仍是中心云服務。
• 邊緣云/邊緣計算：將中心云計算的服務沿著運營商的網(wǎng)絡節(jié)點延伸，構(gòu)建中小規(guī)模云服務或類云服務能力，將網(wǎng)絡延遲優(yōu)化至 15ms 左右，比如多接入邊緣計算(MEC)、CDN。
• 邊緣計算/本地計算：主要是接近終端的現(xiàn)場設備及服務能力，將終端部分邏輯剝離出來，實現(xiàn)邊緣自主的智能服務，由云端控制邊緣的資源調(diào)度、應用管理與業(yè)務編排等能力，將網(wǎng)絡延遲優(yōu)化至 5ms 左右，比如多功能一體機、智能路由器等。

總的來說，基于網(wǎng)絡定義的邊緣計算，更多是面向消費互聯(lián)業(yè)務及新型 2C 業(yè)務，將云中心的能力及數(shù)據(jù)提前下沉至邊緣，除了經(jīng)典的 CDN，視頻語音業(yè)務外，還有今年大火的元宇宙等。

當前大部分面向消費互聯(lián)業(yè)務都是通過安置在骨干網(wǎng)的中心云計算能力支持，時延在 30ms 到 50ms，遠小于本身云端后端業(yè)務處理的延遲;算力下沉至邊緣的初衷，主要是實現(xiàn)中心云海量請求壓力分散，用戶體驗優(yōu)化等，對業(yè)務都屬于錦上添花，而非雪中送炭。

這里說一下運營商網(wǎng)絡，中心云計算技術(shù)，是將數(shù)據(jù)中心內(nèi)部網(wǎng)絡全部虛擬化，即云內(nèi)網(wǎng)絡，衍生出 VPC，負載均衡等諸多產(chǎn)品;數(shù)據(jù)中心外部幾乎完全屏蔽運營商網(wǎng)絡，只提供彈性公網(wǎng) IP 及互聯(lián)網(wǎng)出口帶寬服務，中心云計算與運營商網(wǎng)絡沒有融合;但從中心云計算演進到邊緣計算，是強依賴網(wǎng)絡將中心云與邊緣鏈接起來，如果中心云是大腦，邊緣計算是智能觸角，那么網(wǎng)絡就是神經(jīng)，就是動脈血管，但實際上整體網(wǎng)絡規(guī)劃與建設發(fā)生在云計算發(fā)展之前，并不是專門服務云計算的，所以中心云計算與運營商網(wǎng)需要融合，即云網(wǎng)融合，云網(wǎng)融合最終目標是實現(xiàn)云能力的網(wǎng)絡化調(diào)度編排，網(wǎng)絡能力的云化快速定義。希望借助新型業(yè)務需求和云技術(shù)創(chuàng)新，驅(qū)動運營商網(wǎng)絡架構(gòu)深刻變革升級開放。

當前，網(wǎng)絡的能力極大限制了云計算的發(fā)展，在邊緣計算及物聯(lián)網(wǎng)建設過程中尤為明顯;云網(wǎng)融合與算力網(wǎng)絡依然還是運營商的獨家游戲，新一代 5G 顛覆性技術(shù)變革，引爆整個領(lǐng)域的顛覆性巨變，也只解決了海量設備接入及設備低延遲接入的問題，后端整體配套及解決方案明顯跟不上。就當前情況來看，依然還是 5G 找業(yè)務的尷尬局面，未來 5G 在實體產(chǎn)業(yè)領(lǐng)域(港口， 碼頭，礦山等)領(lǐng)域，相比消費者領(lǐng)域，相信會帶來更大變革與價值。

(2)業(yè)務定義的邊緣計算：

除了面向消費者的互聯(lián)網(wǎng)邊緣場景，邊緣計算更多的是面向?qū)嶓w產(chǎn)業(yè)及智慧化社會衍生的場景。

對于實體產(chǎn)業(yè)場景來說，由于歷史原因，在邊緣及現(xiàn)場存在大量異構(gòu)的基礎設施資源;通過業(yè)務需求驅(qū)動邊緣計算平臺的建設，不僅要整合利用現(xiàn)有基礎設施資源，還要將中心云計算技術(shù)及能力下沉至邊緣及現(xiàn)場，實現(xiàn)大量存量業(yè)務運營管控上云，海量數(shù)據(jù)統(tǒng)一入湖，以此支持整個企業(yè)的數(shù)字化轉(zhuǎn)型。

對于智慧化社會衍生場景來說，越是新型的業(yè)務，對網(wǎng)絡時延敏感越高，數(shù)據(jù)量越大，結(jié)構(gòu)化數(shù)據(jù)逐漸轉(zhuǎn)化成非結(jié)構(gòu)化數(shù)據(jù)，需要人工智能，神經(jīng)網(wǎng)絡等高等智能化技術(shù)支持。

當前對網(wǎng)絡時延敏感的新型業(yè)務場景，都是通過云端總控管理，設備現(xiàn)場實時計算這種分布式架構(gòu)策略，以此減弱對網(wǎng)絡的強依賴。面向業(yè)務將邊緣計算分為智能設備/專業(yè)云及產(chǎn)業(yè)邊緣/行業(yè)云兩種類型：

• 智能設備/專業(yè)云：基于云計算能力之上，圍繞智能設備提供整體化，有競爭力的解決方案，包含智能設備、云端的服務以及端到云之間的邊緣側(cè)服務，比如視頻監(jiān)控云、G7 貨運物聯(lián)等;
• 產(chǎn)業(yè)邊緣/行業(yè)云：也基于云計算能力之上，圍繞行業(yè)應用及場景，提供套件產(chǎn)品及解決方案，比如物流云、航天云等。

總的來說，基于業(yè)務定義的邊緣計算，更多是面向智能設備及實體產(chǎn)業(yè)，對智能設備，從 AVG，密集式存儲，機械手臂等單一功能的智能設備，到無人機，無人駕駛車等超復雜的智能設備，云計算能力不僅支撐設備控制管理應用的運行，同時借助中心云計算能力拓展至邊緣側(cè)，解決這種產(chǎn)品上云，無法集中化標準化管理難題;對產(chǎn)業(yè)邊緣，通過云計算技術(shù)，結(jié)合行業(yè)場景的抽象總結(jié)，構(gòu)建行業(yè)通用的產(chǎn)品及解決方案，隨著整個產(chǎn)業(yè)互聯(lián)網(wǎng)加速建設，是邊緣計算未來發(fā)展的重點方向。

5. 小結(jié)

對于規(guī)模較大的企業(yè)，云邊場景非常復雜，中心云計算平臺與邊緣計算平臺建設，不僅應對業(yè)務需求，還要面臨諸多基礎設施問題：在中心云計算面臨多云使用多云互通問題;在邊緣網(wǎng)絡鏈路面臨多運營商的骨干網(wǎng)，多云運營商網(wǎng)絡及多云的云網(wǎng)融合問題;在端側(cè)接入網(wǎng)面臨多運營商 5G 網(wǎng)絡的共享的問題等，很多問題只能通過治理的手段應對，無法從技術(shù)平臺層面徹底解決。

總的來說，邊緣計算范圍大，場景泛，目前整個行業(yè)缺少經(jīng)典的案例及標準。因此推動邊緣計算落地，一定是面向真實的業(yè)務場景及需求整體規(guī)劃，面向價值逐步建設。

二、Kubernetes 從中心走向邊緣

Kubernetes 遵循以應用為中心的技術(shù)架構(gòu)與思想，以一套技術(shù)體系支持任意負載，運行于任意基礎設施之上;向下屏蔽基礎設施差異，實現(xiàn)底層基礎資源統(tǒng)一調(diào)度及編排;向上通過容器鏡像標準化應用，實現(xiàn)應用負載自動化部署;向外突破中心云計算的邊界，將云計算能力無縫拓展至邊緣及現(xiàn)場，快速構(gòu)建云邊一體基礎設施。

將云原生技術(shù)從中心拓展到邊緣，不僅實現(xiàn)了云邊基礎設施技術(shù)架構(gòu)大一統(tǒng)，業(yè)務也實現(xiàn)了云邊自由編排部署。相對于 Kubernetes 在中心云的革命性創(chuàng)新，在邊緣場景雖優(yōu)勢明顯，但缺點也很致命，因為邊緣側(cè)存在資源有限、網(wǎng)絡受限不穩(wěn)定等特殊情況，需要根據(jù)不同業(yè)務場景，選擇不同 Kubernetes 邊緣方案。

1. Kubernetes 架構(gòu)及邊緣化的挑戰(zhàn)

Kubernetes 是典型的分布式架構(gòu)，Master 控制節(jié)點是集群“大腦”，負責管理節(jié)點，調(diào)度 Pod 以及控制集群運行狀態(tài)。Node 工作節(jié)點，負責運行容器(Container)，監(jiān)控/上報運行狀態(tài)。邊緣計算場景存在以下比較明顯的挑戰(zhàn)：

• 狀態(tài)強一致且集中式存儲架構(gòu)，屬于中心云計算的大成產(chǎn)品，基于大規(guī)模的池化資源的編排調(diào)度實現(xiàn)業(yè)務持續(xù)服務。
• Master 管控節(jié)點與 Worker 工作節(jié)點通過 List-Watch 機制，實現(xiàn)狀態(tài)任務實時同步，但是流量較大，Worker 工作節(jié)點完全依賴 Master 節(jié)點持久化數(shù)據(jù)，無自治能力。
• Kubelet 承載太多邏輯處理，各種容器運行時各種實現(xiàn)的兼容，還有 Device Plugin 硬件設備驅(qū)動，運行占用資源高達 700M;對資源有限的邊緣節(jié)點負擔太重，尤其是低配的邊緣設備。

邊緣計算涉及的范圍大、場景復雜，尚無統(tǒng)一標準;Kubernetes 開源社區(qū)的主線版本并無邊緣場景的適配計劃。

2. Kubernetes 邊緣化運行方案

針對中心云計算及邊緣計算這種云邊分布式架構(gòu)，需要將 Kubernetes 適配成適合邊緣分布式部署的架構(gòu)，通過多集群管理實現(xiàn)統(tǒng)一管理，實現(xiàn)中心云管理邊緣運行，整體分為三種方案：

• 集群 Cluster：將 Kubernetes 標準集群下沉至邊緣，優(yōu)點是無需 Kubernetes 做定制化研發(fā)，同時可以支持 Kubernetes 多版本，支持業(yè)務真正實現(xiàn)云邊架構(gòu)一致;缺點是管理資源占用多。方案比較適合區(qū)域云/中心云、邊緣計算/本地計算以及規(guī)模較大的產(chǎn)業(yè)邊緣場景。
• 單節(jié)點 Single Node：將 Kubernetes 精簡，部署在單節(jié)點設備之上，優(yōu)點與集群 Cluster 方案一致，缺點是 Kubernetes 能力不完整，資源的占用會增加設備的成本，對業(yè)務應用無法保證云邊一致的架構(gòu)部署運行，沒有解決實際問題。
• 邊緣節(jié)點 Remote Node：基于Kubernetes 二次開發(fā)增強擴展，將 Kubernetes 解耦適配成云邊分布式架構(gòu)的場景，中心化部署 Master 管理節(jié)點，分散式部署 Worker 管理節(jié)點。

此外，一致性是邊緣計算的痛點，在邊緣增加一個 Cache 即可實現(xiàn)斷網(wǎng)特殊情況的邊緣自治，同時可以保證正常網(wǎng)絡情況的數(shù)據(jù)一致;還有就是 Kubelet 比較重的問題，隨著 Kubernetes 放棄 Docker 已經(jīng)開始精簡;同時硬件更新迭代較快，相比少量硬件成本，保持 Kubernetes 原生及通用性為大。其實更希望Kubernetes 社區(qū)本身提供適配邊緣化方案，同時考慮為 Kubelet 增加緩存機制。

3. Kubernetes 邊緣容器快速發(fā)展

Kubernetes 已成為容器編排和調(diào)度的事實標準，針對邊緣計算場景，目前國內(nèi)各個公有云廠商都開源了各自基于 Kubernetes 的邊緣計算云原生項目，比如阿里云向 CNCF 貢獻的 OpenYurt，采用邊緣節(jié)點 Remote Node 方案，是業(yè)界首個開源的非侵入式邊緣計算云原生平臺，秉承“Extending your native Kubernetes to Edge”的非侵入式設計理念，擁有可實現(xiàn)邊緣計算全場景覆蓋的能力。華為、騰訊、百度等，也都開源了自己的邊緣容器平臺。

邊緣容器的快速發(fā)展帶動了領(lǐng)域的創(chuàng)新，但一定程度上也導致構(gòu)建邊緣計算平臺時難以抉擇。從技術(shù)架構(gòu)來看，幾個邊緣容器產(chǎn)品總的架構(gòu)思路主要是將 Kubernetes 解耦成適合云邊、弱網(wǎng)絡及資源稀缺的邊緣計算場景，本質(zhì)上無太大差異;從產(chǎn)品功能來看也是如此，基本上都涵蓋云邊協(xié)同、邊緣自治、單元化部署功能等。

4. 如何構(gòu)建云邊一體化云原生平臺

現(xiàn)階段，圍繞 Kubernetes 容器平臺，構(gòu)建云邊一體化云原生基礎設施平臺能力是邊緣計算平臺的最佳選擇，通過云端統(tǒng)一的容器多集群管理，實現(xiàn)分散式集群統(tǒng)一管理，同時標準化 Kubernetes 集群規(guī)格配置：

• 標準集群(大規(guī)模)：支持超過 400 個節(jié)點的大規(guī)模集群，配置為 ETCD + Master 3 臺 8c16G，Prometheus + Ingress 5 臺 8C16G， N * Work 節(jié)點;主要是業(yè)務規(guī)模較大的云原生應用運行場景;
• 標準集群(中等規(guī)模)：支持超過 100 個節(jié)點以內(nèi)的集群，ETCD + Master + Prometheus 3 臺 8c16G，N * Work 節(jié)點;主要是業(yè)務規(guī)模中等的場景;
• 邊緣原生容器集群：在云端部署集群管理節(jié)點，將邊緣節(jié)點單獨部署業(yè)務現(xiàn)場，支持運行單業(yè)務場景的應用，比如 IoT 物理設備接入?yún)f(xié)議解析應用，視頻監(jiān)控分析 AI 算法模型等業(yè)務場景。

按照業(yè)務場景需求選擇最優(yōu)容器集群方案，其中邊緣容器集群方案，與其他集群方案差別較大，其他集群依然保持中心云集群服務一致，基礎資源集中并且池化，所有應用共享整個集群資源;而邊緣容器集群Master 管理節(jié)點集中部署，共享使用;Worker 節(jié)點都是分散在業(yè)務現(xiàn)場，按需自助增加，自運維且獨占使用。

當前邊緣容器領(lǐng)域短時間內(nèi)很難有大一統(tǒng)的開源產(chǎn)品，因此現(xiàn)階段建議通過標準的 Kubernetes API 來集成邊緣原生容器集群，這種兼容所有邊緣容器的中庸方案，如果非要擇其一，建議是 OpenYurt，非侵入式設計，整體技術(shù)架構(gòu)及實現(xiàn)更加優(yōu)雅。

三、OpenYurt：智能邊緣計算平臺開源實踐

OpenYurt 以上游開源項目 Kubernetes 為基礎，針對邊緣場景適配的發(fā)行版。是業(yè)界首個依托云原生技術(shù)體系、“零”侵入實現(xiàn)的智能邊緣計算平臺。具備全方位的“云、邊、端一體化”能力，能夠快速實現(xiàn)海量邊緣計算業(yè)務和異構(gòu)算力的高效交付、運維及管理。

1. 設計原則

OpenYurt 采用當前業(yè)界主流的“中心管控、邊緣運行”的云邊分布式協(xié)同技術(shù)架構(gòu)，始終貫徹“Extending your native Kubernetes to Edge”理念，同時遵守以下設計原則：

• “云邊一體化”原則：保證與中心云一致的用戶體驗及產(chǎn)品能力的基礎上，通過云邊管控通道將云原生能力下沉至邊緣，實現(xiàn)海量的智能邊緣節(jié)點及業(yè)務應用，基礎架構(gòu)提升至業(yè)界領(lǐng)的云原生架構(gòu)的重大突破。
• “零侵入”原則：確保面向用戶開放的 API 與原生 Kubernetes 完全一致。通過節(jié)點網(wǎng)絡流量代理方式(proxy node network traffic)，對 Worker 工作節(jié)點應用生命周期管理新增一層封裝抽象，實現(xiàn)分散式工作節(jié)點資源及應用統(tǒng)一管理及調(diào)度。同時遵循“UpStream First”開源法則;
• “低負載”原則：在保障平臺功能特性及可靠性的基礎上，兼顧平臺的通用性，嚴格限制所有組件的資源，遵循最小化，最簡化的設計理念，以此實現(xiàn)最大化覆蓋邊緣設備及場景。
• “一棧式”原則：OpenYurt 不僅實現(xiàn)了邊緣運行及管理的增強功能，還提供了配套的運維管理工具，實現(xiàn)將原生 Kubernetes 與支持邊緣計算能力的 Kubernetes 集群的相互一鍵高效轉(zhuǎn)換;

2. 功能特性

OpenYurt 基于 Kubernetes 強大的容器編排、調(diào)度能力，針對邊緣資源有限，網(wǎng)絡受限不穩(wěn)定等情況適配增強;將中心云原生能力拓展至分散式邊緣節(jié)點，實現(xiàn)面向邊緣業(yè)務就近低延遲服務;同時打通反向安全控制運維鏈路，提供便捷高效的，云端集中式邊緣設備及應用的統(tǒng)一運維管理能力。其核心功能特性如下：

• 邊緣節(jié)點自治：在邊緣計算場景，云邊管控網(wǎng)絡無法保證持續(xù)穩(wěn)定，通過增強適配解決原生 Worker 工作節(jié)點無狀態(tài)數(shù)據(jù)，強依賴 Master 管控節(jié)點數(shù)據(jù)且狀態(tài)強一致機制，這些在邊緣場景不適配的問題。從而實現(xiàn)在云邊網(wǎng)絡不暢的情況下，邊緣工作負載不被驅(qū)逐，業(yè)務持續(xù)正常服務;即使斷網(wǎng)時邊緣節(jié)點重啟，業(yè)務依然能恢復正常;即邊緣節(jié)點臨時自治能力。
• 協(xié)同運維通道：在邊緣計算場景，云邊網(wǎng)絡不在同一網(wǎng)絡平面，邊緣節(jié)點也不會暴露在公網(wǎng)之上，中心管控無法與邊緣節(jié)點建立有效的網(wǎng)絡鏈路通道，導致所有原生的 Kubernetes 運維 APIs(logs/exec/metrics)失效。適配增強 Kubernetes 能力，在邊緣點初始化時，在中心管控與邊緣節(jié)點之間建立反向通道，承接原生的 Kubernetes 運維 APIs(logs/exec/metrics)流量，實現(xiàn)中心化統(tǒng)一運維;
• 邊緣單元化負載：在邊緣計算場景，面向業(yè)務一般都是“集中式管控，分散式運行”這種云邊協(xié)同分布式架構(gòu);對于管理端，需要將相同的業(yè)務同時部署到不同地域節(jié)點;對于邊緣端，Worker 工作節(jié)是一般是分散在廣域空間，并且具有較強的地域性，跨地域的節(jié)點之間網(wǎng)絡不互通、資源不共享、資源異構(gòu)等明顯的隔離屬性。適配增強 Kubernetes 能力，基于資源，應用及流量三層實現(xiàn)對邊緣負載進行單元化管理調(diào)度。
• 通過 OpenYurt 開源社區(qū)引入更多的參與方共建，聯(lián)合研發(fā)方式提供更多的可選的專業(yè)功能，OpenYurt 特性正在逐步完善，并擴大覆蓋能力：
• 邊緣設備管理：在邊緣計算場景，端側(cè)設備才是平臺真正的服務對象;基于云原生理念，抽象非侵入、可擴展的設備管理標準模型，無縫融合 Kubernetes 工作負載模型與 IoT 設備管理模型，實現(xiàn)平臺賦能業(yè)務的最后一公里。目前，通過標準模型完成 EdgeX Foundry 開源項目的集成，極大的提升了邊緣設備的管理效率。

本地資源管理：在邊緣計算場景，將邊緣節(jié)點上已有的塊設備或者持久化內(nèi)存設備，初始化成云原生便捷使用的容器存儲，支持兩種本地存儲設備：(一)基于塊設備或者是持久化內(nèi)存設備創(chuàng)建的 LVM;(二)基于塊設備或者是持久化內(nèi)存設備創(chuàng)建的 QuotaPath。

3. OpenYurt 設計架構(gòu)及原理

(1)設計架構(gòu)

原生 Kubernetes 是一個中心式的分布式架構(gòu)，Master 控制節(jié)點負責管理調(diào)度及控制集群運行狀態(tài);Worker 工作節(jié)點負責運行容器(Container)及監(jiān)控/上報運行狀態(tài);

OpenYurt 以原生 Kubernetes 為基礎，針對邊緣場景將中，心式分布式架構(gòu)(Cloud Master，Cloud Worker)解耦適配為中心化管控分散式邊緣運行(Cloud Master,Edge Worker)，形成一個中心式大腦，多個分散式小腦的章魚式云邊協(xié)同分布式架構(gòu)，其主要核心點是：

• 將元數(shù)據(jù)集中式且強一致的狀態(tài)存儲，分散至邊緣節(jié)點，并且調(diào)整原生 Kubernetes 調(diào)度機制，實現(xiàn)自治節(jié)點狀態(tài)異常不觸發(fā)重新調(diào)度，以此實現(xiàn)邊緣節(jié)點臨時自治能力;
• 保證 Kubernetes 能力完整一致，同時兼容現(xiàn)有的云原生生態(tài)體系的同時，盡最大肯能將云原生體系下沉至邊緣;
• 將中心大規(guī)模資源池化，多應用委托調(diào)度共享資源的模式，適配為面向地域小規(guī)模甚至單節(jié)點資源，實現(xiàn)邊緣場景下，更精細化的單元化工作負載編排管理;
• 面向邊緣實際業(yè)務場景需求，通過開放式社區(qū)，無縫集成設備管理、邊緣 AI、流式數(shù)據(jù)等，面向邊緣實際業(yè)務場景的開箱的通用平臺能力，賦能更多的邊緣應用場景。

(2)實現(xiàn)原理

OpenYurt 踐行云原生架構(gòu)理念，面向邊緣計算場景實現(xiàn)云邊協(xié)同分布式架構(gòu)及中心管控邊緣運行的能力：

• 針對邊緣節(jié)點自治能力，一方面，通過新增 YurtHub 組件實現(xiàn)邊緣向中心管控請求(Edge To Cloud Request)代理，并緩存機制將最新的元數(shù)據(jù)持久化在邊緣節(jié)點;另一方面新增 YurtControllerManager 組件接管原生 Kubernetes 調(diào)度，實現(xiàn)邊緣自治節(jié)點狀態(tài)異常不觸發(fā)重新調(diào)度;
• 針對 Kubernetes 能力完整及生態(tài)兼容，通過新增 YurtTunnel 組件，構(gòu)建云邊(Cloud To Edge Request)反向通道，保證 Kubectl，Promethus 等中心運維管控產(chǎn)品一致能力及用戶體驗;同時將中心其他能力下沉至邊緣，包含各不同的工作負載及 Ingress 路由等;
• 針對邊緣單元化管理能力，通過新增 YurtAppManager 組件，同時搭配 NodePool,YurtAppSet (原UnitedDeployment)，YurtAppDaemon,ServiceTopology 等實現(xiàn)邊緣資源，工作負載及流量三層單元化管理;
• 針對賦能邊緣實際業(yè)務平臺能力，通過新增 NodeResourceManager 實現(xiàn)邊緣存儲便捷使用，通過引入YurtEdgeXManager/YurtDeviceController 實現(xiàn)通過云原生模式管理邊緣設備。

4. 核心組件

OpenYurt 所有新增功能及組件，均是通過 Addon 與 Controller 方式來實現(xiàn)其核心必選與可選組件如下：

• YurtHub(必選)：有邊緣 (edge) 和云中心 (cloud) 兩種運行模式;以 Static Pod 形態(tài)運行在云邊所有節(jié)點上，作為節(jié)點流量的 SideCar，代理節(jié)點上組件和 kube-apiserver 的訪問流量，其中邊緣 YurtHub 會緩存的數(shù)據(jù)，實現(xiàn)臨時邊緣節(jié)點自治能力。
• YurtTunnel(必選)：由 Server 服務端與 Agent 客戶端組成，構(gòu)建雙向認證加密的云邊反向隧道，轉(zhuǎn)發(fā)云中心 (cloud) 到邊緣 (edge) 原生的 Kubernetes 運維 APIs(logs/exec/metrics)請求流量。其中 Server 以 Deployment 工作負載部署在云中心，Agent 以 DaemonSet 工作負載部署在邊緣節(jié)點。
• YurtControllerManager(必選)：云中心控制器，接管原生 Kubernetes 的 NodeLifeCycle Controller，實現(xiàn)在云邊網(wǎng)絡異常時，不驅(qū)逐自治邊緣節(jié)點的Pod應用;還有 YurtCSRController，用以審批邊緣節(jié)點的證書申請。
• YurtAppManager(必選)：實現(xiàn)對邊緣負載進行單元化管理調(diào)度，包括 NodePool：節(jié)點池管理;YurtAppSet：原 UnitedDeployment，節(jié)點池維度的業(yè)務負載;YurtAppDaemon：節(jié)點池維度的 Daemonset 工作負載。以 Deploymen 工作負載部署在云中心。
• NodeResourceManager(可選)：邊緣節(jié)點本地存儲資源的管理組件，通過修改 ConfigMap 來動態(tài)配置宿主機本地資源。以 DaemonSet 工作負載部署在邊緣節(jié)點。
• YurtEdgeXManager/YurtDeviceController(可選):通過云原生模式管控邊緣設備，當前支持 EdgeX Foundry的集成。YurtEdgeXManager 以 Deployment 工作負載署在云中心，YurtDeviceController 以 YurtAppSet 工作負載署部署在邊緣節(jié)點，并且以節(jié)點池 NodePool 為單位部署一套 YurtDeviceController 即可。
• 運維管理組件(可選)：為了標準化集群管理，OpenYurt 社區(qū)推出 YurtCluster Operator 組件，提供云原生聲名式 Cluster API 及配置，基于標準 Kubernetes 自動化部署及配置 OpenYurt 相關(guān)組件，實現(xiàn) OpenYurt 集群的全生命周期。舊 Yurtctl 工具建議只在測試環(huán)境使用。

除了核心功能及可選的專業(yè)功能外，OpenYurt 持續(xù)貫徹云邊一體化理念，將云原生豐富的生態(tài)能力最大程度推向邊緣，已經(jīng)實現(xiàn)了邊緣容器存儲，邊緣守護工作負載 DaemonSet，邊緣網(wǎng)絡接入 Ingress Controller 等，還有規(guī)劃中的有 Service Mesh，Kubeflow，Serverless 等功能，拭目以待。

5. 當前挑戰(zhàn)

(1)云邊網(wǎng)絡

在邊緣計算場景中，被提到最多的就是云邊網(wǎng)絡差且不穩(wěn)定，其實國內(nèi)基礎網(wǎng)絡在 2015 年開始全面升級，尤其是在“雪亮工程”全面完成之后，基礎網(wǎng)絡有一個很大的提升。上圖摘自《第 48 次中國互聯(lián)網(wǎng)絡發(fā)展狀況》報告，固網(wǎng) 100Mbps 接入占比已達 91.5%;無線網(wǎng)絡接入已經(jīng)都是 4G，5G 的優(yōu)質(zhì)網(wǎng)絡。

而真正的挑戰(zhàn)在云邊網(wǎng)絡組網(wǎng)，對于使用公有云的場景：公有云屏蔽數(shù)據(jù)中心網(wǎng)絡，只提供了互聯(lián)網(wǎng)出口帶寬，通過互聯(lián)網(wǎng)打通云邊，通常只需要解決數(shù)據(jù)安全傳輸即可，接入不復雜。對于私有自建的 IDC 場景：打通云邊網(wǎng)絡并不容易，主要是運營商網(wǎng)絡沒有完全產(chǎn)品化，同時私有 IDC 層層防火墻等其他復雜產(chǎn)品，需要專業(yè)的網(wǎng)絡人員才能完成實施工作。

(2)list-watch 機制與云邊流量

List-Watch 機制是 Kubernetes 的設計精華，通過主動監(jiān)聽機制獲取相關(guān)的事件及數(shù)據(jù)，從而保證所有組件松耦合相互獨立，邏輯上又渾然一體。List 請求返回是全量的數(shù)據(jù)，一旦 Watch 失敗，就需要重新 Relist 。但是 Kubernetes 有考慮管理數(shù)據(jù)同步優(yōu)化，節(jié)點的 kubelet 只監(jiān)聽本節(jié)點數(shù)據(jù)，kube-proxy 會監(jiān)聽所有的 Service 數(shù)據(jù)，數(shù)據(jù)量相對可控;同時采用 gRPC 協(xié)議，文本報文數(shù)據(jù)相比業(yè)務數(shù)據(jù)非常小。上圖是在節(jié)點 1200 節(jié)點的集群規(guī)模，做的壓測數(shù)據(jù)監(jiān)控圖表。

真正的挑戰(zhàn)在基礎鏡像及應用鏡像下發(fā)，當前的基礎鏡像及業(yè)務鏡像，即使在中心云，依然在探索各種技術(shù)來優(yōu)化鏡像快速分發(fā)的瓶頸;尤其是邊緣的 AI 應用，一般都是由推送應用+模型庫構(gòu)成，推算應用的鏡像相對較小，模型庫的體積就非常，同時模型庫隨著自學習還需要頻繁的更新，如果更高效的更新模型庫，需要更多技術(shù)及方案來應對。

(3)邊緣資源和算力

邊緣的資源情況需要細分場景，針對運營商網(wǎng)絡邊緣，面向消費者的邊緣計算，資源相對比較充足，最大的挑戰(zhàn)是資源共享及隔離;針對實體產(chǎn)業(yè)的邊緣，都會有不小的 IDC 支持，邊緣資源非常充足，足以將整個云原生體系下沉;針對智能設備邊緣，資源相對比較稀缺，但一般都會通過一個智能邊緣盒子，一端連接設備，一端連接中心管控服務，從上圖的 AI 邊緣盒子來看，整體配置提升速度較快，長期來看，邊緣的算力快速增強以此來滿足更復雜更智能化的場景需求。

(4)Kubelet 比較重，運行占用資源多

對于 Kubelet 比較重，運行占用資源多的問題，需要深入了解節(jié)點資源分配及使用情況，通常節(jié)點的資源自下而上分為四層：

• 運行操作系統(tǒng)和系統(tǒng)守護進程(如 SSH、systemd 等)所需的資源;
• 運行 Kubernetes 代理所需的資源，如 Kubelet、容器運行時、節(jié)點問題檢測器等;
• Pod 可用的資源;
• 保留到驅(qū)逐閾值的資源。

對于各層的資源分配設置的沒有標準，需要根據(jù)集群的情況來權(quán)衡配置，Amazon Kubernetes 對 Kubelet 資源配置算法是 Reserved memory = 255MiB + 11MiB * MAX_POD_PER_INSTANCE;假設運行32 Pods，高達 90% 的內(nèi)存都可以分配給業(yè)務使用，相對來說 Kubelet 資源占用并不高。

同時也要結(jié)合業(yè)務對高可用的要求,做響應的調(diào)整。針對邊緣場景，一般不建議在一個節(jié)點上運行大量的Pods 穩(wěn)定為大。

四、業(yè)務應用的云邊管運協(xié)同模型

基于中心云的分布式業(yè)務應用架構(gòu)，與云邊分布式協(xié)同業(yè)務應用架構(gòu)本質(zhì)上有很大差別。在中心云更多的是基于 DDD 業(yè)務領(lǐng)域，將復雜的業(yè)務系統(tǒng)拆分成一個個相對獨立的服務，整體構(gòu)建一個松耦合的分布式應用;但在云邊分布式場景下，更多強調(diào)的是集中式管控運營，分散式運作支撐，將管理運營系統(tǒng)集中在云中心，實現(xiàn)中心式管控，將支撐業(yè)務實時運作的應用分散至邊緣，實現(xiàn)低延遲快速響應。

從業(yè)務應用來看，財務/經(jīng)營，計劃/管理兩層屬于管控運營類的應用，就是需要通過中心云統(tǒng)一匯聚，實現(xiàn)集中化強管控;對延遲不敏感，對安全，大數(shù)據(jù)分析能力等要求較高;控制，傳感/執(zhí)行，生產(chǎn)過程三層屬于運作支撐類應用，也可以優(yōu)先考慮中心云;如果業(yè)務場景對延遲敏感，才考慮通過邊緣計算能力，實現(xiàn)分散式低時延響應;

從請求響應來看，對時延不敏感(50ms 以上)都有限考慮部署在中心云計算及云化的邊緣產(chǎn)品(CDN)實現(xiàn);對延遲敏感(小于10ms )，運營商骨干網(wǎng)完全無法支持的，考慮建設邊緣計算平臺，同時業(yè)務面臨不小的投入及人員;

以實體物流領(lǐng)域為例，經(jīng)典的 OTW 系統(tǒng)(OMS 訂單管理系統(tǒng)，WMS 倉庫管理系統(tǒng)，TMS 運輸管理系統(tǒng))其中 OT 就屬于典型的管理運營系統(tǒng)，所以建議部署在中心云，通過中心云數(shù)據(jù)匯聚，實現(xiàn)拼單拆單，多式聯(lián)運等跨區(qū)域業(yè)務;W 是倉庫管理系統(tǒng)，管理四面墻的任務，屬于運作支撐應用，并且倉庫一般都有一些自動化設備，就可以考慮將 W 部署在邊緣。

五、總結(jié)

邊緣計算平臺的建設，以 Kubernetes 為核心的云原生技術(shù)體系，無疑是當前最佳的選擇與建設路徑;但是云原生體系龐大，組件復雜，將體系下沉至邊緣會面臨很大的挑戰(zhàn)與困難，同時充滿巨大的機遇及想象空間。業(yè)務應用想要真正踐行邊緣的云原生體系，需要從理念、系統(tǒng)設計、架構(gòu)設計等多方面來共同實現(xiàn)，才能充分發(fā)揮邊緣的優(yōu)勢及價值。