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

1.邊緣應(yīng)用跨地域部署面臨的挑戰(zhàn)

　　圖1 邊緣應(yīng)用跨地域部署示意圖

在邊緣計(jì)算場(chǎng)景中，邊緣節(jié)點(diǎn)通常分布在不同的地理區(qū)域，這些區(qū)域中的節(jié)點(diǎn)有著計(jì)算資源、網(wǎng)絡(luò)結(jié)構(gòu)和硬件平臺(tái)等屬性上的差異。如圖1所示，邊緣節(jié)點(diǎn)部署在杭州、北京和上海等地域，各地域邊緣節(jié)點(diǎn)的規(guī)模不同，不同地域網(wǎng)絡(luò)不互通，以及不同區(qū)域鏡像倉庫也是不同的，如北京的節(jié)點(diǎn)無法通過IP直接訪問其他區(qū)域的節(jié)點(diǎn)。因此在部署邊緣應(yīng)用的時(shí)候，通常需要為每個(gè)這樣的地理區(qū)域維護(hù)一個(gè)Deployment，對(duì)于資源少的區(qū)域減少副本數(shù)量，對(duì)于局域網(wǎng)中的節(jié)點(diǎn)需要把鏡像地址改為本地鏡像倉庫的地址，同樣也需要為每個(gè)地區(qū)管理單獨(dú)的Service資源，來解決跨地域節(jié)點(diǎn)之間的訪問問題。然而隨著地理區(qū)域和應(yīng)用數(shù)量的增長(zhǎng)，對(duì)應(yīng)用的管理會(huì)變得越來越復(fù)雜，運(yùn)維成本也隨之增加?；谝陨媳尘埃琄ubeEdge提供了邊緣節(jié)點(diǎn)分組管理能力，來解決在跨地域應(yīng)用部署中運(yùn)維復(fù)雜度的問題。

2.邊緣節(jié)點(diǎn)分組管理設(shè)計(jì)與實(shí)現(xiàn)

　　圖2 邊緣節(jié)點(diǎn)分組整體概覽

如圖2所示，邊緣節(jié)點(diǎn)分組特性的整體設(shè)計(jì)圖，主要由節(jié)點(diǎn)分組、邊緣應(yīng)用和流量閉環(huán)三個(gè)部分的內(nèi)容組成，下面會(huì)就以上各個(gè)部分詳細(xì)展開。

2.1 節(jié)點(diǎn)分組（NodeGroup）

　　圖3 節(jié)點(diǎn)分組示例

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

2.2 邊緣應(yīng)用（EdgeApplication）

　　圖4 邊緣應(yīng)用EdgeApplication的組成

邊緣應(yīng)用用于將應(yīng)用資源打包，按照節(jié)點(diǎn)組進(jìn)行部署，并滿足不同節(jié)點(diǎn)組之間的差異化部署需求。該部分引入了一個(gè)新的CRD: EdgeApplication，主要包括兩個(gè)部分：

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

對(duì)于應(yīng)用主體，即Deployment，會(huì)根據(jù)Deployment Template以及差異化配置Overrider生成每組所需的Deployment版本，通過調(diào)整nodeSelector將其分別部署到指定分組中。對(duì)于應(yīng)用依賴的其他資源，如ConfigMap和Service，則只會(huì)在集群中通過模板創(chuàng)建一個(gè)相應(yīng)的資源。邊緣應(yīng)用會(huì)對(duì)創(chuàng)建的資源進(jìn)行生命周期管理，當(dāng)刪除邊緣應(yīng)用時(shí)，所有創(chuàng)建的資源都會(huì)被刪除。

2.3 流量閉環(huán)

　　圖5 流量閉環(huán)示意圖

通過流量閉環(huán)的能力，將服務(wù)流量限制在同一節(jié)點(diǎn)組內(nèi)，在一個(gè)節(jié)點(diǎn)組中訪問Service時(shí)，后端總是在同一個(gè)節(jié)點(diǎn)組中。當(dāng)使用EdgeApplication中的Service Template創(chuàng)建Service時(shí)，會(huì)為Service添上service-topology:range-nodegroup的annotation，KubeEdge云上組件CloudCore會(huì)根據(jù)該annotation對(duì)Endpoint和Endpointslice進(jìn)行過濾，濾除不在同一節(jié)點(diǎn)組內(nèi)的后端，之后再下發(fā)到邊緣節(jié)點(diǎn)。

此外，在下發(fā)集群中默認(rèn)的Master Service “Kubernetes”所關(guān)聯(lián)的Endpoint和Endpointslice時(shí)，會(huì)將其維護(hù)的IP地址修改為邊緣節(jié)點(diǎn)MetaServer地址，用戶在邊緣應(yīng)用中l(wèi)ist/watch集群資源時(shí)，可以兼容K8s流量訪問方式，實(shí)現(xiàn)無縫遷移和對(duì)接。

3.實(shí)現(xiàn)原理與設(shè)計(jì)理念

　　在這個(gè)部分，我們會(huì)分享一下邊緣節(jié)點(diǎn)分組管理特性的設(shè)計(jì)理念，并結(jié)合KubeEdge整體架構(gòu)，詳細(xì)介紹一下我們的實(shí)現(xiàn)原理。

　　圖6 設(shè)計(jì)理念

我們希望給用戶提供一個(gè)統(tǒng)一的運(yùn)維入口，原本我們需要維護(hù)各個(gè)地區(qū)的Deployment，如果需要進(jìn)行增刪改查操作，我們需要對(duì)每個(gè)地區(qū)的Deployment都執(zhí)行一遍相同的操作，不僅增加了運(yùn)維成本，還容易引入人為操作的錯(cuò)誤。邊緣節(jié)點(diǎn)分組管理特性通過引入EdgeApplication CRD，統(tǒng)一了Deployment等資源的運(yùn)維入口。

另外我們需要提供更大的擴(kuò)展可能性，在內(nèi)部實(shí)現(xiàn)中，我們統(tǒng)一使用了Unstructured結(jié)構(gòu)，降低與特定資源的耦合度，方便后續(xù)添加其他資源。另外為了不干涉原生資源和流程，我們降低與Kubernetes Reconciliation的耦合度，可以保證Deployment等資源操作過程的原生性。

　　圖7 節(jié)點(diǎn)組和邊緣應(yīng)用實(shí)現(xiàn)

在邊緣節(jié)點(diǎn)分組管理特性中，我們引入了兩個(gè)CRD，分別是節(jié)點(diǎn)組NodeGroup和邊緣應(yīng)用EdgeApplication。在NodeGroup Reconciliation中，NodeGroup Controller用于監(jiān)聽NodeGroup CRD的變化，并對(duì)節(jié)點(diǎn)的apps.kubeedge.io/belonging-to:nodegroup Label進(jìn)行增刪改等操作，同時(shí)，加入節(jié)點(diǎn)組的節(jié)點(diǎn)，會(huì)上報(bào)狀態(tài)到NodeGroup CRD中，我們就可以通過查詢NodeGroup直接查看節(jié)點(diǎn)組內(nèi)所有節(jié)點(diǎn)的狀態(tài)。

EdgeApplication Reconciliation與NodeGroup Reconciliation類似，由EdgeApplication Controller來監(jiān)聽EdgeApplication CRD的變化，對(duì)相應(yīng)資源進(jìn)行增刪改等操作，同時(shí)對(duì)應(yīng)資源會(huì)上報(bào)狀態(tài)到EdgeApplication CRD中。

　　圖8 整體架構(gòu)

如圖8所示，是最終的整體架構(gòu)圖。在邊緣節(jié)點(diǎn)分組管理特性中，我們引入了新的組件ControllerManager，其中包括了剛才我們介紹的NodeGroup Controller和EdgeApplication Controller，在CloudCore中引入了新的模塊EndpointSlice Filter，用于實(shí)現(xiàn)流量閉環(huán)的能力。

圖中藍(lán)色區(qū)域是前面已經(jīng)介紹了的節(jié)點(diǎn)分組和邊緣應(yīng)用的內(nèi)容，在這里再重點(diǎn)介紹一下Service Template實(shí)現(xiàn)流量閉環(huán)能力的過程。首先在EdgeApplication CRD中加入Service的模板，在創(chuàng)建邊緣應(yīng)用時(shí)，Service range-nodegroup資源也會(huì)隨之生成，同時(shí)控制面會(huì)自動(dòng)為其創(chuàng)建EndpointSlice。EndpointSlice會(huì)通過KubeEdge的云邊通道下發(fā)到邊緣節(jié)點(diǎn)，CloudCore中的EndpointSlice Filter會(huì)進(jìn)行過濾，保證下發(fā)到同一節(jié)點(diǎn)組內(nèi)的邊緣節(jié)點(diǎn)，由此可以保證邊緣上的客戶端訪問始終在一個(gè)節(jié)點(diǎn)組內(nèi)。

對(duì)于用戶來說，圖8中紫色的線表達(dá)了用戶需要維護(hù)的資源。首先用戶需要維護(hù)NodeGroup，來管理節(jié)點(diǎn)組中的節(jié)點(diǎn)；其次，用戶需要維護(hù)EdgeApplication資源，通過EdgeApplication來實(shí)現(xiàn)對(duì)各個(gè)地域邊緣應(yīng)用的生命周期管理。

4.發(fā)展規(guī)劃

目前KubeEdge社區(qū)已經(jīng)實(shí)現(xiàn)了Deployment、Service和ConfigMap等資源的打包以及流量閉環(huán)的能力，并且支持資源的部分狀態(tài)收集；未來將繼續(xù)拓展邊緣節(jié)點(diǎn)分組的能力，實(shí)現(xiàn)邊緣網(wǎng)關(guān)，支持StatefulSet等更多資源，逐步完善應(yīng)用狀態(tài)收集，并在Kubectl中支持更友好的資源展現(xiàn)形式。歡迎大家能夠加入KubeEdge社區(qū)，一起完善與增強(qiáng)KubeEdge邊緣節(jié)點(diǎn)分組等方面的能力。