KubeEdge向左，K3S向右

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 \u0026lt; K3S agent \u0026lt; 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都是非常年輕的優秀開源專案，我相信未來他們會在相互學習的過程中共同進步，更好地解決邊緣計算使用者的需求。