作者 | 何淋波（新勝）
來源|
阿裡巴巴雲原生公衆号随着雲原生技術的逐漸成熟，阿裡雲容器服務團隊在具體落地實踐過程中不斷探索雲原生技術的應用邊界。同時随着物聯網和 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 本雲原生電子書，将前沿的容器技術和開源實踐一網打盡!