![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/c9ce077bde684f9f879562611c436ebb.png)

作者 | 何淋波（新勝）
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/AL-YiwocpKkECOgCAhJqrw)

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

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

# 邊緣計算

![1.png](https://ucc.alicdn.com/pic/developer-ecology/953d873da94d48acb465862d5da15fb1.png)

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

![2.png](https://ucc.alicdn.com/pic/developer-ecology/fff8a267c06248cf8f8c98adc9ce5f98.png)

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

![3.png](https://ucc.alicdn.com/pic/developer-ecology/77be46224f7a4006a8ec18dd24a26567.png)

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

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

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

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

![4.png](https://ucc.alicdn.com/pic/developer-ecology/20dca15e9c664869a028c46a0a78a088.png)

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

# 雲邊一體的邊緣雲原生

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

![5.png](https://ucc.alicdn.com/pic/developer-ecology/51d07ecc7dff423dbc3a53bca6409b4f.png)

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

![6.png](https://ucc.alicdn.com/pic/developer-ecology/f36b0dbb23c04c939bef008d01e5f7a2.png)

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

![7.png](https://ucc.alicdn.com/pic/developer-ecology/d27e75c51ac8455483a74a90f75d21f8.png)

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

![8.png](https://ucc.alicdn.com/pic/developer-ecology/0f3991a834874abc8d57f63652da4667.png)

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

![9.png](https://ucc.alicdn.com/pic/developer-ecology/97b5c424f799423d9f8013197435843b.png)

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

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

- 雲邊網路透過公網相連，網路連線有很大不可控因素，可能帶來邊緣業務執行的不穩定因素。

- 由於邊緣節點一般位於使用者網路的防火牆內部，從而造成雲邊網路只能單向連通的客觀條件，因此給原生的 Kubernetes 運維監控帶來很大挑戰。

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

# OpenYurt 邊緣計算雲原生平臺

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

![10.png](https://ucc.alicdn.com/pic/developer-ecology/e85c91a4a511447bb1bdd800256e3041.png)

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

![11.png](https://ucc.alicdn.com/pic/developer-ecology/a17b5a56501e4a23912750cd285d8d98.png)

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

![12.png](https://ucc.alicdn.com/pic/developer-ecology/4903d83eb55a43b2a6800b7b6908b980.png)

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

![13.png](https://ucc.alicdn.com/pic/developer-ecology/05e81a5e3b7649538eb329ef4766a931.png)

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

![14.png](https://ucc.alicdn.com/pic/developer-ecology/7e409580bca24fa9aba8b612c22e8f8f.png)

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

![15.png](https://ucc.alicdn.com/pic/developer-ecology/d7d45e02e7f74096bd296b8119a4e288.png)

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

# OpenYurt 案例介紹

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

![16.png](https://ucc.alicdn.com/pic/developer-ecology/3950eb4abc2c4959bff66c560db48d87.png)

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

![17.png](https://ucc.alicdn.com/pic/developer-ecology/481daf72dd804fdf9e1070310df1d375.png)

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

最後，OpenYurt 還是一個比較初期的 CNCF 官方邊緣計算雲原生專案，需要大家的支援和幫助，也歡迎大家參與 OpenYurt 社群共建。

# Q & A

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

**Q**：和 KubeEdge 的優劣對比分析？
**A**：首先這個問題可能第三方來評價會客觀一點，有興趣看下知乎這篇文章：《[家裡的樹莓派，如何加入阿里雲搭建的 K8s 叢集？》](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247500490&idx=2&sn=9a5379a69e7decf392737c7384055906&chksm=fae6c905cd914013ac56d52eb05b68f8ae3d6a1a3f159b09ab48cbff1377264768462e9817d4&token=1709676676&lang=zh_CN)。不過站在程式設計師或者雲原生開發者角度，也可以談一點個人的看法：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 與雲原生應用更多開源實踐”大講堂**](https://developer.aliyun.com/topic/k8s/practices)，4 次開源技術直播， 60+ 節 Kubernetes 經典課程，3 本雲原生電子書，將前沿的容器技術和開源實踐一網打盡!

OpenYurt：延伸原生 Kubernetes 到邊緣場景下的落地實踐

相關文章