CN111405055A

CN111405055A - 多集群管理方法、系统、服务器、存储介质

Info

Publication number: CN111405055A
Application number: CN202010207276.2A
Authority: CN
Inventors: 张健; 赵焕彦
Original assignee: Reach Best Technology Co Ltd
Current assignee: Reach Best Technology Co Ltd; Beijing Dajia Internet Information Technology Co Ltd
Priority date: 2020-03-23
Filing date: 2020-03-23
Publication date: 2020-07-10

Abstract

本公开关于一种多集群管理方法、系统、服务器、存储介质。该方法包括：获取多个集群中每个集群分别的业务处理资源的资源数据，所述资源数据由每个集群中设置的集群服务代理模块采集得到；根据所述资源数据，确定所述集群的工作负荷；基于所述多个集群各自的工作负荷，将待处理的业务在所述多个集群进行均衡调度。本实施例中通过在各集群内设置集群服务代理模块，由集群服务代理模块采集所在集群的资源数据并进行上报给容器云平台，这样容器云平台可以根据资源数据确定各集群的工作负荷，并根据工作负荷将待处理的业务在多个集群进行均衡调度，使各集群的资源与处理业务相匹配，从而可以满足超大规模的容器云平台的应用场景，有利于提升管理效率。

Description

多集群管理方法、系统、服务器、存储介质

技术领域

本公开涉及云管理技术领域，尤其涉及一种多集群管理方法、系统、服务器、存储介质。

背景技术

目前，对于视频服务提供平台来说，其可以在不同时间为不同位置的用户提供视频服务，故平台可以在不同的地域部署服务集群，如Kubernetes(通常称之为k8s)集群，从而达到低延时的效果。为方便管理，平台通常会采用容器云来对k8s集群进行管理。其中，k8s作为容器云应用的管理中心，对k8s集群内部所有容器的生命周期进行管理，结合自身的健康检查及错误恢复机制，实现了集群内部应用层的高可用性。

实际应用中，视频服务提供平台采用超大规模的容器云平台来实现，例如上有百个k8s集群。在实际应用中，在某个访问高峰时段或者某个区域内集群内负荷不均的情况，因此面临着资源均衡的实际需求。

发明内容

本公开提供一种多集群管理方法、系统、服务器、存储介质，以解决相关技术中存在的问题。

本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种多集群管理方法，所述方法包括：

获取多个集群中每个集群分别的业务处理资源的资源数据，所述资源数据由每个集群中设置的集群服务代理模块采集得到；

根据所述资源数据，确定所述集群的工作负荷；

基于所述多个集群各自的工作负荷，将待处理的业务在所述多个集群进行均衡调度。

可选地，所述根据所述资源数据，确定所述集群的工作负荷，包括：

若所述资源数据中包括业务处理资源的使用量或剩余量，根据所述业务处理资源的使用量或者剩余量以及业务处理资源的总量，获取所述集群的资源分配率，将所述资源分配率作为所述工作负荷；

或者，

若所述资源数据中包括硬件资源的使用量或剩余量，根据所述硬件资源的使用量或者剩余量以及硬件资源的总量，获取所述集群的硬件使用率，将所述硬件使用率作为所述集群的工作负荷。

可选地，所述基于所述多个集群各自的工作负荷，将待处理的业务在所述多个集群进行均衡调度，包括：

接收业务处理请求，所述业务处理请求携带待处理的业务流量；

基于所述多个集群各自的工作负荷，由所述多个集群中选择确定工作负荷满足预设调度条件的第一目标集群；

将所述业务流量分配至所述第一目标集群，以通过所述第一目标集群中的业务处理资源对所述业务流量进行处理。

接收服务部署请求，所述服务部署请求携带待部署的业务处理服务；

基于所述多个集群各自的工作负荷，由所述多个集群中选择确定工作负荷满足预设调度条件的第二目标集群；

将所述业务处理服务部署至所述第二目标集群。

可选地，所述将所述业务处理服务部署至所述第二目标集群，包括：

向部署处理模块发送服务部署请求，所述服务部署请求中携带：所述第二目标集群的集群标识信息、以及所述业务处理服务的服务文件，以使得所述部署处理模块自动将所述业务处理服务部署至所述第二目标集群。

可选地，所述方法还包括：

获取所述多个集群中的其中一个集群的资源变更数据，所述资源变更数据包括至少一种：所述集群中的各个工作节点的业务处理资源的扩容数据、缩容数据和生命周期数据；

将所述资源变更数据发送至所述集群中的负载均衡处理模块，以使得所述负载均衡处理模块根据所述资源变更数据对所述各个工作节点的工作负荷进行均衡控制。

根据本公开实施例的第二方面，提供一种多集群管理系统，所述系统包括：

多个集群中各集群内设置的集群服务代理模块，用于采集所在集群的业务处理资源的资源数据；

容器云平台，用于获取各集群服务代理模块所采集的资源数据，并根据所述资源数据确定所述集群的工作负荷，以及基于所述各集群的工作负荷将待处理的业务在所述多个集群进行均衡调度。

可选地，所述容器云平台，包括：

分配率获取模块，用于在所述资源数据中包括业务处理资源的使用量或剩余量时，根据所述业务处理资源的使用量或者剩余量以及业务处理资源的总量，获取所述集群的资源分配率，将所述资源分配率作为所述工作负荷；

或者，

使用率获取模块，用于在所述资源数据中包括硬件资源的使用量或剩余量时，根据所述硬件资源的使用量或者剩余量以及硬件资源的总量，获取所述集群的硬件使用率，将所述硬件使用率作为所述集群的工作负荷

可选地，所述容器云平台，包括：

请求接收模块，用于接收业务处理请求，所述业务处理请求携带待处理的业务流量；

集群确定模块，用于基于所述多个集群各自的工作负荷，由所述多个集群中选择确定工作负荷满足预设调度条件的第一目标集群；

流量调度模块，用于将所述业务流量分配至所述第一目标集群，以通过所述第一目标集群中的业务处理资源对所述业务流量进行处理。

可选地，所述容器云平台，包括：

请求接收模块，用于接收服务部署请求，所述服务部署请求携带待部署的业务处理服务；

集群确定模块，用于基于所述多个集群各自的工作负荷，由所述多个集群中选择确定工作负荷满足预设调度条件的第二目标集群；

业务部署模块，用于将所述业务处理服务部署至所述第二目标集群。

可选地，所述系统还包括：部署处理模块；

所述容器云平台，还用于向所述部署处理模块发送服务部署请求，所述服务部署请求中携带：所述第二目标集群的集群标识信息、以及所述业务处理服务的服务文件；

所述部署处理模块，用于根据所述集群标识信息和服务文件，将所述业务处理服务部署至所述第二目标集群。

可选地，所述容器云平台还包括：

变更数据获取模块，用于获取所述多个集群中的其中一个集群的资源变更数据，所述资源变更数据包括至少一种：所述集群中的各个工作节点的业务处理资源的扩容数据、缩容数据和生命周期数据；并将所述资源变更数据发送至所述集群中的负载均衡处理模块，以使得所述负载均衡处理模块根据所述资源变更数据对所述各个工作节点的工作负荷进行均衡控制。

根据本公开实施例的第三方面，提供一种服务器，包括：

处理器；

用于存储所述处理器可执行的计算机程序的存储器；其中，所述处理器被配置为执行所述存储器中的计算机程序，以实现如上述所述方法的步骤。

根据本公开实施例的第四方面，提供一种存储介质，当所述存储介质中的可执行的计算机程序由服务器的处理器执行时，使得服务器能够执行如上述所述方法的步骤。

根据本公开实施例的第五方面，提供一种应用程序，当该应用程序由服务器的处理器执行时，使得所述服务器能够执行上述所述方法的步骤。

本公开的实施例提供的技术方案至少带来以下有益效果：

本实施例中通过在各集群内设置集群服务代理模块，由集群服务代理模块采集所在集群的资源数据并进行上报给容器云平台，这样容器云平台可以根据资源数据确定各集群的工作负荷，并根据工作负荷将待处理的业务在多个集群进行均衡调度，使各集群的资源与处理业务相匹配，从而可以满足超大规模的容器云平台的应用场景，有利于提升管理效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是根据一示例性实施例示出的一种多集群管理系统的架构示意图。

图2是根据一示例性实施例示出的一种k8s集群的架构示意图。

图3是根据一示例性实施例示出的一种多集群管理方法的流程图。

图4是根据一示例性实施例示出的另一种多集群管理方法的流程图。

图5是根据一示例性实施例示出的业务部署的流程图。

图6是根据一示例性实施例示出的另一种多集群管理方法的流程图。

图7～图9是根据一示例性实施例示出的一种多集群管理系统的框图。

图10是根据一示例性实施例示出的一种服务器的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

实际应用中，视频服务提供平台采用超大规模的容器云平台来实现，例如上有百个k8s集群。在实际应用中，存在某个访问高峰时段或者某个区域内集群内工作负荷不均衡的情况，导致多个集群存在剩余资源不均衡的问题。

为此，本公开实施例提供了一种多集群管理系统，其发明构思在于，在多个集群中各集群内设置集群服务代理模块，由该集群服务代理模块采集所在集群的业务处理资源的资源数据上报给容器云平台，这样容器云平台在获取各集群服务代理模块所采集的资源数据后，可以将待处理的业务在所述多个集群进行均衡调度。图1是根据一示例性实施例示出的一种多集群管理系统的架构示意图，参见图1，一种多集群管理系统可以包括多个集群中各集群内设置的集群服务代理模块和容器云平台。其中：

参见图1，该多集群管理系统包括入口服务，例如指令行(kcsctl)/界面服务(webssh)，用户(研发人员或者测试人员等)通过该指令行可以查看各集群中的资源情况，例如当前情况下pod的数量，各集群中pod的数量是否均衡，或者pod是否在期望的集群中启动等。又如，用户可以通过界面服务或客户端请求服务，以获取如观看视频等服务。

参见图1，该多集群管理系统可以包括部署处理模块，该部署处理模块可以采用CI/CD服务实现。本示例中，CI服务是指持续集成(Continuous Integration，CI)服务，CI服务是将各个开发人员的工作集合到一个代码仓库中。这样，开发人员在上传代码时，CI服务会检测新代码是否与已有代码存在冲突，当发现新代码和已有代码存在冲突时可以提醒开发人员，提醒开发人员对新代码进行修改，直至使上传的新代码满足要求。本示例中通过设置CI服务可以尽早发现集成错误，使开发团队更加紧密结合，更好地协作，有助于降低总体构建成本，并在周期的早期发现缺陷，并且，本示例中可以提升系统的迭代速度。

本示例中，CD服务是指持续交付(Continuous Delivery，CD)服务或者持续部署(Continuous Deployment，CD)服务。持续交付服务实际上是持续集成CI服务的扩展，依赖于部署流水线，团队通过流水线自动化测试和部署过程，使软件交付流程进一步自动化，以便随时轻松地部署到生成环境中。在流水线的每个阶段，如果构建无法通过关键测试会向团队发出警报。如果通过关键测试会继续进入下一个测试，并在连续通过测试后自动进入下一个阶段，最后一个部分会将构建部署到和生产环境等效的环境中。持续部署服务扩展了持续交付服务，在软件通过所有测试后会自动部署，即CI/CD服务的最后一步将在构建后的组件/包退出流水线时自动部署。此类自动部署可以配置为快速向客户分发组件、功能模块或修复补丁，并准确说明当前提供的内容，从而无需要开发人员或者运维人员决定何时及如何投入生产环境。

本示例中，容器云平台可以获取部署需求，该部署需求可以由用户输入，也可以是容器云平台根据各集群的资源数据计算得到。在获取部署需求后，容器云平台可以调用CI/CD服务，由CI/CD服务获取相应文件(如软件或代码)后向目标集群自动部署Kubernetes系统和/或pod应用。

以部署Kubernetes系统为例，容器云平台可以根据用户输入的部署需求调用CI/CD服务，CI/CD服务可以从部署需求内获取目标集群，以及Kubernetes系统文件的存储位置，从存储位置获取Kubernetes系统文件。然后，CI/CD服务可以在已安装的操作系统(如linux系统)的服务器上部署Kubernetes系统，即由CI/CD服务响应部署需求自动布置Kubernetes系统。以部署pod应用为例，容器云平台可以根据各集群的资源数据，计算出各集群的工作负荷，其中工作负荷可以采用集群的资源分配率和/或处理器使用率来表征，在一些场景中工作负荷还可以包括缓存使用率、设备温度等等参数来表征，技术人员可以根据具体场景进行设置，在此不作限定。基于负荷平衡原则，CI/CD服务可以将后续的pod应用部署到指定集群中，指定集群可以为工作负荷较低(如资源分配率低于60％，且处理器使用率低于50％)的集群，从而减小各个集群的工作负荷之差，最终使所有集群的工作负荷相同或者相接近。本实施例中，通过设置CI/CD服务，可以在超大规模的容器云平台上实现自动部署，提高部署效率，提升使用体验。

在一示例中，参见图1，该多集群管理系统可以包括数据库(DB)/缓存(cache)。以数据库为例，容器云平台可以将获取的资源数据或者部署数据等历史数据存储到数据库内，以方便后续使用。技术人员可以根据具体场景设置存储方式，在此不作限定。

在一示例中，容器云平台可以设置有发现模块，该发现模块可以作为一个服务中心，用于统一注册各集群中的同一种服务。在注册过程中，会将pod的ip地址和端口以环境变量的形式流入到pod里，比如pod创建时有一个redis-master服务，服务ip地址是10.0.0.11，port是6379，则会把下面一系列环境变量注入到pod里，通过这些环境变量访问redis-master服务可以发现pod应用，或者发现模块直接替代redis-master服务来发现pod。这样该服务中心可以对各集群中的pod应用的生命周期进行管理，有利于实现跨集群服务发现。然后，容器云平台可以动态地将pod应用的变更数据同步到各集群的负载均衡处理模块中，并由负载均衡处理模块对各工作节点的工作负荷进行调整，保证各集群的资源在一个相对健康的水平。并且，本示例中将各集群中的同一种服务由发现模块统一注册，可以跨集群调度同一种服务，例如某一集群的一种服务中断或者后，将该宕机集群的同一种服务由其他集群的同一种服务来提供服务，达到无缝切换的效果。

在一实施例中，继续参见图1，各集群内设置有集群服务代理模块(kcs-agent)，该集群服务代理模块可以自动采集和汇总各个集群的资源数据和集群内各工作节点(node)的资源数据，并通过上报的方式发送给容器云平台。这样，容器云平台可以根据各集群服务代理模块上报的资源数据获取各集群的工作负荷或者各集群内每个工作节点的工作负荷，以及均衡各集群的负荷或者资源，达到自动调度流量的效果，有利于为不同的终端用户提供更高的带宽和更低的延迟。

例如，在集群A的工作负荷较高时，可以在集群B中扩容，然后通过负载迁移的方式将集群A的部分业务迁移到集群B，达到集群A和集群B的负荷均衡的效果。又如，在集群A的工作负荷较高时，对于后续的服务请求，通过负载分配的均衡方式，可以优先将待处理的业务调度到集群B，从而达到集群A和集群B的工作负荷均衡。技术人员可以根据具体场景设置负荷均衡方式，在此不作限定。

在一示例中，容器云平台可以将一个服务跨集群部署，这样当某个集群出现故障时，其他集群也可以提供相同的服务，从而不影响整个服务的正常使用。另外，容器云平台还可以检测集群是否处于不可用状态，若处于不可用状态，则将该集群中任务分配到其他可用的集群上，有利于缩短故障恢复时间。

需要说明的是，图1所示的多集群管理系统仅描述了与本公开发明点相关的服务或组件，实际应用中，为保证容器云平台正常工程，还可以设置其他服务或者组件，在此不再描述。

图2是根据一示例性实施例示出的一种k8s集群的架构图，参见图2，一种k8s集群，包括：交互模块、负载均衡处理模块、多个控制节点和多个工作节点。其中，交互模块可以包括客户端(clients)、命令行(kubectl)等，可以获取用户输入的控制指令或服务请求。其中kubectl作为kubernetes的命令行工具，主要用于对集群中资源的对象进行操作，如对资源对象的创建、删除和查询等。以获取到控制指令为例，交互模块可以访问负载均衡处理模块，从而将负载均衡处理模块所存储的资源数据反馈给用户，以方便用户查询、测试等。以获取到服务请求为例，交互模块可以通过负载均衡处理模块访问到集群内的某一个工作节点，由该工作节点响应上述服务请求，例如视频推送、视频搜索、直播等。

继续参见图2，负载均衡处理模块可以与交互模块通信，将交互模块获取的服务请求分配到各工作节点。这样，集群通过负载均衡处理模块可以均衡各工作节点的负荷、流量等。

需要说明的是，相关技术中各工作结节与控制节点连接，控制节点包括主控制节点和副控制节点，其中主控制节点工作时，副控制节点也同时工作，在主控制节点不可用时，其中一个副控制节点成为新的主控制节点管理各工作节点，控制节点的业务逻辑可以由任务调度(scheduler)和管理控制中心(controller manager)执行，具体可以参考相关技术的内容，在此不再赘述。

相关技术中上述控制方式存在以下不足，主控制节点和副控制节点同时工作，在工作节点有迁移需求时，相关业务也需要迁移，导致迁移效率比较低。而本实施例中，通过负载均衡处理模块均衡各控制节点的负荷，可以保证各工作节点的负荷处于相对健康的水平，从而大大降低业务迁移的需求。并且，在一个控制节点不可用时，由负载均衡处理模块调整控制节点即可，无需对工作节点进行迁移。

继续参见图2，多个控制节点的数量通常设置为奇数个，如图2中的3个控制节点(master node#1，master node#2和master node#3)，图2中采用虚线表示的任务调度和管理控制中心用来说明其属于主控制节点，每个集群只有一个任务调度和管理控制中心工作，其他作为备用。各控制节点内设有apiserver服务，该apiserver服务可以将所在k8s集群内的资源数据存储到Etcd服务。针对apiserver服务而言，多个控制节点同时工作，不区分主控制节点和副控制节点，这样多个apiserver服务中各服务可以分别承担相应的任务，从而在其中一个apiserver服务不可用后，仍然可以由负载均衡处理模块将流量转发到其他apiserver服务，实现无缝衔接，保证apiserver服务的高可用。

在一示例中，Etcd服务可以采用以下架构实现，包括：http服务器用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求，存储器(store)用于处理Etcd支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是Etcd对用户提供的大多数API功能的具体实现，一致性算法(raft)分解为领导人选举，日志复制和安全三个模块，由选举出的领导人为客户端服务；预写式日志(WAL)是Etcd的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，Etcd就通过WAL进行持久化存储。WAL中，所有的数据提交前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示存储的具体日志内容。对于Etcd中各部分之间的数据交互可以参考相关技术的内容，在此不再赘述。

另外，本实施例中，apiserver服务还提供了对k8s集群内各类资源对象(pod，RC，Service等)的增删改查，以及观察(watch)等HTTP Rest接口，其可以作为集群的数据总线和数据中心。

需要说明的是，相关技术中采用多个控制节点的一个控制节点作为主控制节点，其余控制节点作为副控制节点的方案，而本实施例中，针对apiserver服务而言，多个控制节点同时工作，不区分主控制节点和副控制节点，这样多个apiserver服务中各服务可以分别承担相应的任务，从而在其中一个apiserver服务不可用后，仍然可以由负载均衡处理模块将流量转发到其他apiserver服务，实现无缝衔接，保证apiserver服务的高可用。

继续参见图1和图2，本实施例中各集群内设有一个Etcd服务，该Etcd服务的功能已经在上述实施例内描述。需要说明的是，与相关技术中多个集群共用一个Etcd服务相比，本实施例中，容器云平台在管理各集群的过程中，不再依赖Etcd服务。换言之，由于每个集群设有一个Etcd服务，该Etcd负责所在集群内资源数据的存储工作，在一个集群不可用后，容器云平台在迁移业务时，直接启用目标集群的Etcd服务即可。

至此，本实施例中通过在各集群内设置集群服务代理模块，由集群服务代理模块采集和汇总所在集群的资源数据并进行上报，这样容器云平台可以根据资源数据对各集群进行均衡管理。这样，本实施例可以满足超大规模的容器云平台，有利于提升管理效率。

图3是根据一示例性实施例示出的一种多集群管理方法的流程图。参见图3，一种多集群管理方法，适用于图1和图2所示的多集群管理系统，所述方法包括：

301，获取多个集群中每个集群分别的业务处理资源的资源数据，所述资源数据由每个集群中设置的集群服务代理模块采集得到。

本实施例中，集群服务代理模块(kcs-agent)可以自动采集和汇总各个集群的资源数据和各集群内每个工作节点(node)的资源数据，一方面，可以将资源数据存储到Etcd服务，另一方面可以通过上报的方式发送给容器云平台。

302，根据所述资源数据，确定所述集群的工作负荷。

本实施例中，容器云平台可以获取到各集群的所有资源数据，以及当前时刻已分配的资源数据，从而计算出各集群的工作负荷。

在一示例中，当资源数据中包括业务处理资源的使用量或剩余量，可以根据业务处理资源的使用量或者剩余量以及业务处理资源的总量，获取集群的资源分配率，将资源分配率作为所述工作负荷。例如，集群中pod数量为100万个，当前已经使用68万个，则资源分配率为68/100*100％＝68％。

在另一示例中，当资源数据中包括硬件资源的使用量或剩余量，根据硬件资源的使用量或者剩余量以及硬件资源的总量，获取集群的硬件使用率，将硬件使用率作为集群的工作负荷。其中，硬件可以包括处理器、缓存、存储器等。以缓存为例，集群中具有缓存1024GB，当前已经使800GB，则硬件使用率为800/1024*100％＝78％。

303，基于所述多个集群各自的工作负荷，将待处理的业务在所述多个集群进行均衡调度。

在一实施例中，参见图4，在步骤401中，容器云平台可以接收业务处理请求，业务处理请求携带待处理的业务流量。以步骤402中，容器云平台可以对比多个集群各自的工作负荷，从多个集群中选择确定工作负荷满足预设调度条件的第一目标集群。其中，预设调度条件可以是资源分配率最低、在资源分配率接近(差值在设定范围内)时硬件使用率最低、硬件使用率最低中的一种，可以根据具体场景调整预设调度条件。在步骤403中，容器云平台可以将业务流量分配至第一目标集群，以通过第一目标集群中的业务处理资源对业务流量进行处理。本示例中通过业务调度可以实现各集群的流量均衡，达到自动调度流量的效果，有利于为不同的终端用户提供更高的带宽和更低的延迟

在另一实施例中，参见图5，在步骤501中，容器云平台可以接收服务部署请求，该服务部署请求携带待部署的业务处理服务。其中待部署的业务处理服务可以包括操作系统或者pod应用。在步骤502中，容器云平台可以基于所述集群各自的工作负荷，从多个集群中选择确定工作负荷满足预设调度条件的第二目标集群。其中预设调度条件可以参见步骤402的相关说明，在此不再赘述。在步骤503中，容器云平台可以将业务处理服务部署至第二目标集群。例如，容器云平台可以向部署处理模块(CI/CD服务)发送服务部署请求，其中服务部署请求中携带：第二目标集群的集群标识信息、以及业务处理服务的服务文件，以使得部署处理模块自动将业务处理服务部署至第二目标集群。本示例中将业务待部署的业务处理服务部署到第二目标集群，可以均衡多个集群的工作负荷。

例如，待部署的业务处理服务为部署Kubernetes系统，容器云平台可以根据第二目标集群的集群标识信息、Kubernetes系统文件(或者文件存储位置)生成服务部署请求，并发送给CI/CD服务。这样，CI/CD服务可以从服务部署需求内获取Kubernetes系统文件的存储位置，从存储位置获取Kubernetes系统文件，或者直接从服务部署请求获取系统文件。然后，CI/CD服务可以在第二目标集群上部署Kubernetes系统，即由CI/CD服务响应部署需求自动布置Kubernetes系统。

在一实施例中，参见图6，在步骤601中，对于多个集群中的各个集群，当有一个集群的资源发生变化后，容器云平台可以获取该集群的资源变更数据，其中资源变更数据包括以下至少一种：集群中各个工作节点的业务处理资源的扩容数据、缩容数据和生命周期数据。在步骤602中，容器云平台可以将资源变更数据发送至该资源发生变更的集群中的负载均衡处理模块，以使得负载均衡处理模块根据资源变更数据对各个工作节点的工作负荷进行均衡控制。

实际应用中，容器云平台内可以设置有发现模块，由该发现模块实现图6所示例的方案。该发现模块作为一个服务中心，可以统一注册各集群中的同一种服务，并可以对各集群中的pod应用的生命周期进行管理，有利于实现跨集群服务发现。然后，容器云平台可以动态地将pod应用的变更数据同步到各集群的负载均衡处理模块中，并由负载均衡处理模块对各工作节点的工作负荷进行调整，保证各集群的资源在一个相对健康的水平。并且，本实施例中将各集群中的同一种服务由发现模块统一注册，可以跨集群调度同一种服务，例如某一集群该服务宕机中后，将该宕机集群的同一种服务由其他集群的同一种服务来提供服务，达到无缝切换的效果。

关于上述实施例中的方法，其中方法中各步骤的具体实现方式已经在描述系统中相关组件或服务的实施例中进行了详细描述，此处将不做详细阐述说明。

至此，本实施例中通过在各集群内设置集群服务代理模块，由集群服务代理模块采集所在集群的资源数据并进行上报给容器云平台，这样容器云平台可以根据资源数据确定各集群的工作负荷，并根据工作负荷将待处理的业务在多个集群进行均衡调度，使各集群的资源与处理业务相匹配，从而可以满足超大规模的容器云平台的应用场景，有利于提升管理效率。

图7是根据一示例性实施例示出的一种多集群管理系统的框图，参见图7，一种多集群管理系统，包括：

多个集群中各集群内设置的集群服务代理模块701，用于采集所在集群的业务处理资源的资源数据；

容器云平台702，用于获取各集群服务代理模块所采集的资源数据，并根据所述资源数据确定所述集群的工作负荷，以及基于所述各集群的工作负荷将待处理的业务在所述多个集群进行均衡调度。

在一实施例中，所述容器云平台702，包括：

或者，

在一实施例中，参见图8，所述容器云平台702，包括：

请求接收模块801，用于接收业务处理请求，所述业务处理请求携带待处理的业务流量；

集群确定模块802，用于基于所述多个集群各自的工作负荷，由所述多个集群中选择确定工作负荷满足预设调度条件的第一目标集群；

流量调度模块803，用于将所述业务流量分配至所述第一目标集群，以通过所述第一目标集群中的业务处理资源对所述业务流量进行处理。

在一实施例中，参见图9，所述容器云平台702，包括：

请求接收模块901，用于接收服务部署请求，所述服务部署请求携带待部署的业务处理服务；

集群确定模块902，用于基于所述多个集群各自的工作负荷，由所述多个集群中选择确定工作负荷满足预设调度条件的第二目标集群；

在一实施例中，所述系统还包括：部署处理模块；

在一实施例中，所述容器云平台702还包括：

关于上述实施例中的系统，其中系统中各模块的具体实现方式已经在描述系统中相关组件或服务的实施例和方法实施例中进行了详细描述，此处将不做详细阐述说明。

图10是根据一示例性实施例示出的一种服务器的框图。参照图10，服务器1000可以包括以下一个或多个组件：处理组件1002，存储器1004，电源组件1006，多媒体组件1008，音频组件1010，输入/输出(I/O)的接口1012，传感器组件1014，以及通信组件1016。

处理组件1002通常控制服务器1000的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件1002可以包括一个或多个处理器1020来执行指令，以完成图3所示方法的全部或部分步骤。此外，处理组件1002可以包括一个或多个模块，便于处理组件1002和其他组件之间的交互。例如，处理组件1002可以包括多媒体模块，以方便多媒体组件1008和处理组件1002之间的交互。

存储器1004被配置为存储各种类型的数据以支持在服务器1000的操作。这些数据的示例包括用于在服务器1000上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器1004可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件1006为服务器1000的各种组件提供电力。电源组件1006可以包括电源管理系统，一个或多个电源，及其他与为服务器1000生成、管理和分配电力相关联的组件。

多媒体组件1008包括在服务器1000和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件1008包括一个前置摄像头和/或后置摄像头。当服务器1000处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件1010被配置为输出和/或输入音频信号。例如，音频组件1010包括一个麦克风(MIC)，当服务器1000处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器1004或经由通信组件1016发送。在一些实施例中，音频组件1010还包括一个扬声器，用于输出音频信号。

I/O接口1012为处理组件1002和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件1014包括一个或多个传感器，用于为服务器1000提供各个方面的状态评估。例如，传感器组件1014可以检测到服务器1000的打开/关闭状态，组件的相对定位，例如所述组件为服务器1000的显示器和小键盘，传感器组件1014还可以检测服务器1000或服务器1000一个组件的位置改变，用户与服务器1000接触的存在或不存在，服务器1000方位或加速/减速和服务器1000的温度变化。传感器组件1014可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件1014还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件1014还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件1016被配置为便于服务器1000和其他设备之间有线或无线方式的通信。服务器1000可以接入基于通信标准的无线网络，如WiFi，运营商网络(如2G、3G、4G或5G)，或它们的组合。在一个示例性实施例中，通信组件1016经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件1016还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在本公开一实施例中，服务器1000可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在本公开一实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器1004，上述指令可由服务器1000的处理器1020执行以完成上述方法的步骤。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在本公开一实施例中，还提供了一种应用程序，当该应用程序由服务器的处理器执行时，使得所述服务器能够执行如下步骤：获取多个集群中每个集群分别的业务处理资源的资源数据，所述资源数据由每个集群中设置的集群服务代理模块采集得到；根据所述资源数据，确定所述集群的工作负荷；基于所述多个集群各自的工作负荷，将待处理的业务在所述多个集群进行均衡调度。

在本公开一实施例中，还提供了一种计算机程序产品，当该计算机程序产品由服务器的处理器执行时，使得所述服务器能够执行如下步骤：获取多个集群中每个集群分别的业务处理资源的资源数据，所述资源数据由每个集群中设置的集群服务代理模块采集得到；根据所述资源数据，确定所述集群的工作负荷；基于所述多个集群各自的工作负荷，将待处理的业务在所述多个集群进行均衡调度。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置/服务器/存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖上述各实施例的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims

1.一种多集群管理方法，其特征在于，所述方法包括：

根据所述资源数据，确定所述集群的工作负荷；

2.根据权利要求1所述的方法，其特征在于，所述根据所述资源数据，确定所述集群的工作负荷，包括：

或者，

3.根据权利要求1所述的方法，其特征在于，所述基于所述多个集群各自的工作负荷，将待处理的业务在所述多个集群进行均衡调度，包括：

4.根据权利要求1所述的方法，其特征在于，所述基于所述多个集群各自的工作负荷，将待处理的业务在所述多个集群进行均衡调度，包括：

将所述业务处理服务部署至所述第二目标集群。

5.根据权利要求4所述的方法，其特征在于，所述将所述业务处理服务部署至所述第二目标集群，包括：

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

7.一种多集群管理系统，其特征在于，所述系统包括：

8.根据权利要求7所述的多集群管理系统，其特征在于，所述容器云平台，包括：

或者，

使用率获取模块，用于在所述资源数据中包括硬件资源的使用量或剩余量时，根据所述硬件资源的使用量或者剩余量以及硬件资源的总量，获取所述集群的硬件使用率，将所述硬件使用率作为所述集群的工作负荷。

9.一种服务器，其特征在于，包括：

处理器；

用于存储所述处理器可执行的计算机程序的存储器；其中，所述处理器被配置为执行所述存储器中的计算机程序，以实现如权利要求1～6任一项所述方法的步骤。

10.一种存储介质，其特征在于，当所述存储介质中的可执行的计算机程序由服务器的处理器执行时，使得服务器能够执行如权利要求1～6任一项所述方法的步骤。