作者 | Edge Captain

近期兩個?Kubernetes?相關的軟件?KubeEdge?和?K3S?分別開源，Kubernetes?開始在邊緣計算場景探索應用。

KubeEdge?是華為捐獻給?CNCF?的第一個開源項目，也是全球首個基于?Kubernetes?擴展的，提供云邊協同能力的開放式邊緣計算平臺。KubeEdge?的名字來源于?Kube?+?Edge，顧名思義就是依托?Kubernetes?的容器編排和調度能力，實現云邊協同、計算下沉、海量設備接入等。

K3S?是?Rancher?開源的一個自己裁剪的?Kubernetes?發行版，K3S?名字來源于?K8s?–?5，這里的“5”指的是?K3S?比?Kubernetes?更輕量使得它能更好地適配?CI，ARM，邊緣技術，物聯網和測試這?5?個場景。

同樣是基于?Kubernetes，同樣是致力于解決邊緣場景問題的開源軟件，這兩個項目不免經常被人拿來比較。本文將以邊緣計算的實際場景和挑戰為出發點，為您剖析?Kubernetes?能夠在邊緣計算領域的發力點，最后全方位對比?KubeEdge?和?K3S。

邊緣計算場景分類與挑戰

這里要討論的“邊緣”特指計算資源在地理分布上更加靠近設備，而遠離云數據中心的資源節點。典型的邊緣計算分為物聯網（例如：下一代工業自動化，智慧城市，智能家居，大型商超等）和非物聯網（例如：游戲，CDN?等）場景。

在現實世界中，邊緣計算無法單獨存在，它必定要和遠程數據中心?/?云打通（具體原因見下文）。以?IoT（Internet?of?Things，物聯網）為例，邊緣設備除了擁有傳感器收集周邊環境的數據外，還會從云端接收控制指令。邊緣設備與云連接一般有兩種模式：直連和通過中繼邊緣節點連接，如下圖所示:

邊緣設備能否直連云端?/?數據中心取決于是否有全球唯一可路由的?IP，例如：手機、平板電腦等。不過，大部分的設備通過近場通信協議與邊緣節點通信，進而和云端?/?數據中心連接的。邊緣節點是設備的匯聚點，有分配?IP?地址，扮演了邊緣網關的作用。邊緣節點為普通的設備提供?IP?地址，也可以運行容器。

我們注意到，邊緣節點也是有不同層級的，而劃分的標準之一就是資源（計算、存儲、網絡帶寬等）的大小。如上所示，我們將?edge?分為“Device?Edge”和“Infrastructure?Edge”。Device?Edge（設備邊緣）是指那些并不被認為是?IT?基礎設施組成部分的邊緣節點，例如：火車、油田、工廠和家庭等。通常它們沒什么計算能力，被用于解決最后“一公里”接入的問題，一個典型的例子就是智能路由器，它一端通過紅外信號控制家中電器，另一端通過網絡和云數據中心相連。由于設備邊緣網絡穩定性較差，因此必須要考慮它們會較長時間離線的情況（例如火車過隧道）。

注：日常生活中很多設備我們可以看成是?device+device?edge?的結合體，例如智能手機。

Infrastructure?Edge（基礎設施邊緣）相對于?Device?Edge?計算和存儲能力都更強，而且通常通過骨干網與數據中心連接，因此具有更大的網絡帶寬和更加可靠的網絡連接，例如：CDN，游戲服務器等。基礎設施邊緣除了能運行容器外，有些甚至還有足夠資源運行完整的?Kubernetes。

對邊緣節點進行分類的意義在于，針對不同層級的邊緣需要有針對性的部署模型，并且平臺要為邊緣節點提供通信能力。

最后，我們總結一下當前邊緣計算領域面臨的幾個挑戰：

• 云邊協同：AI/?安全等業務在云和邊的智能協同、彈性遷移；

• 網絡：邊緣網絡的可靠性和帶寬限制；

• 管理：邊緣節點的資源管理與邊緣應用生命周期管理；

• 擴展：高度分布和大規模的可擴展性；

• 異構：邊緣異構硬件和通信協議。

其中，云邊協是當前面臨最大的技術挑戰！

為什么我們需要云邊協同

邊緣計算和云計算不是兩種互斥的技術，它們是相輔相成的關系。而且從場景需求上看，IoT/Edge?與云數據中心有一些相似之處，例如：

• 邊緣也有管理節點的計算、存儲、網絡等資源的需求；

• 邊緣應用也想容器化和微服務化；

• 邊緣計算希望能有標準的?API?和工具鏈；

• 安全，數據?/?信道加密和認證授權。

因此，將云數據中心的現有架構和能力順勢延伸到邊緣就變得水到渠成了。下面列舉了一些需要云邊協同的場景：

• AI?云上訓練，邊緣執行。即充分發揮云計算海量資源的優勢，將?AI?模型的訓練放在云端，而?AI?的執行則貼近設備側；

• 微服務，DevOps。微服務和?DevOps?不僅僅是云上開發的專利，將它們引入邊緣將會顯著加速嵌入式設備、機器人等?IoT?軟件的迭代周期，提升部署和運維效率；

• 數據備份轉儲。例如，海量的工業數據（加密后）存儲在云端；

• 遠距離控制。云端遠程下發對邊緣設備的控制信號；

• 自動擴展。由于邊緣節點不如云具備良好的自動擴展能力，因此可以選擇在峰值時將邊緣的負載彈性擴容到云上。

我們已經積累了足夠的管理云上資源的經驗，現在下一步的挑戰就是如何構建一個邊緣云平臺，把對云上資源的管理方法延伸到邊緣，讓我們能夠無縫地管理邊緣的資源和設備。邊緣云平臺將重點解決以下問題：

• 大規模?/?異構的設備，網關和邊緣節點的接入；

• 大量遙測數據匯聚、處理后提供給云端應用使用；

• 設備安全和識別服務；

• 支持遠程下達對設備的指令；

• 自動創建和管理邊緣節點和設備；

• 實現云端對邊緣應用的編排、部署和配置；

• 為邊緣應用的開發提供數據存儲、事件管理、API?管理和數據分析等能力。

Kubernetes 的優勢與挑戰

Kubernetes?已經成為云原生的標準，并且能夠在任何基礎設施上提供一致的云上體驗。我們經常能夠看到“容器?+?Kubernetes”的組合在?DevOps?發揮?10X?效率，最近也有越來越多?Kubernetes?運行在數據中心外（邊緣）的需求。

如果要在邊緣部署較復雜的應用，那么?Kubernetes?是個理想的選擇：

• 容器的輕量化和可移植性非常適合邊緣計算的場景；

• Kubernetes?已經被證明具備良好的可擴展性；

• 能夠跨底層基礎設施提供一致的體驗；

• 同時支持集群和單機運維模式；

• Workload?抽象，例如：Deployment?和?Job?等；

• 應用的滾動升級和回滾；

• 圍繞?Kubernetes?已經形成了一個強大的云原生技術生態圈，諸如：監控、日志、CI、存儲、網絡都能找到現成的工具鏈；

• 支持異構的硬件配置（存儲、CPU、GPU?等）；

• 用戶可以使用熟悉的?kubectl?或者?helm?chart?把?IoT?應用從云端推到邊緣；

• 邊緣節點可以直接映射成?Kubernetes?的?Node?資源，而?Kubernetes?的擴展API（CRD）可以實現對邊緣設備的抽象。

然而?Kubernetes?畢竟是為云數據中心設計的，要想在邊緣使用?Kubernetes?的能力，Kubernetes?或其擴展需要解決以下問題：

• ARM?的低功耗和多核的特點又使得其在?IoT/Edge?領域的應用非常廣泛，然而大部分的?Kubernetes?發行版并不支持?ARM?架構；

• 很多設備邊緣的資源規格有限，特別是?CPU?處理能力較弱，因此無法部署完整的?Kubernetes；

• Kubernetes?非常依賴?list/watch?機制，不支持離線運行，而邊緣節點的離線又是常態，例如：設備休眠重啟；

• Kubernetes?的運維相對于邊緣場景用到的功能子集還是太復雜了；

• 特殊的網絡協議和拓撲要求。設備接入協議往往非?TCP/IP?協議，例如，工業物聯網的?Modbus?和?OPC?UA，消費物聯網的?Bluetooth?和?ZigBee?等；

• 設備多租。

關于如何在邊緣使用?Kubernetes，Kubernetes?IoT/Edge?WG?組織的一個調查顯示，30%?的用戶希望在邊緣部署完整的?Kubernetes?集群，而?70%?的用戶希望在云端部署?Kubernetes?的管理面并且在邊緣節點上只部署?Kubernetes?的?agent。

把?Kubernetes?從云端延伸到邊緣，有兩個開源項目做得不錯，分別是?KubeEdge?和?K3S，下面我們將詳解這兩個項目，并做全方位的對比。

KubeEdge 架構分析

KubeEdge?是首個基于?Kubernetes?擴展的，提供云邊協同能力的開放式智能邊緣平臺，也是?CNCF?在智能邊緣領域的首個正式項目。KubeEdge?重點要解決的問題是：

• 云邊協同

• 資源異構

• 大規模

• 輕量化

• 一致的設備管理和接入體驗

KubeEdge?的架構如下所示：KubeEdge?架構上清晰地分為三層，分別是：云端、邊緣和設備層，這是一個從云到邊緣再到設備的完整開源邊緣云平臺，消除了用戶廠商綁定的顧慮。

KubeEdge?的邊緣進程包含以下?5?個組件：

• edged?是個重新開發的輕量化?Kubelet，實現?Pod，Volume，Node?等?Kubernetes?資源對象的生命周期管理；

• metamanager?負責本地元數據的持久化，是邊緣節點自治能力的關鍵；

• edgehub?是多路復用的消息通道，提供可靠和高效的云邊信息同步；

• devicetwin?用于抽象物理設備并在云端生成一個設備狀態的映射；

• eventbus?訂閱來自于?MQTT?Broker?的設備數據。

KubeEdge?的云端進程包含以下?2?個組件：

• cloudhub?部署在云端，接收?edgehub?同步到云端的信息；

• edgecontroller?部署在云端，用于控制?Kubernetes?API?Server?與邊緣的節點、應用和配置的狀態同步。

Kubernetes?maser?運行在云端，用戶可以直接通過?kubectl?命令行在云端管理邊緣節點、設備和應用，使用習慣與?Kubernetes?原生的完全一致，無需重新適應。

K3S 架構分析

K3S?是?CNCF?官方認證的?Kubernetes?發行版，開源時間較?KubeEdge?稍晚。K3S?專為在資源有限的環境中運行?Kubernetes?的研發和運維人員設計，目的是為了在?x86、ARM64?和?ARMv7D?架構的邊緣節點上運行小型的?Kubernetes?集群。K3S?的整體架構如下所示：

事實上，K3S?就是基于一個特定版本?Kubernetes（例如：1.13）直接做了代碼修改。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?接口，即?Tunnel?Proxy；

• 加了一個簡單的安裝程序。

K3S?的所有組件（包括?Server?和?Agent）都運行在邊緣，因此不涉及云邊協同。如果?K3S?要落到生產，在?K3S?之上應該還有一個集群管理方案負責跨集群的應用管理、監控、告警、日志、安全和策略等，遺憾的是?Rancher?尚未開源這部分能力。

KubeEdge 與 K3S 全方位對比

部署模型

KubeEdge?遵循的是以下部署模型:

KubeEdge?是一種完全去中心化的部署模式，管理面部署在云端，邊緣節點無需太多資源就能運行?Kubernetes?的?agent，云邊通過消息協同。從?Kubernetes?的角度看，邊緣節點?+?云端才是一個完整的?Kubernetes?集群。這種部署模型能夠同時滿足“設備邊緣”和“基礎設施邊緣”場景的部署要求。

K3S?的部署模型如下所示：

K3S?會在邊緣運行完整的?Kubernetes?集群，這意味著?K3S?并不是一個去中心化的部署模型，每個邊緣都需要額外部署?Kubernetes?管理面。這種部署模型帶來的問題有：

• 在邊緣安裝?Kubernetes?管理面將消耗較多資源，因此該部署模型只適合資源充足的“基礎設施邊緣”場景，并不適用于資源較少的“設備邊緣”的場景；

• 集群之間網絡需要打通；

• 為了管理邊緣?Kubernetes?集群還需要在上面疊加一層多集群管理組件（遺憾的是該組件未開源）。

云邊協同

云邊協同是?KubeEdge?的一大亮點。KubeEdge?通過?Kubernetes?標準?API?在云端管理邊緣節點、設備和工作負載的增刪改查。邊緣節點的系統升級和應用程序更新都可以直接從云端下發，提升邊緣的運維效率。另外，KubeEdge?底層優化的多路復用消息通道相對于?Kubernetes?基于?HTTP?長連接的?list/watch?機制擴展性更好，允許海量邊緣節點和設備的接入。KubeEdge?云端組件完全開源，用戶可以在任何公有云?/?私有云上部署?KubeEdge?而不用擔心廠商鎖定，并且自由集成公有云的其他服務。K3S?并不提供云邊協同的能力。

邊緣節點離線自治

與?Kubernetes?集群的節點不同，邊緣節點需要在完全斷開連接的模式下自主工作，并不會定期進行狀態同步，只有在重連時才會與控制面通信。此模式與?Kubernetes?管理面和工作節點通過心跳和?list/watch?保持狀態更新的原始設計非常不同。

KubeEdge?通過消息總線和元數據本地存儲實現了節點的離線自治。用戶期望的控制面配置和設備實時狀態更新都通過消息同步到本地存儲，這樣節點在離線情況下即使重啟也不會丟失管理元數據，并保持對本節點設備和應用的管理能力。

K3S?也不涉及這方面能力。

設備管理

KubeEdge?提供了可插拔式的設備統一管理框架，允許用戶在此框架上根據不同的協議或實際需求開發設備接入驅動。當前已經支持和計劃支持的協議有：MQTT，BlueTooth，OPC?UA，Modbus?等，隨著越來越多社區合作伙伴的加入，KubeEdge?未來會支持更多的設備通信協議。KubeEdge?通過?device?twins/digital?twins?實現設備狀態的更新和同步，并在云端提供?Kubernetes?的擴展?API?抽象設備對象，用戶可以在云端使用?kubectl?操作?Kubernetes?資源對象的方式管理邊緣設備。

K3S?并不涉及這方面能力。

輕量化

為了將?Kubernetes?部署在邊緣，KubeEdge?和?K3S?都進行了輕量化的改造。區別在于?K3S?的方向是基于社區版?Kubernetes?不斷做減法（包括管理面和控制面），而?KubeEdge?則是保留了?Kubernetes?管理面，重新開發了節點?agent。

需要注意的是，K3S?在裁剪?Kubernetes?的過程中導致部分管理面能力的缺失，例如：一些?Admission?Controller。而?KubeEdge?則完整地保留了?Kubernetes?管理面，沒有修改過一行代碼。

下面我們將從二進制大小、內存和?CPU?三個維度對比?KubeEdge?和?K3S?的資源消耗情況。由于?KubeEdge?的管理面部署在云端，用戶不太關心云端資源的消耗，而?K3S?的?server?和?agent?均運行在邊緣，因此下面將對比?KubeEdge?agent，K3S?agent?和?K3S?server?這三個不同的進程的?CPU?和內存的資源消耗。

測試機規格為?4?vCPU，8GB?RAM。

?內存消耗對比

分別用?KubeEdge?和?K3S?部署?0~100?個應用，分別觀測兩者的內存消耗，對比如下所示：從上圖可以看出，內存消耗：KubeEdge?agent?<?K3S?agent?<?K3S?Server。有意思的是，K3S?agent?即使不運行應用也消耗?100+MB?的內存，而?K3S?server?在空跑的情況下內存消耗也在?300MB?左右。

?CPU 使用對比

分別用?KubeEdge?和?K3S?部署?0~100?個應用，分別觀測兩者的?CPU?使用情況，對比如下所示：

從上圖可以看出，KubeEdge?agent?CPU?消耗要比?K3S?agent?和?server?都要少。

?二進制大小

KubeEdge?agent?二進制大小為?62MB，K3S?二進制大小為?36MB。

大規模

Kubernetes?原生的可擴展性受制于?list/watch?的長連接消耗，生產環境能夠穩定支持的節點規模是?1000?左右。KubeEdge?作為華為云智能邊緣服務?IEF?的內核，通過多路復用的消息通道優化了云邊的通信的性能，壓測發現可以輕松支持?5000+?節點。而?K3S?的集群管理技術尚未開源，因為無法得知?K3S?管理大規模集群的能力。

? ?小結??

K3S?最讓人印象深刻的創新在于其對?Kubernetes?小型化做的嘗試，通過剪裁了?Kubernetes?一些不常用功能并且合并多個組件到一個進程運行的方式，使得一些資源較充足的邊緣節點上能夠運行?Kubernetes，讓邊緣場景下的用戶也能獲得一致的?Kubernetes?體驗。然而通過上面的性能對比數據發現，K3S?的資源消耗還是比?KubeEdge?要高出好幾倍，而且動輒幾百?MB?的內存也不是大多數設備邊緣節點所能提供的。最重要的是，Kubernetes?最初是為云數據中心而設計的，很多邊緣計算場景特殊的問題原生?Kubernetes?無法很好地解決，?K3S?直接修改?Kubernetes?的代碼甚至基礎實現機制（例如，使用?SQLite?替換?etcd）的做法仍值得商榷。關于什么能改，什么不能改以及怎么改？每個用戶根據自己的實際需求有各自的觀點，而且也很難達成一致。另外，?K3S?這種侵入式的修改能否持續跟進?Kubernetes?上游的發展也是一個未知數。

KubeEdge?和?K3S?走的是另一條道路，KubeEdge?是一個從云到邊緣再到設備的完整邊緣云平臺，它與?Kubernetes?的耦合僅僅是?100%?兼容?Kubernetes?原生?API。KubeEdge?提供了?K3S?所不具備的云邊協同能力，開發了更輕量的邊緣容器管理?agent，解決了原生?Kubernetes?在邊緣場景下的離線自治問題，并且支持海量異構邊緣設備的接入等。KubeEdge?最近捐獻給?CNCF，成為?CNCF?邊緣計算領域的第一個正式項目，就是為了和社區合作伙伴一起制定云和邊緣計算協同的標準，結束邊緣計算沒有統一標準和參考架構的混沌狀態，共同推動邊緣計算的產業發展。

最后，邊緣計算還有廣闊的發展前景，KubeEdge?和?K3S?都是非常年輕的優秀開源項目，我相信未來他們會在相互學習的過程中共同進步，更好地解決邊緣計算用戶的需求。

總結

以上是生活随笔為你收集整理的KubeEdge vs K3S：Kubernetes在边缘计算场景的探索的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。