邊緣計算場景分類與挑戰
這裏要討論的“邊緣”特指計算資源在地理分佈上更加靠近設備，而遠離雲數據中心的資源節點。典型的邊緣計算分爲物聯網（例如：下一代工業自動化，智慧城市，智能家居，大型商超等）和非物聯網（例如：遊戲，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都是非常年輕的優秀開源項目，我相信未來他們會在相互學習的過程中共同進步，更好地解決邊緣計算用戶的需求。