导读
随着近些年VR、AR、物联网等技术的发展和推广，VR头显设备、物联网终端设备等瘦客户端的算力不足问题越发凸显，面对用户终端算力不足的问题，很多厂商都选择利用云计算来拓展用户终端的算力。但是传统的单中心云计算平台距离用户终端太远，其网络时延往往无法满足VR头显等设备的响应速度要求。为减少用户终端调用云计算算力的时延，距离用户终端距离更近、网络时延极低的的边缘计算节点就应运而生了。相较于单中心部署的云计算架构，部署在多个边缘节点的应用服务的运维和管理就变得复杂许多了，所以寻找一套运行高效、维护方便的云-边一体化调度解决方案是非常重要的，本文将会从拓展终端算力的视角出发，逐一剖析目前主要的云-边应用调度方案，并汇总各方案的优劣，希望能在云-边一体化调度方案选择方面给予一定的参考。
作者：郭杨勇
单位：中国移动智慧家庭运营中心成都业务支持中心
Part 01
● 边缘计算方案的概念界定 ●
图1
如上图1所示，在《AI边缘计算技术白皮书》[5]中提出的边缘计算体系定义中，以云数据中心为核心，将边缘计算划分为三个层级：
云边缘：部署在云服务的CDN节点或者是各个地市的分布式数据中心当中的云计算资源，是与现有云计算业务最为接近的一种边缘计算形态。可以提供函数计算、AI智能服务、云渲染等边缘云服务。
移动边缘：伴随着5G通信的发展而出现的新兴边缘计算形态，由于5G网络具备的大带宽、低时延特点，可以通过5G基站+终端实现最佳的边缘位置布放，但要实现云计算能力在5G基站的布放，需要针对基站做较大的改造，而且由于基站空间和配电的限制，无法布放大规模的计算能力。
物边缘：终端自身具备计算能力，如智能手机、VR头显设备、智能摄像头等，由于在终端本地处理计算请求，虽然响应时延低和稳定性能达到最优，但受限于功耗、物理资源等因素，一般仅完成简单计算任务。
综合比较以上三个边缘计算不同层级的特性，可以看出物边缘就是利用了用户终端的算力来处理简单的事务，无法扩展算力以满足云渲染、大数据分析、AI智能服务等重算力场景的需求；而移动边缘也有空间和配电的先天限制，无法扩展太多的算力来给用户终端提供重算力的云计算服务。云边缘既具备云计算中心的重算力储备特点，又贴近用户终端进行部署，应该作为拓展用户终端算力的首选解决方案。
Part 02
● 边缘计算一体化调度的主要技术路线 ●
在单一云中心节点的基础上增加了多个边缘云节点后（如下图2），应用服务的运维管理复杂度会成倍增加，而且多个边缘节点之间的负载均衡、请求转发也更为复杂。为了解决以上问题，Kubernetes、Openstack、微软、华为等国内外开源社区和软件厂商都纷纷推出了自己的边缘云架构解决方案。
图2
综合比较了各大厂商提出的云边缘解决方案，可以归纳两种不同的技术路线：
基于云原生的方案：基于目前已广泛应用的云原生容器化管理架构如Kubernetes和K3s，在其基础上拓展出跨公网的容器化应用下发、统一监控、负载均衡、接口转发等适配边缘云架构的功能，代表性的方案为KubeEdge[1]、Kubernetes Federation[2]。
基于云计算IAAS的方案：依托Openstack等云计算管理平台，在云计算的基础设施层面拓展边缘云的资源管理、应用打包和下发、负载均衡等功能，其功能范围覆盖了物理硬件管理-虚拟化-容器化的全流程，代表性的工具为StarlingX[3]、EdgeGallery[4]。
Part 03
● Nacos的服务发现 ●
3.1 KubeEdge
KubeEdge是基于kubernetes之上将容器化应用的编排能力拓展到边缘主机或边缘设备，在云端和边缘端提供网络通信，应用部署、元数据同步等功能。最早是由华为开源并捐献给Kubernetes社区的。
KubeEdge的优势包括：
便捷部署：开发者可以开发http或mqtt协议的应用，运行在云端和边缘端。
kubernetes原生支持：可以通过kubernetes管理和监控边缘设备和边缘节点，原有的各种应用编排可以无缝移植到KubeEdge中。
KubeEdge作为一个云-边一体化调度的开源解决方案，也将自己的核心模块分为了云侧和边缘侧两类，分别部署在中心云节点和边缘云节点，其核心的模块如下表1所示。
表1
从以上表格不难看出，KubeEdge新增的模块是比较多的，而且这些模块都必须通过命令行的方式到集群的宿主机上执行很多的命令行才能安装，其安装和配置的复杂度相对于纯粹的云原生应用还是要高出许多。
3.2 Kubernetes Federation
Kubernetes Federation通常又被称为K8s联邦，Kubernetes在1.3版本之后，增加了“集群联邦”Federation的功能。这个功能使企业能够快速有效的、低成本的跨区跨域、甚至在不同的云平台上运行集群，还可以按照地理位置创建一个复制机制，将多个kubernetes集群进行复制，即使遇到某个区域连接中断或某个数据中心故障，也会保持最关键的服务运行。
该方案的主要优点包括：
基于原生kubernetes，各个扩展的基础模块都可以复用集群原有的API，且能在社区获得较好的技术支持。
真正的与基础设施无关，相关扩展工具的安装都是通过容器化的方式实现。
相较于之前提到的KubeEdge，Kubernetes Federation主要是扩展了Type Configuration、Schedule、MutiClusterDNS三个组件，如下表2所示。
表2
Kubernetes Federation跨公网的多级群联邦调度机制，其实就是一个依托于MutiClusterDNS多级群服务发现的一种分布式Kubernetes集群调度体系如下图3所示：
图3
3.3 StarlingX
StarlingX准确的说是一个软件栈，他包含了打包、编译、安装配置、Openstack、WindRiver的MTCE平台，以及WindRiver针对电信云开发的VIM等等。StarlinX的部署应用需要从物理机虚拟化开始逐一安装相关工具，因此其边缘节点资源调度的能力很强。但由于跟底层硬件和虚拟化等软件耦合较为验证，业内也主要是九州、风河等云服务厂商在使用，普通的应用系统开发厂商要应用该软件栈的开发和改造成本会很大。
3.4 EdgeGallery
同样是提供了从虚拟化到容器化的一整套软件栈以支持边缘计算的一体化调度，且将APP开发、测试、认证以及上线的技术流程全打通，和StartlingX不同的是，该开源项目的各个模块可以拆分开来按需进行部署，由于该开源项目出现时间较晚，且发行的版本很少，目前还未见到有厂商应用的示例。
综合对比目前主要的一些边缘计算解决方案，对于普通的应用服务厂商来说基于云原生路线的KubeEdge和Kubernetes Federation相较于基于云计算的StartlingX和EdgeGallery具有更高的易用性和更低的实施成本，而对于已经通过Kubernetes进行了容器化部署的厂商，选择Kubernetes Federation平台切换成本最小（如下表3）。
Part 04
● Kubernetes Federation的使用 ●
4.1 环境初始化
1)下载kubefedctl命令行并下载
2）将kubefed-0.3.1.tgz、kubefedctl-0.3.1-linux-amd64.tgz两个文件上传到主机群的master节点，并执行以下命令：
3)查看并确认kubefed的po全部都启动成功了
4.2 将边缘节点的集群添加到联邦中
1）查看各个边缘集群的config信息
2）将各个集群的信息添加到中心集群的$HOME/.kube/config配置文件当中
3）通过kubefedctl命令行工具将自己群加入联邦
如果想要退出联邦，可以执行命令：
4.3 配置联邦化的namespace和yaml配置文件
1)创建联邦化的namespace
添加以下内容：
由于采用应用商店部署只能看到登录账号所属项目的命名空间，所以还必须强制指定各个集群中的projectid：
2）创建联邦化的deployment
添加以下内容：
3）查看各个集群当中容器部署的情况
4.4 跨集群的service和ingress配置
1）创建联邦化的service
2）创建联邦化的ingress
完成以上配置，就可以在内网环境配置出可供验证的Kubernetes联邦集群，对于跨公网的联邦则需要进一步配置公网的DNS和Externel DNS服务来进行跨公网的服务发现。
Part 05
● 总结 ●
从笔者所在的分布式直播项目实践情况来看，Kubernetes Federation作为Kubernetes社区主推的云原生边缘计算一体化调度解决方案，对于普通的应用服务厂商将单中心的应用改造为云边协同的应用，是一个高效且开发成本最低的一种方案。但对于云服务提供商来说，StarlingX也许能更好地分配不同节点的云计算算力，所以具体选择哪一种边缘计算的一体化调度方案还是需要根据自己项目的实际情况而定。
👉参考文献
[1] KubeEdge官方文档 https://kubeedge.io.
[2] Kubernetes Federation文档
https://kubernetes.io/blog/2018/12/12/kubernetes-federation-evolution/.
[3] StarlingX官方文档 www.starlingx.io.
[4] EdgeGallery官方文档https://www.edgexfoundry.org/.