基於KubeEdge的邊緣節點分組管理設計與實現

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

01

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

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

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

02

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

圖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流量訪問方式，實現無縫遷移和對接。

03

實現原理與設計理念

在這個部分，我們會分享一下邊緣節點分組管理特性的設計理念，並結合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來實現對各個地域邊緣應用的生命週期管理。

04

發展規劃

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

本文作者：

KubeEdge社群Member：華為雲 鮑玥 ; 浙江大學SEL實驗室 張逸飛