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

頭圖.png

作者 | 何淋波(新勝)
來源|阿里巴巴雲原生公衆號

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

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

邊緣計算

1.png

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

2.png

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

3.png

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

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

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

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

4.png

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

雲邊一體的邊緣雲原生

作爲雲原生領域的從業人員,我們試着從雲原生的角度來思考和解決這些問題:

5.png

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

6.png

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

7.png

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

8.png

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

9.png

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

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

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

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

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

OpenYurt 邊緣計算雲原生平臺

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

10.png

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

11.png

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

12.png

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

13.png

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

14.png

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

15.png

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

OpenYurt 案例介紹

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

16.png

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

17.png

第二個,是交通領域的視頻上雲場景,通過雲邊端一體化協同,融合了中心雲大交通智慧能力,邊緣 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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章