摘要：KubeEdge 是首個基於 Kubernetes 擴展的，提供雲邊協同能力的開放式智能邊緣計算平臺，也是 CNCF 在智能邊緣領域的首個正式項目。依託 Kubernetes 強大的容器編排和調度能力，實現雲邊協同、計算下沉、海量設備接入等。
邊緣計算場景與挑戰
邊緣計算是一種分佈式計算概念，擁有去中心化處理能力的分散型開放 IT 架構，數據由設備自己或本地計算機或服務器處理，無需傳輸到數據中心，也可在更靠近終端的網絡邊緣上提供服務。安全
但邊緣計算沒法單獨存在，它一定要和遠程數據中心 / 雲打通，以 IoT（Internet of Things，物聯網）場景爲例，邊緣設備除了擁有傳感器收集周邊環境的數據外，還會從雲端接收控制指令，所以邊緣計算與雲計算兩者是相依而生、協同運做的。服務器
據2020邊緣計算狀態報告顯示，到2022年，75%的數據將經過邊緣分析和處理。這種數據處理的流動性，將伴隨有4大邊緣技術演進方向：網絡
- 人工智能的實用性加強，從雲端滲透到邊緣
- 物聯網設備的數量呈指數級增加
- 5G時代的快速到來
- 邊緣計算中心逐步克服分佈式設施複雜性和單位成本經濟性的問題
結合邊緣計算的場景與技術演進方向，能夠總結出當前邊緣計算領域面臨的幾個挑戰：架構
- 雲邊協同：逐步從雲端滲透到邊緣的AI/安全等業務，在雲和邊的智能協同、彈性遷移；
- 網絡：邊緣網絡的可靠性和帶寬限制；
- 設備管理：呈指數級增加的物聯網設備，邊緣節點與邊緣設備的管理；
- 擴展：高度分佈和大規模的可擴展性；
- 異構：邊緣異構硬件和通訊協議。
Kubernetes構建邊緣計算平臺的優點與挑戰
Kubernetes 已經成爲雲原生的事實標準，而且可以在任何基礎設施上提供一致的雲上體驗。咱們常常可以看到「容器 + Kubernetes」的組合在 DevOps 發揮 10X 效率。基於Kubernetes的技術架構與生態優點，近幾年也有愈來愈多的將Kubernetes 運行在數據中心外（邊緣）的需求。框架
基於Kubernetes構建的邊緣計算平臺，將會具有衆多自然的優點：運維
（1）容器化應用封裝：容器的輕量化和可移植性很是適合邊緣計算的場景，邊緣容器應用Build一次，能夠運行在任何邊緣節點上。分佈式
（2）通用的應用抽象定義：Kubernetes的應用定義已成爲雲原生業界的事實標準，被普遍接受。經過原生的Kubernetes應用API，用戶能夠將雲上與邊緣的應用統一管理。例如用戶可使用熟悉的 kubectl 或者 helm chart管理雲上與邊緣的應用。ide
（3）平臺易擴展性：Kubernetes 已經被證實具有良好的可擴展性，基於CRD能夠自定義API，如邊緣設備管理；基於CRI、CNI、CSI等插件能夠擴展各類邊緣自定義插件。工具
（4）強大的技術生態圈：圍繞 Kubernetes 已經造成了一個強大的雲原生技術生態圈，諸如：監控、日誌、CI、存儲、網絡都能找到現成的工具鏈。測試
然而 Kubernetes 畢竟原生是爲雲數據中心設計的，要將Kubernetes 的能力擴展到邊緣，必須解決如下問題：
（1）邊緣設備資源有限：不少設備邊緣的資源規格有限，特別是 CPU 處理能力較弱，內存資源較少，所以沒法部署完整的 Kubernetes。
（2）邊緣網絡的不穩定性：Kubernetes依賴數據中心穩定的網絡，邊緣場景下網絡一般又是不穩定的。
（3）邊緣節點離線自治：Kubernetes依賴 list/watch 機制，不支持離線運行，而邊緣節點的離線又是常態，例如：設備離線重啓。
（4）海量邊緣設備管理：如何使用Kubernetes管理指數級增加的海量邊緣設備以及產生的數據。
另外，關於如何在邊緣使用 Kubernetes，Kubernetes IoT/Edge WG 組織的一個調查顯示，30% 的用戶但願在邊緣部署完整的 Kubernetes 集羣，而 70% 的用戶但願在雲端部署 Kubernetes 的管理面而且在邊緣節點上只部署 Kubernetes 的 agent。
邊緣容器開源現狀
Kubernetes社區很早就已經關注到邊緣計算場景，早在2018年社區就已經成立專門的Edge工做組來研討邊緣相關場景。而2018年末，華爲在業界首次開源Kubernetes邊緣項目KubeEdge，將華爲雲智能邊緣平臺產品IEF（Intelligent EdgeFabric）核心代碼開源，並於19年初捐獻給CNCF基金會，成爲CNCF迄今爲止惟一邊緣計算官方項目。隨後，Rancher、阿里雲也陸續跟進，開源了K3s、OpenYurt等項目，邊緣容器這個領域真正進入到快速發展期。下面，咱們對這三個表明性的K8s@Edge的項目進行一些簡要分析。
KubeEdge架構分析
KubeEdge 是華爲雲於2018年11月開源，2019年3月捐獻給 CNCF 的開源項目。KubeEdge 是首個基於 Kubernetes 擴展的，提供雲邊協同能力的開放式智能邊緣計算平臺，也是 CNCF 在智能邊緣領域的首個正式項目。KubeEdge 的名字來源於 Kube + Edge，顧名思義就是依託 Kubernetes 強大的容器編排和調度能力，實現雲邊協同、計算下沉、海量設備接入等。
KubeEdge架構上分爲雲、邊、端三個層次。雲端中心管控邊緣節點與設備，邊緣節點實現邊緣自治，雲上管控邊緣節點的架構也符合Kubernetes IoT/Edge WG 調查結果中大多數用戶的訴求。KubeEdge完整的打通了邊緣計算中雲、邊、設備協同的場景，總體架構以下圖。
針對邊緣特定的場景，KubeEdge 重點解決的問題是：
雲邊協同：KubeEdge 經過 Kubernetes 標準 API 在雲端管理邊緣節點、設備和工做負載的增刪改查。邊緣節點的系統升級和應用程序更新均可以直接從雲端下發，提高邊緣的運維效率；在邊緣AI場景下，雲端訓練好的模型能夠直接下發到邊緣節點，進行推理等，實現邊緣AI的雲邊一體化。
邊緣自治：KubeEdge 經過消息總線和元數據本地存儲實現了節點的離線自治。用戶指望的控制面配置和設備實時狀態更新都經過消息同步到本地存儲，這樣節點在離線狀況下即便重啓也不會丟失管理元數據，並保持對本節點設備和應用的管理能力。
極致輕量：KubeEdge 則是保留了 Kubernetes 管理面，對Kubernetes的節點端組件進行重組，達到極致輕量的目的，節點組件能夠運行在內存256M的邊緣節點上。
海量邊緣設備管理：KubeEdge了可插拔式的設備統一管理框架，在雲端基於Kubernetes的CRD能力，自定義了設備管理的API，徹底符合Kubernetes的原生標準，用戶能夠在雲端經過API來管理海量邊緣設備；在邊緣可根據不一樣的協議或實際需求開發設備接入驅動，當前已經支持和計劃支持的協議有：MQTT，BlueTooth，OPC UA，Modbus 等，隨着愈來愈多社區合做夥伴的加入，KubeEdge 將來會支持更多的設備通訊協議。
K3s架構分析
K3s 是 Rancher於2019年2月開源的一個本身裁剪的 Kubernetes 發行版，K3S 名字來源於 K8s – 5，這裏的「5」指的是 K3S 比 Kubernetes 更輕量使得它能更好地適配 CI，ARM，邊緣技術，物聯網和測試這 5 個場景。K3S 是 CNCF 官方認證的 Kubernetes 發行版，開源時間較 KubeEdge 稍晚。K3S 專爲在資源有限的環境中運行 Kubernetes 的研發和運維人員設計，目的是爲了在 x8六、ARM64 和 ARMv7D 架構的邊緣節點上運行小型的 Kubernetes 集羣。K3S 的總體架構以下所示：
K3S 就是基於一個特定版本 Kubernetes（例如：1.17）直接作了代碼修改。K3S 分 Server 和 Agent，Server 就是 Kubernetes 管理面組件 + SQLite 和 Tunnel Proxy，Agent 即 Kubernetes 的數據面 + Tunnel Proxy。
爲了減小運行 Kubernetes 所需的資源，K3S 對原生 Kubernetes 代碼作了如下幾個方面的修改：
刪除舊的、非必須的代碼。K3S 不包括任何非默認的、Alpha 或者過期的 Kubernetes 功能。除此以外，K3S 還刪除了全部非默認的 Admission Controller，in-tree 的 cloud provider 和存儲插件；
整合打包進程。爲了節省內存，K3S 將本來以多進程方式運行的 Kubernetes 管理面和數據面的多個進程分別合併成一個來運行；
使用 Containderd 替換 Docker，顯著減小運行時佔用空間；
引入 SQLite 代替 etcd 做爲管理面數據存儲，並用 SQLite 實現了 list/watch 接口；
將全部Kubernetes原生進程打包在同一個進程中。
K3s項目本質上是一個K8s的「輕量化」版本，而不是一個真正意義上的「邊緣」版本。從架構上看，K3s 的全部組件（包括 Server 和 Agent）都運行在邊緣側，這意味着 K3S 並非一個去中心化的部署模型，每一個邊緣都須要額外部署 Kubernetes 管理面，所以不涉及雲邊協同。也缺少針對邊緣網絡不穩定性的邊緣自治能力，也不涉及邊緣設備的管理。
此外，若是 K3s 要落到生產，在 K3s 之上應該還有一個雲上的統一集羣管理方案負責跨集羣的應用管理、監控、告警、日誌、安全和策略等，遺憾的是 Rancher 還沒有開源這部分能力。
OpenYurt架構分析
OpenYurt是阿里雲於2020年5月開源的雲原生邊緣計算項目，跟KubeEdge架構基本類似，OpenYurt也是依託原生Kubernetes的容器編排及調度能力，提供雲邊協同能力的邊緣計算平臺。OpenYurt 也是依託 Kubernetes 強大的容器應用編排能力，實現雲-邊一體化的應用分發、管控的訴求，也是從雲端集中管控邊緣節點，OpenYurt 的總體架構以下所示：
項目目前還未發佈0.1版本，從已開源部分能夠看出，OpenYurt架構與KubeEdge相似，也是打通了雲邊協同的場景。提供的能力也與KubeEdge相似，包括邊緣自治、雲邊協同、單元化管理能力（未開源）等。
OpenYurt並未對Kubernetes進行改造，而是經過Addon（插件化）的形式提供邊緣計算所須要的管控能力，邊緣端的YurtHub，做爲節點上的臨時配置中心，在網絡鏈接中斷的狀況下，持續爲節點上全部設備和客戶業務提供數據配置服務。這種簡化的架構，重點在於解決「離線自治」問題，且比較有利於保留現有K8s的完整功能，但因爲未對Kubelet進行修改，所以OpenYurt沒法運行在資源有限的邊緣設備中；物聯網場景中的對於邊緣設備的管理，OpenYurt也不涉及；而且一些邊緣場景下涉及到Kubelet原生不支持的高級特性好比離線自愈、自調度等沒法實現。
邊緣容器總結與展望
對比三個開源項目， K3s 最讓人印象深入的特色在於其對 Kubernetes 進行了輕量化、部署便捷化作的嘗試，經過剪裁了 Kubernetes 一些不經常使用功能而且合併多個組件到一個進程運行的方式，使得一些資源較充足的邊緣節點上可以很方便的得到與Kubernetes一致的體驗。可是從測試數據看K3s 的資源消耗仍是很高，並且動輒幾百 MB 的內存也不是大多數設備邊緣節點所能提供的，並且目前只適合運行在邊緣，不具有云邊協同、邊緣自治等邊緣計算領域的核心訴求。
OpenYurt經過非侵入的插件化形式在原生Kubernetes的基礎上提供邊緣計算能力，雖然提供了雲邊協同、邊緣自治等能力，可是未作輕量化改造，只能運行在資源充足的邊緣節點，沒法運行在大量資源有限的邊緣節點上，而且也未提供邊緣計算中海量邊緣設備管理的能力。
KubeEdge是一個從雲到邊緣再到設備的完整邊緣雲平臺，100% 兼容Kubernetes的原生API，基於Kubernetes解決了邊緣計算領域的核心訴求，包括雲邊協同、邊緣網絡不穩定、邊緣自治、邊緣輕量化、海量邊緣設備管理以及異構擴展等問題。
將來邊緣容器技術仍將聚焦於解決邊緣計算領域所面臨的雲邊協同、網絡、設備管理、擴展及異構等挑戰，KubeEdge 已是 CNCF正式項目，將來將持續與社區合做夥伴一塊兒制定雲和邊緣計算協同的標準，解決邊緣計算領域的難題，結束邊緣計算沒有統一標準和參考架構的混沌狀態，共同推進邊緣計算的產業發展。