基于kubeedge的边缘节点分组管理设计与实现-4008云顶国际网站

本文作者：kubeedge社区member：华为云 鲍玥；浙江大学sel实验室 张逸飞 

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. 发展规划

目前我们已经实现了deployment、service和configmap等资源的打包以及流量闭环的能力，并且支持资源的部分状态收集。未来我们将继续拓展边缘节点分组的能力，实现边缘网关，支持statefulset等更多资源，逐步完善应用状态收集，并在kubectl中支持更友好的资源展现形式。欢迎大家能够加入kubeedge社区，一起完善与增强kubeedge边缘节点分组等方面的能力。

了解kubeedge社区

kubeedge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同ai框架sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。添加小助手微信putong3333进入kubeedge交流群

kubeedge网站 :  https://kubeedge.io

github地址 : https://github.com/kubeedge/kubeedge

slack地址 : https://kubeedge.slack.com

邮件列表 : https://groups.google.com/forum/#!forum/kubeedge

每周社区例会 : https://zoom.us/j/4167237304

twitter : https://twitter.com/kubeedge

文档地址 : https://docs.kubeedge.io/en/latest/

扫码回复“进群”和kubeedge成员交流