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 從雲端延伸到邊緣，有3個開源項目做得不錯，分別是 OpenYurt, KubeEdge 和 K3S，這篇文章主要講下三者的主要差異。
K3S, OpenYurt, KubeEdge 三者都是基於Kubernetes的邊緣計算相關的開源項目，完全兼容Kubernetes API，都可應用在邊緣計算的場景。
K3S是輕量化的Kubernetes，可以不需要中心雲，獨立部署於邊緣節點。和OpenYurt, KubeEdge相比也缺少邊緣計算的雲邊協同，邊緣自治等特性，K3S主要強調是輕量化的Kubernetes，應用於需要完整集群（包含管理集群）的邊緣節點。
在邊緣安裝 Kubernetes 管理面將消耗較多資源，Kubernetes適合資源充足的“基礎設施邊緣”場景，K3S適用於資源較少的“設備邊緣”的場景；但是為了管理邊緣 Kubernetes/K3S 集群還需要在上面疊加一層多集群管理方案，遺憾的是該方案還不成熟。
KubeEdge的架構如下：
OpenYurt的架構如下：
KubeEdge要早於OpenYurt開源，KubeEdge已到1.4， 1.5版本，OpenYurt還處於0.3版本，還未發布1.0版本，KubeEdge相對於OpenYurt更成熟，功能更完善，但兩者特色都是雲邊協同，邊緣自治，管理節點在中心雲，邊緣節點在邊緣。
KubeEdge和OpenYurt最主要的差異在：
OpenYurt可以通過命令將 Kubernetes 集群轉換為 OpenYurt 集群，將 OpenYurt 集群 轉換為 Kubernetes 集群。且OpenYurt完整的保留kubelet，KubeEdge的edged組件 是個重新開發的輕量化 Kubelet，實現 Pod，Volume，Node 等 Kubernetes 資源對象的生命周期管理。所以KubeEdge需要維護更新K8S的新版本，OpenYurt對邊緣節點的資源要求較高，2U4G 起步，這個要求不管手機還是樹莓派都可以輕松滿足，要求不算苛刻，KubeEdge在邊緣運行內存只有區區幾十兆，做到了至極輕量，但功能精簡嚴重，隨着版本的升級，功能逐漸增加，對資源的消耗也逐漸在增加。OpenYurt相對於KubeEdge 跟隨 Kubernetes 版本升級零負擔，OpenYurt 非常容易擴展出更多的能力。
OpenYurt和KubeEdge的對比
OpenYurt和K3S的對比
邊緣計算場景應用概況對比
