作者 | 黃玉奇（徙遠） 阿裡巴巴進階技術專家
導讀：伴随 5G、IoT 的發展，邊緣計算正在成為雲計算的新邊界，而規模和複雜度的日益提升對邊緣計算的效率、可靠性、資源使用率等一系列能力又提出了新的訴求。試想，如果能将雲能力從中心往邊緣觸達，上述問題是不是将迎刃而解？在雲原生時代建構雲到邊的觸達通路，保持雲邊一緻性體驗，我們的抓手又在哪裡呢？本文将一一為你揭曉。
雲原生的理念現今正如火如荼。它不僅僅是一種技術，更是随着雲生态的發展而被逐漸提煉出的一系列技術、最佳實踐與方法論的集合；它帶來了資源使用率提升、分布式系統的彈性擴充與可靠性等能力，能夠讓 IT 系統最大程度的享受雲計算紅利，業界全面擁抱雲原生就是最好的佐證。
雲原生概念
雲原生的概念最早是在 2013 年被提出，經過近幾年的發展，尤其是從 2015 年 Google 牽頭成立 CNCF 以來，雲原生技術開始進入公衆的視線并逐漸演變成包括 DevOps、持續傳遞、微服務、容器、基礎設施、Serverless、FaaS 等一系列的技術、實踐和方法論集合。伴随着技術的普及，與之相配套的團隊建設、技術文化、組織架構和管理方法也呼之欲出。
越來越多的企業選擇雲原生建構其應用，以此來獲得更好的資源效率和持續的服務能力。相比較過往着力雲原生概念的普及、了解和力求共識，雲原生落地已經成為現如今 I/CT 日常主旋律。
雲原生的技術範疇包括了以下幾個方面：雲應用定義與開發、雲應用的編排與管理、監控與可觀測性、雲原生的底層技術（比如容器運作時、雲原生存儲技術、雲原生網絡技術等）、雲原生工具集、Serverless。
雖然，CNCF 以目前 200 多個項目和産品（
CNCF 雲原生全景）的巨大體量保持高速發展，不斷壯大雲原生體系的技術集合，但所有項目基本都在上述技術範疇中，緊守雲原生理念不放。
那麼雲原生的核心優勢到底有哪些？能帶給我們真實體感又是什麼呢？
引用 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 架構圖：
- 核心層：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 倉儲。
智慧樓宇-親橙裡
智慧倉儲-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 将和大家一起見證。
歡迎有興趣的同學加入釘釘讨論群！
Q & A
Q1：如何适配不同的平台？OS 不同（linux 及各種發行版、非 linux）、硬體架構不同（x86、ARM 等等）。不同平台的節點能在同一個叢集内管理嗎？
A1：可以的，目前 ack@edge 支援 OS 類型：linux (centos、ubuntu)，windows server；CPU 架構：X86，arm 邊緣節點接入；支援異構節點在同一個叢集管理；K8s管控托管在雲上，異構節點的支援主要在邊緣端實施。
Q2：如何應對 worker 節點網絡不一定通的問題，通過 servicename 或者 clusterIP 是否還能通路？
A2：分兩個角度：ACK@Edge 提供了完整的标準的 K8s 能力，是以 servicename 和 clusterIP 預設是可以 work 的；如果 worker 節點間網絡不通，那麼 Pod 間東西向流量是不可達的。是以我們擴充了 service 的 scope 能力，service 的流量隻會被限制在一組網絡可達的節點之間轉發（就是上文中提到的 edgeunit）。
Q3：邊緣能自治到什麼程度，還能正常做增删改查嗎？apiserver 資源發生變化時節點還能感覺和同步嗎？目前如果觸發了邊緣自治，對我的應用程式會有哪些影響？
A3：首先，明确邊緣自治工作的時機是在邊緣節點和雲端管控失聯後，此時為了防止腦裂雲端會限制相關應用和節點資源的操作。apiserver 資源的變化隻能夠在網絡恢複後同步到 worker 節點，并且網絡恢複後，woker 節點相關的資源狀态仍然以 apiserver 資料為準；進入自治狀态後，節點上 agent 和應用都隻能夠消費斷網前一刻的資源狀态，自治元件 edgehub 替代 apiserver 接管了所有發往 apiserver 的請求。
Q4：K8s 具備很好的應用容災能力，ack@edge 在應用容災方面具備哪些能力？
A4：ack@edge 就是标準的 K8s；除了具備 K8s 原生的應用、資源管理能力之外，在邊緣場景還提供了斷網自治，元資訊保持等等能力，這些也都是為應用容災考慮。除此之外，因為提供的标準 K8s 完整能力，K8s 周邊生态 servicemesh、Knative 等都能很好支援。
Q5：項目是否有開源的計劃？
A5：edgehub、edgetunnel、edgeunit、knative-edge 等相關邊緣能力都在開源流程中，敬請期待。
Q6：可否直接打通雲-邊-端的網絡，比如我邊上的 pod 通路雲上的服務，直接通過servicename.namespace.cluster.svc.local，而不是用 ingress 暴露雲上服務，目前 kubeedge 經過定制是具備這個能力的，還未做生産驗證。阿裡的和 kubeedge 及 k3s 有什麼差別？A6：這個問題的本質是容器網絡能否跨雲，邊，端；在 ack@edge 中我們也支援 overlay 跨公網的安全方案，支援反向網絡穿透打通雲、邊，支援 VPN 網絡等。
Q7：ack@edge 是否有提供原生 K8s API？還是經過封裝後的 API？雲邊直連的安全問題，要把 apiserver 直接暴露到外網是不是不太安全？
A7：ack@edge 的設計理念是将原生的 K8s 托管在雲上，支援接入邊緣算力；使用者可以很便捷的通過産品界面配置并生産出一個原生的高可用的 K8s 叢集，并預設安裝上支援邊緣能力的 addons 和 operator，是以邊緣 K8s 提供了原生的 API。雲上 apiserver 通過阿裡雲 slb 暴露，對外提供服務，通過雲上 slb 服務的安全能力結合 K8s 的認證、鑒權能力保證了雲上 apiserver 的安全。
Q8：ack@edge 容器化後的程式與雷射雷達、深度相機、imu、com 通信協定的底層控制闆等傳感器的通信和資料互動是如何進行的？是否能夠提供穩定的資料互動通道？點雲及圖像資料的傳輸與直接運作在作業系統上的程式是否會有差别 ？
A8：應用容器化與否和對物聯網協定的支援不沖突，傳統的裸程序部署和容器化部署對應用而言是不感覺的，資料通道需要依賴其他的物聯網協定支援。
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”