作者 | 黃玉奇（徙遠）  阿里巴巴高階技術專家

**關注“阿里巴巴雲原生”公眾號，回覆關鍵詞 1219 即可下載本文 PPT 及實操演示影片。**

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

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

# 雲原生概念
雲原生的概念最早是在 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."

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

# 雲原生和邊緣基礎設施
在雲端計算真正普及之前，獲取基礎設施能力（比如服務發現、流量控制、監控與可觀測性、訪問控制、網路控制、儲存層抽象等）需要應用透過某種抽象或介面方式，使得兩者之間是非常緊密的耦合關係，應用本身的能力和演進需要強依賴基礎設施。

而在雲原生時代，類似 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?spm=ata.13261165.0.0.791c210dIjwpSc)：

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

- 核心層：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 場景中的端裝置，例如智慧樓宇智慧停車裝置，藍芽裝置、人臉識別裝置等。

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

## 雲端託管原生 K8s
先看最核心的雲端託管層，在雲邊一體的設計理念中，自然而然的能夠聯想到將原生的標準 K8s 託管在公共雲上，開箱即用各種被整合的雲能力必定是不二之選。K8s 免運維上面已經談到了幾點原因，原生的 K8s 便於被上層業務系統整合，卻常常被忽視，透過雲廠商將 Kubernetes 和其他雲能力（彈性、日誌監控、應用市場，映象服務等）打通，無論是終端使用者直接使用，還是做新業務創新，複雜度都大大降低。

此外，將雲管控作為中心式服務，透過提供統一管控能力，反而非常適合管理邊緣場景中零散分佈的計算資源和應用，比如 CDN 服務、IoT 業務等；最後，雲原生的方式又可以讓使用者以往的 K8s 經驗用於新的邊緣計算業務。

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

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

## 適度定製適配邊緣場景
K8s 除了上述特徵之外，還有一個強大的外掛機制，CxI 自不必說，CRD、Operator 更是讓 K8s 如虎添翼。在面向邊緣場景，自然而然會有一些別樣的邏輯需要適配，例如：邊緣節點和雲端管控走弱連線公網互動帶來的管理邏輯適配；邊緣節點應用驅逐邏輯適配；邊緣節點支援原生運維介面適配等等。

外掛化的非侵入方式可以讓原生 K8s 在免受任何衝擊的同時，擴充套件更多的邏輯，比如用來做邊緣單元化管理的 EdgeUnit Operator 再比如做邊緣節點自治管理的 EdgeNode Operator。

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

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

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

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

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

- 節點上 agent（kubelet、proxy 等）無感知持續執行，就像還穩穩的連著 master（其實是要騙騙它們）；
- 節點間東西向流量持續穩定互動（老師不在，同學們自己上自習）；
- 節點重啟後，節點上管控元資訊和應用原資訊能夠恢復原樣，因為沒法透過管控配置中心同步（郵局關門，我不能給你寫信，我就在原地等你帶著青春容顏--mac 地址保持、podIP 保持等）；

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

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

### 原生運維支援
說完邊緣端，再來說說雲邊連結的“臍帶”--EdgeTunnel。用過 K8s 命令列工具--kubectl 的同學，肯定會對 "kubectl exec，kubectl logs， kubectl attach，kubectl top" 等運維命令直呼過癮，原理也很簡單，大致就是 apiserver 建聯到 kubelet 提供長連結支援。

但是在邊緣場景，由於大多數邊緣節點沒有暴露在公網之上，主動的雲到邊的網路建鏈突然變成不可能，所有的原生運維 api 黯然失效。

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

EdgeTunnel 的設計目的就是為了彌補這份缺失，它透過在管控與邊緣 worker 節點之間建立反向通道，並和 worker 節點的生命週期完整聯動，支援證書配置、支援 websocktet 等等。我們看到最終 apiserver 透過它按需中轉，metricserver（K8s 原生運維工具）透過它按需中轉......

至此，這條寬似太平洋的通道讓運維介面又轉動起來，既安全又高效，皆大歡喜。

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

- 客戶 A，IoT 廠商，他們負責交付安防裝置到商場、機場、火車站等；但是各場所的資源、應用管理訴求不同，客戶希望能夠一次提交，單元化管理，且要有“邏輯多租能力”：流量單一場地閉環，部署按場地排程；

- 客戶 B，CDN 廠商，機房遍佈世界各地，海外和國內業務部署差異明顯，資源規格各異；希望能夠將資源分組，為後續開展不同業務鋪墊。單元化、單元化流量管理、單元化排程、批次管理？K8s 好像沒有這個能力，但是 K8s 的自定義資源控制器（CRD&Operator）提供了一條方便的解決途徑。

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

透過 K8s 的擴充套件機制，在原生 K8s 基礎上我們增加了 edgeunit 的管控邏輯：
- 分屬同一個 edgeunit 的 worker 節點，可以批次控制節點上的標籤、annotation，設定節點排程狀態等等；
- 使用者提交應用，可以按照單元化部署；如使用者提交一份 "deployment" 配置，透過邊緣單元的排程控制，可以在每個 edgeunit 中被克隆部署；除了批次管理之外，也可以賦予“單元”的獨立控制能力，靈活高效；
- 使用者的服務流量控制，可以在單元內閉環。大家都知道，原生 K8s Service 提供的叢集內東西流量互動，是不會感知邊緣場景下節點位置屬性而做額外處理的，但是出於資料安全或天然的網路隔離等考慮，我們需要將東西流量限制在一個邊緣單元內，這也是 edgeunit 在 service 管理上需要額外設計的邏輯。

### 輕量化
上文提到，邊緣算力的涵義頗廣，包括：規模較大的 CDN 資源，通常被稱之為“另一朵雲”的邊緣基礎設施；也有浩如煙海的 IoT 的邊緣裝置，算力規模小但是數量龐大。

在處理 IoT 場景雲原生轉型問題上，輕量化是繞不開的一環。我們知道，IoT 業務場景充斥著大量的異構、小規格的邊緣算力，像各種智慧終端、裝置，它們對資源的約束是極致的，難於接受額外的資源佔用。所以，首當其衝的必然是管控層面的輕量化，簡單介紹下目前常見的技術嘗試：

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

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

# 邊緣 K8s 用在哪裡
那麼回頭再看，是否還有一個問題我們還沒有討論到：邊緣容器/K8s 到底用在哪裡？一言以蔽之，Edge Kubernetes 適用於需要透過中心統一管控遠端機房、伺服器、裝置的場景，輕鬆實現雲、邊、端一體的應用交付、運維、管控能力。

- 在 IoT 領域，可用於工廠、倉庫、樓宇、園區、高速收費站等場景； 
- 在 CDN 領域，可以支援影片直播、影片監控、線上教育等行業客戶就近計算和儲存的需求；
- 在 ENS 邊緣計算產品上，提供了針對 ENS 邊緣例項的 DevOps 能力，方便針對邊緣的應用分發及部署運維。

# 阿里雲容器服務邊緣託管 ACK@Edge
人們常說“技術的發展有其自身的內在直接動力”，而阿里雲邊緣雲原生的產品化落地動力卻是實實在在的客戶場景催生。大致分以下幾個階段：

## 第一階段：雲邊一體概念萌生
眾所周知，阿里雲在兩大邊緣計算領域 CDN 和 IoT 深耕已久，邊緣規模和業務複雜度的日益攀升帶來了不小的效能問題。在雲原生大有爆發之勢的 2018 年，阿里雲容器服務先是和 IoT 業務團隊聯合推出 Kubernetes Edge 定製版本，作為雲上 IoT 邊緣託管服務底座，支援海量邊緣閘道器節點接入，深度融合 IoT 雲端市場、雲端 FaaS、訊息、運維等服務，**雲邊一體概念萌生**。

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

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

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

智慧樓宇-親橙裡
![12.png](https://ucc.alicdn.com/pic/developer-ecology/e0e42709f6ac41b5a430d690a7c4e424.png)

智慧倉儲-XX 倉儲

## 第二階段：雲邊一體威力初現
隨著 IoT 業務規模增長，Kubernetes Edge 定製版作為獨立底座的維護成本越來越高，產品化勢在必行。在 2019 年 4 月，阿里雲容器服務 ACK 推出 EdgeKubernetes 的託管服務（ACK@Edge），就是上文提到的 K8s 的託管服務，只不過兼具了滿足邊緣計算場景的能力補齊，**雲邊一體威力初現。**

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

而這一次，ACK@Edge 又在產品化之初選擇和 CDN 聯合。阿里雲有著國內最大體量的 CDN 業務，並正在從以內容分發服務為主轉變為邊緣計算，以 ACK@Edge 為依託構建雲原生的 EdgePaaS 服務，而 CDN 的海量節點也考驗了ACK@Edge 的大規模服務能力。

## 第三階段：雲邊一體成熟化
隨著 ACK@Edge 的技術成熟，越來越多的內外部客戶選擇雲邊一體的雲原生標準 K8s 託管服務。

這裡有一個優酷的 case，優酷是國內最大的影片平臺，隨著業務的快速發展，需要將原來部署在若干 IDC 內的集中式架構，演進到雲+ 邊緣計算的架構。這就勢必需要業務方能夠有一種方式來統一管理阿里雲十幾個 region 和眾多的邊緣節點。

透過邊緣 K8s 架構，統一管理雲與邊緣的節點，實現了應用釋出和彈性擴縮容的統一。透過彈效能力，節省了 50% 以上的機器成本；使用者終端就近訪問邊緣節點，讓端到端網路延遲降低了 75%。

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

# 邊緣雲原生未來
雲原生未來的技術演進是我們共同的期待，在消除邊緣和雲的差異之後，雲邊一體的架構體系會在未來將邊緣計算牢牢堅定在“雲端計算新邊界”的理念之上。新業務的開展將和雲上保持高度一致：Serverless、安全沙箱技術、函式計算等新的業務形態都會在不遠的將來落地，ACK@Edge 將和大家一起見證。

歡迎有興趣的同學加入釘釘討論群！
![15.png](https://ucc.alicdn.com/pic/developer-ecology/b33fe8e6b6d0404c912275905797f076.png)

# 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**：應用容器化與否和對物聯網協議的支援不衝突，傳統的裸程式部署和容器化部署對應用而言是不感知的，資料通道需要依賴其他的物聯網協議支援。
> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

阿里雲如何基於標準 K8s 打造邊緣計算雲原生基礎設施

相關文章