物聯網關鍵技術：在邊緣運行的Kubernetes
Kubernetes(K8S)已經成為云原生的標準技術，其能夠在各種類型的云計算基礎設施上提供一致的使用體驗。
“容器 + Kubernetes”的黃金組合在互聯網企業的DevOps中發揮了巨大的作用。隨著物聯網領域對邊緣計算的需求越來越多，近期也出現了K8S運行在邊緣側的需求和解決方案。
如何在邊緣使用Kubernetes呢?有調查結果顯示，30%的用戶希望在邊緣部署完整的K8S集群，而70%的用戶希望在云端部署K8S的管理平臺，在邊緣部署K8S的代理程序(agent)。
K8S主要是為集中性的云計算平臺來設計的，對于邊緣計算來說有點太重了。為了將K8S從云端延伸到邊緣場景，業內提出了幾種不同的開源K8S邊緣解決方案。其中比較有代表性的解決方案包括華為的KubeEdge、Rancher Labs的K3S和阿里云的OpenYurt等。
KubeEdge
KubeEdge是由華為開發，在2019年成為CNCF在智能邊緣領域的首個正式項目。云邊協同是KubeEdge的一大亮點。KubeEdge通過K8S標準API在云端管理邊緣節點、設備和工作負載，邊緣節點的系統升級和應用程序更新都可以直接從云端下發，提升邊緣運維效率。
KubeEdge架構上分為三層：云端、邊緣和設備層。Kubernetes master運行在云端，用戶可以直接通過kubectl命令行在云端管理邊緣節點、設備和應用，使用習慣與原生Kubernetes完全一致，使用者無需重新適應。
KubeEdge系統架構
KubeEdge的云端進程包含2個組件：
- Cloud Hub部署在云端，接收Edge Hub同步到云端的信息;
- Edge Controller部署在云端，用于控制Kubernetes API Server與邊緣的節點、應用和配置的狀態同步。
KubeEdge的邊緣進程主要包括5個組件：
- Edged是個輕量級的節點代理Kubelet，實現Pod、Volume、Node等K8S資源對象的生命周期管理;
- Meta Manager負責本地元數據的持久化，是邊緣節點自治能力的關鍵;
- Edge Hub是多路復用的消息通道，提供可靠和高效的云邊信息同步;
- Device Twin用于抽象物理設備并在云端生成一個設備狀態的映射;
- EventBus訂閱來自于MQTT Broker的設備數據。
K3S
K3S是CNCF官方認證的Kubernetes發行版，專為在資源受限環境中運行K8S而設計，目的是為了在x86、ARM64和ARMv7D架構的邊緣節點上運行小型的K8S集群。由Rancher Labs公司開發，Rancher Labs 是一家提供容器技術基礎設施的初創企業，于2014年成立。
K3S的名稱含義是指“5 Less Than K8S”，其尺寸、資源需求、復雜度、使用難度等都遠低于K8S，最大特點就是輕量和易用，非常適合用于邊緣計算場景。
K3S系統架構
K3S分Server和Agent，Server就是K8S管理面組件，Agent即K8S的數據面組件。與KubeEdge不同，K3S的所有組件(包括Server和Agent)都運行在邊緣側。
K3S基于特定版本的K8S做了代碼修改，包括：使用containderd替換Docker，顯著減少運行時占用空間;引入SQLite代替etcd作為管理面數據存儲等。
K3S與KubeEdge比較
KubeEdge的管理面部署在云端，邊緣節點無需太多資源就能運行代理節點程序，云邊通過消息協同。從K8S的角度看，邊緣節點 + 云端構成一個完整的K8S集群。
KubeEdge部署模式：云邊結合才是一個K8S集群
K3S可以在邊緣運行完整的K8S集群，這意味著K3S在每個邊緣網絡都需要額外部署Kubernetes管理面。
K3S部署模式：每個邊緣網絡都是一個K8S集群
K3S的部署方式存在一些問題：部署管理面需要消耗較多資源;不同K3S集群間網絡還需要打通;管理多個K3S集群還需要在上面再疊加一層多集群管理組件，遺憾的是Rancher Labs公司尚未開源這個多集群管理組件。
相比K3S，KubeEdge可以支持云邊協同，借助華為強大的技術和市場能力，KubeEdge技術的未來市場前景非常值得期待。
