作者?|?何淋波（新勝）
來源|阿里巴巴云原生公眾號

隨著云原生技術的逐步成熟，阿里云容器服務團隊在具體落地實踐過程中不斷探索云原生技術的應用邊界。同時隨著物聯網和 5G 的迅猛發展，傳統的邊緣計算架構已經不能滿足業務發展的需要。

如何基于云原生技術構建新一代的邊緣計算平臺成為行業的新焦點。如何解決云邊協同，邊緣自治等業界難題來幫助開發者輕松完成在海量邊，端資源上大規模應用的交付、運維、管控？我們構建并開源了 OpenYurt：業內首個基于原生 Kubernetes 構建的、對于 Kubernetes 非侵入式的邊緣計算項目，無縫的融合了云原生和邊緣計算，目前已經在萬臺邊緣節點規模場景下落地實踐。本文將介紹如何融合云原生技術和邊緣計算，解決大規模應用的交付、運維、管控。

邊緣計算

首先，我們從直觀感受上看看什么是邊緣計算。隨著 5G、IoT、音視頻、直播、CDN 等行業和業務的發展，我們看到一個行業趨勢，就是越來越多的算力和業務開始下沉到距離數據源或者終端用戶更近的地方，從而來獲得更好的響應時間和更低的計算成本，這明顯區別傳統的中心式的云計算模式，并越來越被廣泛應用于汽車、農業、能源、交通等各行各業。邊緣計算，總結為一句話“讓計算離數據和設備更近”。

再從 IT 架構上看邊緣計算，可以看到它具有明顯的按照業務時延和計算形態來確定的分層結構，這里分別引用 Gartner 和 IDC 對邊緣計算架構的解釋：Gartner 將邊緣計算分為“Near Edge”、“Far Edge”、“Cloud”三部分，分別對應常見的設備終端，云下 IDC/CDN 節點，以及公共云/私有云；而 IDC 則將邊緣計算定義為更直觀的“Heavy Edge”、“Light Edge”來分別表示數據中心維度、低功耗計算的端側。從圖中我們可以看到分層結構中，層層相依，互相協作。這種定義也是現在業界對邊緣計算和云計算關系所達成的一個共識，接下來再看看邊緣計算的趨勢。

去分析一個 IT 行業的趨勢，通常包括業務、架構和規模三個維度；邊緣計算的三大趨勢是：

• 第一，AI、IoT 與邊緣計算的融合，會有種類越來越多、規模越來越大、復雜度越來越高的業務運行在邊緣計算場景中，從圖上我們也能看到一些非常震撼人心的數字。

• 第二，邊緣計算作為云計算的延伸，將被廣泛應用于混合云場景，這里面需要未來的基礎設施能夠去中心化、邊緣設施自治、邊緣云端托管能力，同樣圖上也有部分引用數字。

• 第三個場景趨勢是基礎設施的發展將會引爆邊緣計算的增長，隨著 5G、IoT、音視頻行業的發展，邊緣計算的爆發是理所當然，今年疫情期間在線直播、在線教育行業的爆發式增長也是一個例子。

隨著架構的共識形成，落地過程中我們發現，邊緣計算的規模、復雜度正逐日攀升，而短缺的運維手段和運維能力也終于開始不堪重負，那么如何去解這個問題呢？“云邊端一體“的運維協同是目前比較能形成共識的一種方案。

云邊一體的邊緣云原生

作為云原生領域的從業人員，我們試著從云原生的角度來思考和解決這些問題：

首先我們一起回顧下云原生的定義和技術體系，眼下，云原生已經作為一系列的工具、架構、方法論而深入人心，并廣泛使用；那么云原生到底是如何定義的呢？早期，云原生含義包括：容器、微服務、DevOps、CI/CD；18 年以后 CNCF 又加入了服務網格和聲明式 API。而回過頭，我們再粗線條的看看云原生的發展歷史，早期因為 Docker 的出現，大量的業務開始容器化、Docker 化，容器化通過統一交付件、隔離性從而帶來了 DevOps 的快速發展；Kubernetes 的出現讓資源編排調度與底層基礎設施解耦，應用和資源的管控也開始得心應手；隨后，以 Istio 為代表的服務網格技術解耦了服務實現與服務治理能力。越來越多的企業、行業開始擁抱云原生。

接下來聊下阿里云的云原生產品家族。阿里云作為云原生的踐行者，不論是集團內部全面上云，還是為廣大的客戶提供豐富的云原生業務，都是擁抱云原生最好的佐證；我們堅信云原生是未來；云原生技術已經無處不在, 作為云原生服務的提供者，我們認為云原生技術會繼續高速發展，并被應用于“新的應用負載” ，“新的計算形態”和“新的物理邊界”；從阿里云云原生產品家族大圖中我們可以看到：容器正被用于越來越多類型應用和云服務中；并且通過越來越多的計算形態承載，如 Serverless，函數計算等等；而豐富的形態也開始從傳統的中心云走向邊緣計算，走向終端。

在中心云的標準托管架構下，我們抽象出了云邊端協同的云原生架構：在中心（云），我們保留了原汁原味的云原生管控和產品化能力，通過云邊管控通道將之下沉到邊緣，使海量邊緣節點和邊緣業務搖身一變成為云原生體系的工作負載，通過服務流量和服務治理更好的和端進行交互；從而完成業務、運維、生態的一體化。

那么，通過云邊一體架構我們可以有哪些收益呢；首先，云上云下通過云原生體系實現云邊一體化融合，從而為用戶在任何基礎設施上提供和云上一致的功能和體驗，實現云邊端一體化的應用分發，容器化的隔離特性、流量控制，網絡策略等等能力讓工作負載的運行更加安全；“云邊端一體”有云原生的加持，將會更好的加速多云，云邊融合進程。

聊完云邊一體的云原生基礎設施之后，接下來聊下云原生和邊緣計算融合的難點，在實際落地過程中，我們主要識別了下面幾個問題：

• 邊緣計算規模和業務復雜，采取原生 Kubernetes 的 workload 管理模型遠不能滿足現實需求。

• 云邊網絡通過公網相連，網絡連接有很大不可控因素，可能帶來邊緣業務運行的不穩定因素。

• 由于邊緣節點一般位于用戶網絡的防火墻內部，從而造成云邊網絡只能單向連通的客觀條件，因此給原生的 Kubernetes 運維監控帶來很大挑戰。

• 最后是邊緣資源種類多樣，系統可能是 Linux/Windows，架構也可能是 amd64/arm/arm64 等等，從而給邊緣標準化支持帶來巨大挑戰。

OpenYurt 邊緣計算云原生平臺

接下來我們看下 OpenYurt，業界首個非侵入式 Kubernets 的邊緣計算云原生開源平臺。

OpenYurt 是一個典型的“中心-邊緣”簡潔架構。如架構圖所示：邊緣和云之間通過公網連接，其中藍色框是原生 Kubernetes 的組件，橙色框是 OpenYurt 的組件。基于 Kubernetes 強大的插件化，Operator 能力，OpenYurt 保證對 upstream kubernetes 的零修改，因此保證了 OpenYurt 可以跟隨社區同步演進，并且保證和云原生社區主流技術的兼容。OpenYurt 項目在 2020 年 9 月份已經捐給 CNCF，也保證了項目的中立性。同時 OpenYurt 目前在阿里內部已經大規模使用，管理了數百萬核的規模，場景上覆蓋了 CDN，物聯網，音視頻，邊緣AI等多種場景。也意味著 OpenYurt 的品質和穩定性已經有足夠驗證。

OpenYurt 目前已經發布三個版本，具備如下能力：邊緣單元化、邊緣自治、云邊協同、無縫轉換能力、異構資源（amd64/arm/arm64）支持能力、云上云下業務彈性和互通能力等。

單元化管理能力用于解決前面提到的融合難點 1，主要是對節點提供分組、批量管理能力，并在分組內對應用編排部署、業務流量做更精細化管控，比如為了業務流量的安全、效率考慮可以將業務流量現在在某一個單元內；或者為了批量管理某一個區域內的節點，打標簽，配置調度策略等等；相關能力由 yurt-app-manager 組件提供。

邊緣自治能力用于解決前面提到的融合難點 2，主要是云邊網絡斷開或者連接不穩定時，確保邊緣業務可以持續運行；相關能力由 yurt-controller-manager 和 YurtHub 組件提供。另外下個版本中還會繼續增強邊緣自治能力。

云邊協同能力用于解決前面提到的融合難點 3，主要是由于邊緣節點位于用戶內網，無法從云端訪問時，造成原生 Kubernetes 運維能力（如 kubectl logs/exec/port-forward，Prometheus 等）無法支持。云邊協同能力通過云邊隧道解決云邊網絡只能單向通，從而支持原生 Kubernetes 運維能力。相關能力由 tunnel-server/tunnel-agent 組件提供。

無縫轉換能力用于部分解決融合難點 4，主要用于標準 Kubernetes 和 OpenYurt 集群之間的一鍵式轉換，目前在 Minikube，Kubeadm，ACK 等工具部署的集群上完整驗證過。也歡迎有興趣的同學來支持和貢獻其他工具部署的集群。相關能力由 yurtctl 組件提供。

OpenYurt 案例介紹

接下來我們介紹一下 OpenYurt 的實踐案例。

第一個，是盒馬鮮生基于邊緣云原生實現的“人貨場”數字化融合轉型，通過云原生體系將多種類型的邊緣異構算力統一接入、統一調度，包括：ENS（阿里公共云邊緣節點服務、線下自建邊緣網關節點，GPU 節點等）。獲取了強大的資源彈性和業務混編帶來的靈活性。

第二個，是交通領域的視頻上云場景，通過云邊端一體化協同，融合了中心云大交通智慧能力，邊緣 CDN/ENS 等算力資源，給業務提供就近接入的資源能力；視頻采集端設備的統一管理。邊緣云原生的調度、編排、服務管理等能力穿插其中，三層融合。

最后，OpenYurt 還是一個比較初期的 CNCF 官方邊緣計算云原生項目，需要大家的支持和幫助，也歡迎大家參與?OpenYurt 社區共建。

Q?& A

Q：YurtHub 代理實現機制，需要修改什么配置嗎？
A：主要是邊緣節點上組件的云端訪問地址需要調整為本地 YurtHub 監聽地址（http://127.0.0.1:10261），其他配置不用修改。

Q：和 KubeEdge 的優劣對比分析？
A：首先這個問題可能第三方來評價會客觀一點，有興趣看下知乎這篇文章：《家里的樹莓派，如何加入阿里云搭建的 K8s 集群？》。不過站在程序員或者云原生開發者角度，也可以談一點個人的看法：OpenYurt 對 Kubernetes 零修改，通過 Kubernetes 的插件和 Operator 機制進行增強，因此對原生 Kubernetes 使用者會比較友好。而 KubeEdge 對 Kubernetes 有比較大的修改（kubelet/kube-proxy/list-watch 機制等重寫了），對原生 Kubernetes 使用者的友好性會弱一點。當然還有不少其他差別，時間有限，有興趣的同學可以自行研究。

Q：想問問貴司在萬臺規模的機器采用了哪些版本系統呢？內核有什么要求嗎？
A：目前主要是 AliOS，CentOS，以及 Ubuntu，內核版本基本在 3.10 以上。

Q：請問案例 1 和 2 分別是什么樣的節點規模？
A：集群規模都在 100+ 以上。

Q：請問案例 1 中的 GPU 節點主要是什么功能？
A：案例 1 的 AI 訓練是云端完成的，GPU 節點主要做推理相關的任務。

Q：如果中心和邊緣徹底網絡斷開了，邊緣側是否可以繼續持久運作？
A：節點重啟或者業務重啟的狀態下，業務是可以持續運行的。如果出現節點宕機的情況下，云端還無法準確識別并在其他正常節點重建，這個會在下個版本解決。

Q：請問目前阿里內部是否會有專門的技術、產品等團隊來支撐？
A：目前阿里云容器服務產品 ACK@Edge 是基于 OpenYurt 開源項目來實現的，因此是有專門團隊來統一支撐的。

Q：請問邊緣側的 CPU 是否有限制？端側呢？例如 arm。
A：邊緣側 CPU 架構目前支持 amd64/arm/arm64。端側主要是設備端，由運行在 OpenYurt 邊緣節點上的業務負責。所以端側目前不在 OpenYurt 的覆蓋范圍內。

Q：請問對未來 3 年內，邊緣這一塊的主流應用場景在哪一塊，怎么看？
A：這是一個好問題，目前能確定的是像 CDN，邊緣 AI，音視頻，5G MEC，IOT 等已經在大規模鋪開邊緣計算云原生方案。其他像后續的車聯網，云游戲，其他傳統行業（如農業，能源等）都在逐步展開，總之邊緣這快 ToB 屬性比較強。

Q：現在 Kubernetes 場景已經覆蓋的場景大概能占總邊緣場景的多少百分比呢？估計。
A：這個很難講，我個人覺得目前比例應該很低，整個邊緣計算場景的數字化轉型應該剛剛開始。相信這是一個會持續可以做 20 年的行業^-！

分享人簡介

何淋波（花名：新勝），來自于阿里云容器服務團隊，OpenYurt 作者&初創成員之一。2015 年開始從事 Kubernetes 相關產品的設計，研發，開源等工作，先后負責和參與物聯網邊緣計算，邊緣容器服務，OpenYurt 等相關項目。

內容來源：Dockone

點擊訪問“Kubernetes 與云原生應用更多開源實踐”大講堂，4 次開源技術直播， 60+ 節 Kubernetes 經典課程，3 本云原生電子書，將前沿的容器技術和開源實踐一網打盡!

總結

以上是生活随笔為你收集整理的OpenYurt：延伸原生 Kubernetes 到边缘场景下的落地实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。