01 边缘应用跨地域部署场景及问题
应用生命周期管理复杂导致运维成本提高
02 边缘节点分组管理
节点分组：将不同地区的边缘节点按照节点组的形式组织
边缘应用：将应用资源整体打包并满足不同节点组之间的差异化部署需求
流量闭环：将服务流量限制在同一节点组中
NodeGroup：
-
根据节点标签和节点名称选取节点形成节点组
-
为节点组中的每个节点增加belonging-to标签
EdgeApplication：
-
包含应用资源模版和各地区差异化配置信息2. 为各个节点组创建差异化应用实例
-
根据服务模板创建服务，使其拓扑范围为节点组内
提供统一的运维入口
在这里插入图片描述
03
最佳实践
在开始之前：
- 开启AKE(Autonomic Kube-API Endpoint)特性AKE特性可以使边缘的kube-proxy组件正常运行，通过cloudcore-edgecore之间建立的云边信道list/watch所需资源。CloudCore配置：
开启DynamicController组件，在cloudcore配置中：
EdgeCore配置：
开启MetaServer组件，在edgecore配置中(通常为/etc/kubeedge/config/edgecore.yaml)：
- 配置Kube-Proxy
将kubeconfig的server地址配置为http://127.0.0.1:10550(10550为MetaServer端口)，通常通过修改kube-proxy的configmap进行。
- 配置完成后重启上述组件
启用分组管理特性：
- 在k8s中创建节点分组管理CRD
kubectl apply -f build/crds/apps
该命令会安装NodeGroup和EdgeApplication两个CRD到集群中，如果使用keadm init来初始化kubeedge，则该CRD会自动安装；否则需要执行上述命令来手动安装。
- 部署controllers
kubectl apply -f build/controllermanager
该命令会在集群的云端节点上部署controllermanager，其中包含NodeGroupController和EdgeApplicationController，分别用于两个CRD的管理，同时也配套安装了相关RBAC规则。
NodeGroup用法说明：
NodeGroup会选取节点组成节点组，主要有两种选取方式：节点名和标签。被选取的节点会被额外加上http://apps.kubeedge.io/belonging-to的标签。
- 根据节点名选取节点
可以通过指定需要被放入节点组的节点名。
- 根据标签选取节点
多个标签之间是AND关系，节点需要同时具有这些标签才会被放入节点组中。当新接入的节点拥有满足条件的标签时，会被自动地放入相应节点组中。
- NodeGroup生命周期
当删除节点组时，节点组中节点上的belonging-to标签会被自动删除，即节点组中的节点会自动退出节点组。
EdgeApplication用法说明
- WorkloadTemplateWorkloadTemplate中存放的是应用所需要的资源模板，如Deployment，Service，ConfigMap等。对于Deployment：会根据WorloadScope中的差异化配置生成各节点组的实例。对于Service：会为其增加range-nodegroup的标签。
对于其他资源：会直接在集群中创建。
- WorkloadScope
WorkloadScope中存放的是节点组的差异化配置信息，可以为特定节点组设置Overrider。目前支持设置replicas overrider和image overrider。replicas overrider：设置的值会覆盖Deployment模板中的replicas字段。
image overrider：可以修改镜像地址的Registry、Repository、Tag三个部分，每个部分可以进行的修改有add、remove、replace。
- EdgeApplication生命周期
更新：
当更新EdgeApplication时，其创建的子资源会被自动更新，同时兼容Deployment的滚动更新策略，在同节点组的Pod实例间进行滚动更新。
删除：
当删除EdgeApplication时，所有该EdgeApplication创建的资源都会被自动删除。
