從中心走向邊緣——深度決議云原生邊緣計算落地痛點

作者：段嘉，新勝

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

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

邊緣計算的理解與思考

邊緣計算的定義

邊緣計算當前沒有準確定義，從 IT 云計算領域視角，邊緣計算被看作中心云計算的拓展，邊緣計算產業聯盟對邊緣計算的定義：“在靠近物或資料源頭的網路邊緣側，融合網路、計算、存盤、應用核心能力的開放平臺，就近提供邊緣智能服務，滿足行業數字化在敏捷連接、實時業務、資料優化、應用智能、安全與隱私保護等方面的關鍵需求”，從 CT 電信領域視角，邊緣計算最初也被稱為移動邊緣計算（MEC），歐洲電信標準協會（ETSI）對 MEC 的定義：“移動邊緣計算在移動網路的邊緣、無線接入網（RAN）的內部以及移動用戶的近處提供了一個 IT 服務環境以及云計算能力”，

邊緣計算的定義各有側重，但核心思想基本一致——邊緣計算是基于云計算核心技術，構建在邊緣基礎設施之上的新型分布式計算形式，在邊緣端靠近最終用戶提供計算能力，是一種靠近資料源的現場云計算，

中心云計算憑借其強大的資料中心，為業務應用提供大規模池化，彈性擴展的計算、存盤、網路等基礎設施服務，更適用于非實時、長周期資料、業務決策場景；邊緣計算則聚焦在實時性、短周期資料、本地決策等業務場景，比如當下熱門的音視頻直播、IoT、產業互聯網、虛擬現實甚至元宇宙等，將作業負載下沉至離終端設備或者靠近最終用戶的地方，以此實作更低的網路延遲，提升用戶的使用體驗，

“章魚式”邊緣計算

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

如上圖漫畫中所示，章魚全身神經元中心式腦部占 40%，其余 60% 在分散式腿部，形成 1 個大腦總控協調 + N 個小腦分散執行的結構，1 個大腦擅長全域調度，進行非實時、長周期的大資料處理與分析；N 個小腦側重區域、小規模資料處理，適用于現場級、實時、短周期的智能分析與快速決策，

章魚式邊緣計算采用中心云+邊緣計算的分布式云邊一體化架構，海量終端采集到資料后，在邊緣完成小規模區域資料的實時決策處理，而復雜大規模的全域性決策處理則匯總至中心云深入分析處理，

邊緣計算的位置

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

云計算能力由中心逐步下沉到邊緣，節點數量增多，覆寫范圍縮小，運維服務成本快速增加，根據國內網路（國內有多張骨干網，分別是電信 CHINANET 與 CN2，聯通 CNCNET 以及移動 CMNET）現狀，骨干網節點，城際網節點，匯聚網節點，接入網節點，以及數以萬計的業務現場計算節點都可以安置邊緣計算，因此范圍太廣難以形成統一標準，因此我們說中心云計算由技術定義，邊緣計算由網路與業務需求定義，

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

邊緣計算的型別

（1）網路定義的邊緣計算：

通過優化終端與云中心網路路徑，將中心云能力逐漸下沉至靠近終端，實作業務就近接入訪問，從中心到邊緣依次分為區域云/中心云，邊緣云/邊緣計算，邊緣計算/本地計算三大型別：

區域云/中心云：將中心云計算的服務在骨干網拓展延伸，將中心化云能力拓展至區域，實作區域全覆寫，解決在骨干網上耗時，將網路延遲優化至 30ms 左右，但邏輯上仍是中心云服務，

邊緣云/邊緣計算：將中心云計算的服務沿著運營商的網路節點延伸，構建中小規模云服務或類云服務能力，將網路延遲優化至 15ms 左右，比如多接入邊緣計算（MEC）、CDN，

邊緣計算/本地計算：主要是接近終端的現場設備及服務能力，將終端部分邏輯剝離出來，實作邊緣自主的智能服務，由云端控制邊緣的資源調度、應用管理與業務編排等能力，將網路延遲優化至 5ms 左右，比如多功能一體機、智能路由器等，

總的來說，基于網路定義的邊緣計算，更多是面向消費互聯業務及新型 2C 業務，將云中心的能力及資料提前下沉至邊緣，除了經典的 CDN，視頻語音業務外，還有今年大火的元宇宙等，

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

這里說一下運營商網路，中心云計算技術，是將資料中心內部網路全部虛擬化，即云內網路，衍生出 VPC，負載均衡等諸多產品；資料中心外部幾乎完全屏蔽運營商網路，只提供彈性公網 IP 及互聯網出口帶寬服務，中心云計算與運營商網路沒有融合；但從中心云計算演進到邊緣計算，是強依賴網路將中心云與邊緣鏈接起來，如果中心云是大腦，邊緣計算是智能觸角，那么網路就是神經，就是動脈血管，但實際上整體網路規劃與建設發生在云計算發展之前，并不是專門服務云計算的，所以中心云計算與運營商網需要融合，即云網融合，云網融合最終目標是實作云能力的網路化調度編排，網路能力的云化快速定義，希望借助新型業務需求和云技術創新，驅動運營商網路架構深刻變革升級開放，

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

（2）業務定義的邊緣計算：

除了面向消費者的互聯網邊緣場景，邊緣計算更多的是面向物體產業及智慧化社會衍生的場景，

對于物體產業場景來說，由于歷史原因，在邊緣及現場存在大量異構的基礎設施資源；通過業務需求驅動邊緣計算平臺的建設，不僅要整合利用現有基礎設施資源，還要將中心云計算技術及能力下沉至邊緣及現場，實作大量存量業務運營管控上云，海量資料統一入湖，以此支持整個企業的數字化轉型，

對于智慧化社會衍生場景來說，越是新型的業務，對網路時延敏感越高，資料量越大，結構化資料逐漸轉化成非結構化資料，需要人工智能，神經網路等高等智能化技術支持，

當前對網路時延敏感的新型業務場景，都是通過云端總控管理，設備現場實時計算這種分布式架構策略，以此減弱對網路的強依賴，面向業務將邊緣計算分為智能設備/專業云及產業邊緣/行業云兩種型別：

智能設備/專業云：基于云計算能力之上，圍繞智能設備提供整體化，有競爭力的解決方案，包含智能設備、云端的服務以及端到云之間的邊緣側服務，比如視頻監控云、G7 貨運物聯等；

產業邊緣/行業云：也基于云計算能力之上，圍繞行業應用及場景，提供套件產品及解決方案，比如物流云、航天云等，

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

小結

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

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

Kubernetes 從中心走向邊緣

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

將云原生技術從中心拓展到邊緣，不僅實作了云邊基礎設施技術架構大一統，業務也實作了云邊自由編排部署，相對于 Kubernetes 在中心云的革命性創新，在邊緣場景雖優勢明顯，但缺點也很致命，因為邊緣側存在資源有限、網路受限不穩定等特殊情況，需要根據不同業務場景，選擇不同 Kubernetes 邊緣方案，

Kubernetes 架構及邊緣化的挑戰

Kubernetes 是典型的分布式架構，Master 控制節點是集群“大腦”，負責管理節點，調度 Pod 以及控制集群運行狀態，Node 作業節點，負責運行容器（Container），監控/上報運行狀態，邊緣計算場景存在以下比較明顯的挑戰：

1、狀態強一致且集中式存盤架構，屬于中心云計算的大成產品，基于大規模的池化資源的編排調度實作業務持續服務，

2、Master 管控節點與 Worker 作業節點通過 List-Watch 機制，實作狀態任務實時同步，但是流量較大，Worker 作業節點完全依賴 Master 節點持久化資料，無自治能力，

3、Kubelet 承載太多邏輯處理，各種容器運行時各種實作的兼容，還有 Device Plugin 硬體設備驅動，運行占用資源高達 700M；對資源有限的邊緣節點負擔太重，尤其是低配的邊緣設備，

邊緣計算涉及的范圍大、場景復雜，尚無統一標準；Kubernetes 開源社區的主線版本并無邊緣場景的適配計劃，

Kubernetes 邊緣化運行方案

針對中心云計算及邊緣計算這種云邊分布式架構，需要將 Kubernetes 適配成適合邊緣分布式部署的架構，通過多集群管理實作統一管理，實作中心云管理邊緣運行，整體分為三種方案：

• 集群 Cluster：將 Kubernetes 標準集群下沉至邊緣，優點是無需 Kubernetes 做定制化研發，同時可以支持 Kubernetes 多版本，支持業務真正實作云邊架構一致；缺點是管理資源占用多，方案比較適合區域云/中心云、邊緣計算/本地計算以及規模較大的產業邊緣場景，

• 單節點 Single Node：將 Kubernetes 精簡，部署在單節點設備之上，優點與集群 Cluster 方案一致，缺點是 Kubernetes 能力不完整，資源的占用會增加設備的成本，對業務應用無法保證云邊一致的架構部署運行，沒有解決實際問題，

• 邊緣節點 Remote Node：基于Kubernetes 二次開發增強擴展，將 Kubernetes 解耦適配成云邊分布式架構的場景，中心化部署 Master 管理節點，分散式部署 Worker 管理節點，

此外，一致性是邊緣計算的痛點，在邊緣增加一個 Cache 即可實作斷網特殊情況的邊緣自治，同時可以保證正常網路情況的資料一致；還有就是 Kubelet 比較重的問題，隨著 Kubernetes 放棄 Docker 已經開始精簡；同時硬體更新迭代較快，相比少量硬體成本，保持 Kubernetes 原生及通用性為大，其實更希望Kubernetes 社區本身提供適配邊緣化方案，同時考慮為 Kubelet 增加快取機制，

Kubernetes 邊緣容器快速發展

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

邊緣容器的快速發展帶動了領域的創新，但一定程度上也導致構建邊緣計算平臺時難以抉擇，從技術架構來看，幾個邊緣容器產品總的架構思路主要是將 Kubernetes 解耦成適合云邊、弱網路及資源稀缺的邊緣計算場景，本質上無太大差異；從產品功能來看也是如此，基本上都涵蓋云邊協同、邊緣自治、單元化部署功能等，

如何構建云邊一體化云原生平臺

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

• 標準集群（大規模）：支持超過 400 個節點的大規模集群，配置為 ETCD + Master 3 臺 8c16G，Prometheus + Ingress 5 臺 8C16G， N * Work 節點；主要是業務規模較大的云原生應用運行場景；

• 標準集群（中等規模）：支持超過 100 個節點以內的集群，ETCD + Master + Prometheus 3 臺 8c16G，N * Work 節點；主要是業務規模中等的場景；

• 邊緣原生容器集群：在云端部署集群管理節點，將邊緣節點單獨部署業務現場，支持運行單業務場景的應用，比如 IoT 物理設備接入協議決議應用，視頻監控分析 AI 演算法模型等業務場景，

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

當前邊緣容器領域短時間內很難有大一統的開源產品，因此現階段建議通過標準的 Kubernetes API 來集成邊緣原生容器集群，這種兼容所有邊緣容器的中庸方案，如果非要擇其一，建議是 OpenYurt，非侵入式設計，整體技術架構及實作更加優雅，

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

OpenYurt 以上游開源專案 Kubernetes 為基礎，針對邊緣場景適配的發行版，是業界首個依托云原生技術體系、“零”侵入實作的智能邊緣計算平臺，具備全方位的“云、邊、端一體化”能力，能夠快速實作海量邊緣計算業務和異構算力的高效交付、運維及管理，

設計原則

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

• “云邊一體化”原則：保證與中心云一致的用戶體驗及產品能力的基礎上，通過云邊管控通道將云原生能力下沉至邊緣，實作海量的智能邊緣節點及業務應用，基礎架構提升至業界領的云原生架構的重大突破，

• “零侵入”原則：確保面向用戶開放的 API 與原生 Kubernetes 完全一致，通過節點網路流量代理方式（proxy node network traffic），對 Worker 作業節點應用生命周期管理新增一層封裝抽象，實作分散式作業節點資源及應用統一管理及調度，同時遵循“UpStream First”開源法則；

• “低負載”原則：在保障平臺功能特性及可靠性的基礎上，兼顧平臺的通用性，嚴格限制所有組件的資源，遵循最小化，最簡化的設計理念，以此實作最大化覆寫邊緣設備及場景，

• “一堆疊式”原則：OpenYurt 不僅實作了邊緣運行及管理的增強功能，還提供了配套的運維管理工具，實作將原生 Kubernetes 與支持邊緣計算能力的 Kubernetes 集群的相互一鍵高效轉換；

功能特性

OpenYurt 基于 Kubernetes 強大的容器編排、調度能力，針對邊猿澩有限，網路受限不穩定等情況適配增強；將中心云原生能力拓展至分散式邊緣節點，實作面向邊緣業務就近低延遲服務；同時打通反向安全控制運維鏈路，提供便捷高效的，云端集中式邊緣設備及應用的統一運維管理能力，其核心功能特性如下：

1、邊緣節點自治：在邊緣計算場景，云邊管控網路無法保證持續穩定，通過增強適配解決原生 Worker 作業節點無狀態資料，強依賴 Master 管控節點資料且狀態強一致機制，這些在邊緣場景不適配的問題，從而實作在云邊網路不暢的情況下，邊緣作業負載不被驅逐，業務持續正常服務；即使斷網時邊緣節點重啟，業務依然能恢復正常；即邊緣節點臨時自治能力，

2、協同運維通道：在邊緣計算場景，云邊網路不在同一網路平面，邊緣節點也不會暴露在公網之上，中心管控無法與邊緣節點建立有效的網路鏈路通道，導致所有原生的 Kubernetes 運維 APIs（logs/exec/metrics）失效，適配增強 Kubernetes 能力，在邊緣點初始化時，在中心管控與邊緣節點之間建立反向通道，承接原生的 Kubernetes 運維 APIs（logs/exec/metrics）流量，實作中心化統一運維；

3、邊緣單元化負載：在邊緣計算場景，面向業務一般都是“集中式管控，分散式運行”這種云邊協同分布式架構；對于管理端，需要將相同的業務同時部署到不同地域節點;對于邊緣端，Worker 作業節是一般是分散在廣域空間，并且具有較強的地域性，跨地域的節點之間網路不互通、資源不共享、資源異構等明顯的隔離屬性，適配增強 Kubernetes 能力，基于資源，應用及流量三層實作對邊緣負載進行單元化管理調度，

通過 OpenYurt 開源社區引入更多的參與方共建，聯合研發方式提供更多的可選的專業功能，OpenYurt 特性正在逐步完善，并擴大覆寫能力：

1、邊緣設備管理：在邊緣計算場景，端側設備才是平臺真正的服務物件；基于云原生理念，抽象非侵入、可擴展的設備管理標準模型，無縫融合 Kubernetes 作業負載模型與 IoT 設備管理模型，實作平臺賦能業務的最后一公里，目前，通過標準模型完成 EdgeX Foundry 開源專案的集成，極大的提升了邊緣設備的管理效率，

2、本地資源管理：在邊緣計算場景，將邊緣節點上已有的塊設備或者持久化記憶體設備，初始化成云原生便捷使用的容器存盤，支持兩種本地存盤設備：（一）基于塊設備或者是持久化記憶體設備創建的 LVM；（二）基于塊設備或者是持久化記憶體設備創建的 QuotaPath，

OpenYurt 設計架構及原理

（1）設計架構

原生 Kubernetes 是一個中心式的分布式架構，Master 控制節點負責管理調度及控制集群運行狀態；Worker 作業節點負責運行容器（Container）及監控/上報運行狀態；

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

1、將元資料集中式且強一致的狀態存盤，分散至邊緣節點，并且調整原生 Kubernetes 調度機制，實作自治節點狀態例外不觸發重新調度，以此實作邊緣節點臨時自治能力；

2、保證 Kubernetes 能力完整一致，同時兼容現有的云原生生態體系的同時，盡最大肯能將云原生體系下沉至邊緣；

3、將中心大規模資源池化，多應用委托調度共享資源的模式，適配為面向地域小規模甚至單節點資源，實作邊緣場景下，更精細化的單元化作業負載編排管理；

4、面向邊緣實際業務場景需求，通過開放式社區，無縫集成設備管理、邊緣 AI、流式資料等，面向邊緣實際業務場景的開箱的通用平臺能力，賦能更多的邊緣應用場景，

（2）實作原理

OpenYurt 踐行云原生架構理念，面向邊緣計算場景實作云邊協同分布式架構及中心管控邊緣運行的能力：

• 針對邊緣節點自治能力，一方面，通過新增 YurtHub 組件實作邊緣向中心管控請求（Edge To Cloud Request）代理，并快取機制將最新的元資料持久化在邊緣節點；另一方面新增 YurtControllerManager 組件接管原生 Kubernetes 調度，實作邊緣自治節點狀態例外不觸發重新調度；

• 針對 Kubernetes 能力完整及生態兼容，通過新增 YurtTunnel 組件，構建云邊（Cloud To Edge Request）反向通道，保證 Kubectl，Promethus 等中心運維管控產品一致能力及用戶體驗；同時將中心其他能力下沉至邊緣，包含各不同的作業負載及 Ingress 路由等；

• 針對邊緣單元化管理能力，通過新增 YurtAppManager 組件，同時搭配 NodePool,YurtAppSet （原UnitedDeployment），YurtAppDaemon,ServiceTopology 等實作邊猿澩，作業負載及流量三層單元化管理；

• 針對賦能邊緣實際業務平臺能力，通過新增 NodeResourceManager 實作邊緣存盤便捷使用，通過引入YurtEdgeXManager/YurtDeviceController 實作通過云原生模式管理邊緣設備，

核心組件

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

1．YurtHub(必選)：有邊緣 (edge) 和云中心 (cloud) 兩種運行模式；以 Static Pod 形態運行在云邊所有節點上，作為節點流量的 SideCar，代理節點上組件和 kube-apiserver 的訪問流量，其中邊緣 YurtHub 會快取的資料，實作臨時邊緣節點自治能力，

2．YurtTunnel(必選)：由 Server 服務端與 Agent 客戶端組成，構建雙向認證加密的云邊反向隧道，轉發云中心 (cloud) 到邊緣 (edge) 原生的 Kubernetes 運維 APIs（logs/exec/metrics）請求流量，其中 Server 以 Deployment 作業負載部署在云中心，Agent 以 DaemonSet 作業負載部署在邊緣節點，

3．YurtControllerManager(必選)：云中心控制器，接管原生 Kubernetes 的 NodeLifeCycle Controller，實作在云邊網路例外時，不驅逐自治邊緣節點的Pod應用；還有 YurtCSRController，用以審批邊緣節點的證書申請，

4．YurtAppManager(必選)：實作對邊緣負載進行單元化管理調度，包括 NodePool：節點池管理；YurtAppSet：原 UnitedDeployment，節點池維度的業務負載；YurtAppDaemon：節點池維度的 Daemonset 作業負載，以 Deploymen 作業負載部署在云中心，

5．NodeResourceManager(可選)：邊緣節點本地存盤資源的管理組件，通過修改 ConfigMap 來動態配置宿主機本地資源，以 DaemonSet 作業負載部署在邊緣節點，

6．YurtEdgeXManager/YurtDeviceController(可選):通過云原生模式管控邊緣設備，當前支持 EdgeX Foundry的集成，YurtEdgeXManager 以 Deployment 作業負載署在云中心，YurtDeviceController 以 YurtAppSet 作業負載署部署在邊緣節點，并且以節點池 NodePool 為單位部署一套 YurtDeviceController 即可，

7．運維管理組件(可選)：為了標準化集群管理，OpenYurt 社區推出 YurtCluster Operator 組件，提供云原生聲名式 Cluster API 及配置，基于標準 Kubernetes 自動化部署及配置 OpenYurt 相關組件，實作 OpenYurt 集群的全生命周期，舊 Yurtctl 工具建議只在測驗環境使用，

除了核心功能及可選的專業功能外，OpenYurt 持續貫徹云邊一體化理念，將云原生豐富的生態能力最大程度推向邊緣，已經實作了邊緣容器存盤，邊緣守護作業負載 DaemonSet，邊緣網路接入 Ingress Controller 等，還有規劃中的有 Service Mesh，Kubeflow，Serverless 等功能，拭目以待，

當前挑戰

（1）云邊網路

在邊緣計算場景中，被提到最多的就是云邊網路差且不穩定，其實國內基礎網路在 2015 年開始全面升級，尤其是在“雪亮工程”全面完成之后，基礎網路有一個很大的提升，上圖摘自《第 48 次中國互聯網路發展狀況》報告，固網 100Mbps 接入占比已達 91.5%；無線網路接入已經都是 4G，5G 的優質網路，

而真正的挑戰在云邊網路組網，對于使用公有云的場景：公有云屏蔽資料中心網路，只提供了互聯網出口帶寬，通過互聯網打通云邊，通常只需要解決資料安全傳輸即可，接入不復雜，對于私有自建的 IDC 場景：打通云邊網路并不容易，主要是運營商網路沒有完全產品化，同時私有 IDC 層層防火墻等其他復雜產品，需要專業的網路人員才能完成實施作業，

（2）list-watch 機制與云邊流量

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

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

（3）邊猿澩和算力

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

（4）Kubelet 比較重，運行占用資源多

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

1. 運行作業系統和系統守護行程（如 SSH、systemd 等）所需的資源；
2. 運行 Kubernetes 代理所需的資源，如 Kubelet、容器運行時、節點問題檢測器等；
3. Pod 可用的資源；
4. 保留到驅逐閾值的資源，

對于各層的資源分配設定的沒有標準，需要根據集群的情況來權衡配置，Amazon Kubernetes 對 Kubelet 資源配置演算法是 Reserved memory = 255MiB + 11MiB * MAX_POD_PER_INSTANCE；假設運行32 Pods，高達 90% 的記憶體都可以分配給業務使用，相對來說 Kubelet 資源占用并不高，

同時也要結合業務對高可用的要求,做回應的調整，針對邊緣場景，一般不建議在一個節點上運行大量的Pods 穩定為大，

業務應用的云邊管運協同模型

基于中心云的分布式業務應用架構，與云邊分布式協同業務應用架構本質上有很大差別，在中心云更多的是基于 DDD 業務領域，將復雜的業務系統拆分成一個個相對獨立的服務，整體構建一個松耦合的分布式應用；但在云邊分布式場景下，更多強調的是集中式管控運營，分散式運作支撐，將管理運營系統集中在云中心，實作中心式管控，將支撐業務實時運作的應用分散至邊緣，實作低延遲快速回應，

從業務應用來看，財務/經營，計劃/管理兩層屬于管控運營類的應用，就是需要通過中心云統一匯聚，實作集中化強管控；對延遲不敏感，對安全，大資料分析能力等要求較高；控制，傳感/執行，生產程序三層屬于運作支撐類應用，也可以優先考慮中心云；如果業務場景對延遲敏感，才考慮通過邊緣計算能力，實作分散式低時延回應；

從請求回應來看，對時延不敏感（50ms 以上）都有限考慮部署在中心云計算及云化的邊緣產品（CDN）實作；對延遲敏感（小于10ms ），運營商骨干網完全無法支持的，考慮建設邊緣計算平臺，同時業務面臨不小的投入及人員；

以物體物流領域為例，經典的 OTW 系統（OMS 訂單管理系統，WMS 倉庫管理系統，TMS 運輸管理系統）其中 OT 就屬于典型的管理運營系統，所以建議部署在中心云，通過中心云資料匯聚，實作拼單拆單，多式聯運等跨區域業務；W 是倉庫管理系統，管理四面墻的任務，屬于運作支撐應用，并且倉庫一般都有一些自動化設備，就可以考慮將 W 部署在邊緣，

總結

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

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

戳此處，立即了解 OpenYurt 專案！

發布云原生技術最新資訊、匯集云原生技術最全內容，定期舉辦云原生活動、直播，阿里產品及用戶最佳實踐發布，與你并肩探索云原生技術點滴，分享你需要的云原生內容，

關注【阿里巴巴云原生】公眾號，獲取更多云原生實時資訊！

標籤：其他

上一篇：醫院安防系統為何要GPS北斗衛星同步時鐘（NTP服務器）

下一篇：深度決議｜基于 eBPF 的 Kubernetes 一站式可觀測性系統