雲邊一體--如何基于标準k8s打造邊緣計算雲原生基礎設施

引言

雲原生的理念如今正如火如荼。它不僅僅是一種技術，更是随着雲生态的發展而被逐漸提煉出的一系列技術、最佳實踐與方法論的集合；它帶來了資源使用率提升、分布式系統的彈性擴充與可靠性等能力，能夠讓IT系統最大程度的享受雲計算紅利，業界全面擁抱雲原生就是最好的佐證。

伴随5G、IoT的發展，邊緣計算正在成為雲計算的新邊界，而規模和複雜度的日益提升對邊緣計算的效率，可靠性，資源使用率等一系列能力又有了新的訴求。試想，如果能将雲能力從中心往邊緣觸達，上述問題是不是将迎刃而解？那麼在雲原生時代建構雲到邊的觸達通路，保持雲邊一緻性體驗，我們的抓手又在哪裡呢？本次分享将一一為你揭曉。

雲原生概念

雲原生的概念最早是在2013年被提出，經過這幾年的發展，尤其是從 2015 年 Google 牽頭成立 CNCF 以來，雲原生技術開始進入公衆的視線并逐漸演變成包括 DevOps、持續傳遞、微服務、容器、基礎設施，Serverless，FaaS等一系列的技術，實踐和方法論集合。伴随着技術的普及，與之相配套的團隊建設，技術文化，組織架構和管理方法也呼之欲出。越來越多的企業選擇雲原生建構其應用來獲得更好的資源效率和持續的服務能力。相比較過往着力雲原生概念的普及、了解和力求共識，雲原生落地已經成為現如今I/CT日常主旋律。

雲原生的技術範疇包括了以下幾個方面：雲應用定義與開發、雲應用的編排與管理、監控與可觀測性、雲原生的底層技術（比如容器運作時、雲原生存儲技術、雲原生網絡技術等）、雲原生工具集、Serverless。雖然，CNCF以目前200多個項目和産品（CNCF雲原生全景

https://github.com/cncf/landscape

） 的巨大體量保持高速發展，不斷壯大雲原生體系的技術集合，但所有項目基本都在上述技術範疇中，緊守雲原生理念不放；

那麼雲原生的核心優勢到底有哪些，能帶給我們真實體感又是什麼？

引用CNCF的重新定義："Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil."

雲原生和邊緣基礎設施

在雲計算真正普及之前，擷取基礎設施能力（比如服務發現、流量控制、監控與可觀測性、通路控制、網絡控制、存儲層抽象等）需要應用通過某種抽象或接口方式，使得兩者之間是非常緊密的耦合關系，應用本身的能力和演進需要強依賴基礎設施。而在雲原生時代，類似kubernetes這樣的标準化資源抽象、編排、整合平台促進基礎設施能力正在不斷下沉，雲能力和應用之間的隔閡也正在雲原生技術體系下被不斷瓦解。“面向雲架構”、“面向雲程式設計”的呼聲日漸高漲的同時，cloudnative的雲基礎設施越來越“友好”。但是，雲原生基礎設施概念遠遠超出公有雲上運作的基礎設施範疇。

“軟硬體技術的成熟、巨大的社會價值和偉大的商業模式”造就了雲計算的興起和蓬勃發展，迅猛的勢頭也催生了各種新型技術架構的誕生，筆者認為雲原生的出現同樣是順應了技術和商業的浪潮。

放眼當下，随着網際網路智能終端裝置數量的急劇增加和資料、業務下沉的訴求增多，邊緣計算規模和業務複雜度已經發生了翻天覆地的變化，邊緣智能、邊緣實時計算、邊緣分析等新型業務不斷湧現。傳統雲計算中心集中存儲、計算的模式已經無法滿足邊緣裝置對于時效、容量、算力的需求，如何打造邊緣基礎設施成了一個新課題。

本次分享也是從這個問題出發，和大家一起探讨雲原生基礎設施在邊緣計算落地的可能性。

試想，從雲到端，是否能将雲計算的能力下沉到邊緣側、裝置側，并通過中心進行統一傳遞、運維、管控，通過粘合雲計算核心能力和邊緣算力，構築在邊緣基礎設施之上的雲計算平台？在回答這個問題之前，我們先梳理一下邊緣計算可能面臨的一些挑戰：

• 雲邊端協同：缺少統一的傳遞、運維、管控标準。
• 安全：邊緣服務和邊緣資料的安全風險控制難度較高。
• 網絡：邊緣網絡的可靠性和帶寬限制。
• 異構資源：對不同硬體架構、硬體規格、通信協定的支援，以及基于異構資源、網絡、規模等差異化提供标準統一的服務能力的挑戰。

這些問題雲原生模式能解嗎，雲原生的技術底座kubernetes能撐起大梁嗎？衆所周知，以Kubernetes為基礎的雲原生技術，核心價值之一是通過統一的标準實作在任何基礎設施上提供和雲上一緻的功能和體驗：那麼借助雲原生技術，可以實作雲-邊-端一體化的應用分發，解決在海量邊、端裝置上統一完成大規模應用傳遞、運維、管控的訴求是不是就有可能；同時在安全方面，雲原生技術可以提供容器等更加安全的工作負載運作環境，以及流量控制、網絡政策等能力，能夠有效提升邊緣服務和邊緣資料的安全性；而依托雲原生領域強大的社群和廠商支援，雲原生技術對異構資源的适用性逐漸提升，在物聯網領域，雲原生技術已經能夠很好的支援多種CPU架構(x86-64/arm/arm64)和通信協定，并實作較低的資源占用。k8s雖好，但落地邊緣計算場景好像還有一段路要走。

Kubernetes概念

基本概念

“Kubernetes——讓容器應用進入大規模工業生産，已然成了容器編排系統的事實标準；”下圖是kubernetes架構圖（圖文引用自

https://jimmysong.io/kubernetes-handbook/cloud-native/from-kubernetes-to-cloud-native.html

）

• 核心層：Kubernetes最核心的功能，對外提供API建構高層的應用，對内提供插件式應用執行環境
• 應用層：部署（無狀态應用、有狀态應用、批處理任務、叢集應用等）和路由（服務發現、DNS解析等）
• 管理層：系統度量（如基礎設施、容器和網絡的度量），自動化（如自動擴充、動态Provision等）以及政策管理（RBAC、Quota、PSP、NetworkPolicy等）
• 接口層：kubectl指令行工具、用戶端SDK以及叢集聯邦
• 生态系統：在接口層之上的龐大容器叢集管理排程的生态系統，可以劃分為兩個範疇
• Kubernetes外部：日志、監控、配置管理、CI、CD、Workflow、FaaS、OTS應用、ChatOps等
• Kubernetes内部：CRI、CNI、CVI、鏡像倉庫、Cloud Provider、叢集自身的配置和管理等

Kubernetes落地形态

随着kubernetes的普及，越來越來的上層系統開始搭建在kubernetes底座之上，比如CICD、Serverless、IoT、PaaS等業務。過往經驗告訴我們，在享受kubernetes帶來的友善快捷內建體驗的同時，kubernetes的自身運維也帶來了額外的巨大工作量：kubernetes的更新、高可用部署，資源對接、監控、事件告警、多租管理等等。是以，專門的運維團隊，運維工具，以及公有雲托管服務就應運而生了，這也是目前業界kubernetes幾種常見的服務形态。

先說說公共雲托管kubernetes服務，目前主流雲廠商基本上都推出了XKS/XCK的服務，雖然底層實作各異，但是都有着類似的使用者體驗。使用者隻需要在雲廠商界面送出叢集配置，點選購買按鈕，一個高可用的，無縫對接各種雲資源，雲服務的kubernetes叢集就能夠在3-5分鐘内被建立出來；且後續的叢集更新、運維、擴縮容等等運維操作都是動動小手的白屏化操作，體驗簡潔到極緻。kubernetes強大接口能力也能夠讓使用者快速便捷的按需使用上各廠商的IaaS資源。綜合各種因素，公共雲托管kubernetes服務正成為大多數使用者的選擇。但往往也有出于各種資料安全、叢集規模、價格因素等等考慮，部分使用者也會選擇自建或者使用雲廠商的專有雲kubernetes版本、混合雲版本。如果從kubernetes層面考量，三者本質都大同小異，依賴第三方提供一個穩定、相容、安全可以持續發展的商業化kubernetes底座，以期得到規模化、标準化的k8s服務能力。

重新回到前面的問題，邊緣計算基礎設施既要雲原生，又要雲邊一體，還要一緻性體驗，那麼使用雲端托管、邊緣定制會不會是一個很好的選擇呢？接下來展開叙述。

雲端管控、邊緣自治

“雲邊端一體化協同”作為标準化的一個構想，将标準化的雲原生能力向邊緣端複制，需要分為三個層次：

• 第一個層次是能夠在雲端提供标準化的接口、管控能力，或者是标準的雲服務和雲資源的接入能力。其中我們能夠看到 Kubernetes 的身影；
• 第二個層次是能夠高效的管理處在整個邊緣端的衆多資源，其中包括在邊緣端應用的效率問題。
• 第三層次是典型的 IoT 場景中的端裝置，例如智慧樓宇智能停車裝置，藍牙裝置、人臉識别裝置等。

  

雲端托管原生k8s

先看最核心的雲端托管層，在雲邊一體的設計理念中，自然而然的能夠聯想到将原生的标準k8s托管在公共雲上，開箱即用各種被內建的雲能力必定是不二之選。幾點原因，k8s免運維上面已經談到，原生的k8s便于被上層業務系統內建卻常常被忽視，通過雲廠商将kubernetes和其他雲能力（彈性、日志監控、應用市場，鏡像服務等）打通，無論是終端使用者直接使用，還是做新業務創新，複雜度都大大降低；此外，将雲管控作為中心式服務，通過提供統一管控能力，反而非常适合管理邊緣場景中零散分布的計算資源和應用，比如CDN服務、IoT業務等；最後，雲原生的方式又可以讓使用者以往K8s經驗用于新的邊緣計算業務。

上圖所示的管控架構也符合前文提到的雲邊分層結構：“分而自治，中心管控”。

适度定制适配邊緣場景

k8s除了上述諸般特征之外，還有一個強大的插件機制，CxI自不必說，CRD、Operator更是讓k8s如虎添翼。在面向邊緣場景，自然而然會有一些别樣的邏輯需要适配，例如：邊緣節點和雲端管控走弱連接配接公網互動帶來的管理邏輯适配；邊緣節點應用驅逐邏輯适配；邊緣節點支援原生運維接口适配等等。插件化的非侵入方式可以讓原生k8s在免受任何一丁點的沖擊的同時，擴充更多的邏輯，比如用來做邊緣單元化管理的EdgeUnit Operator，再比如做邊緣節點自治管理的EdgeNode Operator。

前文提到，邊緣托管叢集要将運維能力統一收編到雲端，中心式的運維能力高效又便捷；是以，除了各種控制器之外，雲端還有各種運維控制器來做日志、監控資料等請求的轉運，如：日志控制器，MetricServer等；EdgeTunnelServer提供了一條穩健的反向資料通道，很多雲到邊的請求都要從此經過，至于它的用途後面分解；

自治

如上圖所示，每個Edge節點上配備了一個EdgeHub元件，邊緣節點自治離不開它。

先說說背景，衆所周知k8s原生設計為資料中心内部的容器編排系統（DCOS），預設網絡可靠、可信。管控端（apiserver、排程器，資源控制器）源源不斷收集節點心跳做相應的排程決策，若worker節點和管控斷鍊，原生k8s管控就要将節點置為不可用、并驅逐應用（容忍時間到了之後）。而這些看似再正常不過的業務邏輯，在邊緣場景确是萬萬不可接受的。

在“分而自治，中心管控”的設計理念下，woker節點和中心管控走弱連結的公網互動，各種環境、網絡、人為因素都會帶來網絡的抖動，甚至不可用。但是此時，邊緣節點上的業務和agent卻要能夠持續提供服務，這就是自治。概括起來還包括，worker節點和雲端斷連後：

• 節點上agent（kubelet、proxy等）無感覺持續運作，就像還穩穩的連着master（其實是要騙騙它們）
• 節點間東西向流量持續穩定互動（老師不在，同學們自己上自習）；
• 節點重新開機後，節點上管控元資訊和應用原資訊能夠恢複原樣，因為沒法通過管控配置中心同步（郵局關門，我不能給你寫信，我就在原地等你--mac位址保持、podIP保持等）；

  

EdgeHub作為節點上的臨時配置中心，在斷鍊情況下，持續為節點上所有裝置提供斷網前一刻的配置服務。資料持久化在本地磁盤，和節點共存亡。EdgeHub上實作了諸多k8s api，除了給agent用，節點上承載的業務pod也可以使用，輕量又便捷；

原生運維支援

說完邊緣端，再來說說雲邊連結的“臍帶”--EdgeTunnel。用過k8s指令行工具--kubectl的同學，肯定會對“kubectl exec，kubectl logs， kubectl attach，kubectl top”等運維指令直呼過瘾，原理也很簡單，大緻就是apiserver建聯到kubelet提供長連結支援。但是在邊緣場景，由于大多數邊緣節點沒有暴露在公網之上，主動的雲到邊的網絡建鍊突然變成不可能，所有的原生運維api黯然失效。

EdgeTunnel的設計目的就是為了彌補這份缺失，它通過在管控與邊緣worker節點之間建立反向通道，并和worker節點的生命周期完整關聯，支援證書配置，支援websocktet等等。我們看到最終apiserver通過它按需中轉，metricserver（k8s原生運維工具）通過它按需中轉......至此，這條寬似太平洋的通道讓運維接口又轉動起來，既安全又高效，皆大歡喜。

邊緣單元

在真實落地過程中，我們發現邊緣場景還真的是新奇又多彩。先賣個關子：

客戶A，IoT廠商，它們負責傳遞安防裝置到商場，機場、火車站等；但是各場所的資源、應用管理訴求不同，客戶希望能夠一次送出，單元化管理，且要有“邏輯多租能力”：流量單一場地閉環，部署按場地排程；客戶B，CDN廠商，機房遍布世界各地，海外和國内業務部署差異明顯，資源規格各異；希望能夠将資源分組，為後續開展不同業務鋪墊。

單元化，單元化流量管理，單元化排程、批量管理？k8s好像沒有這個能力。千真萬确，是沒有，但是k8s的自定義資源控制器（CRD&Operator）提供了一條友善的解決途徑。

通過k8s的擴充機制，在原生k8s基礎上我們增加了edgeunit的管控邏輯，簡言之：

• 分屬同一個edgeunit的worker節點，可以批量控制節點上的标簽、annotation，設定節點排程狀态等等；
• 使用者送出應用，可以按照單元化部署；如使用者送出一份“deployment”配置，通過邊緣單元的排程控制，可以在每個edgeunit中被克隆部署；除了批量管理之外，也可以賦予“單元”的獨立控制能力，靈活高效。
• 使用者的服務流量控制，可以在單元内閉環。大家都知道，原生k8s service提供的叢集内東西流量互動是不會感覺邊緣場景下節點位置屬性而做額外處理的，但是出于資料安全考慮或天然的網絡隔離等原因，我們需要将東西流量限制在一個邊緣單元内，這也是edgeunit在service管理上需要額外設計的邏輯；

輕量化

上文提到，邊緣算力的涵義頗廣，包括：規模較大的CDN資源，通常被稱之為“另一朵雲”的邊緣基礎設施；也有浩如煙海的IoT的邊緣裝置，算力規模小但是數量龐大。在處理IoT場景雲原生轉型問題上，輕量化是繞不開的一環。我們知道，IoT業務場景充斥着大量的異構、小規格的邊緣算力，像各種智能終端、裝置，它們對資源的限制是極緻的，難于接受額外的過多資源占用。是以，首當其沖的必然是管控層面的輕量化，簡單介紹下目前常見的技術嘗試：

• 管控元件的輕量化替代和壓縮，如containerd替代docker，以及減少額外node sidecar的部署和開銷的方案等等；
• 管控元件的裁剪，在k8s體系下對kubelet相關功能的裁剪和子產品化，社群也有類似方案；

  

邊緣k8s用在哪裡

那麼回頭再看，似否還有一個問題我們還沒有讨論到，邊緣容器/k8s到底用在哪裡？一言以蔽之，Edge kubernetes适用于需要通過中心統一管控遠端機房、伺服器、裝置的場景，輕松實作雲、邊、端一體的應用傳遞、運維、管控能力。

• 在IOT領域，可用于工廠、倉庫、樓宇、園區、高速收費站等場景。
• 在CDN領域，可以支援視訊直播、視訊監控、線上教育等行業客戶就近計算和存儲的需求。
• 在ENS邊緣計算産品上，提供了針對ENS邊緣執行個體的DevOps能力，友善針對邊緣的應用分發及部署運維。

阿裡雲容器服務邊緣托管ACK@Edge

人們常說“技術的發展有其自身的内在直接動力”，而阿裡雲邊緣雲原生的産品化落地動力确是實實在在的客戶場景催生。大緻分幾個階段：

• 衆所周知，阿裡雲在兩大邊緣計算領域CDN和IoT深耕已久，邊緣規模和業務複雜度的日益攀升帶來了不小的效能問題。在雲原生大有爆發之勢的2018年，阿裡雲容器服務先是和IoT業務團隊聯合推出Kubernetes Edge定制版本，作為雲上IoT邊緣托管服務底座，支援海量邊緣網關節點接入，深度融合IoT雲端市場、雲端FaaS、消息、運維等服務，

  雲邊一體概念萌生

在這個過程中，雲原生讓IoT托管如虎添翼，持續落地智慧樓宇、智慧工廠、智慧倉儲項目，雲邊端分層結構也日益顯現，這裡和大家分享兩個案例：親橙裡和XX倉儲：

• 随着IoT業務規模增長，Kubernetes Edge定制版作為獨立底座的維護成本越來越高，産品化勢在必行。在2019年4月，阿裡雲容器服務ACK推出EdgeKubernetes的托管服務（ACK@Edge），就是上文提到的k8s的托管服務，隻不過兼具了滿足邊緣計算場景的能力補齊，雲邊一體威力初現。

而這一次，ACK@Edge又在産品化之初選擇和CDN聯姻。阿裡雲有着國内最大體量的CDN業務，并正在從以内容分發服務為主轉變為邊緣計算，以ACK@Edge為依托建構雲原生的EdgePaaS服務，而CDN的海量節點也考驗了

ACK@Edge的大規模服務能力。

• 随着ACK@Edge的技術成熟，越來越多的内外部客戶選擇雲邊一體的雲原生标準k8s托管服務。這裡有一個優酷的case，優酷是國内最大的視訊平台，随着業務的快速發展，需要将原來部署在若幹 IDC 内的集中式架構，演進到雲+邊緣計算的架構。這就勢必需要業務方能夠有一種方式來統一管理阿裡雲十幾個 region 和衆多的邊緣節點。通過邊緣k8s架構，統一管理雲與邊緣的節點，實作了應用釋出和彈性擴縮容的統一。通過彈性能力，節省了機器成本 50%以上；使用者終端就近通路邊緣節點，讓端到端網絡延遲降低了 75%

邊緣雲原生未來

雲原生的未來是共同的期待和技術演進，在消除邊緣和雲的差異之後，雲邊一體的架構體系會在未來将邊緣計算牢牢堅定在“雲計算新邊界”的理念之上。新業務的開展将和雲上保持高度一緻：serverless，安全沙箱技術，函數計算等新的業務形态都将在不遠的将來落地。ACK@Edge将和大家一起見證。技術讨論可以加入釘釘群：21976595。