KubeEdge 1.11版本提供了“邊緣節點分組管理”新特性，抽象出了跨地域的應用部署模型。該模型將邊緣節點按地區劃分為節點組，并將應用所需資源打包成一個整體在節點組上進行部署，降低了邊緣應用生命周期管理的復雜度，有效減少運維成本。

1.邊緣應用跨地域部署面臨的挑戰

　　圖1 邊緣應用跨地域部署示意圖

在邊緣計算場景中，邊緣節點通常分布在不同的地理區域，這些區域中的節點有著計算資源、網絡結構和硬件平臺等屬性上的差異。如圖1所示，邊緣節點部署在杭州、北京和上海等地域，各地域邊緣節點的規模不同，不同地域網絡不互通，以及不同區域鏡像倉庫也是不同的，如北京的節點無法通過IP直接訪問其他區域的節點。因此在部署邊緣應用的時候，通常需要為每個這樣的地理區域維護一個Deployment，對于資源少的區域減少副本數量，對于局域網中的節點需要把鏡像地址改為本地鏡像倉庫的地址，同樣也需要為每個地區管理單獨的Service資源，來解決跨地域節點之間的訪問問題。然而隨著地理區域和應用數量的增長，對應用的管理會變得越來越復雜，運維成本也隨之增加。基于以上背景，KubeEdge提供了邊緣節點分組管理能力，來解決在跨地域應用部署中運維復雜度的問題。

2.邊緣節點分組管理設計與實現

　　圖2 邊緣節點分組整體概覽

如圖2所示，邊緣節點分組特性的整體設計圖，主要由節點分組、邊緣應用和流量閉環三個部分的內容組成，下面會就以上各個部分詳細展開。

2.1 節點分組（NodeGroup）

　　圖3 節點分組示例

根據邊緣節點的地理分布特點，可以把同一區域的邊緣節點分為一組，將邊緣節點以節點組的形式組織起來，同一節點同時只能屬于一個節點組。節點分組可以通過matchLabels字段，指定節點名或者節點的Label兩種方式對節點進行選擇。節點被包含到某一分組后，會被添加上apps.kubeedge.io/belonging-to:nodegroup的Label。

2.2 邊緣應用（EdgeApplication）

　　圖4 邊緣應用EdgeApplication的組成

邊緣應用用于將應用資源打包，按照節點組進行部署，并滿足不同節點組之間的差異化部署需求。該部分引入了一個新的CRD: EdgeApplication，主要包括兩個部分：

1. Workload Templates。主要包括邊緣應用所需要的資源模板，例如Deployment Template、Service Template和ConfigMap Template等；
2. WorkloadScopes。主要針對不同節點組的需求，用于資源模板的差異化配置，包括副本數量差異化配置（Replicas Overrider）和鏡像差異化配置（Image Overrider），其中Image Overrider包括鏡像倉庫地址、倉庫名稱和標簽。

對于應用主體，即Deployment，會根據Deployment Template以及差異化配置Overrider生成每組所需的Deployment版本，通過調整nodeSelector將其分別部署到指定分組中。對于應用依賴的其他資源，如ConfigMap和Service，則只會在集群中通過模板創建一個相應的資源。邊緣應用會對創建的資源進行生命周期管理，當刪除邊緣應用時，所有創建的資源都會被刪除。

2.3 流量閉環

　　圖5 流量閉環示意圖

通過流量閉環的能力，將服務流量限制在同一節點組內，在一個節點組中訪問Service時，后端總是在同一個節點組中。當使用EdgeApplication中的Service Template創建Service時，會為Service添上service-topology:range-nodegroup的annotation，KubeEdge云上組件CloudCore會根據該annotation對Endpoint和Endpointslice進行過濾，濾除不在同一節點組內的后端，之后再下發到邊緣節點。

此外，在下發集群中默認的Master Service “Kubernetes”所關聯的Endpoint和Endpointslice時，會將其維護的IP地址修改為邊緣節點MetaServer地址，用戶在邊緣應用中list/watch集群資源時，可以兼容K8s流量訪問方式，實現無縫遷移和對接。

3.實現原理與設計理念

　　在這個部分，我們會分享一下邊緣節點分組管理特性的設計理念，并結合KubeEdge整體架構，詳細介紹一下我們的實現原理。

　　圖6 設計理念

我們希望給用戶提供一個統一的運維入口，原本我們需要維護各個地區的Deployment，如果需要進行增刪改查操作，我們需要對每個地區的Deployment都執行一遍相同的操作，不僅增加了運維成本，還容易引入人為操作的錯誤。邊緣節點分組管理特性通過引入EdgeApplication CRD，統一了Deployment等資源的運維入口。

另外我們需要提供更大的擴展可能性，在內部實現中，我們統一使用了Unstructured結構，降低與特定資源的耦合度，方便后續添加其他資源。另外為了不干涉原生資源和流程，我們降低與Kubernetes Reconciliation的耦合度，可以保證Deployment等資源操作過程的原生性。

　　圖7 節點組和邊緣應用實現

在邊緣節點分組管理特性中，我們引入了兩個CRD，分別是節點組NodeGroup和邊緣應用EdgeApplication。在NodeGroup Reconciliation中，NodeGroup Controller用于監聽NodeGroup CRD的變化，并對節點的apps.kubeedge.io/belonging-to:nodegroup Label進行增刪改等操作，同時，加入節點組的節點，會上報狀態到NodeGroup CRD中，我們就可以通過查詢NodeGroup直接查看節點組內所有節點的狀態。

EdgeApplication Reconciliation與NodeGroup Reconciliation類似，由EdgeApplication Controller來監聽EdgeApplication CRD的變化，對相應資源進行增刪改等操作，同時對應資源會上報狀態到EdgeApplication CRD中。

　　圖8 整體架構

如圖8所示，是最終的整體架構圖。在邊緣節點分組管理特性中，我們引入了新的組件ControllerManager，其中包括了剛才我們介紹的NodeGroup Controller和EdgeApplication Controller，在CloudCore中引入了新的模塊EndpointSlice Filter，用于實現流量閉環的能力。

圖中藍色區域是前面已經介紹了的節點分組和邊緣應用的內容，在這里再重點介紹一下Service Template實現流量閉環能力的過程。首先在EdgeApplication CRD中加入Service的模板，在創建邊緣應用時，Service range-nodegroup資源也會隨之生成，同時控制面會自動為其創建EndpointSlice。EndpointSlice會通過KubeEdge的云邊通道下發到邊緣節點，CloudCore中的EndpointSlice Filter會進行過濾，保證下發到同一節點組內的邊緣節點，由此可以保證邊緣上的客戶端訪問始終在一個節點組內。

對于用戶來說，圖8中紫色的線表達了用戶需要維護的資源。首先用戶需要維護NodeGroup，來管理節點組中的節點；其次，用戶需要維護EdgeApplication資源，通過EdgeApplication來實現對各個地域邊緣應用的生命周期管理。

4.發展規劃

目前KubeEdge社區已經實現了Deployment、Service和ConfigMap等資源的打包以及流量閉環的能力，并且支持資源的部分狀態收集；未來將繼續拓展邊緣節點分組的能力，實現邊緣網關，支持StatefulSet等更多資源，逐步完善應用狀態收集，并在Kubectl中支持更友好的資源展現形式。歡迎大家能夠加入KubeEdge社區，一起完善與增強KubeEdge邊緣節點分組等方面的能力。