KubeEdge节点分组特性简介

01 边缘应用跨地域部署场景及问题

应用生命周期管理复杂导致运维成本提高

02 边缘节点分组管理

节点分组：将不同地区的边缘节点按照节点组的形式组织
边缘应用：将应用资源整体打包并满足不同节点组之间的差异化部署需求
流量闭环：将服务流量限制在同一节点组中

NodeGroup：

1. 根据节点标签和节点名称选取节点形成节点组

2. 为节点组中的每个节点增加belonging-to标签

EdgeApplication：

1. 包含应用资源模版和各地区差异化配置信息2. 为各个节点组创建差异化应用实例

2. 根据服务模板创建服务，使其拓扑范围为节点组内

提供统一的运维入口

在这里插入图片描述

03

最佳实践

在开始之前：

1. 开启AKE(Autonomic Kube-API Endpoint)特性AKE特性可以使边缘的kube-proxy组件正常运行，通过cloudcore-edgecore之间建立的云边信道list/watch所需资源。CloudCore配置：

开启DynamicController组件，在cloudcore配置中：

EdgeCore配置：

开启MetaServer组件，在edgecore配置中(通常为/etc/kubeedge/config/edgecore.yaml)：

2. 配置Kube-Proxy

将kubeconfig的server地址配置为http://127.0.0.1:10550(10550为MetaServer端口)，通常通过修改kube-proxy的configmap进行。

3. 配置完成后重启上述组件

启用分组管理特性：

1. 在k8s中创建节点分组管理CRD

kubectl apply -f build/crds/apps

该命令会安装NodeGroup和EdgeApplication两个CRD到集群中，如果使用keadm init来初始化kubeedge，则该CRD会自动安装；否则需要执行上述命令来手动安装。

2. 部署controllers

kubectl apply -f build/controllermanager

该命令会在集群的云端节点上部署controllermanager，其中包含NodeGroupController和EdgeApplicationController，分别用于两个CRD的管理，同时也配套安装了相关RBAC规则。

NodeGroup用法说明：
NodeGroup会选取节点组成节点组，主要有两种选取方式：节点名和标签。被选取的节点会被额外加上http://apps.kubeedge.io/belonging-to的标签。

1. 根据节点名选取节点

可以通过指定需要被放入节点组的节点名。

2. 根据标签选取节点

多个标签之间是AND关系，节点需要同时具有这些标签才会被放入节点组中。当新接入的节点拥有满足条件的标签时，会被自动地放入相应节点组中。

3. NodeGroup生命周期

当删除节点组时，节点组中节点上的belonging-to标签会被自动删除，即节点组中的节点会自动退出节点组。

EdgeApplication用法说明

1. WorkloadTemplateWorkloadTemplate中存放的是应用所需要的资源模板，如Deployment，Service，ConfigMap等。对于Deployment：会根据WorloadScope中的差异化配置生成各节点组的实例。对于Service：会为其增加range-nodegroup的标签。

对于其他资源：会直接在集群中创建。

2. WorkloadScope

WorkloadScope中存放的是节点组的差异化配置信息，可以为特定节点组设置Overrider。目前支持设置replicas overrider和image overrider。replicas overrider：设置的值会覆盖Deployment模板中的replicas字段。

image overrider：可以修改镜像地址的Registry、Repository、Tag三个部分，每个部分可以进行的修改有add、remove、replace。

3. EdgeApplication生命周期

更新：

当更新EdgeApplication时，其创建的子资源会被自动更新，同时兼容Deployment的滚动更新策略，在同节点组的Pod实例间进行滚动更新。

删除：

当删除EdgeApplication时，所有该EdgeApplication创建的资源都会被自动删除。