作者：段嘉，新勝
雲端計算髮展史，就是虛擬化技術的發展史。近 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 比較重，執行佔用資源多的問題，需要深入瞭解節點資源分配及使用情況，通常節點的資源自下而上分為四層：
- 執行作業系統和系統守護程式（如 SSH、systemd 等）所需的資源；
- 執行 Kubernetes 代理所需的資源，如 Kubelet、容器執行時、節點問題檢測器等；
- Pod 可用的資源；
- 保留到驅逐閾值的資源。
對於各層的資源分配設定的沒有標準，需要根據叢集的情況來權衡配置，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 專案！