CN114679380B - 边缘集群的创建方法和相关装置 - Google Patents

Abstract

本申请实施例公开了一种边缘集群的创建方法和相关装置，涉及云技术领域，该方法包括：获取边缘集群的创建指令；利用所述配置文件和所述静态文件部署第一组件集合，得到基础集群，所述第一组件集合包括管理和控制的所述基础集群的组件；利用所述配置文件和所述静态文件在所述基础集群上部署第二组件集合，得到所述边缘集群，所述第二组件集合包括为所述边缘集群提供边缘计算能力的组件。在本申请实施例中，借助edgeadm由云服务器对基础的kubernetes集群进行部署，在基础的kubernetes集群上部署边缘组件，能够一键创建独立的边缘kubernetes集群，能有效地提高边缘集群创建的成功率。

Description

边缘集群的创建方法和相关装置

技术领域

本申请涉及云计算领域，尤其涉及一种边缘集群的创建方法和相关装置。

背景技术

随着互联网智能终端设备数量的急剧增加，以及5G和物联网时代的到来，传统云计算中心集中存储、计算的模式已经无法满足终端设备对于时效、容量、算力的需求，边缘计算平台由此应运而生。边缘计算平台旨在将边缘端靠近数据源的计算单元纳入到中心云，实现集中管理，将云服务部署其上，及时响应终端请求。边缘计算平台能够很好地将云计算的能力下沉到边缘侧、设备侧，并通过中心进行统一交付、运维、管控。因此，边缘计算平台也成为了云计算的重要发展趋势。

在当今的技术中，边缘计算平台的创建通常通过手工或者脚本将kubernetes集群转化为边缘独立的kubernetes集群。用户需要自己用服务商要求的工具部署了一个特定版本的kubernetes集群，然后通过手工或脚本，将这个kubernetes集群转化成边缘计算平台需要的kubernetes底座，然后再在这个底座上面部署边缘能力组件，将这个kubernetes集群转化为具有边缘能力的kubernetes集群。

采用上述方式构建边缘集群只能基于特定版本的kubernetes集群去部署集群底座。用户需要根据该特定版本kubernetes集群去修改特定位置的特定配置文件，才能将一个普通的kubernetes底座转化成为边缘计算的kubernetes底座。由于kubernetes底座的繁杂，在对普通的kubernetes底座转化过程中，用户需要进行需要大量的配置工作，且转化的成功率极低。因此，需要研究更为简便和高效的边缘集群的创建方法。

发明内容

本申请实施例公开了一种边缘集群的创建方法和相关装置，该方法基于现有的kubernetes集群，通过edgeadm对基础的kubernetes集群进行部署，在基础的kubernetes集群上部署具备边缘计算能力的组件，能够一键创建独立的边缘kubernetes集群，无需进行繁杂的转化工作，操作简单，且能有效地提高边缘集群创建的成功率。

第一方面，本申请实施例提供了一种边缘集群的创建方法，所述方法包括获取边缘集群的创建指令，所述创建指令用于利用配置文件和静态文件创建边缘集群；利用所述配置文件和所述静态文件部署第一组件集合，得到基础集群，所述第一组件集合包括管理和控制的所述基础集群的组件；利用所述配置文件和所述静态文件在所述基础集群上部署第二组件集合，得到所述边缘集群，所述第二组件集合包括为所述边缘集群提供边缘计算能力的组件。

本方法利用管理边缘集群的命令行工具edgeadm结合基础的kubernetes集群部署所述边缘集群。所述第一组件集合包括docker、kubelet、etcd等基础kubernetes集群架构中的组件。在第一组件部署完成之后，得到基础的kubernetes集群。之后，在所述基础的kubernetes集群的上，接着部署所述第二组件集合，所述第二组件集合包括edge-cloudapps、tunnel-coredns、tunnel-cloud、application-grid controller、edge-health-admission、tunnel-edge等具备边缘计算能力的组件。在所述第二组件集合部署完成后，原本基础的kubernetes集群则变为了具备边缘计算能力的边缘集群。在本方法中，通过edgeadm对基础的kubernetes集群进行一键部署，无需经过复杂的底座转化环节即可得到具备边缘计算能力的边缘集群，能有效提高边缘集群的创建效率以及成功率。此外，本方法对原生kubernetes组件并没有修改，可以随着原生kubernetes的升级体验新的kubernetes功能，完全兼容kubernetes的能力。

在第一方面一个可选的实施方式中，所述根据所述配置文件和所述静态文件部署所述第一组件集合，得到基础集群，包括：根据所述配置文件和所述静态文件部署第三组件集合和静态容器组，所述第三组件集合被包含于所述第一组件集合，所述第三组件集合和所述静态容器组用于向所述边缘集群中添加主节点和从节点。

由于edgeadm提供了支持灵活添加边缘kubernetes集群的主节点和边缘从节点的组件(例如haproxy/nginx)，因此，在本申请实施例中，在构建基础kubernetes集群时，可以在组件部署的过程中，相应的将用于添加主节点和从节点的所述第三组件集合以及静态容器组进行部署，从而使得用户能自由的扩展kubernetes集群的主节点的数量，实现所述边缘集群的高可用；此外，由于本申请实施例支持添加任意位置的边缘节点，因此可以在任意位置部署用户的边缘应用，让边缘应用离用户更近，集群的边缘能力显著提高。

在第一方面一个可选的实施方式中，所述获取边缘集群的创建指令之后，所述方法还包括：判断用户的输入数据是否有误；所述根据所述配置文件和所述静态文件部署所述第一组件集合，得到基础集群，包括：在所述输入数据无误的情况下，根据所述配置文件和所述静态文件部署所述第一组件集合，得到基础集群。

在本实施方式中，为确保边缘群集群的顺利创建，在设备获取到用户的所述创建指令后，将接着判断用户输入数据的是否有误，例如参数的类型、IP地址的格式是否有误等等，在输入数据无误的情况下，再开始边缘集群的创建，能确保后续的创建步骤的顺利进行，进一步提所述边缘集群的创建的成功率。

在第一方面一个可选的实施方式中，所述判断用户的输入数据是否有误之后，所述方法还包括：判断所述边缘集群的安装环境是否有风险项；所述在所述输入数据无误的情况下，根据所述配置文件和所述静态文件部署所述第一组件集合，得到基础集群，包括：在所述输入数据无误且所述安装环境没有风险项的情况下，根据所述配置文件和所述静态文件部署所述第一组件集合，得到基础集群。

在本实施方式中，为确保边缘群集群的顺利创建，在设备获取到用户的所述创建指令后，并判断用户输入数据的无误后，再开始边缘集群的创建，能确保后续的创建步骤的顺利进行，进一步提所述边缘集群的创建的成功率。

在第一方面一个可选的实施方式中，所述利用所述配置文件和所述静态文件在所述基础集群上部署第二组件集合，得到所述边缘集群，包括：在所述基础集群健康的情况下，利用所述配置文件和所述静态文件在所述基础集群上部署第二组件集合，得到所述边缘集群。

在本实施方式中，为确保边缘群集群的顺利创建，在完成对所述基础集群的部署后，将相应的检查所述基础集群的健康性。例如基于Dockerfile文件中的CMD或者ENTRYPOINT进行检查，如果进程退出时返回码为非零，则认为容器发生故障，所述基础集群就会根据restartPolicy重启容器。在确保所述基础集群健康后，再开始部署所述边缘集群的边缘能力组件，即所述第二组件集合，能确保后续的创建步骤的顺利进行，进一步提所述边缘集群的创建的成功率。

在第一方面一个可选的实施方式中，所述获取边缘集群的创建指令之后，所述方法还包括：创建日志文件库，所述日志文件库用于存储所述边缘集群创建过程中产生的日志数据。

在本实施方式中，在开始部署所述边缘集群之前，将事先创建一个能够记录所述边缘集群创建过程的步骤以及执行每一步骤后集群状态的日志文件库，因此在集群安装故障时可以有效的追踪到故障的源头。此外，在所述边缘集群创建成功之后，在后续使用的过程中，所述日志文件库还用于存储所述边缘集群产生的数据以及边缘集群的状态情况，从而便于集群日常的维护和风险项排查。

在第一方面一个可选的实施方式中，所述获取边缘集群的创建指令，之前，所述方法还包括接收创建请求以及所述用配置文件和所述静态文件；所述获取边缘集群的创建指令，包括：调用目标程序的目标接口对所述创建请求进行解析，得到所述创建指令，所述目标程序为将所述边缘集群的方法进行封装所得的程序。

在本实施方式中，安装边缘集群的方法被封装成一个程序，并通过接口调用所述程序来触发边缘集群的创建，可以远程控制设备安装所述边缘集群。例如，设备1中安装有所述程序，则可通过远程设备2将创建指令发送给设备1；设备1接收到所述创建指令后调用所述程序的接口对所述创建指令进行解析后，将按照所述程序中封装的方法创建边缘集群。

第二方面。本申请实施例提供了一种边缘集群的创建装置，所述装置包括：获取单元，获取边缘集群的创建指令，所述创建指令用于利用配置文件和静态文件创建边缘集群；第一部署单元，用于利用所述配置文件和所述静态文件部署第一组件集合，得到基础集群，所述第一组件集合包括管理和控制的所述基础集群的组件；第二部署单元，用于利用所述配置文件和所述静态文件在所述基础集群上部署第二组件集合，得到所述边缘集群，所述第二组件集合包括为所述边缘集群提供边缘计算能力的组件。

在第二方面一个可选的实施方式中，所述第一部署单元，具体用于根据所述配置文件和所述静态文件部署第三组件集合和静态容器组，所述第三组件集合被包含于所述第一组件集合，所述第三组件集合和所述静态容器组用于向所述边缘集群中添加主节点和从节点。

在第二方面一个可选的实施方式中，所述装置还包括：判断单元，用于判断用户的输入数据是否有误；所述第一部署单元，具体用于在所述输入数据无误的情况下，根据所述配置文件和所述静态文件部署所述第一组件集合，得到基础集群。

在第二方面一个可选的实施方式中，所述判断单元，还用于判断所述边缘集群的安装环境是否有风险项；所述第一部署单元，具体用于在所述输入数据无误且所述安装环境没有风险项的情况下，根据所述配置文件和所述静态文件部署所述第一组件集合，得到基础集群。

在第二方面一个可选的实施方式中，所述第二部署单元，具体用于在所述基础集群健康的情况下，根据所述配置文件和所述静态文件部署第二组件集合，得到所述边缘集群。

在第二方面一个可选的实施方式中，所述装置还包括：记录单元，具体用于创建日志文件库，所述日志文件库用于存储所述边缘集群创建过程中产生的日志数据。

在第二方面一个可选的实施方式中，所述装置还包括：接收单元，用于接收创建请求以及所述用配置文件和所述静态文件，所述创建单元，具体用于，调用目标程序的目标接口对所述创建指令进行解析，得到所述创建指令，所述目标程序为将所述边缘集群的方法进行封装所得的程序。

第三方面，本申请实施例提供了一种电子设备，包括：存储器，用于存储程序；处理器，用于执行所述存储器存储的所述程序，当所述程序被执行时，所述处理器用于执行如所述第一方面及任一种可选的实现方式的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，其特征在于，所述计算机存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行如所述第一方面及任一种可选的实现方式的方法。

附图说明

为了更清楚地说明本申请实施例或背景技术中的技术方案，下面将对本申请实施例或背景技术中所需要使用的附图作简单的介绍。

图1为本申请实施例提供的一种传统云计算模型的示意图；

图2为本申请实施例提供的一种边缘计算模型的示意图；

图3为本申请实施例提供的一种搭建边缘集群的场景示意图；

图4为本申请实施例提供的一种边缘集群的创建方法的流程图；

图5为本申请实施例提供的一种安装边缘集群的过程示意图；

图6为本申请实施例提供的一种边缘集群的架构图；

图7为本申请实施例提供一种添加Master节点的方法的流程示意图；

图8为本申请实施例提供的一种添加Node节点的方法的流程示意图；

图9为本申请实施例提供的一种为边缘集群添加Node节点的过程示意图；

图10为本申请实施例提供的一种边缘集群的创建装置的结构示意图；

图11为本申请实施例提供的一种电子设备的结构示意图；

图12为本申请实施例提供的一种服务器的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地描述。

本申请的说明书、权利要求书及附图中的术语“第一”和“第二”等仅用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备等，没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元等，或可选地还包括对于这些过程、方法、产品或设备等固有的其它步骤或单元。

在本文中提及的“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员可以显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上，“至少两个(项)”是指两个或三个及三个以上，“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”。

本发明实施例提供了边缘集群的创建方法及相关装置，为更清楚的描述本发明的方案。下面先介绍一些本申请实施例提供的边缘集群的和创建方法及相关装置所涉及的知识。

Master节点和Node节点：kubernetes整个架构分为master节点和node节点，其中master节点负责容器组pod的调度、服务账户以及令牌的管理等等；而node节点主要负责容器的创建，服务的代理以及其他相关应用。Master又称为主节点或者控制节点，提供集群的控制面板，也是整个Kubernetes集群的管控中心。而Node称为从节点，负责承载容器运行，是容器的宿主机。

高可用：高可用是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务，则系统的可用性是100％；如果系统每运行100个时间单位，会有1个时间单位无法提供服务，则系统的可用性是99％。系统可用性越高，则系统高可用性能越好。

网格：网格是通过利用大量异构计算机的未用资源，如CPU、磁盘存储等，将其作为嵌入在分布式的一个虚拟的计算机集群，为解决大规模的计算问题提供一个模型。目标是解决对于任何单一的计算机来说仍然大得难以解决的问题，并同时保持解决多个较小的问题的灵活性。

edgeadm：edgeadm是superedge团队推出的管理边缘集群的命令行工具。edgeadm能够无缝的将kubernestes集群转化成edge集群，应用于边缘场景。其次，edgeadm能够支持用户自定义边缘集群的属性和相关组件的调试开发。

自云计算提出之后，就开始逐步的改变我们生活、学习、工作的方式。生活中经常用到的google、facebook等软件提供的服务就是典型的代表。并且，可伸缩的基础设施和能够支持云服务的处理引擎也对我们运营商业的模式产生了一定的影响，比如，hadoop、spark等等。

物联网的快速发展让我们进入了后云时代，在我们的日常生活中会产生大量的数据。据统计，2019年有将近500亿的事物连接到互联网。物联网应用可能会要求极快的响应时间，数据的私密性等等。如果把物联网产生的数据传输给云计算中心，将会加大网络负载，网路可能造成拥堵，并且会有一定的数据处理延时。

图1为本申请实施例提供的一种传统云计算模型的示意图。如图1所示，最左侧为数据库101，用于提供数据，上传到云中心102。客户终端103发送请求到云中心102，云中心102响应相关请求并发送数据给客户终端103。在传统的云计算模型中，客户终端103始终是数据消费者的角色，物联网产生的数据均传输给云中心，网络负载严重，数据传输过程中网路可能会拥堵，并且会有一定的数据处理延时。

针对传统的云计算模型中存在的问题，我们假设了一种新的处理问题的模型，即边缘计算平台，具体请参阅图2。

图2为本申请实施例提供的一种边缘计算模型的示意图。如图2所示，边缘结点(即图中数据源和消费者202，包括智能家电、手机、平板等)产生数据，上传到云中心202，服务提供商，即数据库201也产生数据上传到云中心202。边缘结点发送请求到云中心202，云中心202返还相关数据给边缘结点。边缘平台中，终端设备与云计算中心的请求与响应是双向的，终端设备不仅向云计算中心发出请求，同时也能够完成云计算中心下发的计算任务。云计算中心不再是数据生产者和消费者的唯一中继，终端设备兼顾数据生产者和消费者的角色，部分服务直接在边缘完成响应并返回终端设备，云计算中心和边缘分别形成了两个服务响应流。相比于传统的云计算，它能够节省网络流量、提高响应速度和保护用户隐私。

在当今已有的技术中，如果想要得到具备边缘计算能力的集群，较常用的方法就是通过手工或者脚本将基础的kubernetes集群转化为具备边缘计算能力的kubernetes集群。但该方案需要用户自己用服务商要求的工具部署了一个特定版本的kubernetes集群，然后在这个特定版本的kubernetes集群上面通过手工或脚本，将这个kubernetes集群转化成边缘计算平台需要的kubernetes底座，然后再在这个底座上面部署边缘能力组件，让这个kubernetes集群具有边缘计算能力。但该方法存在明显缺点：部署kubernetes底座比较复杂，学习成本极高；其次，在对底座转化的过程中还需要进行大量的配置和修改，转化的成功率极低；此外，通过该方法得到的边缘集群不能灵活地添加边缘节点，只能在创建时添加好节点，再进行转化，把kubernetes集群中一个普通的节点转化成为边缘节点；且不具备自己的高可用能力，若要实现高可用，需要用户部署同一个高可用的kubernetes集群作为边缘集群的底座，然后转化为高可用的边缘集群，如果用户搭建的集群工具不具备高可用能力，则无法得到高可用的边缘集群。

针对上述方法中的不足，本申请实施例提供了一种边缘集群的创建方法，该方法无需进行复杂的转化工作，而是通过edgeadm一键创建一个独立的边缘集群。除此之外，由于edgeadm提供了灵活的添加边缘kubernetes集群的master节点和边缘node节点的方法，因此，该边缘集群可以实现高可用；其次，该边缘集群支持添加任意位置的边缘节点，实现在任意位置部署用户的边缘应用，可以让边缘应用离用户更近。最后，edgeadm还支持清理集群中任意master节点和node节点，将该节点重新命名接入到同一边缘集群，或者其他边缘集群，实现了节点的可重入性。

接下来介绍本申请实施例提供的一种搭建边缘集群的场景示意图，具体请参阅图3。

如图3所示，本申请实施例提供的边缘集群的创建方法可基于图1的场景环境实施。在对边缘集群进行搭建时，客户端发送集群搭建请求到服务器，服务器获取集群搭建请求后，获取预设的配置模板，根据配置文件信息部署配置模板，得到配置文件；再根据配置文件进行kubernetes集群的模块化部署，得到基础的kubernetes集群。应理解，此时的kubernetes集群还不具备边缘化能力。之后，接着按照上述配置模板，在上述基础的kubernetes集群上部署提供边缘计算能力的组件，得到最终的具备边缘计算能力的边缘集群。其中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器；客户端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。客户端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

接下来介绍本申请实施例提供的一种边缘集群的创建方法的流程图，该边缘集群的创建方法可以基于图3所示的搭建场景进行实施，具体请参阅图2。

图4为本申请实施例提供的一种边缘集群的创建方法的流程图。如图2所示，该方法包括如下步骤：

401、服务器获取边缘集群的创建指令。

客户端发起边缘集群的创建指令后，上述服务器将获取该创建指令。该创建指令用于利用配置文件和静态文件创建边缘集群。上述服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器；上述客户端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。客户端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

可选的，该创建指令包含用于指示上述边缘集群的配置文件的指示信息以及用于指示上述边缘集群的静态文件的指示信息。具体的，上述配置文件可包括以下内容：cluster，即边缘kubernetes集群的相关配置；master：即master节点的信息；ha，即高可用的相关配置信息；registries，即镜像仓库的信息、docker，即docker运行时的配置信息等等。上述静态文件可以包括以下内容：bin，即运行上述边缘集群需要的二进制文件(例如kubeadm、kubelet、kubectl等)；conf，即运行边缘kubernetes集群组件需要的配置文件(例如kubeadm.yaml)；container-runtime，即容器运行时需要的安装包(例如cri-dockerd-cni-linux-amd64.tar.gz)；images，即上述边缘集群需要的镜像文件包(例如kubeadm.yaml)；shell，即安装上述边缘集群可能需要运行的shell脚本(例如master.sh)等等。

在一些实施例中，在获取到用户的输入数据后，上述服务器将检测用户的输入数据是否有误。上述输入数据可以包括ETCD参数、主节点参数和从节点参数等。ETCD参数包括集群名称、节点存储目录和节点名称等。主节点参数可以包括Kubernetes主节点的属性参数，例如安装版本、Kubernetes主节点的地址、运行Kubernetes主节点的节点标识(名称)以及区域标识等。从节点参数可以包括Kubernetes从节点的属性参数，例如安装版本、Kubernetes从节点的地址、运行Kubernetes从节点的节点标识(名称)以及区域标识等。若输入数据有误则向用户发送提示信息；若输入数据无误则将上述输入数据保存。

具体地，客户端获取的客户的操作行为，若获取到预设的指令或者触发动作，则采集或者获取对应的信息，生成边缘集群的创建指令。示例性地，用户可以通过客户端上传包含配置文件信息的文件，在文件上传成功之后自动触发该集群搭建请求的生成或者通过预设的指令或者按键来触发。或者，客户端提供了包含各种配置参数的可视化编辑界面，用户在该可视化编辑界面进行配置参数的编辑，编辑完成之后自动触发该集群搭建请求的生成或者通过预设的指令或者按键来触发。

在一些实施例中，上述创建指令由上述客户端接收其他终端设备的创建请求后，对该创建请求进行解析而来。具体地，在这些实施例中，本申请实施例提供的方法被封装在一个常驻程序中，该程序安装在上述客户端中。上述客户端可以接收上述其他终端设备发送的创建指令(该创建指令由用户输入至上述其他终端设备，再由上述其他终端设备发送给上述客户端)，上述客户端接收到该创建指令后，将调用上述程序中的API接口对该创建指令进行解析，所述创建指令。

402、上述服务器利用配置文件和静态文件部署第一组件集合，得到基础集群。

在得到配置文件之后，上述服务器将根据配置文件中预设的配置模板进行基础kubernetes集群的模块化部署。上述第一组件集合包括docker、kubelet、etcd、kube-*(kube-*表示组件名称前缀为“kube-”的组件，例如kube-apiser，kube-scheduler、kube-controller-manager等)等组件中的部分或全部，本申请实施例不做限定。应注意，kube-apiser，kube-scheduler、kube-controller-manager等组件的安装需通过etcd组件的支持。因此，在部署上述第一组件集合时，etcd组件需安装于kube-apiser，kube-scheduler、kube-controller-manager等组件之前。

优选地，上述第一组件集合还包括haproxy/nginx等组件。由于edgeadm提供了支持灵活添加边缘kubernetes集群的主节点和边缘从节点的组件(例如haproxy/nginx)，因此，在一些实施例中，在构建基础kubernetes集群时，可以在组件部署的过程汇中，相应的将用于添加主节点和从节点的组件集合以及静态容器组部进行部署，从而使得用户能自由的扩展kubernetes集群的主节点的数量，实现所述边缘集群的高可用；此外，由于本申请实施例支持添加任意位置的边缘节点，因此可以在任意位置部署用户的边缘应用，让边缘应用离用户更近。

在一些实施例中，在上述第一组件集合的部署过程中，上述服务器还会为集群部署日志文件库，用于记录所述边缘集群创建过程的步骤以及执行每一步骤后集群状态，或者记录在后续使用的过程中所述边缘集群产生的数据以及边缘集群的状态情况。具体地，上述日志文件库可以是ETCD数据库，ETCD数据库是为kubernetes集群提供默认的存储系统，用于保存集群数据，主要存储各个模块的持久化数据，例如服务信息、kubernetes集群的基本信息、调度模块的调度结果、跨集群服务发现模块所需要的服务与集群对应关系等。此外，部署上述第一组件集合还可以包括registry部署、dns部署和traefik部署等。

在一些实施例中，在部署上述第一组件集合之前，上述服务器还将检查集群的安装环境是否有风险项(例如上述客户端中虚拟机的版本信息、配置文件的安全性等等)。

可选地，可以调用Ansible工具进行上述基础kubernetes集群的模块化部署。Ansible工具是基于Python语言实现的自动化运维管理工具，相比于另一些如服务器/客户端架构的工具，Ansible工具不需要在待部署节点上部署客户端代理。

403、上述服务器利用上述配置文件和上述静态文件在上述基础集群上部署第二组件集合，得到上述边缘集群。

应理解，本申请实施例提供的边缘集群的创建方法是利用SuperEdge提供的edgeadm在原生kubernetes基础集群上进行了扩展，增加了边缘计算的若干组件，对Kubernetes完全无侵入；另外通过简单部署SuperEdge核心组件就可以使原生kubernetes集群开启边缘计算功能；而且零侵入使得可以在边缘集群上部署任何kubernetes原生工作负载(deployment，statefulset，daemonset和etc)。也就是说，步骤402中得到的是基础的kubernetes集群，该集群并不具备边缘能力。因此，需要继续对该基础的kubernetes集群进行部署，在该基础的kubernetes集群上部署具备边缘计算能力的组件，上述第二组件集合可以包括edge-cloud apps、tunnel-coredns、tunnel-cloud、application-gridcontroller、application-grid wrapper、edge-health-admission、tunnel-edge、lite-apisever、edge health、kublet、coredns、flannel、kube-proxy等组件中的部分或全部，用户可以根据具体需求选择具体的组件，本申请实施例不作限定。

其中，tunnel-cloud组件为云边协同隧道的云端组件，负责代理云端请求到边端；tunnel-edge组件为云边协同隧道的边端组件，其负责承接tunnel-cloud组件的请求，并将云端请求转发给边端组件；而application-grid controller组件为应用网络控制器，负责服务访问控制ServiceGroup对应的Kubernetes Controller，负责管理DeploymentGrids以及ServiceGrids CRDs，并由这两种CR生成对应的Kubernetes deployment以及service，同时自研实现服务拓扑感知，使得服务闭环访问。

优选地，在部署上述第二组件集合时，上述服务器将部署支持边缘应用分发的插件，使所述边缘集群能实现同时部署多个站点的功能，进一步提高了所述边缘集群的边缘计算能力。

在一些实施例中，在进行上述第二组件的部署之前，上述服务器将检查上述基础集群的健康性。例如基于Dockerfile文件中的CMD或者ENTRYPOINT进行集群的健康性检查，如果进程退出时返回码为非零，则认为容器发生故障，所述基础集群就会根据restartPolicy重启容器。在确保所述基础集群健康后，再开始部署所述边缘集群的边缘能力组件，能确保后续的创建步骤的顺利进行。

在一些实施例中，当上述创建边缘集群的流程中出现安装失败的情况时，例如某个组件安装失败，上述服务器将读取上述日志文件库中的相应的安装步骤，并重试失败的步骤；若成功继续进行下一步，否则继续弹出错误。再例如，当需要重新创建整个集群时，上述服务器将提示用户使用相应的清除指令(edgeadm clean master/node)，让用户主动去清理边缘master/node节点的信息，清理之前安装的错误数据；清理完成后，再重新进行安装。

由于本申请实施例提供的创建边缘集群的方法是利基于命令行工具edgeadm以及相应的配置文件和静态文件来实现集群的创建，因此，基于图4所示的边缘集群的创建方法，本申请实施例结合edgeadm中的具体指令行提出了一种安装边缘集群的过程示意图，具体请参阅图5。

图5为本申请实施例提供的一种安装边缘集群的过程示意图。如图5所示，用户在预安装边缘Kubernetes集群的目标设备上运行创建边缘Kubernetes集群的命令(即图5中的“edgeadm edgecluster”，这里的指令只是一种抽象的指令形式，只是为了体现该指令行的功能，在实际应用时该指令行可以为其他形式，下同)，该命令可以通过用户在客户端(即上述目标设备)输入指令、上传配置文件信息或者通过客户端展示的界面进行相应信息的输入来生成。

具体的，上述输入指令可以是诸如[root@master01]#edgeadm init-confcluster-conf.yaml-install pkg-path/root/edgecluster-install-pkg.tar.gz此类的指令。

其中，cluster-conf.yaml是边缘kubernetes集群的配置文件，该配置文件主要包含如下内容：

1)cluster：边缘kubernetes相关配置；

2)master：安装集群的目标设备的相关信息；

3)ha：高可用相关的配置信息；

4)registries：镜像仓库的信息；

5)docker：dockerr运行时的配置信息；

6)kube-*：kubelet、kube-api-service、kube-scheduler、kube-controller等用户自定义配置信息；等等

edgecluster-install-pkg.tar.gz是安装边缘kubernetes集群的静态文件，主要包含如下内容：

1)bin：运行边缘kubernetes集群需要的二进制文件，如kubeadm、kubelet、kubect等；

2)conf：运行边缘kubernetes集群组件需要的配置文件，如kubeadm.yaml；

3)container-runtime：容器运行时的安装包，如cri-dockerd-cni-linux-amd64.tar.gz；

4)images：边缘kubernetes集群需要的镜像文件包，如flannel.tar.gz；

5)shell：安装边缘kubernetes集群可能需要运行的shell脚本，如master.sh；

服务器在获取到用户的命令后，将检查用户的输入数据是否有误。若用户输入的数据无误，上述服务器将依次执行步骤①中所包含的指令，即把用户的请求数据以.json的格式存储在诸如/tmp/edgeadm/edgeadm-init.json的日志文件库中。

之后，将接着执行步骤②中所包含的指令，即在检查集群的安装环境是否有风险项(例如上述客户端中虚拟机的版本信息、配置文件的安全性等等)。在确定无风险项后，进行安装前的清理工作，确保边缘Kubernetes集群的master干净。

步骤②执行之后，安装集群的准备工作已经准备完毕。因此，将进行即步骤③和步骤④，即开始边缘kubernetes集群的正式安装工作。在步骤④中，服务器将按照配置模板为集群依次安装docker、kubelet、etcd、kube-*等组件中的部分或全部。具体地在步骤④中部署的组件可以是前述第一组件集合。

步骤④执行完毕后，基础的kubernetes集群已经成功建立，但此时集群并不具本边缘能力，还需要为上述基础的kubernetes集群安装具备边缘能力的组件。于是，接着执行步骤⑤。在步骤⑤之前，用户还可以通过指令“edgeadm check cluster”来检查上述kubernetes集群的健康性(此步骤并未在图5体现)，在确保集群运行一切正常后进行步骤⑤，即为上述基础的Kubernetes集群安装具备边缘能力的组件，该边缘能力的组件可以包括：edge-cloud apps、tunnel-coredns、tunnel-cloud、application-grid controller、edge-health-admission、tunnel-edge等组件中的部分或全部；此外，该边缘能力组件还可以根据用户的具体需求变化，本申请实施例不做限定。在步骤⑤中部署的具备边缘能力的组件可以是前述第二组件集合。

步骤⑤执行完毕后，具备边缘能力的集群基本建立完成。但此时集群中还是一个空集群，集群中并不具备任何可以工作的节点。因此，步骤⑥所示的指令可以为上述边缘集群安装边缘节点deamonset，并为集群中的节点安装边缘能力的组件。

此外，在上述安装的过程中运行的每一步所产生的日志文件(日志文件用于记录集群安装过程所运行的步骤及状态)，edgeadm都会将这些日志文件以.json格式化的形式写入/tmp/edgeadm/edgeadm-init.json。并且执行过程中所产生的日志文件，也会被存储于相应的位置，便于安装故障时进行错误排查。

接下来介绍本申请实施例提供的一种边缘集群的架构图，该架构图中的边缘集群可以为利用图4所示的边缘集群的创建方法创建得到的边缘集群，该架构图所示的架构可以通过前述图5所示的过程图中的过程进行构建。具体请参阅图6。

图6为本申请实施例提供的一种边缘集群的架构图。如图6所示，该边缘集群的架构通过在原生kubernetes基础上进行了扩展，增加了边缘计算的若干组件，在对kubernetes完全无侵入的情况下使原生的kubernetes集群成为具备边缘能力的边缘集群。在本申请实施例中，边缘集群的架构中的组件可以分为云端组件和边缘组件(在图6中，虚线上方的为云端组件，虚线下方的为边缘组件)。

其中，云端除了边缘集群部署的原生kubernetes apisever组件(kubernetesapisever包括cloud-kube-apiserver，cloud-kube-controller以及cloud-kube-scheduler，为方便读者理解，将这三者在图6中一起表示为kubernetes apisever。此外，应注意kube-apiser，kube-scheduler、kube-controller-manager等组件的安装需通过etcd组件的支持。因此，在部署上述第一组件集合时，etcd组件需安装于kube-apiser，kube-scheduler、kube-controller-manager等组件之前。)外，主要管控组件还包括：

tunnel-cloud：负责维持与边缘节点Tunnel-Edge的网络隧道，目前支持TCP/HTTP/HTTPS协议。

application-grid controller：服务访问控制ServiceGroup对应的KubernetesController，负责管理DeploymentGrids以及ServiceGrids CRDs，并由这两种CR生成对应的Kubernetes deployment以及service，同时自研实现服务拓扑感知，使得服务闭环访问。

edge-admission：通过边端节点分布式健康检查的状态报告决定节点是否健康，并协助cloud-kube-controller执行相关处理动作。

而边端除了原生kubernetes worker节点需要部署的kubelet，kube-proxy外，还添加了如下边缘计算组件：

lite-apiserver：边缘自治的核心组件，是cloud-kube-apiserver的代理服务，缓存了边缘节点组件对apiServer的某些请求，当遇到这些请求而且与cloud-kube-apiserver网络存在问题的时候会直接返回给client端。

edge-health：边端分布式健康检查服务，负责执行具体的监督、控制和探测操作，并进行投票选举判断节点是否健康。

tunnel-edge：负责建立与云端边缘集群tunnel-cloud的网络隧道，并接收API请求，转发给边缘节点组件(kubelet)。

application-grid wrapper：与application-grid controller结合完成ServiceGrid内的闭环服务访问(服务拓扑感知)。

根据图6所示的架构进行部署所得的边缘集群除了具备优秀的边缘计算能力之外，还具备了由传统的方法所得的边缘集群没有的优点，具体如下：

(1)分布式健康检查

以图6中节点1至节点6为例，节点1至节点6为该边缘集群中的6个边缘node节点，其中节点1和节点2属于网格B，节点1、节点2和节点3属于网格A，节点4、节点5和节点6属于网格C。边缘计算场景下，边缘节点与云端的网络环境十分复杂，连接并不可靠，在原生kubernetes集群中，会造成apiserver和节点连接的中断，节点状态的异常，最终导致Pod的驱逐和Endpoint(Endpoints表示一个Service对应的所有Pod副本的访问地址)的缺失，造成服务的中断和波动，具体来说原生Kubernetes处理如下：

1)失联的节点被置为ConditionUnknown状态；

2)失联的节点上的Pod被驱逐，并在其他节点上进行重建；

3)失联的节点上的Pod从Service的Endpoint列表中移除；

因此，边缘计算场景仅仅依赖边端和apiServer的连接情况是不足以判断节点是否异常的，会因为网络的不可靠造成误判，影响正常服务。而相较于云端和边缘端的连接，显然边端节点之间的连接更为稳定，具有一定的参考价值，因此本申请实施例提出了边缘分布式健康检查机制。该机制中节点状态判定除了要考虑apiServer的因素外，还引入了节点的评估因素，进而对节点进行更为全面的状态判断。上述组件edge-health可以监督、控制和探测上述节点1至节点6的运行状态，并通过投票选举判断各个节点是否健康。通过这个功能，能够避免由于云边网络不可靠造成的大量的Pod迁移和重建，保证服务的稳定

具体来说，主要通过如下三个层面增强节点状态判断的准确性：每个节点定期探测其他节点健康状态、集群内所有节点定期投票决定各节点的状态以及云端和边端节点共同决定节点状态。而分布式健康检查最终的判断处理如下面表1所示：

表1

(2)边缘自治

对于边缘计算来说，除了需要具备便捷的管理运维能力，弱网环境下的容灾能力也尤其重要。具体来说，强大的容灾能力需要保证以下几点如下：

1)节点即使和Master失联，节点上的业务能继续运行；

2)保证如果业务容器异常退出或者挂掉，kubelet能继续拉起；

3)保证节点重启后，业务能继续重新被拉起来；

4)节点重启后，同一个厂房内的微服务可以访问；

而对于标准的kubernentes，如果节点断网失联并且发生异常重启的行为后，失联的节点状态将被置为ConditionUnknown状态，失联的节点上的业务进程异常退出后，容器可以被拉起，失联的节点上的Pod IP从Endpoint列表中摘除，失联的节点发生重启后，容器全部消失不会被拉起。

而本申请实施例提供的边缘集架构通过在边端加了一层镜像lite-apiserver组件，使得所有边端节点对于云端kube apiserver的请求，都会指向lite-apiserver组件。此外，通过上述lite-apiserver组件可以实现边缘节点断网情况下重启后Pod可以被正常拉起，但是根据原生Kubernetes原理，拉起后的Pod IP会发生改变，这在某些情况下是不能允许的。为此本申请实施例提供的边缘集群的架构还相应地设计了网络快照机制保障边缘节点重启，Pod拉起后IP保存不变。具体来说，就是将节点上组件的网络信息定期快照，并在节点重启后进行恢复。

在边缘计算情况下，节点之间可能是不在一个局域网，很可能是跨可用区的，此时coredns服务可能访问不通。为了保障dns访问始终正常，在本申请实施例提供的边缘集群架构中，本地dns采用DaemonSet方式部署coredns，保证每个节点都有可用的coredns，同时修改每个节点上kubelet的启动参数(cluster-dns)，将其指向本机私有IP(每个节点都相同)。这样就保证了即使在断网的情况下也能进行域名解析。

(3)云边隧道

云边隧道主要用于代理云端访问边缘节点组件的请求，解决云端无法直接访问边缘节点的问题(边缘节点没有暴露在公网中)。

在本申请实施例提供的边缘集群的架构中，边缘节点上tunnel-edge主动连接云端tunnel-cloud service，tunnel-cloud service根据负载均衡策略将请求转到tunnel-cloud的具体Pod上，tunnel-edge与tunnel-cloud建立grpc连接后，tunnel-cloud会把自身的Pod Ip和tunnel-Edge所在节点的nodeName的映射写入DNS(tunnel dns)。grpc连接断开之后，tunnel-cloud会删除相关Pod IP和节点名的映射

而整个请求的代理转发流程如下：

aserver或者其它云端的应用访问边缘节点上的kubelet或者其它应用时，tunnel-dns通过DNS劫持(将host中的节点名解析为tunnel-cloud的Pod Ip)把请求转发到tunnel-cloud的Pod上。tunnel-cloud根据节点名把请求信息转发到节点名对应的与tunnel-edge建立的grpc连接上，tunnel-edge根据接收的请求信息请求边缘节点上的应用。

(4)灵活向边缘集群中添加主节点(Master节点)和从节点(Node节点)

与容灾能力相似，集群的高可用能力也是衡量集群性能的重要指标。

而对于现有的利用kubernentes底座转化得到的边缘集群而言，边缘集群的高可用完全依赖部署kubernetes集群的工具。用户先要用部署kubernetes集群的工具部署同一个高可用的kubernetes集群作为边缘集群的底座，然后再将改的底座转化一个高可能用的边缘集群。若用户搭建的集群工具不具备高可用能力，则该方法所创建的边缘集群也无法实现高可用。

由于本申请实施例提供的边缘集架构基于superedge团队推出的edgeadm创建，edgeadm提供了提供高可用功能的组件，于是，在本申请实施例提供的边缘集群的架构中，还可以通过部署高可用组件haproxy/nginx(该组件并未在图6中体现)和keepalived的静态Pod使集群能够灵活地添加Master节点和Node节点，使集群能够在多个Master节点的协同配合下工作，从而具备高可用能力。为进一步说明向边缘集群中添加Master节点和Node节点的具体流程进行说明，本申请实施例提供了一种添加Master节点的方法的流程示意图，以及一种添加Node节点的方法的流程示意图，具体请参阅图7和图8。

图7为本申请实施例提供的一种添加Master节点的方法的流程示意图。如图7所示，该方法包括：

701、服务器获取用户输入的安装指令。

用户在客户端输入添加Master节点的添加请求(edgeadm join master)后，上述服务器将获取该添加请求。上述服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器；上述客户端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。客户端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。具体地，上述服务器和客户端可以是图3中的服务器和客户端。

702、上述服务器检查安装Master节点的风险项。

在开始安装Master节点之前，上述服务器将检查安装Master节点的风险项，例如边缘集群的健康性，边缘集群中已有Master节点的安全性等等。在确保Master节点的安装无风险项的情况下，执行步骤703；否则，向客户端发送风险项提示，提示用户安装存在风险。

703、上述服务器按照安装模板安装Master节点。

在确保Master节点的安装无风险项的情况下，服务器按照创建边缘集群时预设的安装模板，依次为上述Master节点安装docker、lite-apiserver等组件，直至该Master节点安装完成。

应理解，添加Master节点时边缘集群已经创建成功，在Master节点的添加过程中所产生的日志文件，例如各组件的安装情况、Master节点的状态等数据将以.json的形式存入前述日志文件库中。

图8为本申请实施例提供的一种添加Node节点的方法的流程示意图。如图8所示，该方法包括：

801、服务器获取用户输入的安装指令。

用户在客户端输入添加Node节点的添加请求(edgeadm join node)后，上述服务器将获取该添加请求。上述服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器；上述客户端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。客户端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。具体地，上述服务器和客户端可以是图3中的服务器和客户端。

802、上述服务器检查安装Node节点的风险项。

在开始安装Node节点之前，上述服务器将检查安装Node节点的风险项，例如边缘集群的健康性，边缘集群中已有Node节点的安全性等等。在确保Node节点的安装无风险项的情况下，执行步骤803；否则，向客户端发送风险项提示，提示用户安装存在风险。

803、上述服务器按照安装模板安装Node节点。

在确保Node节点的安装无风险项的情况下，服务器按照创建边缘集群时预设的安装模板，依次为上述Node节点安装doker、lite-apiserver等组件，直至该Node节点安装完成。

同理，在Node节点的添加过程中所产生的日志文件，例如各组件的安装情况、Node节点的状态等数据将以.json的形式存入前述日志文件库中。

整体来说，本申请实施例提供的边缘集群的架构采用无侵入的方式构建，在原有Kubernetes组件保留不变的基础上新增了一些组件完成边缘计算的功能，既保留了kubernetes强大的编排系统，同时也具备完善的边缘计算能力。

基于图8所示的添加Node节点的方法，本申请实施例结合edgeadm中的具体指令行提出了一种安装边缘集群的过程示意图，具体请参阅图9。图9为本申请实施例提供的一种安装边缘集群的过程示意图。如图9所示，用户在已安装边缘kubernetes集群的目标设备上运行创建添加Node节点的命令(即图9中的“edgeadm join node”，这里的指令只是一种抽象的指令形式，只是为了体现该指令行的功能，在实际应用时该指令行可以为其他形式，下同)，该命令可以通过用户在客户端(即上述目标设备)输入指令、上传配置文件信息或者通过客户端展示的界面进行相应信息的输入来生成。

服务器在获取到用户的命令后，上述服务器将依次执行步骤(1)中所包含的指令；即把用户的请求数据以.json的格式存储在诸如/tmp/edgeadm/edgeadm-init.json的日志文件库中。

之后，将接着执行步骤(2)中所包含的指令，即在检查集群安装Node节点的环境是否有风险项。在确定无风险项后，进行安装前的清理工作，确保边缘kubernetes集群中Node节点的干净。

步骤②执行之后，安装集群的准备工作已经准备完毕。因此，将进行即步骤(3)和步骤(4)，即开始Node的正式添加工作。在步骤④中，服务器将按照配置模板为集群依次安装docker、kubelet、etcd、kube-*等组件。

此外，在上述添加Node节点的过程中所产生的日志文件，edgeadm都会将这些日志文件以.json格式化的形式写入/tmp/edgeadm/edgeadm-init.json。并且执行过程中所产生的日志文件，也会被存储于相应的位置，便于安装故障时进行错误排查。

由于本发明提供的边缘集群的创建方法以及边缘集群的架构均需要基于superedge团队推出的管理边缘集群的命令行工具edgeadm实现，因此，为使方便读者了解edgeadm中典型的命令，接下来对edgeadm所包含一些典型的命令以及其具体功能进行说明，具体请参阅下列表2。

表2

命令	命令的具体功能
		edgeadm check master	检查安装Master节点的风险项
edgeadm check node	检查安装Node节点的风险项
		edgeadm check cluster	检查集群的健康性
edgeadm clean master	还原Master节点
		edgeadm clean node	还原Node节点
edgeadm install plugin	安装某插件
		edgeadm install init	初始化Node节点
edgeadm install docker	安装docker容器运行时
		edgeadm install containerd	安装containerd容器运行时
edgeadm installedge-apps	安装具备边缘能力的APP
		edgeadm install iptbales	初始化时安装一些插件
edgeadm init master	初始化第一个Master节点
		edgeadm check cluster	检查集群是都安装就绪
edgeadm join master	为边缘集群添加Master节点
		edgeadm join node	为边缘集群添加Node节点
edgeadm token create	创建一个令牌

接下来介绍本申请实施例提供的一种边缘集群的创建装置的结构示意图，请参阅图10。如图10所示，该边缘集群的创建装置包括：

获取单元901，用于获取边缘集群的创建指令，上述创建指令用于利用配置文件和静态文件创建边缘集群；

第一部署单元902，用于利用上述配置文件和上述静态文件部署第一组件集合，得到基础集群，上述第一组件集合包括管理和控制的上述基础集群的组件；

第二部署单元903，用于利用上述配置文件和上述静态文件部署在上述基础集群上部署第二组件集合，得到上述边缘集群，上述第二组件集合包括为上述边缘集群提供边缘计算能力的组件。

在一个可选的实施方式中，上述第一部署单元，具体用于利用上配置文件和上述静态文件部署第三组件集合和静态容器组，上述第三组件集合包含于上述第一组件集合，上述第三组件集合和上述静态容器组用于向上述边缘集群中添加主节点和从节点。

在一个可选的实施方式中，上述装置还包括：判断单元904，用于判断用户的输入数据是否有误；上述第一部署单元，具体用于在上述输入数据无误的情况下，利用上述配置文件中和上述静态文件部署上述第一组件集合，得到基础集群。

在一个可选的实施方式中，上述判断单元904，还用于判断上述边缘集群的安装环境是否有风险项；上述第一部署单元902，具体用于在上述输入数据无误且上述安装环境没有风险项的情况下，利用上述配置文件和上述静态文件部署上述第一组件集合，得到基础集群。

在一个可选的实施方式中，上述第二部署单元903，具体用于在上述基础集群健康的情况下，利用上述配置文件和上述静态文件在上述基础集群上部署第二组件集合，得到上述边缘集群。

在一个可选的实施方式中，上述装置还包括：记录单元905，具体用于创建日志文件库，上述日志文件库用于存储上述边缘集群创建过程中产生的日志数据。

在一个可选的实施方式中，上述装置还包括：接收单元906，用于接收创建请以及上述配置文件和上述静态文件；上述创建单元，具体用于，调用目标程序的目标接口对上述创建请求进行解析，得到上述创建指令，上述目标程序为将上述边缘集群的方法进行封装所得的程序。

应理解以上定位装置以及自动驾驶装置中的各个单元的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。例如，以上各个单元可以为单独设立的处理元件，也可以集成在终端的某一个芯片中实现，此外，也可以以程序代码的形式存储于控制器的存储元件中，由处理器的某一个处理元件调用并执行以上各个单元的功能。此外各个单元可以集成在一起，也可以独立实现。这里的处理元件可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个单元可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。该处理元件可以是通用处理器，例如中央处理器(英文：central processing unit，简称：CPU)，还可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(英文：application-specific integrated circuit，简称：ASIC)，或，一个或多个微处理器(英文：digital signal processor，简称：DSP)，或，一个或者多个现场可编程门阵列(英文：field-programmable gate array，简称：FPGA)等。

图11为本申请实施例提供的一种电子设备的结构示意图。如图11所示，该电子设备100包括处理器1001、存储器1002以及通信接口1003；该处理器1001、存储器1002以及通信接口1003通过总线相互连接。该电子设备可以是图3中的服务器。

存储器1002包括但不限于是随机存储记忆体(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmablereadonly memory，EPROM)、或便携式只读存储器(compact disc read-only memory，CDROM)，该存储器902用于相关指令及数据。通信接口1003用于接收和发送数据，其可以实现图10中获取单元901和接收单元906的功能。存储器1002可实现图10中的记录单元905的功能。

处理器1001可以是一个或多个中央处理器(central processing unit，CPU)，在处理器1001是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。上述实施例中由电子设备所执行的步骤可以基于该图11所示的电子设备的结构。具体的，处理器1001可实现图9中第一部署单元902和第二部署单元903的功能。图11中的电子设备还可以通过鼠标、触摸屏、键盘等输入设备，用于实现图10中接收单元906和获取单元901的功能。

该电子设备100中的处理器1001用于读取该存储器1002中存储的程序代码，执行前述实施例中的边缘集群的创建方法。

图12是本申请实施例提供的一种服务器的结构示意图，该服务器110可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessing units，CPU)1101(例如，一个或一个以上处理器)和存储器1106，一个或一个以上存储应用程序11043或数据11042的存储介质1106(例如一个或一个以上海量存储设备)。其中，存储器1106和存储介质1104可以是短暂存储或持久存储。存储在存储介质1104的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1101可以设置为与存储介质1104通信，在服务器110上执行存储介质1104中的一系列指令操作。服务器110可以为本申请提供的边缘集群的创建装置，也可以是图3中的服务器。

服务器110还可以包括一个或一个以上电源1102，一个或一个以上有线或无线网络接口1103，一个或一个以上输入输出接口1105，和/或，一个或一个以上操作系统11041，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。

本申请的实施例还提供一种计算机可读存储介质，上述计算机可读存储介质存储有计算机程序，上述计算机程序被处理器执行时实现：获取边缘集群的创建指令，上述创建指令用于利用配置文件和静态文件创建边缘集群；利用上述配置文件和上述静态文件部署第一组件集合，得到基础集群，上述第一组件集合包括管理和控制的上述基础集群的组件；利用上述配置文件和上述静态文件在上述基础集群上部署第二组件集合，得到上述边缘集群，上述第二组件集合包括为上述边缘集群提供边缘计算能力的组件。

本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (7)

1.一种边缘集群的创建方法，其特征在于，包括：

接收创建请求以及配置文件和静态文件；所述创建请求为用户在可视化编辑界面进行文件参数配置后自动触发生成的；

获取边缘集群的创建指令，包括：调用目标程序的目标接口对所述创建请求进行解析，得到所述创建指令，所述目标程序为将安装所述边缘集群的方法进行封装所得的程序；所述创建指令用于利用配置文件和静态文件创建边缘集群；

利用所述配置文件和所述静态文件部署第一组件集合，得到基础集群，包括：根据所述配置文件和所述静态文件部署第三组件集合和静态容器组，所述第三组件集合被包含于所述第一组件集合，所述第三组件集合和所述静态容器组用于向所述边缘集群中添加主节点和从节点；所述第一组件集合包括管理和控制的所述基础集群的组件；

在所述基础集群健康的情况下，利用所述配置文件和所述静态文件在所述基础集群上部署第二组件集合，得到所述边缘集群，所述第二组件集合包括为所述边缘集群提供边缘计算能力的组件。

2.根据权利要求1所述的方法，其特征在于，所述获取边缘集群的创建指令之后，所述方法还包括：

判断用户的输入数据是否有误；

所述利用所述配置文件和所述静态文件部署所述第一组件集合，得到基础集群，包括：

在所述输入数据无误的情况下，利用所述配置文件和所述静态文件部署所述第一组件集合，得到所述基础集群。

3.根据权利要求2所述的方法，其特征在于，所述判断用户的输入数据是否有误之后，所述方法还包括：

判断所述边缘集群的安装环境是否有风险项；

所述在所述输入数据无误的情况下，利用所述配置文件和所述静态文件部署所述第一组件集合，得到基础集群，包括：

在所述输入数据无误且所述安装环境没有风险项的情况下，利用所述配置文件和所述静态文件部署所述第一组件集合，得到所述基础集群。

4.根据权利要求1或3所述的方法，其特征在于，所述获取边缘集群的创建指令之后，所述方法还包括：

创建日志文件库，所述日志文件库用于存储所述边缘集群创建过程中产生的日志数据。

5.一种边缘集群的创建装置，其特征在于，包括：

接收单元，用于接收创建请求以及配置文件和静态文件；所述创建请求为用户在可视化编辑界面进行文件参数配置后自动触发生成的；

创建单元，用于调用目标程序的目标接口对所述创建请求进行解析，得到所述创建指令，所述目标程序为将安装所述边缘集群的方法进行封装所得的程序；

获取单元，获取边缘集群的创建指令，所述创建指令用于利用配置文件和静态文件创建边缘集群；

第一部署单元，用于利用所述配置文件和所述静态文件部署第一组件集合，得到基础集群，包括：根据所述配置文件和所述静态文件部署第三组件集合和静态容器组，所述第三组件集合被包含于所述第一组件集合，所述第三组件集合和所述静态容器组用于向所述边缘集群中添加主节点和从节点；所述第一组件集合包括管理和控制的所述基础集群的组件；

第二部署单元，用于在所述基础集群健康的情况下，利用所述配置文件和所述静态文件在所述基础集群上部署第二组件集合，得到所述边缘集群，所述第二组件集合包括为所述边缘集群提供边缘计算能力的组件。

6.一种电子设备，其特征在于，包括：存储器、处理器，其中，所述存储器存储有程序指令；所述程序指令被所述处理器执行时，使所述处理器执行如权利要求1至4中任一项所述的方法。

7.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序；当所述计算机程序在一个或多个处理器上运行时，执行如权利要求1至4中任一项所述的方法。