CN112104723A - 一种多集群的数据处理系统及方法 - Google Patents

一种多集群的数据处理系统及方法 Download PDF

Info

Publication number
CN112104723A
CN112104723A CN202010926782.7A CN202010926782A CN112104723A CN 112104723 A CN112104723 A CN 112104723A CN 202010926782 A CN202010926782 A CN 202010926782A CN 112104723 A CN112104723 A CN 112104723A
Authority
CN
China
Prior art keywords
cluster
virtual
pod
module
task
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010926782.7A
Other languages
English (en)
Other versions
CN112104723B (zh
Inventor
薛磊
阎姝含
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202010926782.7A priority Critical patent/CN112104723B/zh
Publication of CN112104723A publication Critical patent/CN112104723A/zh
Application granted granted Critical
Publication of CN112104723B publication Critical patent/CN112104723B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请涉及计算机技术领域，尤其涉及一种多集群的数据处理系统及方法，该系统至少包括元数据集群和计算集群，元数据集群至少包括用户集群，用户集群至少包括第一接口服务模块和虚拟处理模块，计算集群至少包括第二接口服务模块和处理模块，该系统可以部署于云服务器，进而在数据处理时，第一接口服务模块接收应用平台发送的任务处理请求，虚拟处理模块将任务处理请求发送给对应的计算集群中的第二接口服务模块，处理模块执行任务处理请求关联的任务，通过虚拟处理模块管理多计算集群，便于多集群统一管理。

Description

一种多集群的数据处理系统及方法
技术领域
本申请涉及计算机技术领域，尤其涉及一种多集群的数据处理系统及方法。
背景技术
目前，多集群具有高可用性、高可管理性、高可扩展性等优势，可以满足不同的业务需求，例如kubernetes(k8s)集群是自动化容器操作的开源平台，随着kubernetes集群被应用到了各种各样的领域，在应用过程中，也出现了很多问题，其中一个比较典型的问题，就是如何管理多个kubernetes集群，无论是多云还是混合云场景，由于物理或空间，以及kubernetes本身规模限制，通常需要多个kubernetes集群提供服务，如何高效并便捷地统一管理kubernetes多集群，保证多集群高可用是亟待解决的问题。
发明内容
本申请实施例提供一种多集群的数据处理系统及方法，以提高多集群管理的效率和性能，提高可用性和简便性。
本申请实施例提供的具体技术方案如下：
本申请一个实施例提供了一种多集群的数据处理系统，所述系统至少包括元数据集群和计算集群，所述元数据集群中至少包括用户集群，用户集群中至少包括第一接口服务模块和虚拟处理模块，计算集群中至少包括第二接口服务模块和处理模块，计算集群通过虚拟处理模块提供的扩展接口与对应的用户集群接入，具体地：
所述用户集群中第一接口服务模块，用于接收所述用户集群对应的应用平台发送的任务处理请求；
所述用户集群中虚拟处理模块，用于将所述任务处理请求发送给对应的计算集群中的第二接口服务模块；
所述对应的计算集群中的处理模块，用于执行所述任务处理请求关联的任务。
本申请另一个实施例提供了一种多集群的数据处理方法，应用于多集群系统，所述多集群系统至少包括元数据集群和计算集群，所述元数据集群中至少包括用户集群，用户集群中至少包括第一接口服务模块和虚拟处理模块，计算集群中至少包括第二接口服务模块和处理模块，计算集群通过虚拟处理模块提供的扩展接口与对应的用户集群接入，所述方法包括：
用户集群中第一接口服务模块接收所述用户集群对应的应用平台发送的任务处理请求；
所述用户集群中虚拟处理模块，将所述任务处理请求发送给对应的计算集群中的第二接口服务模块；
所述对应的计算集群中的处理模块，执行所述任务处理请求关联的任务。
本申请另一个实施例提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述任一种多集群的数据处理方法的步骤。
本申请另一个实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一种多集群的数据处理方法的步骤。
本申请实施例中，构建多集群系统，该系统至少包括元数据集群和计算集群，所述元数据集群中至少包括用户集群，用户集群中至少包括第一接口服务模块和虚拟处理模块，计算集群中至少包括第二接口服务模块和处理模块，计算集群通过虚拟处理模块提供的扩展接口与对应的用户集群接入，进而基于该系统进行数据处理时，第一接口服务模块接收所述用户集群对应的应用平台发送的任务处理请求，并虚拟处理模块将所述任务处理请求发送给对应的计算集群中的第二接口服务模块，发送给计算集群后，计算集群中的处理模块执行任务处理请求关联的任务，这样，在构建多集群系统时，分别部署元数据集群和计算集群，并扩展虚拟处理接口，将元数据集群和计算集群连接，从而可以向用户提供统一的接口，并通过虚拟处理管理多个计算集群，进行资源分配和调度，从而减少了环境切换带来的负担，并且能够简化多集群组件，提高了可用性和简便性，也提高了多集群管理的效率和性能。
附图说明
图1为申请实施例中多集群的数据处理方法的应用环境架构示意图；
图2为本申请实施例中多集群的架构图；
图3为相关技术中虚拟kubelet整体架构示意图；
图4为本申请实施例中的多集群的数据处理系统结构示意图；
图5为本申请实施例中多集群的数据处理方法流程图；
图6为本申请实施例中多集群的数据处理方法的交互流程图；
图7为本申请实施例中电子设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，并不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
为便于对本申请实施例的理解，下面先对几个概念进行简单介绍：
kubernetes：简称为k8s，是自动化容器操作的开源平台，这些操作包括部署、调度和节点集群间扩展等，kubernetes集群表示一组节点(node)，这些节点可以是物理服务器或者虚拟机，之上安装了kubernetes平台。
kubelet：kubernetes是一个分布式的集群管理系统，在执行具体的业务容器的节点上都要运行一个运行者(worker)对容器进行生命周期的管理，这个worker程序就是kubelet，kubelet是运行在每个节点上的主要的“节点代理”，每个节点都会启动kubelet进程，用来处理主(master)节点下发到本节点的任务，按照PodSpec描述来管理Pod和其中的容器(其中，PodSpec是用来描述一个Pod的YAML或者JSON对象)，通常情况下kubelet的主要工作是创建、销毁Pod，kubelet需要对Pod资源进行监听，kubelet会监听想要监听的Pod，即那些已经分配到本节点的Pod。
虚拟(virtual)kubelet：是kubernete中kubelet的一个实现，它伪装成一个kubelet，用于将kubernetes集群连接到其他应用程序接口(Application ProgramInterface，API)，这允许kubernetes由其他服务支持，例如无服务器容器平台。通常kubernetes kubelet为每个kubernetes节点实现Pod和容器操作，作为每个节点上的代理运行，无论该节点是物理服务器还是虚拟机，在该节点上处理Pod或容器操作，kubelet将PodSpec配置文件作为输入，并确保PodSpec中指定的容器正在运行且运行正常。从kubernetes API的角度来看，虚拟kubelet看起来像普通的kubelet，但其关键区别在于其在其他地方调度容器，而不是在节点上。
Pod：是kubernetes项目中最小的API对象，由多个容器和相关配置信息构成，在kubernetes中，最基本的管理单位是Pod，而不是容器(container)，Pod是kubernetes在容器上的一层封装，由一组运行在同一主机的一个或者多个容器组成，通过Pod封装这是因为容器推荐的用法是里面只运行一个进程，而一般情况下某个应用都是由多个组件构成的。容器的本质是进程，就是未来云计算系统中的进程，容器镜像就是这个系统里的".exe"安装包，相应地kubernetes可以理解为操作系统。
Pod中所有的容器最大的特性和优势就是可以共享资源，例如，共享同一个网络命名空间(Network Namespace)，并且可以声明共享同一个数据存储空间(Volume)，Pod中所有容器共享网络和端口空间，也就是它们之间可以通过本地主机(localhost)访问和通信，对外的通信方式也是一样的，省去了很多容器通信的麻烦，除了网络之外，定义在Pod里的volume也可以挂载(mount)到多个容器里，以实现共享的目的，并且，定义在Pod中的资源限制，例如中央处理器(Central Processing Unit，CPU)和存储器(Memory)等也是所有容器共享的。
调度器(Scheduler)：根据等待队列中的资源对象将其分配到合适的节点，通常情况下分配过程需要两层调度：预选调度和优选调度，其中，预选调度：一般根据资源对象的配置信息进行筛选，例如NodeSelector、HostSelector和节点亲和性等；优选调度：根据资源对象需要的资源和节点资源的使用情况，为每个节点打分，然后选出最优的节点创建资源对象(即创建Pod)，例如，本申请实施例中，分别在用户集群和计算集群中部署Scheduler，本申请实施例中分别称为第一调度器和第二调度器。
混合云(Hybrid Cloud)：融合了公有云(Public Cloud)和私有云(PrivateCloud)，也可能包含多种虚拟化技术，形成多种不同技术架构组成的云平台，是近年来云计算的主要模式和发展方向。私有云主要是面向企业用户，出于安全考虑，企业更愿意将数据存放在私有云中，但是同时又希望可以获得公有云的计算资源，在这种情况下混合云被越来越多的采用，它将公有云和私有云进行混合和匹配，以获得最佳的效果，这种个性化的解决方案，达到了既省钱又安全的目的。
私有云(Private Cloud)：是将云基础设施与软硬件资源创建在防火墙内，以供机构或企业内各部门共享数据中心内的资源。创建私有云，除了硬件资源外，一般还有云设备的基础设施即服务(Infrastructure as a Service，IaaS)软件。
私有云计算同样包含云硬件、云平台、云服务三个层次。不同的是，云硬件是用户自己的个人电脑或服务器，而非云计算厂商的数据中心。云计算厂商构建数据中心的目的是为千百万用户提供公共云服务，因此需要拥有几十上百万台服务器。私有云计算，对个人来说只服务于亲朋好友，对企业来说只服务于本企业员工以及本企业的客户和供应商，因此个人或企业自己的个人电脑或服务器已经足够用来提供云服务。
公有云(Public Cloud)：通常指第三方提供商为用户提供的能够使用的云，公有云一般可通过因特网(Internet)使用，可能是免费或成本低廉的，公有云的核心属性是共享资源服务。这种云有许多实例，可在当今整个开放的公有网络中提供服务。
云技术(Cloud technology)：基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。
云计算(cloud computing)：指IT基础设施的交付和使用模式，指通过网络以按需、易扩展的方式获得所需资源；广义云计算指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关，也可是其他服务。云计算是网格计算(Grid Computing)、分布式计算(DistributedComputing)、并行计算(Parallel Computing)、效用计算(Utility Computing)、网络存储(Network StorageTechnologies)、虚拟化(Virtualization)、负载均衡(Load Balance)等传统计算机和网络技术发展融合的产物。
随着互联网、实时数据流、连接设备多样化的发展，以及搜索服务、社会网络、移动商务和开放协作等需求的推动，云计算迅速发展起来。不同于以往的并行分布式计算，云计算的产生从理念上将推动整个互联网模式、企业管理模式发生革命性的变革。例如，本申请实施例中的多集群的数据处理系统可以部署在云服务器，基于云计算技术处理提交的任务。
目前，kubernetes集群被应用到了各种各样的领域，在应用过程中，比较典型的问题就是如何管理多个kubernetes集群，无论是多云还是混合云场景，由于物理或空间，以及kubernetes本身规模限制，通常需要多个kubernetes集群提供服务，如何高效并便捷地统一管理kubernetes多集群，简化用户的操作难度，自动平衡负载并进行调度，保证kubernetes多集群高可用是亟待解决的问题。
针对上述问题，本申请实施例中提供了一种新的多集群系统架构，该系统至少包括元数据集群和计算集群，元数据集群中至少包括用户集群，用户集群中至少包括第一接口服务模块和虚拟处理模块，计算集群中至少包括第二接口服务模块和处理模块，计算集群通过虚拟处理模块提供的扩展接口与对应的用户集群接入，进而第一接口服务模块接收用户集群对应的应用平台发送的任务处理请求，并且虚拟处理模块将任务处理请求发送给对应的计算集群中的第二接口服务模块，该对应的计算集群中的处理模块执行任务处理请求关联的任务，这样，针对多集群部署时，分别构建元数据集群和计算集群，并拓展虚拟处理模块的接口，将元数据集群和计算集群连接，从而可以在面向用户提供统一的接口的情况下，通过虚拟处理模块构建并管理多个计算集群，进行资源分配和调度，从而减少了环境切换带来的负担，并且能够简化多集群组件，提高了可用性和简便性，也提高了多集群管理的效率和性能。
参阅图1所示，为本申请实施例中多集群的数据处理方法的应用环境架构示意图，包括终端100、服务器200。
终端100面向用户，可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此，本申请实施例中，终端100上安装有应用平台，用户可以通过终端100上的应用平台提交任务。
服务器200为提供云端任务处理能力的服务器，其中，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器，例如，本申请实施例中在服务器200端可以部署多集群系统，该系统包括元数据集群和计算集群，在具体部署时可以部署在一台服务器，也可以分别部署在不同的服务器，本申请实施例中并不进行限制。
终端100和服务器200可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。
值得说明的是，本申请实施例中的应用架构图是为了更加清楚地说明本申请实施例中的技术方案，并不构成对本申请实施例提供的技术方案的限制，并且本申请实施例中主要是针对kubernetes集群，但是对于其它的应用架构和集群构建，本申请实施例提供的技术方案对于类似的问题，同样适用。
需要说明的是，本申请各个实施例中，以多集群的数据处理方法应用于图1和图2所示的应用架构为例进行示意性说明。
另外，本申请各个实施例中以针对kubernetes集群的场景为例，具体地，第一接口服务模块为第一kubernetes接口服务模块，虚拟处理模块为虚拟kubelet模块、第二接口服务模块为第二kubernetes接口服务模块、处理模块为kubelet模块、操作模块为operator为例进行说明，当然，本申请实施例中的多集群的数据处理系统和方法也可以应用于其它业务场景，本申请实施例中并不进行限制。
基于上述实施例，下面具体地对本申请实施例中多集群系统进行说明，参阅图2所示，为本申请实施例中多集群的架构图，如图2所示，本申请实施例中构建的kubernetes多集群可以分为三部分，分别为用户端、元数据集群和计算集群，具体地：
第一部分：用户端。
本申请实施例中，kubernetes多集群可以对接多种用户端和多类用户，用户端即面向用户，可以为终端上安装的应用平台，例如图2中以两个不同应用平台为例进行说明，例如应用平台为机智平台、运管平台等，并不进行限制，并且面向的用户类别也不进行限制，例如使用者、浏览者等用户，用户可以通过应用平台提交任务，进而通过后台服务器部署的元数据集群和计算集群，来处理该任务。
第二部分：元数据集群。
本申请实施例中，为了达到隔离用户的使用以及简化管理的目的，将对接不同应用平台的各个用户集群运行在一个元数据集群中，即元数据集群中至少包括多个用户集群，这样使得集群构建和管理更加方便，并且，如图2所示，每一个用户即应用平台对应创建一个用户集群，可以预先进行部署，图2中以三个用户集群为例进行说明，并不进行限制，每个用户集群中至少包括第一kubernetes接口服务模块和虚拟kubelet模块，还包括operator和第一调度器，其中，用户集群中虚拟kubelet模块的数目并不进行限制，也不需要限制每个用户集群中数目必须相同，具体可以根据本用户集群所对接的计算集群数目而定，通过虚拟kubelet模块可以对后端的计算集群进行分配和调度，另外需要说明的是，在实际应用中，每个用户集群中至少包括master节点，第一kubernetes接口服务模块和虚拟kubelet模块、operator、第一调度器等部署在该master节点上，当然用户集群中的master节点中还可以部署其它模块，本申请实施例中并不进行限制。
并且，本申请实施例中还可以扩展元数据集群，例如，如图2所示元数据集群可以再扩展并连接其它更多元数据集群。
另外，本申请实施例中，元数据集群中每个模块还可以设置主备模块，以提高可靠性，例如针对operator模块，可以设置主operator模块和备operator模块。
本申请实施例中为解决多集群控制和管理的问题，主要是通过扩展虚拟kubelet模块的接口能力来实现，为便于理解下面对虚拟kubelet模块进行简单介绍。
参阅图3所示，为相关技术中虚拟kubelet整体架构示意图，虚拟kubelet主要是为了解决单一集群可扩展性的问题，如图3所示，虚拟kubelet可以将公有云的弹性容器服务接入到用户的某一个kubernetes集群，这样用户可以按照kubernetes的方式去使用一些弹性的容器资源，例如这些可扩展的弹性容器服务：azure-aci、aws-fargate、openstack-zun、alibabacloud-eci等，图3中所示的是相关技术中虚拟kubelet的使用方式，kubernetes集群中包括一系列标准kubelet和一个虚拟kubelet，标准kubelet为每个节点实现Pod和容器操作，虚拟kubelet伪装成一个kubelet，可以将kubernetes集群连接到其他API，相关技术中通常虚拟kubelet只提供了几种简单的接口，例如Pod相关的增删改查操作、Pod和容器的logs/exec接口、节点状态汇报。
虚拟kubelet的整体逻辑与kubelet类似，其主要的能力就是监听Pod、节点、Service，以及其他相关资源的创建、删除、更新等操作，作为一个桥梁去联通两个kubernetes集群，虚拟kubelet提供一个插件式的Provider接口，让开发者可以自定义实现传统kubelet的功能，自定义的Provider接口可以用自定义的配置文件和环境参数。
基于此，本申请实施例中构建了元数据集群，并且在元数据集群上部署虚拟kubelet，同时还扩展了虚拟kubelet更多的接口功能，例如，扩展虚拟kubelet提供的Provider接口到以下资源：ConfigMap(主要用于下发配置信息)、Secret(主要用于数据的加密和权限管理)、Role/ClusterRole(主要用于角色访问控制管理)、Rolebinding/ClusterRolebinding(也为角色访问控制管理)，具体地，本申请实施例中虚拟kubelet的Provider扩展的具体接口为：node.PodLifecycleHandler、GetContainerLogs、RunInContainer、ConfigureNode，分别提供了维持Pod生命周期、获取容器日志、在容器内运行指令、以及配置节点实例的能力。例如，本申请实施例中虚拟kubelet模块还用于：监控任务处理请求对应的Pod的状态，即可以实时从计算集群中获取Pod的状态。
并且，本申请实施例中虚拟kubelet另外的一个作用就是控制用户可访问资源，任务相应创建Pod后，同一Pod中容器可以共享资源，但是不能访问除自身Pod之外的其它Pod的资源，并且虚拟kubelet还可以使用kubernetes原生的方式，通过使用者(User)、角色(Role)、基于角色的访问控制(Role-Based Access Control，RBAC)以及服务账号(ServiceAccount)等来提供权限控制能力，本申请实施例中提供了一种可能的实施方式：虚拟kubelet模块还用于对任务处理请求对应的身份权限进行校验，校验任务处理请求是否具有对该对应的计算集群的访问权限，校验通过后，将任务处理请求发送给对应的计算集群中的第二kubernetes接口服务模块。
这样，本申请实施例中，通过扩展虚拟kubelet模块的接口，就可以将用户创建的资源调度到具体的一个虚拟kubelet，进而对应到连接的计算集群，实现多集群的管理。
第三部分：计算集群。
本申请实施例中，计算集群中至少包括第二kubernetes接口服务模块和kubelet模块、第二调度器等，计算集群通过虚拟kubelet模块提供的扩展接口与对应的用户集群接入，例如扩展接口为本申请实施例中扩展的组件k8s-provider接口，也就是说，本申请实施例中计算集群通过虚拟kubelet与用户集群连接，即接入元数据集群，用户集群中可以设置多个虚拟kubelet模块，分别与不同的计算集群连接，进而在执行任务时，可以通过相应的虚拟kubelet模块，将该任务分配到所需的计算集群，例如，如图2所示，以两个计算集群为例，本申请实施例中并不进行限制，每个用户集群中有两个虚拟kubelet模块，通过这两个虚拟kubelet模块，分别接入各计算集群。
另外需要说明的是，本申请实施例中，在实际应用中计算集群至少包括master节点和worker节点，其中，第二kubernetes接口服务模块、第二调度器可以部署在master节点，kubelet模块可以部署在worker节点，当然同样地，计算集群中的master节点和worker节点中也可以部署其它功能模块，本申请实施例中并不进行限制，本申请实施例中在图2中仅是以模块布局进行示例说明。
这样，本申请实施例中，可以预先构建和部署如图2所示的系统架构图，来实现kubernetes多集群管理，具体地本申请实施例中提供了一种部署方式。
1、构建元数据集群。
a)创建自定义资源的定义(CustomResourceDefinitions，CRDs)。
例如，输入命令行kubectl create-f examples/crds/，来创建用户资源。
b)创建role/rolebinding。
例如，输入命令行kubectl create-f examples/rbac.yaml，目的是为了设置集群的权限控制。
2、部署虚拟Kubelet Provider。
a)获取计算集群的KubeConfig文件。
例如，输入命令行kubectl config-dump--vc vc-sample-2-n tenant-2，获取计算集群的配置文件。
b)将KubeConfig文件作为Secret添加到元数据集群中。
例如，输入命令行kubectl-n tenant-2create secret generic kubeconfig--from-file＝/tmp/kube/kubeconfig.conf，可以将计算集群的配置文件进行加密并添加到元数据集群，即可以实现将计算集群接入元数据集群中。
c)运行虚拟Kubelet Provider。
例如，输入命令行kubectl-n tenant-2create-f./k8s-provider/deploy.yaml，运行虚拟kubelet即完成系统构建，计算集群通过虚拟kubelet接口提供的扩展provider接口接入。
本申请实施例中，分别部署元数据集群和计算集群，在元数据集群上应用虚拟kubelet模块，可以提供原生的kubernetes API接口以及扩展接口，来构建和管理kubernetes多集群，可以向用户提供统一的kubernetes API接口，相应周边组件可以统一使用，可以减少切换带来的负担，同时能够简化多集群的组件，多集群部署更加简便，并且通过虚拟kubelet模块对计算集群进行调度和分配，提高多集群管理的效率和性能，这样，通过标准并统一的kubernetes API接口下，kubernetes多集群的性能和可用性会更好，可以充分利用kubernetes功能。
基于上述图2所示的架构图，基于上述实施例，下面介绍下在数据处理时多集群系统中各个模块的功能实现，参阅图4所示，为本申请实施例中的多集群的数据处理系统结构示意图，包括元数据集群和计算集群，元数据集群中至少包括用户集群，用户集群中至少包括第一kubernetes接口服务模块、虚拟kubelet模块、operator和第一调度器，计算集群中至少包括第二kubernetes接口服务模块、kubelet模块和第二调度器，本申请实施例中，元数据集群主要用于提供转发功能，将任务调度到具体的计算集群中进行处理，以针对其中任意一个用户集群为例，具体地：
a)用户集群中第一kubernetes接口服务模块，用于接收用户集群对应的应用平台发送的任务处理请求。
本申请实施例中，一个应用平台会对接部署一个用户集群，例如，可以应用到深度学习训练平台上，用户可以在终端登录应用平台，提交一个任务到应用平台对应的后台服务器，该后台服务器会将该任务提交到元数据集群，进而元数据集群发送到计算集群以执行该任务。
其中，任务处理请求关联的任务，并不进行限制，例如为训练任务等，另外任务处理请求中还可以包括配置参数，例如指示执行该任务所需的资源配置参数，如需要多少CPU或图形处理器(Graphics Processing Unit，GPU)，需要多个机器等，进而在后续调度时，可以根据任务所需资源配置参数进行调度。
b)用户集群中虚拟kubelet模块，用于将任务处理请求发送给对应的计算集群中的第二kubernetes接口服务模块。
具体地本申请实施例中接收到应用平台的任务处理请求后，将任务处理请求发送给对应的计算集群中的第二kubernetes接口服务模块的实施过程，本申请实施例中提供了一种可能的执行过程：
1)operator，用于监听到第一kubernetes接口服务模块接收到任务处理请求时，基于任务处理请求关联的任务，创建虚拟Podgroup和虚拟Pod，其中，虚拟Pod至少包括多个用于承载运行任务所需代码的容器。
本申请实施例中，应用平台的后台服务器接收到任务处理请求后，还会将任务转换为多集群系统可理解的形式或类型，例如转换为信息传递接口任务(Message PassingInterface job，MPIjob)，MPI是一种标准，进而operator监听到MPIjob时，会相应创建虚拟Podgroup和虚拟Pod，虚拟Podgroup是用于约束Pod，可以使得标注为同一个Podgroup的所有Pod一起被调度，其中，在具体创建虚拟Podgroup和虚拟Pod时，operator会根据任务本身的处理类型来进行确定，例如一个训练任务为分布式训练任务，需要多机训练并通过一个主节点来统计各机器的执行结果，最终获得该训练任务的执行结果，这时，可以将该训练任务转换为一个master Pod和多个worker Pod，即相应创建一个虚拟Podgroup，以及多个虚拟Pod。
2)第一调度器，用于监听到有虚拟Podgroup和虚拟Pod创建时，确定虚拟Pod对应的虚拟kubelet模块，并将虚拟Pod和对应的虚拟kubelet模块所在节点绑定。
其中，第一调度器确定虚拟Pod对应的虚拟kubelet模块时，主要是根据该任务处理请求在提交时所指定或分配的计算集群来确定的，确定该用户集群中连接对应的计算集群是哪一个虚拟kubelet模块，进而由于虚拟kubelet模块部署在节点上，因此通过第一调度器可以将虚拟Pod与对应的节点绑定，进而绑定的节点中对应的虚拟kubelet模块，就可以发送给对应的计算集群。
3)虚拟kubelet模块，具体用于将任务处理请求发送给对应的计算集群中的第二kubernetes接口服务模块，并指示对应的计算集群创建任务处理请求对应的Pod和Podgroup。
即可以通过虚拟kubelet模块，将任务处理请求对应的Pod和Podgroup创建请求发送到对应的计算集群中。
进一步地，虚拟kubelet模块还可以具有权限校验功能，本申请实施例中提供了一种可能的实施方式，虚拟kubelet模块还用于：对任务处理请求对应的身份权限进行校验，校验任务处理请求是否具有对该对应的计算集群的访问权限，校验通过后，将任务处理请求发送给对应的计算集群中的第二kubernetes接口服务模块。
其中，本申请实施例中可以预先建立各个应用平台与计算集群的权限关联关系，进而虚拟kubelet模块在下发任务时，可以先校验该任务处理请求对应的身份权限，具有对计算集群的访问权限时才会下发到该计算集群。
c)该对应的计算集群中的kubelet模块，用于执行任务处理请求关联的任务。
具体地，本申请实施例中计算集群的执行过程为：
1)对应的计算集群中第二调度器，用于基于任务处理请求对应的Pod和Podgroup所需资源进行调度，确定任务处理请求对应的部署有kubelet模块的节点。
具体地，在调度时，可以根据Pod和Podgroup所需资源，以及该计算集群中各个worker节点的资源使用情况进行调度，为每个worker节点打分，确定出最优的worker节点，例如，Pod运行时需要4个GPU卡，则可以分别确定该计算集群中各个worker节点中的剩余GPU卡资源，较佳的选择是正好剩余4个GPU卡资源的worker节点，进而可以通过确定出的worker节点中的kubelet模块来执行任务，这样可以减少资源碎片，提高资源利用率。
当然也可以采用其它调度方式，来确定对应的worker节点，本申请实施例中并不进行限制。
进一步地，计算集群中第二kubernetes接口服务模块创建任务处理请求对应的Podgroup。
2)确定出节点中的kubelet模块，用于创建任务处理请求对应的Pod，并运行创建的Pod，以执行Pod中对应的任务处理请求关联的任务。
即基于该确定出的kubelet模块中为该Pod分配的资源，来运行Pod中容器所承载的任务的代码。
进一步地，本申请实施例中，元数据集群中的虚拟Podgroup和虚拟Pod，以及计算集群中的Podgroup和Pod是同步的，具体地，虚拟kubelet模块，还用于：将任务处理请求对应的虚拟Podgroup和虚拟Pod，分别与创建的Podgroup和Pod建立关联，以使虚拟Podgroup和虚拟Pod，分别与创建的Podgroup和Pod同步更新。
这样，可以使得用户可以直接从元数据集群获得Pod状态，计算集群只需要做计算即可，无需关心用户差异，元数据集群通过虚拟kubelet模块可以监控所有任务处理请求对应的Pod状态。
进一步地，本申请实施例中，元数据集群和计算集群中不仅虚拟Podgroup和虚拟Pod，与Podgroup和Pod是同步更新的，另外元数据集群中虚拟kubelet扩展接口的资源对象，与计算集群中相应的资源对象也是同步更新的，具体实现方式也是通过元数据集群中创建的虚拟资源对象和计算集群中相应创建的资源对象，来进行同步更新。具体本申请实施例中提供了一种可能的实施方式：用户集群中虚拟kubelet模块创建虚拟资源对象；计算集群中的第二kubernetes接口服务模块接收到虚拟kubelet模块发送的任务处理请求后，相应创建资源对象，并将资源对象与对应的虚拟资源对象进行关联，以使虚拟资源对象和对应的资源对象同步更新。
例如本申请实施例中，虚拟kubelet扩展接口的资源对象有ConfigMap、Secret、Role/ClusterRole、Rolebinding/ClusterRolebinding等，则用户集群中这些资源对象和计算集群中的对应的资源对象是同步更新的，以ConfigMap为例进行说明，则用户集群中创建虚拟ConfigMap，并计算集群中对应创建ConfigMap，将虚拟ConfigMap和创建的ConfigMap关联，以实现同步更新，这样，可以使得元数据集群和计算集群中的相关信息都是同步的。
其中，计算集群可以主动实时向元数据集群发送Pod状态，或者在Pod状态更新时发送给元数据集群，也可以元数据集群通过虚拟kubelet模块向计算集群发送Pod状态获取请求，来获取Pod状态，具体实施方式，本申请实施例中并不进行限制，例如，本申请实施例中提供了一种可能的实施方式：
1)kubelet模块还用于：根据Pod的运行情况，更新Pod的状态，并将Pod更新后的状态，通过第二kubernetes接口服务模块发送给虚拟kubelet模块。
其中，Pod状态包括等待中(Pending)、运行中(Running)、完成(Completed)以及失败(Failed)、未知状态(Unknown)等，具体地：(1)Pending表示Pod已被Kubernetes系统接受，但有一个或者多个容器镜像尚未创建；(2)Running表示Pod已经绑定到了一个节点上，Pod中所有的容器都已被创建，并且至少有一个容器正在运行，或者正处于启动或重启状态；(3)Completed表示Pod中的所有的容器已经正常的自行退出，并且k8s不会自动重启这些容器，一般会是在部署job的时候会出现；(4)Failed表示Pod中的所有容器都已终止了，并且至少有一个容器是因为失败终止；(5)Unknown表示出于某种原因，无法获得Pod的状态，例如可能是由于与Pod主机通信出错。
2)虚拟kubelet模块还用于：更新Pod对应的虚拟Pod的状态，并将虚拟Pod更新后的状态发送给第一kubernetes接口服务模块。
3)operator还用于：从第一kubernetes接口服务模块监听到虚拟Pod的状态更新后，根据虚拟Pod更新后的状态，更新虚拟Pod关联的任务的状态，并将关联的任务更新后的状态发送给第一kubernetes接口服务模块。
4)第一kubernetes接口服务模块还用于：将关联任务更新后的状态发送给应用平台，以使应用平台展示关联的任务的更新后的状态。
这样，用户在应用平台可以查询并查看所提交任务关联的所有Pod的状态，提高任务管理效率。
本申请实施例中，通过虚拟kubelet构建kubernetes多集群，元数据集群面向用户，向用户提供统一的kubernetes API，相应周边组件可以统一使用，可以提高kubernetes多集群构建的便捷性，简化多集群的组件，便于多集群统一管理，通过虚拟kubelet模块进行任务调度和分配，调度到对应的计算集群以执行任务，可以平衡负载和流量，多个集群之间高可用，并且由于本申请实施例中，元数据集群和计算集群是分别部署，元数据集群中各个用户集群都可以通过虚拟kubelet模块与计算集群连接，即可以通过各自中部署的虚拟kubelet模块来转发任务到对应的计算集群，这样，本申请实施例中还可以支持多任务并行处理，不同用户集群接收到任务处理请求后，都可以通过自身中的虚拟kubelet模块发送到对应的计算集群来处理，提高了效率和系统可用性。
基于上述实施例，基于上述图2和图3所示的系统架构，下面对本申请实施例中的多集群的数据处理方法进行说明，参阅图5所示，为本申请实施例中多集群的数据处理方法流程图，该方法包括：
步骤500：用户集群中第一kubernetes接口服务模块接收用户集群对应的应用平台发送的任务处理请求。
步骤510：用户集群中虚拟kubelet模块，将任务处理请求发送给对应的计算集群中的第二kubernetes接口服务模块。
具体执行步骤510时，可以通过以下任意一个方式，将任务处理请求发送给对应的计算集群中的第二kubernetes接口服务模块：
第一种实施方式：根据任务处理请求对应的应用平台标识，以及应用平台标识与计算集群标识的关联关系，通过与关联的计算集群连接的虚拟kubelet模块，将任务处理请求发送给对应的计算集群中的第二kubernetes接口服务模块。
也就是说，本申请实施例中可以在构建kubernetes多集群系统时，可以预先设置各个应用平台与计算集群之间的关联关系，应用平台具有对具有关联关系的计算集群的访问权限，可以使用该计算集群中的资源，进而可以通过与该关联的计算集群连接的虚拟kubelet模块，发送到对应的计算集群中以执行任务。
第二种实施方式：根据任务请求中指定的计算集群标识，通过与指定的计算集群标识对应的计算集群连接的虚拟kubelet模块，将任务处理请求发送给指定的计算集群标识对应的计算集群中的第二kubernetes接口服务模块。
例如，用户在应用平台上提交任务时，可以根据提供的计算集群，从中选择计算集群，例如应用平台中显示了三个计算集群，分别为计算集群1、计算集群2和计算集群3，若用户想要使用计算集群3来执行任务，则可以从中选择计算集群3，然后提交任务，即可以调度到计算集群3对接的虚拟kubelet模块，通过该虚拟kubelet模块发送到计算集群3。
第三种实施方式：根据各个计算集群的负载情况，从各个计算集群中确定出一个计算集群，并通过与确定出的计算集群连接的虚拟kubelet模块，将任务处理请求发送给确定出的计算集群中的第二kubernetes接口服务模块。
也就是说，本申请实施例中用户提交任务时，也可以不指定计算集群，这时可以自动由调度器分配，用户集群中调度器可以根据负载情况，来确定出可用的计算集群，并通过连接的虚拟kubelet模块发送到该确定出的计算集群中，来执行任务。
当然也可以采用其它方式，来调度任务处理请求到某个具体的计算集群中，本申请实施例中并不进行限制。
步骤520：对应的计算集群中的kubelet模块，执行任务处理请求关联的任务。
需要说明的是，本申请实施例中的多集群的数据处理方法的具体执行方法，和上述系统中不同模块的执行方法相同，这里就不再进行赘述了。
本申请实施例中，分别部署元数据集群和计算集群，并在元数据集群上应用虚拟kubelet模块来构建和管理kubernetes多集群，进而接收到任务处理请求时，可以通过虚拟kubelet模块，下发到对应的计算集群，计算集群来执行关联的任务，提高数据处理效率，计算集群无需关心各个用户的差异，只需要执行相应任务即可，并且针对各个不同用户分别构建的用户集群，均可以向用户提供统一并且标准的kubernetes API，减少切换带来的负担，也可以减少多集群的组件，提高多集群的可用性和性能。
下面采用具体应用场景进行说明，以基于图2和图3的系统架构图为例，参阅图6所示，为本申请实施例中多集群的数据处理方法的交互流程图，该方法包括：
步骤600：用户向应用平台提交任务处理请求。
其中，任务处理请求中可以包括资源配置参数、选择的指定的计算集群标识等，并不进行限制。
例如，应用平台为机智平台，任务处理请求关联的任务为训练任务，则用户登录机智平台，配置任务所需的参数，并且还可以选择具体的计算集群，或不进行选择而自动分配，进而提交一个任务到应用平台。
步骤601：应用平台将任务处理请求转换成MPIjob，并发送给第一kubernetes接口服务模块。
应用平台接收到任务处理请求后，组织成定义好的资源，转换成系统可理解的任务处理请求，这里以MPIjob为例。
步骤602：应用平台监听MPIjob状态。
步骤603：operator从第一kubernetes接口服务模块监听MPIjob的创建。
步骤604：operator创建虚拟Podgroup。
即operator从第一kubernetes接口服务模块监听到MPIjob时，可以创建虚拟Podgroup。
步骤605：operator将MPIjob拆分转换为多个虚拟Pod创建需求。
步骤606：operator创建虚拟Pod。
步骤607：第一调度器监听虚拟Podgroup和虚拟Pod的创建。
步骤608：第一调度器调度虚拟Podgroup和虚拟Pod。
第一调度器监听到有虚拟Podgroup和虚拟Pod创建时，确定虚拟Pod对应的虚拟kubelet模块所在的节点，即包括虚拟kubelet模块的节点。
步骤609：第一调度器将虚拟Pod和对应的虚拟kubelet所在的节点绑定。
另外本申请实施例中，一个任务处理请求的Pod和Podgroup的创建需求可以调度到具体的一个或多个虚拟kubelet，然后再由虚拟kubelet下发到对应的计算集群。
步骤610：第一kubernetes接口服务模块转发Pod和Podgroup创建请求。
本申请实施例中，监听到有虚拟Pod和虚拟kubelet绑定关系后，就会将Pod和Podgroup创建请求转发至计算集群。
步骤611：虚拟kubelet模块将任务转换为MPIjob。
进而可以通过虚拟kubelet模块发送给对应的计算集群中的第二kubernetes接口服务模块。
步骤612：第二kubernetes接口服务模块监听Pod和Podgroup的创建。
进一步地，第二kubernetes接口服务模块还创建任务处理请求对应的Podgroup。
步骤613：第二调度器基于Pod和Podgroup所需资源进行调度。
例如第二调度器为批调度器(batch scheduler)，可以并行处理多个调度任务。
步骤614：第二调度器将Pod和kubelet模块所在节点绑定。
即第二调度器调度后，确定调度分配的worker节点，并和分配的worker节点绑定。
步骤615：kubelet模块监控Pod和kubelet模块所在节点的绑定关系。
步骤616：kubelet模块创建任务处理请求对应的Pod，并运行创建的Pod。
也就是说，kubelet模块监控到有Pod与自身所在的节点绑定后，说明该任务处理请求分配到本节点进行处理，进而该节点就会通过包括的kubelet模块相应创建Podgroup和Pod，并运行Pod来执行该任务。
步骤617：kubelet模块更新Pod状态。
步骤618：虚拟kubelet模块通过第二kubernetes接口服务模块获取Pod状态。
步骤619：虚拟kubelet模块更新Pod对应的虚拟Pod状态，并将虚拟Pod更新后的状态发送给第一kubernetes接口服务模块。
步骤620：operator从第一kubernetes接口服务模块监听虚拟Pod的状态更新。
步骤621：operator根据虚拟Pod更新后的状态，更新虚拟Pod关联的MPIjob的状态。
步骤622：operator将关联的MPIjob更新后的状态发送给第一kubernetes接口服务模块。
步骤623：应用平台从第一kubernetes接口服务模块获取MPIjob的状态变化。
步骤624：应用平台基于MPIjob的状态更新任务处理请求关联的任务状态。
本申请实施例中，通过扩展虚拟kubelet模块，解决多集群控制和管理的问题，用户集群通过统一的第一kubernetes接口服务模块面向用户，并通过虚拟kubelet模块将任务分发到对应的计算集群进行处理，还可以监控相应的Pod状态，这样，在统一而标准的API下，kubernetes多集群才能够真正发挥本身的能力，提高多个集群之间的高可用性。
基于上述实施例，参阅图7所示为本申请实施例中电子设备的结构示意图。
本申请实施例提供了一种电子设备，该电子设备可以包括处理器710(CenterProcessing Unit，CPU)、存储器720、输入设备730和输出设备740等，输入设备730可以包括键盘、鼠标、触摸屏等，输出设备740可以包括显示设备，如液晶显示器(Liquid CrystalDisplay，LCD)、阴极射线管(Cathode Ray Tube，CRT)等。
存储器720可以包括只读存储器(ROM)和随机存取存储器(RAM)，并向处理器710提供存储器720中存储的程序指令和数据。在本申请实施例中，存储器720可以用于存储本申请实施例中任一种多集群的数据处理方法的程序。
处理器710通过调用存储器720存储的程序指令，处理器710用于按照获得的程序指令执行本申请实施例中任一种多集群的数据处理方法。
基于上述实施例，本申请实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意方法实施例中的多集群的数据处理方法。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。这样，倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (11)

1.一种多集群的数据处理系统，其特征在于，所述系统至少包括元数据集群和计算集群，所述元数据集群中至少包括用户集群，用户集群中至少包括第一接口服务模块和虚拟处理模块，计算集群中至少包括第二接口服务模块和处理模块，计算集群通过虚拟处理模块提供的扩展接口与对应的用户集群接入，具体地：
所述用户集群中第一接口服务模块，用于接收所述用户集群对应的应用平台发送的任务处理请求；
所述用户集群中虚拟处理模块，用于将所述任务处理请求发送给对应的计算集群中的第二接口服务模块；
所述对应的计算集群中的处理模块，用于执行所述任务处理请求关联的任务。
2.如权利要求1所述的系统，其特征在于，所述用户集群中还包括操作模块和第一调度器，则：
所述操作模块，用于监听到所述第一接口服务模块接收到任务处理请求时，基于所述任务处理请求关联的任务，创建虚拟Podgroup和虚拟Pod，其中，所述虚拟Pod至少包括多个用于承载运行任务所需代码的容器；
所述第一调度器，用于监听到有虚拟Podgroup和虚拟Pod创建时，确定所述虚拟Pod对应的虚拟处理模块，并将所述虚拟Pod和对应的虚拟处理模块所在节点绑定；
所述虚拟处理模块，具体用于将所述任务处理请求发送给对应的计算集群中的第二接口服务模块，并指示所述对应的计算集群创建所述任务处理请求对应的Pod和Podgroup。
3.如权利要求2所述的系统，其特征在于，所述计算集群还包括第二调度器，则：
所述对应的计算集群中第二调度器，用于基于所述任务处理请求对应的Pod和Podgroup所需资源进行调度，确定所述任务处理请求对应的部署有处理模块的节点；
确定出的节点中的处理模块，用于创建所述任务处理请求对应的Pod，并运行创建的Pod，以执行所述Pod中对应的所述任务处理请求关联的任务。
4.如权利要求2或3所述的系统，其特征在于，所述虚拟处理模块，还用于：
将所述任务处理请求对应的虚拟Podgroup和虚拟Pod，分别与创建的所述Podgroup和所述Pod建立关联，以使所述虚拟Podgroup和所述虚拟Pod，分别与创建的所述Podgroup和所述Pod同步更新。
5.如权利要求1所述的系统，其特征在于，所述虚拟处理模块，还用于：
对所述任务处理请求对应的身份权限进行校验，校验所述任务处理请求是否具有对所述对应的计算集群的访问权限，校验通过后，将所述任务处理请求发送给对应的计算集群中的第二接口服务模块。
6.如权利要求3所述的系统，其特征在于，所述虚拟处理模块还用于：
监控所述任务处理请求对应的Pod的状态。
7.如权利要求3或6所述的系统，其特征在于，所述处理模块还用于：根据所述Pod的运行情况，更新所述Pod的状态，并将所述Pod更新后的状态，通过所述第二接口服务模块发送给所述虚拟处理模块；
所述虚拟处理模块还用于：更新所述Pod对应的虚拟Pod的状态，并将所述虚拟Pod更新后的状态发送给所述第一接口服务模块；
所述操作模块还用于：从所述第一接口服务模块监听到所述虚拟Pod的状态更新后，根据所述虚拟Pod更新后的状态，更新所述虚拟Pod关联的任务的状态，并将关联的任务更新后的状态发送给所述第一接口服务模块；
所述第一接口服务模块还用于：将所述关联的任务的更新后的状态发送给所述应用平台，以使所述应用平台展示所述关联的任务的更新后的状态。
8.一种多集群的数据处理方法，其特征在于，应用于多集群系统，所述多集群系统至少包括元数据集群和计算集群，所述元数据集群中至少包括用户集群，用户集群中至少包括第一接口服务模块和虚拟处理模块，计算集群中至少包括第二接口服务模块和处理模块，计算集群通过虚拟处理模块提供的扩展接口与对应的用户集群接入，所述方法包括：
用户集群中第一接口服务模块接收所述用户集群对应的应用平台发送的任务处理请求；
所述用户集群中虚拟处理模块，将所述任务处理请求发送给对应的计算集群中的第二接口服务模块；
所述对应的计算集群中的处理模块，执行所述任务处理请求关联的任务。
9.如权利要求8所述的方法，其特征在于，所述用户集群中虚拟处理模块，将所述任务处理请求发送给对应的计算集群中的第二接口服务模块，具体包括：
通过以下任意一个方式，将所述任务处理请求发送给对应的计算集群中的第二接口服务模块：
根据所述任务处理请求对应的应用平台标识，以及应用平台标识与计算集群标识的关联关系，通过与关联的计算集群连接的虚拟处理模块，将所述任务处理请求发送给对应的计算集群中的第二接口服务模块；
根据所述任务请求中指定的计算集群标识，通过与所述指定的计算集群标识对应的计算集群连接的虚拟处理模块，将所述任务处理请求发送给所述指定的计算集群标识对应的计算集群中的第二接口服务模块；
根据各个计算集群的负载情况，从所述各个计算集群中确定出一个计算集群，并通过与确定出的计算集群连接的虚拟处理模块，将所述任务处理请求发送给确定出的计算集群中的第二接口服务模块。
10.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求8-9任一项所述方法的步骤。
11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于：所述计算机程序被处理器执行时实现权利要求8-9任一项所述方法的步骤。
CN202010926782.7A 2020-09-07 2020-09-07 一种多集群的数据处理系统及方法 Active CN112104723B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010926782.7A CN112104723B (zh) 2020-09-07 2020-09-07 一种多集群的数据处理系统及方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010926782.7A CN112104723B (zh) 2020-09-07 2020-09-07 一种多集群的数据处理系统及方法

Publications (2)

Publication Number Publication Date
CN112104723A true CN112104723A (zh) 2020-12-18
CN112104723B CN112104723B (zh) 2024-03-15

Family

ID=73758556

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010926782.7A Active CN112104723B (zh) 2020-09-07 2020-09-07 一种多集群的数据处理系统及方法

Country Status (1)

Country Link
CN (1) CN112104723B (zh)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112764886A (zh) * 2021-01-29 2021-05-07 上海弘积信息科技有限公司 一种基于Kubernetes平台的负载均衡控制器
CN113010385A (zh) * 2021-03-18 2021-06-22 山东英信计算机技术有限公司 一种任务状态更新方法、装置、设备及介质
CN113220432A (zh) * 2021-05-08 2021-08-06 中国联合网络通信集团有限公司 多云互联方法、装置、设备、存储介质及产品
CN113641503A (zh) * 2021-09-01 2021-11-12 上海联蔚盘云科技有限公司 多云多集群的Kubernetes管理系统及方法与设备
CN113778623A (zh) * 2021-08-26 2021-12-10 北京达佳互联信息技术有限公司 资源处理方法和装置、电子设备及存储介质
CN114281556A (zh) * 2022-03-08 2022-04-05 北京蚂蚁云金融信息服务有限公司 用于自适应地优化在线资源分配的方法及装置
CN115460075A (zh) * 2022-09-14 2022-12-09 深圳前海环融联易信息科技服务有限公司 基于云原生的多网络模式实现方法、装置、设备及介质
CN115633084A (zh) * 2022-12-01 2023-01-20 苏州浪潮智能科技有限公司 一种k8s集群访问方法、装置及计算机可读存储介质
CN115991223A (zh) * 2023-03-23 2023-04-21 北京全路通信信号研究设计院集团有限公司 轨道交通计算系统和方法
CN113641503B (zh) * 2021-09-01 2024-05-14 上海联蔚盘云科技有限公司 多云多集群的Kubernetes管理系统及方法与设备

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013097147A1 (zh) * 2011-12-29 2013-07-04 华为技术有限公司 云计算系统和管理云计算系统中存储资源的方法
CN107491343A (zh) * 2017-09-08 2017-12-19 中国电子科技集团公司第二十八研究所 一种基于云计算的跨集群资源调度系统
EP3382546A1 (en) * 2017-03-29 2018-10-03 Juniper Networks, Inc. Multi-cluster dashboard for distributed virtualization infrastructure element monitoring and policy control
CN109067828A (zh) * 2018-06-22 2018-12-21 杭州才云科技有限公司 基于Kubernetes和OpenStack容器云平台多集群构建方法、介质、设备
WO2019100605A1 (zh) * 2017-11-21 2019-05-31 平安科技（深圳）有限公司 平台即服务paas容器平台的构建方法、服务器、系统及存储介质
CN110389836A (zh) * 2019-07-17 2019-10-29 腾讯科技（深圳）有限公司 一种多集群管理方法、装置、服务器及存储介质
US20190361626A1 (en) * 2018-05-22 2019-11-28 Pure Storage, Inc. Integrated storage management between storage systems and container orchestrators
CN110519361A (zh) * 2019-08-22 2019-11-29 北京宝兰德软件股份有限公司 基于kubernetes的容器云平台多租户构建方法及装置
CN110532058A (zh) * 2019-07-26 2019-12-03 济南浪潮数据技术有限公司 容器集群服务的管理方法、装置、设备及可读存储介质
WO2020017847A1 (ko) * 2018-07-19 2020-01-23 나무기술 주식회사 클라우드 플랫폼에서의 멀티 클러스터 프로비저닝 및 관리 방법
CN111049876A (zh) * 2019-10-18 2020-04-21 烽火通信科技股份有限公司 一种轻量电信云边缘计算系统架构
US10659523B1 (en) * 2014-05-23 2020-05-19 Amazon Technologies, Inc. Isolating compute clusters created for a customer
CN111405055A (zh) * 2020-03-23 2020-07-10 北京达佳互联信息技术有限公司 多集群管理方法、系统、服务器、存储介质
CN111522628A (zh) * 2020-04-27 2020-08-11 上海仪电（集团）有限公司中央研究院 一种基于OpenStack的Kubernetes集群搭建部署方法、架构及存储介质

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013097147A1 (zh) * 2011-12-29 2013-07-04 华为技术有限公司 云计算系统和管理云计算系统中存储资源的方法
US10659523B1 (en) * 2014-05-23 2020-05-19 Amazon Technologies, Inc. Isolating compute clusters created for a customer
EP3382546A1 (en) * 2017-03-29 2018-10-03 Juniper Networks, Inc. Multi-cluster dashboard for distributed virtualization infrastructure element monitoring and policy control
CN107491343A (zh) * 2017-09-08 2017-12-19 中国电子科技集团公司第二十八研究所 一种基于云计算的跨集群资源调度系统
WO2019100605A1 (zh) * 2017-11-21 2019-05-31 平安科技（深圳）有限公司 平台即服务paas容器平台的构建方法、服务器、系统及存储介质
US20190361626A1 (en) * 2018-05-22 2019-11-28 Pure Storage, Inc. Integrated storage management between storage systems and container orchestrators
CN109067828A (zh) * 2018-06-22 2018-12-21 杭州才云科技有限公司 基于Kubernetes和OpenStack容器云平台多集群构建方法、介质、设备
WO2020017847A1 (ko) * 2018-07-19 2020-01-23 나무기술 주식회사 클라우드 플랫폼에서의 멀티 클러스터 프로비저닝 및 관리 방법
CN110389836A (zh) * 2019-07-17 2019-10-29 腾讯科技（深圳）有限公司 一种多集群管理方法、装置、服务器及存储介质
CN110532058A (zh) * 2019-07-26 2019-12-03 济南浪潮数据技术有限公司 容器集群服务的管理方法、装置、设备及可读存储介质
CN110519361A (zh) * 2019-08-22 2019-11-29 北京宝兰德软件股份有限公司 基于kubernetes的容器云平台多租户构建方法及装置
CN111049876A (zh) * 2019-10-18 2020-04-21 烽火通信科技股份有限公司 一种轻量电信云边缘计算系统架构
CN111405055A (zh) * 2020-03-23 2020-07-10 北京达佳互联信息技术有限公司 多集群管理方法、系统、服务器、存储介质
CN111522628A (zh) * 2020-04-27 2020-08-11 上海仪电（集团）有限公司中央研究院 一种基于OpenStack的Kubernetes集群搭建部署方法、架构及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
王博: "基于边缘计算的多集群容器云资源调度机制研究与实现", 《中国优秀硕士学位论文电子期刊》, pages 26 - 38 *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112764886A (zh) * 2021-01-29 2021-05-07 上海弘积信息科技有限公司 一种基于Kubernetes平台的负载均衡控制器
CN113010385A (zh) * 2021-03-18 2021-06-22 山东英信计算机技术有限公司 一种任务状态更新方法、装置、设备及介质
CN113010385B (zh) * 2021-03-18 2022-10-28 山东英信计算机技术有限公司 一种任务状态更新方法、装置、设备及介质
US11915035B1 (en) 2021-03-18 2024-02-27 Shandong Yingxin Computer Technologies Co., Ltd. Task state updating method and apparatus, device, and medium
CN113220432B (zh) * 2021-05-08 2023-11-21 中国联合网络通信集团有限公司 多云互联方法、装置、设备、存储介质及产品
CN113220432A (zh) * 2021-05-08 2021-08-06 中国联合网络通信集团有限公司 多云互联方法、装置、设备、存储介质及产品
CN113778623A (zh) * 2021-08-26 2021-12-10 北京达佳互联信息技术有限公司 资源处理方法和装置、电子设备及存储介质
CN113778623B (zh) * 2021-08-26 2024-04-16 北京达佳互联信息技术有限公司 资源处理方法和装置、电子设备及存储介质
CN113641503A (zh) * 2021-09-01 2021-11-12 上海联蔚盘云科技有限公司 多云多集群的Kubernetes管理系统及方法与设备
CN113641503B (zh) * 2021-09-01 2024-05-14 上海联蔚盘云科技有限公司 多云多集群的Kubernetes管理系统及方法与设备
CN114281556A (zh) * 2022-03-08 2022-04-05 北京蚂蚁云金融信息服务有限公司 用于自适应地优化在线资源分配的方法及装置
CN115460075A (zh) * 2022-09-14 2022-12-09 深圳前海环融联易信息科技服务有限公司 基于云原生的多网络模式实现方法、装置、设备及介质
CN115633084A (zh) * 2022-12-01 2023-01-20 苏州浪潮智能科技有限公司 一种k8s集群访问方法、装置及计算机可读存储介质
CN115991223A (zh) * 2023-03-23 2023-04-21 北京全路通信信号研究设计院集团有限公司 轨道交通计算系统和方法

Also Published As

Publication number Publication date
CN112104723B (zh) 2024-03-15

Similar Documents

Publication Publication Date Title
CN112104723B (zh) 一种多集群的数据处理系统及方法
CN112119374B (zh) 使用替代服务器名称选择性地提供相互传输层安全
US10042628B2 (en) Automated upgrade system for a service-based distributed computer system
US10942790B2 (en) Automated-application-release-management subsystem that incorporates script tasks within application-release-management pipelines
US9009697B2 (en) Hybrid cloud integrator
EP3559801A1 (en) Methods, systems, and portal using software containers for accelerating aspects of data analytics application development and deployment
US20150111567A1 (en) Apparatus for End-User Transparent Utilization of Computational, Storage, and Network Capacity of Mobile Devices, and Associated Methods
US20120203908A1 (en) Hybrid cloud integrator plug-in components
US20170161023A1 (en) Automated application-release-management subsystem
US20190227793A1 (en) Code-change and developer rating in an automated-application-release-management subsystem
US20170161043A1 (en) Integrated automated application deployment
US11301262B2 (en) Policy enabled application-release-management subsystem
CN102882947A (zh) 自动化的桌面服务供应
US20170163518A1 (en) Model-based artifact management
CN111190586A (zh) 软件开发框架的搭建及使用方法、计算设备和存储介质
US20170161057A1 (en) Plug-in-based artifact-management subsystem
CN111338641A (zh) 一种应用发布方法及装置
US10223218B2 (en) Disaster recovery of managed systems
KR101680702B1 (ko) 클라우드 기반 웹 호스팅 시스템
US20170161101A1 (en) Modularized automated-application-release-management subsystem
WO2019135133A1 (en) Dynamic delivery of software functions
CN111274002A (zh) 支撑paas平台构建方法、装置、计算机设备及存储介质
Grandinetti Pervasive cloud computing technologies: future outlooks and interdisciplinary perspectives: future outlooks and interdisciplinary perspectives
CN112328390A (zh) 自动化实施云管理平台的方法、装置及存储介质
CN110688197A (zh) 一种云操作系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant