隨著kubernetes已經成為容器編排和排程的事實標準，各大公有云廠商都已經基於kubernetes提供了完善的kubernetes雲上託管服務。同時也看到越來越多的企業、行業開始在生產中使用kubernetes, 擁抱雲原生。在各行各業數位化轉型和上雲過程中，公有雲廠商也在主動擁抱傳統線下環境，在思考各種各樣的解決方案使雲上能力向邊緣(或線下)延伸。
而kubernetes由於遮蔽了底層架構的差異性，可以幫助應用平滑地執行在不同的基礎設施上的特性，雲上的kubernetes服務也在考慮拓展其服務邊界，雲原生和邊緣計算結合的想法自然就呼之欲出了。
01 比較思路
這幾個專案都是雲邊一體，雲邊協同的架構，走的是kubernetes和邊緣計算結合的路數，因此決定從以下幾點比較:
（1） 各個專案的開源狀況：比如開源專案的背景、開源的時間、是否進入了cncf等；
（2）kubernetes架構:
（3）對邊緣計算場景支援能力:
接下來以專案的開源順序，從上述幾個方面來介紹各個專案。
02 邊緣雲原生開源專案對比
2.1kubeedge
（1）開源狀況
kubeedge是華為雲於2023年11月份開源的，目前是cncf孵化專案。其架構如下:
（2）與kubernetes的架構差異
首先從架構圖可以看到，雲端(k8s master)增加了cloud hub元件和各類controller，而在邊緣端(k8s worker)沒有看到原生的kubelet和kube-proxy，而是乙個對原生元件進行重寫了edgecore元件。
從架構圖看edgecore是基於kubelet重構的，為了保證輕量化，裁剪了原生kubelet的部分能力，同時也增加了很多適配邊緣場景的能力。具體如下:
上述的架構設計，對比kubernetes的能力增強點主要有：
架構差異可能帶來的影響：
跟隨社群同步演進挑戰大: 由於對kubernetes系統的侵入式修改，後續跟隨kubernetes社群的演進將會遇到很大挑戰。
邊緣節點無法執行operator：因為雲邊通訊機制的修改，cloud hub只能往邊緣推送有限的幾種資源(如pod，configmap等)。而operator既需要自定義crd資源，又需要list/watch雲端獲取關聯資源，因此社群的operator無法執行的kubeedge的邊緣節點上。
邊緣節點不適合執行需要list/watch雲端的應用: 因為雲邊通訊機制的修改，導致原來需要使用list/watch機制訪問kube-apiserver的應用，都無法通過hub tunnel 通道訪問kube-apiserver，導致雲原生的能力在邊緣側大打折扣。
基於增量資料的雲邊推送模式：可以解決邊緣watch失敗時的重新全量list從而引發的kube-apiserver 壓力問題，相比原生kubernetes架構可以提公升系統穩定性。
infra管控資料和業務管控資料耦合：kubernetes集群的管控資料(如pod，configmap資料)和邊緣業務資料(裝置管控資料)使用同一條websocket鏈路，如果邊緣管理大量裝置或者裝置更新頻率過高，大量的業務資料將可能影響到集群的正常管控，從而可能降低系統的穩定性。
邊緣計算場景支援能力
2.2openyurt
（1）開源狀況
openyurt是阿里雲於2023年5月份開源的，目前是cncf沙箱專案。架構如下:
（2）與kubernetes的架構差異
上述的架構設計，對比kubernetes的能力增強點主要有：
邊緣自治:因為每個邊緣節點增加了具備快取能力的透明**yurthub，從而可以保障雲邊網路斷開，如果節點或者業務重啟時，可以利用本地快取資料恢復業務。
雲邊協同(運維監控)：通過tunnel server/tunnel agent的配合，為位於防火牆內部的邊緣節點提供安全的雲邊雙向認證的加密通道，即使邊到雲網路單向連通的邊緣計算場景下，使用者仍可執行原生kubernetes運維命令(如kubectl proxy/logs/exec/port-forward/attach等)。同時中心式的運維監控系統(如prometheus, metrics-server等)也可以通過雲邊通道獲取到邊緣的監控資料。
雲原生生態相容:
所有功能均是通過addon或者controller形式來增強kubernetes，因此保證來對kubernetes以及雲原生社群生態的100%相容。
另外值得一提的是：openyurt專案還提供了乙個yurtctl工具，可以用於原生kubernetes和openyurt集群的一鍵式轉換，
架構差異可能帶來的影響
邊緣計算場景
2.3superedge
（1）開源狀況
（2）與kubernetes的架構差異
與openyurt對比
2.4對比結果一覽
專案華為kubeedge
阿里openyurt
是否cncf專案
是(孵化專案)
是(沙箱專案)
否開源時間
2018.11
2020.5
2020.12
侵入式修改kubernetes是否
否和kubernetes無縫轉換無有
未知邊緣自治能力
有(無邊緣健康檢測能力)
有(無邊緣健康檢測能力)
有(安全及流量消耗待優化)
邊緣單元化
不支援支援
支援(只支援deployment)
是否輕量化
是(節點維度待確認)否否
原生運維監控能力
部分支援
全量支援
全量支援(證書管理及連線管理待優化)
雲原生生態相容
部分相容
完整相容
完整相容
系統穩定性挑戰
大(接入裝置數量過多)
大(大規模節點並且雲邊長時間斷網恢復)
大(大規模節點並且雲邊長時間斷網恢復)
裝置管理能力
有(有管控流量和業務流量耦合問題)無無
總結各個開源專案，整個比較下來自己的感受是：
kubeedge和openyurt/superedge的架構設計差異比較大，相比而言openyurt/superedge的架構設計更優雅一些。而openyurt和superedge架構設計相似，superedge的開源時間晚於openyurt，專案成熟度稍差。
如果打算選擇乙個邊緣計算雲原生專案用於生產，我會從以下角度考慮：
愛好開源，追隨雲原生。
邊緣計算社群長期中立、客觀。
感謝！
雲話題 當邊緣計算遇上雲原生
特邀專家 吳龍輝 阿里雲技術專家，kuberentes實戰 作者，致力於雲原生技術的研究，擁有豐富的雲原生和容器化實踐經驗 目前負責阿里雲cdn和邊緣雲原生技術體系建設，包括邊緣容器平台研發 cdn容器化等。作為雲計算時代的新技術理念，雲原生概念在2015年被提出，它從技術理念 核心架構等多個方面，...
雲計算與邊緣計算
在介紹邊緣計算之前，先來介紹一下雲計算 1.傳統雲計算模型 從圖可以直 到 終端使用者只作為乙個資料消費者，負責像雲請求資料，得到返回結果則進行顯示。雲端的資料也是只從資料生產者那裡獲得。簡言之 雲端接收資料提供者提供的資料，然後接收處理來自終端的請求，再將處理結果返回給終端使用者。2.特點 雲計算...
邊緣計算框架 中國首發的開源邊緣計算框架
baetyl 是 linux foundation edge 旗下的邊緣計算專案，旨在將雲計算能力拓展至使用者現場。baetyl v2 提供了乙個全新的邊雲融合平台，採用雲端管理 邊緣執行的方案，分成邊緣計算框架 本專案 和雲端管理套件兩部分，支援多種部署方式。可在雲端管理所有資源，比如節點 應用 ...