CN116954878A - 容器集群的管理方法、装置、设备、存储介质及程序产品 - Google Patents

Abstract

本申请实施例提供了一种容器集群的管理方法、装置、设备、存储介质及程序产品，涉及人工智能领域、云技术领域、地图领域等，应用场景包括但不限于容器集群扩容等场景。该方法包括：获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及各节点包括的容器组的相关信息；基于至少一个虚拟工作负载的相关信息，构建至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组；基于各节点的相关信息，以及各节点包括的容器组的相关信息，确定第一缓存数据；若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则将待测容器集群的节点数量进行调整；提升了确定待测容器集群是否能部署新增业务的准确度。

Description

容器集群的管理方法、装置、设备、存储介质及程序产品

技术领域

本申请涉及计算机技术领域，具体而言，本申请涉及一种容器集群的管理方法、装置、设备、存储介质及程序产品。

背景技术

现有技术中Kubernetes集群是一种容器集群，Kubernetes集群可以包括多个Node(节点)，每个Node可以包括多个Pod(容器组)，每个Pod可以包括多个容器。由于在Kubernetes集群中部署新增业务之前，现有技术不能准确的估算出Kubernetes集群中每个节点的剩余可用资源是否能满足新增业务需求，也不能准确的确定是否需要对Kubernetes集群进行扩容，即增加Kubernetes集群的Node数量，从而可能导致新增业务部署后无法运行，以及新增业务的作业失败。

发明内容

本申请针对现有的方式的缺点，提出一种容器集群的管理方法、装置、设备、计算机可读存储介质及计算机程序产品，用于解决如何提升确定Kubernetes集群是否能部署新增业务的准确度的问题。

第一方面，本申请提供了一种容器集群的管理方法，包括：

获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及各节点包括的容器组的相关信息；

基于至少一个虚拟工作负载的相关信息，构建至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组；

基于各节点的相关信息，以及各节点包括的容器组的相关信息，确定第一缓存数据；

若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则将待测容器集群的节点数量进行调整。

在一个实施例中，获取至少一种虚拟节点的相关信息，至少一种虚拟节点的相关信息包括至少一种虚拟节点的数量；

基于至少一种虚拟节点的相关信息，构建至少一种虚拟节点对应的各虚拟节点；

基于至少一种虚拟节点的数量、各节点的相关信息，以及各节点包括的容器组的相关信息，确定第二缓存数据；

若基于第二缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点和各虚拟节点，则将至少一种虚拟节点的数量进行累加处理，并更新至少一种虚拟节点的数量；

重复执行基于至少一种虚拟节点的数量、各节点的相关信息，以及各节点包括的容器组的相关信息，确定第二缓存数据、若基于第二缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点和各虚拟节点，则将至少一种虚拟节点的数量进行累加处理，并更新至少一种虚拟节点的数量，直至得到至少一种虚拟节点的更新后的数量，以及至少一种虚拟节点对应的新增的虚拟节点，且任一虚拟容器组能调度到新增的虚拟节点，则将至少一种虚拟节点的更新后的数量确定为待测容器集群的新增节点数量。

在一个实施例中，获取至少一种虚拟节点的相关信息；

基于至少一种虚拟节点的相关信息，构建至少一种虚拟节点对应的各虚拟节点，并确定第三缓存数据；

若基于第三缓存数据确定至少一个虚拟容器组中任一虚拟容器组能调度到各虚拟节点，则基于至少一种虚拟节点的相关信息，以及至少一个虚拟工作负载的相关信息，构建新的容器集群。

在一个实施例中，至少一个虚拟工作负载的相关信息包括至少一个虚拟工作负载中每个虚拟工作负载的名称、每个虚拟工作负载中虚拟容器组的数量、每个虚拟工作负载中虚拟容器组的相关信息；基于至少一个虚拟工作负载的相关信息，构建至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组，包括：

基于每个虚拟工作负载的名称、每个虚拟工作负载中虚拟容器组的数量、每个虚拟工作负载中虚拟容器组的相关信息，构建每个虚拟工作负载中至少一个虚拟容器组，每个虚拟工作负载中虚拟容器组的相关信息包括所需资源量和调度约束中至少一项。

在一个实施例中，各节点的相关信息包括各节点的标签和各节点的资源量，各节点包括的容器组的相关信息包括各节点中容器组的标签和各节点中容器组的资源量；基于各节点的相关信息，以及各节点包括的容器组的相关信息，确定第一缓存数据，包括：

基于各节点的标签、各节点的资源量、各节点中容器组的标签和各节点中容器组的资源量，确定第一缓存数据。

在一个实施例中，若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到所述各节点，则将待测容器集群的节点数量进行调整，包括：

通过预设调度算法，若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组的所需资源量大于各节点的资源量、各节点的标签不满足任一虚拟容器组的调度约束、各节点中容器组的标签不满足任一虚拟容器组的调度约束中的任意一项，则确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，并增加待测容器集群的节点数量。

在一个实施例中，待测容器集群为Kubernetes集群，第一缓存数据为调度器缓存数据。

第二方面，本申请提供了一种容器集群的管理装置，包括：

第一处理模块，用于获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及各节点包括的容器组的相关信息；

第二处理模块，用于基于至少一个虚拟工作负载的相关信息，构建所述至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组；

第三处理模块，用于基于各节点的相关信息，以及各节点包括的容器组的相关信息，确定第一缓存数据；

第四处理模块，用于若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则将待测容器集群的节点数量进行调整。

第三方面，本申请提供了一种电子设备，包括：处理器、存储器和总线；

总线，用于连接处理器和存储器；

存储器，用于存储操作指令；

处理器，用于通过调用操作指令，执行本申请第一方面的容器集群的管理方法。

第四方面，本申请提供了一种计算机可读存储介质，存储有计算机程序，计算机程序被用于执行本申请第一方面的容器集群的管理方法。

第五方面，本申请提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现本申请第一方面中容器集群的管理方法的步骤。

本申请实施例提供的技术方案，至少具有如下有益效果：

获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及各节点包括的容器组的相关信息；基于至少一个虚拟工作负载的相关信息，构建至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组；基于各节点的相关信息，以及各节点包括的容器组的相关信息，确定第一缓存数据；若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则将待测容器集群的节点数量进行调整；如此，可以准确的确定待测容器集群(例如Kubernetes集群)能不能容纳虚拟工作负载，若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则准确的确定待测容器集群中各节点的剩余可用资源是不能满足虚拟工作负载(新增业务)需求，从而准确的确定要对待测容器集群进行扩容，提升了确定待测容器集群是否能部署新增业务的准确度。

附图说明

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

图1为本申请实施例提供的容器集群的管理***架构示意图；

图2为本申请实施例提供的一种容器集群的管理方法的流程示意图；

图3为本申请实施例提供的容器集群的管理的示意图；

图4为本申请实施例提供的另一种容器集群的管理方法的流程示意图；

图5为本申请实施例提供的一种容器集群的管理装置的结构示意图；

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

具体实施方式

下面结合本申请中的附图描述本申请的实施例。应理解，下面结合附图所阐述的实施方式，是用于解释本申请实施例的技术方案的示例性描述，对本申请实施例的技术方案不构成限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“A和/或B”指示实现为“A”，或者实现为“B”，或者实现为“A和B”。

可以理解的是，在本申请的具体实施方式中，涉及到容器集群的管理数据，当本申请以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

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

本申请实施例是容器集群的管理***提供的一种容器集群的管理方法，该容器集群的管理方法涉及人工智能、云技术、地图领域等领域。示例性的，本申请实施例中所涉及的Kubernetes集群是云技术中的云计算技术。该容器集群的管理应用场景包括但不限于容器集群扩容等场景，容器集群扩容场景例如Kubernetes集群扩容场景等。

人工智能(Artificial Intelligence，AI)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用***。换句话说，人工智能是计算机科学的一个综合技术，它企图了解智能的实质，并生产出一种新的能以人类智能相似的方式做出反应的智能机器。人工智能也就是研究各种智能机器的设计原理与实现方法，使机器具有感知、推理与决策的功能。

人工智能技术是一门综合学科，涉及领域广泛，既有硬件层面的技术也有软件层面的技术。人工智能基础技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理技术、操作/交互***、机电一体化等技术。人工智能软件技术主要包括计算机视觉技术、语音处理技术、自然语言处理技术以及机器学习/深度学习、自动驾驶、智慧交通等几大方向。

智能交通***(Intelligent Traffic System，ITS)又称智能运输***(Intelligent Transportation System)，是将先进的科学技术(信息技术、计算机技术、数据通信技术、传感器技术、电子控制技术、自动控制理论、运筹学、人工智能等)有效地综合运用于交通运输、服务控制和车辆制造，加强车辆、道路、使用者三者之间的联系，从而形成一种保障安全、提高效率、改善环境、节约能源的综合运输***。

为了更好的理解及说明本申请实施例的方案，下面对本申请实施例中所涉及到的一些技术用语进行简单说明。

Kubernetes集群：Kubernetes集群是为生产环境而设计的容器调度管理***，对于负载均衡、服务发现、高可用、滚动升级、自动伸缩等容器云平台的功能要求有原生支持；一个Kubernetes集群是由分布式存储(etcd)、服务节点(节点，Node)和控制节点(Master)构成，所有的集群状态都保存在etcd中，Master上则运行集群的管理控制模块，Node是真正运行应用容器的主机节点。

工作负载：容器集群，例如Kubernetes集群，工作负载在Kubernetes集群中通常指Deployment、Statefulset等，工作负载是一组Pod的集合，在工作负载描述中，通过副本数来指定需要创建多少个同样描述的Pod。工作负载可以是工作负载资源。

调度器：Kubernetes集群中的原生调度器叫kube-scheduler。

仿真调度：模拟kube-scheduler的行为，但不会在容器集群内创建真实的工作负载和Pod去调度运行，而是根据容器集群当前状态对输入的工作负载，进行虚拟Pod的调度算法执行。

Pod：Pod(容器组)是容器集群的调度单位，例如Kubernetes集群的调度单位；通常Pod的描述文件中会声明Pod所需要的中央处理器CPU、内存、临时存储等资源量，以及节点选择、亲和与反亲和、拓扑打散等高级的调度约束条件。

本申请实施例提供的方案涉及人工智能技术，下面以具体的实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

为了更好的理解本申请实施例提供的方案，下面结合具体的一个应用场景对该方案进行说明。

在一个实施例中，图1中示出了本申请实施例所适用的一种容器集群的管理***的架构示意图，可以理解的是，本申请实施例所提供的容器集群的管理方法可以适用于但不限于应用于如图1所示的应用场景中。

本示例中，如图1所示，该示例中的容器集群的管理***的架构可以包括但不限于终端10、服务器20、网络30和数据库40。终端10、服务器20和数据库40之间可以通过网络30进行交互。终端10发送新增业务需求给服务器20，其中，新增业务需求中描述的新增业务对应至少一个虚拟工作负载；服务器20获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及各节点包括的容器组的相关信息；服务器20基于至少一个虚拟工作负载的相关信息，构建至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组；服务器20基于各节点的相关信息，以及各节点包括的容器组的相关信息，确定第一缓存数据；服务器20若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则将待测容器集群的节点数量进行调整，并将调整后的结果发送给终端10和数据库40，其中，调整后的结果包括增加待测容器集群的节点数量。

可理解，上述仅为一种示例，本实施例在此不作限定。

其中，终端可以是智能手机(如Android手机、iOS手机等)、手机模拟器、平板电脑、笔记本电脑、数字广播接收器、MID(Mobile Internet Devices，移动互联网设备)、PDA(个人数字助理)等。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器或服务器集群。

云计算(cloud computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用***能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。

作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS(Infrastructure as a Service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作***)、存储设备、网络设备。

按照逻辑功能划分，在IaaS(Infrastructure as a Service，基础设施即服务)层上可以部署PaaS(Platform as a Service，平台即服务)层，PaaS层之上再部署SaaS(Software as a Service，软件即服务)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、web容器等。SaaS为各式各样的业务软件，如web门户网站、***器等。一般来说，SaaS和PaaS相对于IaaS是上层。

所谓人工智能云服务，一般也被称作是AIaaS(AIas a Service，中文为“AI即服务”)。这是目前主流的一种人工智能平台的服务方式，具体来说AIaaS平台会把几类常见的AI服务进行拆分，并在云端提供独立或者打包的服务。这种服务模式类似于开了一个AI主题商城：所有的开发者都可以通过API接口的方式来接入使用平台提供的一种或者是多种人工智能服务，部分资深的开发者还可以使用平台提供的AI框架和AI基础设施来部署和运维自已专属的云人工智能服务。

上述网络可以包括但不限于：有线网络，无线网络，其中，该有线网络包括：局域网、城域网和广域网，该无线网络包括：蓝牙、Wi-Fi及其他实现无线通信的网络。具体也可基于实际应用场景需求确定，在此不作限定。

参见图2，图2示出了本申请实施例提供的一种容器集群的管理方法的流程示意图，其中，该方法可以由任一电子设备执行，如可以是服务器，作为一可选实施方式，该方法可以由服务器执行，为了描述方便，在下文的一些可选实施例的描述中，将以服务器作为该方法执行主体为例进行说明。如图2所示，本申请实施例提供的容器集群的管理方法包括如下步骤：

S201，获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及各节点包括的容器组的相关信息。

具体地，至少一个虚拟工作负载的相关信息包括至少一个虚拟工作负载中每个虚拟工作负载的名称、每个虚拟工作负载中虚拟容器组的数量、每个虚拟工作负载中虚拟容器组的相关信息。待测容器集群的各节点的相关信息包括各节点的标签和各节点的资源量，待测容器集群的各节点包括的容器组的相关信息包括各节点中容器组的标签和各节点中容器组的资源量。虚拟工作负载可以是虚拟工作负载资源。

在一个实施例中，通过仿真调度控制器，获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及各节点包括的容器组的相关信息；其中，仿真调度控制器是区别于Kubernetes集群中原生调度器kube-scheduler的额外的控制器，仿真调度控制器可以设置在Kubernetes集群中。

需要说明的是，新增业务可以对应虚拟工作负载，虚拟工作负载不是真实的工作负载，虚拟工作负载是虚拟资源，仿真调度控制器通过虚拟工作负载，进行仿真，确定待测容器集群(例如容器集群为Kubernetes集群)是否能容纳虚拟工作负载，即确定待测容器集群中各节点的剩余可用资源是否能满足虚拟工作负载(新增业务)需求。

在一个实施例中，如图3所示，多个虚拟工作负载的相关信息可以通过虚拟工作负载描述列表的方式展现，虚拟工作负载描述列表中的虚拟工作负载1、虚拟工作负载2和虚拟工作负载x为不同的虚拟工作负载；其中，每个虚拟工作负载的相关信息包括该虚拟工作负载的名称(例如虚拟工作负载1)、副本数(虚拟容器组的数量)和虚拟Pod模板描述(虚拟容器组的相关信息)，副本数为必填项。

S202，基于至少一个虚拟工作负载的相关信息，构建至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组。

具体地，每个虚拟工作负载可以包括多个虚拟容器组，即虚拟Pod。由于虚拟工作负载不是真实的工作负载，因此，虚拟Pod也不是真实的Pod，虚拟Pod是虚拟资源。

虚拟容器组(虚拟Pod)的相关信息可以包括虚拟Pod描述文件。虚拟Pod描述文件是一个指定格式的yaml文件，虚拟Pod描述文件里面声明了虚拟Pod运行所需的中央处理器CPU、内存、临时存储等资源量，以及调度约束条件。若待测容器集群中一个节点上剩余的资源量满足某虚拟Pod声明所需的资源量，则该节点可以作为该虚拟Pod调度的候选节点，并再确定该节点是否满足该虚拟Pod的调度约束条件。

虚拟Pod描述文件中声明的调度约束条件包括：具体选择必须将虚拟Pod调度到哪一类节点(节点选择)、虚拟Pod尽量亲和到哪一类节点(虚拟Pod和节点之间亲和)、虚拟Pod和哪一类Pod尽量调度到相同节点(虚拟Pod和Pod之间亲和)、虚拟Pod和哪一类Pod尽量不要调度到相同节点(虚拟Pod和Pod之间反亲和)、在某个拓扑区域内只能有几个同类型的Pod(拓扑打散)、其他按照Kubernetes调度插件规范实现的自定义调度约束条件等。

在一个实施例中，虚拟Pod上通常都打有标签(例如，app＝wechat)，可以指定具备一些标签的虚拟Pod为同种类型的虚拟Pod，通常不会直接在容器集群里面提交创建虚拟Pod，可以通过比虚拟Pod更高级的虚拟工作负载(例如，deployment、statefulset等)来创建N个同种类型的虚拟Pod，N为虚拟Pod的副本数，也就是一个虚拟工作负载的每个副本都是一个虚拟Pod。

在一个实施例中，节点上可以打标签(例如，region＝south，zone＝shenzhen，hostname＝node1)，虚拟Pod可以指定选择必须在具备某标签的节点上(例如，一个虚拟Pod可以指定该虚拟Pod必须被调度到zone＝shenzhen的节点上)，或者是尽量亲和到具备某标签的节点上。节点的标签的取值可以不同，例如，标签zone取值可以是shenzhen，也可以是guangzhou，还可以是dongguan。

拓扑打散就是针对同类型的Pod，要求在指定的节点的标签上打散分布，使得这个标签不同取值情况下，调度得到的Pod数量偏差不超过指定数值；例如，同类型的Pod共有3个，指定节点的标签zone要求不同取值情况下，调度得到的Pod数量偏差不超过1，假设容器集群内所有节点zone标签的取值为shenzhen、guangzhou或dongguan，则这3个pod经过调度后就只能是zone＝shenzhen节点上得到1个pod、zone＝guangzhou节点上得到1个Pod、zone＝dongguan节点上得到1个Pod，而不会出现zone＝shenzhen的节点上得到2个Pod或者3个Pod的情况，因为这样就是2:1:0或者3:0:0，偏差2-0＝2、3-0＝3不满足调度约束条件中的拓扑打散。

在一个实施例中，容器集群中的一个节点分到一个虚拟Pod后，就会从节点状态(节点的相关信息)中减掉虚拟Pod所声明的资源量；例如，一个节点可以有8核CPU和32G内存的资源量，一个虚拟Pod声明1核2G，通过仿真调度控制器，分配到该节点后，该节点就会更新自己的节点状态，减掉虚拟Pod所声明的1核2G，则该节点还剩7核30G可以被其他的虚拟Pod所使用。

S203，基于各节点的相关信息，以及各节点包括的容器组的相关信息，确定第一缓存数据。

具体地，第一缓存数据可以为调度器缓存数据，调度器缓存数据可以和容器集群中调度器kube-scheduler的SchedulerCache相同。

S204，若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则将待测容器集群的节点数量进行调整。

具体地，若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组能调度到各节点，则待测容器集群的节点数量不用进行调整，从而准确的确定该待测容器集群中各节点的剩余可用资源能满足虚拟工作负载需求，并准确的确定不用对待测容器集群进行扩容。

若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则将待测容器集群的节点数量进行调整，从而准确的确定该待测容器集群中各节点的剩余可用资源不能满足虚拟工作负载需求，并准确的确定需要对待测容器集群进行扩容。

本申请实施例中，获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及各节点包括的容器组的相关信息；基于至少一个虚拟工作负载的相关信息，构建至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组；基于各节点的相关信息，以及各节点包括的容器组的相关信息，确定第一缓存数据；若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则将待测容器集群的节点数量进行调整；如此，可以准确的确定待测容器集群(例如Kubernetes集群)能不能容纳虚拟工作负载，若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则准确的确定待测容器集群中各节点的剩余可用资源是不能满足虚拟工作负载(新增业务)需求，从而准确的确定要对待测容器集群进行扩容，提升了确定待测容器集群是否能部署新增业务的准确度。

在一个实施例中，容器集群的管理方法包括如下步骤A1-A4：

步骤A1，获取至少一种虚拟节点的相关信息，至少一种虚拟节点的相关信息包括至少一种虚拟节点的数量。

具体地，通过仿真调度控制器，获取至少一种虚拟节点的相关信息，至少一种虚拟节点的相关信息包括至少一种虚拟节点的数量。

需要说明的是，虚拟工作负载不是真实的工作负载，虚拟节点不是真实的虚拟节点，虚拟节点是虚拟资源。仿真调度控制器通过虚拟工作负载和虚拟节点，进行仿真，确定待测容器集群中各节点的剩余可用资源和各虚拟节点的可用资源是否能满足虚拟工作负载需求；若确定待测容器集群中各节点的剩余可用资源和各虚拟节点的可用资源能满足虚拟工作负载需求，则基于各虚拟节点的种类和数量，对待测容器集群进行扩容，即可以在待测容器集群中新增与虚拟节点类型相同且与虚拟节点数量相同的节点。

步骤A2，基于至少一种虚拟节点的相关信息，构建至少一种虚拟节点对应的各虚拟节点。

在一个实施例中，如图3所示，多种虚拟节点的相关信息可以通过虚拟节点描述列表的方式展现，虚拟节点描述列表中的虚拟节点描述1、虚拟节点描述2、虚拟节点描述y为不同种类的虚拟节点的相关信息。每种虚拟节点的相关信息包括该种虚拟节点的数量和该种虚拟节点模板描述。虚拟节点的数量为选填项，若输入了数量，某种虚拟节点的数量是指定的，则构建指定数量的虚拟节点；若没输入数量，某种虚拟节点数量没有指定，则将该种虚拟节点的初始数量自动设置为0，仿真调度控制器可以自动对虚拟节点的数量进行增长，来满足虚拟工作负载的调度需求。虚拟节点模板描述可以包括虚拟节点的标签、虚拟节点的资源量等；例如虚拟节点模板描述为16核36G、32核64G等。

步骤A3，基于至少一种虚拟节点的数量、各节点的相关信息，以及各节点包括的容器组的相关信息，确定第二缓存数据。

具体地，第二缓存数据可以为调度器缓存数据，调度器缓存数据里面是结构化的数据。调度器缓存数据包含节点信息(至少一种虚拟节点的数量和各节点的相关信息)和已经存在的Pod的信息(各节点包括的容器组的相关信息)，调度算法会读取调度器缓存数据里的数据，来计算虚拟Pod能不能在虚拟节点或各节点上调度；调度算法是kubernetes集群原生具备的，调度算法用来计算虚拟节点的资源或各节点剩余的资源能不能满足正准备调度的虚拟Pod，虚拟节点上的标签或各节点上的标签能不能满足虚拟Pod的调度约束，已经存在的Pod中有哪些Pod在各节点上，已经存在的Pod和正准备调度的虚拟Pod之间是否满足亲和、反亲和等调度约束条件。调度算法会遍历虚拟节点和各节点，找出虚拟节点或各节点中哪些满足虚拟Pod所需的资源和调度约束条件，从中选定一个虚拟节点或一个节点作为一个虚拟Pod最终的调度结果。若虚拟节点或各节点都不满足，则说明该虚拟Pod调度失败。

步骤A4，若基于第二缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点和各虚拟节点，则将至少一种虚拟节点的数量进行累加处理，并更新至少一种虚拟节点的数量。

重复执行步骤A3(基于至少一种虚拟节点的数量、各节点的相关信息，以及各节点包括的容器组的相关信息，确定第二缓存数据)、步骤A4(若基于第二缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点和各虚拟节点，则将至少一种虚拟节点的数量进行累加处理，并更新至少一种虚拟节点的数量)，直至得到至少一种虚拟节点的更新后的数量，以及至少一种虚拟节点对应的新增的虚拟节点，且任一虚拟容器组能调度到新增的虚拟节点，则将至少一种虚拟节点的更新后的数量确定为待测容器集群的新增节点数量。

具体地，累加处理，例如将虚拟节点的数量加1，即增加一个虚拟节点。又例如，一种虚拟节点的数量为1，经过3次累加处理后，新增的该种虚拟节点的数量为3，该种虚拟节点的更新后的数量为1+3＝4，因此，待测容器集群的新增节点数量为4，即对待测容器集群进行扩容，在待测容器集群中增加4个节点。

本申请实施例中，可以准确的确定待测容器集群(例如Kubernetes集群)和虚拟节点能不能容纳虚拟工作负载，若确定待测容器集群中各节点的剩余可用资源和各虚拟节点的可用资源能满足虚拟工作负载需求，则基于各虚拟节点的种类和数量，对待测容器集群进行扩容，从而提升了对待测容器集群进行扩容的准确度。

在一个实施例中，容器集群的管理方法包括如下步骤B1-B3：

步骤B1，获取至少一种虚拟节点的相关信息。

具体地，如图3所示，多种虚拟节点的相关信息可以通过虚拟节点描述列表的方式展现。

步骤B2，基于至少一种虚拟节点的相关信息，构建至少一种虚拟节点对应的各虚拟节点，并确定第三缓存数据。

具体地，第三缓存数据可以为调度器缓存数据，调度器缓存数据里面是结构化的数据。调度器缓存数据包含至少一种虚拟节点的相关信息，调度算法会读取调度器缓存数据里的数据，来计算虚拟Pod能不能在虚拟节点上调度；调度算法是kubernetes集群原生具备的，调度算法用来计算虚拟节点的资源能不能满足正准备调度的虚拟Pod，虚拟节点上的标签能不能满足虚拟Pod的调度约束。调度算法会遍历虚拟节点，找出虚拟节点中哪些满足虚拟Pod所需的资源和调度约束条件，从中选定一个虚拟节点作为一个虚拟Pod最终的调度结果。若虚拟节点都不满足，则说明该虚拟Pod调度失败。

步骤B3，若基于第三缓存数据确定至少一个虚拟容器组中任一虚拟容器组能调度到各虚拟节点，则基于至少一种虚拟节点的相关信息，以及至少一个虚拟工作负载的相关信息，构建新的容器集群。

在一个实施例中，若需要新建一个容器集群，则仿真调度控制器通过虚拟工作负载和虚拟节点，进行仿真，确定虚拟节点的可用资源是否能满足虚拟工作负载需求；若虚拟节点的可用资源能满足虚拟工作负载需求，则基于虚拟节点的种类和数量，进行机器(例如服务器)采购，新建一个容器集群，该新建的容器集群中的节点的可用资源能容纳虚拟工作负载对应的业务量。

本申请实施例中，可以准确的确定虚拟节点能不能容纳虚拟工作负载，若确定虚拟节点的可用资源能满足虚拟工作负载需求，则基于虚拟节点的种类和数量，构建新的容器集群，从而提升了构建新的容器集群的准确度。

在一个实施例中，至少一个虚拟工作负载的相关信息包括至少一个虚拟工作负载中每个虚拟工作负载的名称、每个虚拟工作负载中虚拟容器组的数量、每个虚拟工作负载中虚拟容器组的相关信息；基于至少一个虚拟工作负载的相关信息，构建至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组，包括：

基于每个虚拟工作负载的名称、每个虚拟工作负载中虚拟容器组的数量、每个虚拟工作负载中虚拟容器组的相关信息，构建每个虚拟工作负载中至少一个虚拟容器组，每个虚拟工作负载中虚拟容器组的相关信息包括所需资源量和调度约束中至少一项。

具体地，虚拟容器组(虚拟Pod)的相关信息可以包括虚拟Pod描述文件。虚拟Pod描述文件是一个指定格式的yaml文件，虚拟Pod描述文件里面声明了虚拟Pod运行所需的中央处理器CPU、内存、临时存储等资源量，以及调度约束条件(调度约束)。若待测容器集群中一个节点上剩余的资源量满足某虚拟Pod声明所需的资源量，则该节点可以作为该虚拟Pod调度的候选节点，并再确定该节点是否满足该虚拟Pod的调度约束条件。

虚拟Pod描述文件中声明的调度约束条件包括：具体选择必须将虚拟Pod调度到哪一类节点(节点选择)、虚拟Pod尽量亲和到哪一类节点(虚拟Pod和节点之间亲和)、虚拟Pod和哪一类Pod尽量调度到相同节点(虚拟Pod和Pod之间亲和)、虚拟Pod和哪一类Pod尽量不要调度到相同节点(虚拟Pod和Pod之间反亲和)、在某个拓扑区域内只能有几个同类型的Pod(拓扑打散)中的至少一项。

在一个实施例中，各节点的相关信息包括各节点的标签和各节点的资源量，各节点包括的容器组的相关信息包括各节点中容器组的标签和各节点中容器组的资源量；基于各节点的相关信息，以及各节点包括的容器组的相关信息，确定第一缓存数据，包括：

基于各节点的标签、各节点的资源量、各节点中容器组的标签和各节点中容器组的资源量，确定第一缓存数据。

具体地，第一缓存数据可以为调度器缓存数据，调度器缓存数据里面是结构化的数据。调度器缓存数据包含节点信息(各节点的相关信息)和已经存在的Pod的信息(各节点包括的容器组的相关信息)，调度算法会读取调度器缓存数据里的数据，来计算虚拟Pod能不能在各节点上调度；调度算法是kubernetes集群原生具备的，调度算法用来计算各节点剩余的资源能不能满足正准备调度的虚拟Pod，各节点上的标签能不能满足虚拟Pod的调度约束，已经存在的Pod中有哪些Pod在各节点上，已经存在的Pod和正准备调度的虚拟Pod之间是否满足亲和、反亲和等调度约束条件。调度算法会遍历各节点，找出各节点中哪些满足虚拟Pod所需的资源和调度约束条件，从中选定一个节点作为一个虚拟Pod最终的调度结果。若各节点都不满足，则说明该虚拟Pod调度失败。

在一个实施例中，若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到所述各节点，则将待测容器集群的节点数量进行调整，包括：

通过预设调度算法，若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组的所需资源量大于各节点的资源量、各节点的标签不满足任一虚拟容器组的调度约束、各节点中容器组的标签不满足任一虚拟容器组的调度约束中的任意一项，则确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，并增加待测容器集群的节点数量。

具体地，节点的资源量表示节点的剩余的资源，也就是节点的可用资源。

若基于第一缓存数据确定一个虚拟容器组的所需资源量大于一个节点的资源量，或该节点的标签不满足该虚拟容器组的调度约束，则确定该虚拟容器组不能调度到该节点。

若基于第一缓存数据确定一个虚拟容器组的所需资源量小于或等于一个节点的资源量，且该节点的标签满足该虚拟容器组的调度约束，则确定该虚拟容器组能调度到该节点。

在一个实施例中，待测容器集群为Kubernetes集群，第一缓存数据为调度器缓存数据。

为了更好的理解本申请实施例所提供的方法，下面结合具体应用场景的示例对本申请实施例的方案进行进一步说明。

本申请实施例所提供的方法可以应用到容器集群扩容场景、容器集群的新建场景等，容器集群扩容场景例如Kubernetes集群扩容场景，容器集群的新建场景例如Kubernetes集群的新建场景。

在一个具体应用场景实施例中，例如容器集群扩容场景，参见图4，示出了一种容器集群的管理方法的处理流程，其中，该方法可以由任一电子设备执行，如可以是服务器，作为一可选实施方式，该方法可以由服务器执行，为了描述方便，在下文的一些可选实施例的描述中，将以服务器作为该方法执行主体为例进行说明。如图4所示，本申请实施例提供的容器集群的管理方法的处理流程包括如下步骤：

S401，服务器获取仿真调度任务。

具体地，仿真调度任务包括虚拟工作负载描述列表、仿真策略和虚拟节点描述列表，或者，仿真调度任务包括虚拟工作负载描述列表和仿真策略。如图3所示，多个虚拟工作负载的相关信息可以通过虚拟工作负载描述列表的方式展现，多种虚拟节点的相关信息可以通过虚拟节点描述列表的方式展现，其中，虚拟节点模板描述可以与Kubernetes Node定义保持一致。仿真策略包括：完全基于容器集群(例如S201-S204)、完全基于虚拟节点(例如步骤B1-B3)、同时基于容器集群和虚拟节点(例如步骤A1-A4)中的任一项。

S402，服务器将仿真调度任务输入至仿真调度控制器的虚拟资源准备模块，得到虚拟资源。

具体地，虚拟资源可以是虚拟Pod、虚拟节点等。仿真调度控制器运行在Kubernetes集群中，将仿真调度任务输入至仿真调度控制器的虚拟资源准备模块，虚拟资源准备模块会按照仿真调度任务中的虚拟工作负载描述列表，创建指定数量、指定资源规格、指定调度约束条件的虚拟Pod列表，即多个虚拟Pod。可以选择的将仿真调度任务中的虚拟节点描述列表输入至仿真调度控制器的虚拟资源准备模块，若虚拟节点描述列表中有虚拟节点且有指定数量，则创建指定数量的虚拟节点列表，即多个虚拟节点。

其中，仿真调度控制器可以是一个单次运行的二进制工具。

S403，通过仿真调度控制器的本地Cache准备模块，得到调度器缓存数据。

具体地，仿真调度器的本地Cache准备模块通过容器集群API(ApplicationProgramming Interface，应用程序编程接口)，采集容器集群的状态信息，容器集群的状态信息包括容器集群的各节点的相关信息、各节点包括的容器组的相关信息、虚拟节点的相关信息等。容器集群的状态信息可以用于构建仿真调度器运行调度算法时，所需要的调度器缓存数据。针对不同的仿真策略：

(1)若完全基于容器集群(例如S201-S204)，则基于容器集群的各节点的相关信息和各节点包括的容器组的相关信息，构建和容器调度器kube-scheduler一致的SchedulerCache，即第一缓存数据。

(2)若完全基于虚拟节点(例如步骤B1-B3)，则构建空的Cache(调度器缓存数据)，并且按照使用的虚拟节点的数量，逐个添加虚拟节点到Cache中；虚拟节点的数量为0，则Cache为空。

S404，基于虚拟资源和调度器缓存数据，通过仿真调度控制器的调度算法执行模块，得到虚拟资源中每个虚拟Pod的调度结果。

具体地，仿真调度控制器将仿真策略、虚拟Pod列表、调度器缓存数据传递给仿真调度控制器的调度算法执行模块，调度算法执行模块会对虚拟Pod列表中的每个虚拟Pod依次执行调度算法，并记录每个虚拟Pod的调度结果。

S405，若确定某个虚拟Pod满足预设第一条件，则通过仿真调度控制器的循环控制模块，对虚拟资源中虚拟节点的数量进行累加处理，并转到步骤S403处理；若确定某个虚拟Pod满足预设第二条件，则转到步骤S406处理。

具体地，预设第一条件包括若某个虚拟Pod的调度结果为调度失败、仿真调度任务中包括虚拟节点、仿真策略有使用虚拟节点，且虚拟节点模板描述中没有指定虚拟节点的数量。预设第二条件包括这批虚拟工作负载的所有虚拟Pod都调度成功、仿真调度任务没有包括虚拟节点、仿真调度策略为完全基于容器集群、虚拟节点模板描述中指定了虚拟节点数量中的至少一项。

若一批虚拟工作负载有调度失败的虚拟Pod、仿真调度任务中包括虚拟节点、仿真策略有使用虚拟节点，且虚拟节点模板描述中没有指定虚拟节点的数量，则通过仿真调度控制器的循环控制模块对虚拟节点的数量从0开始，逐次加1后，赋值给当前使用的虚拟节点数量，然后仿真调度控制器重新从步骤S403开始执行，重新构建调度器缓存数据和执行调度算法。循环控制模块实现了对满足输入这批虚拟工作负载所需扩容节点数量的估算，从而可以指导容器集群扩容和机器采购；若这批虚拟工作负载的所有虚拟Pod都调度成功、仿真调度任务没有包括虚拟节点、仿真调度策略为完全基于容器集群，或虚拟节点模板描述中指定了虚拟节点数量，则循环控制结束，并统计每个虚拟工作负载的调度结果。

S406，仿真调度控制器输出仿真调度任务结果。

具体地，针对每个虚拟工作负载，仿真调度任务结果包括：该虚拟工作负载的名称、该虚拟工作负载中所有调度成功的虚拟Pod的数量、该虚拟工作负载中所有调度失败的虚拟Pod的数量、调度成功的虚拟Pod的节点分布、调度失败的原因等。

应用本申请实施例，至少具有如下有益效果：

通过仿真调度控制器，实现了对容器集群进行扩容或新建容器集群，提升了确定容器集群是否能部署新增业务或新建容器集群的准确度。通过仿真调度控制器，实现了在部署新增业务之前，能够较为准确地估算出容器集群是否能满足新增业务需求，容器集群是否需要扩容，从而有效地避免新增业务部署后，新增业务无法运行导致作业失败的问题，并且可以指导容器集群扩容，避免盲目的机器(容器集群中的服务器)采购。

本申请实施例还提供了一种容器集群的管理装置，该容器集群的管理装置的结构示意图如图5所示，容器集群的管理装置50，包括第一处理模块501、第二处理模块502、第三处理模块503和第四处理模块504。

第一处理模块501，用于获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及各节点包括的容器组的相关信息；

第二处理模块502，用于基于至少一个虚拟工作负载的相关信息，构建所述至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组；

第三处理模块503，用于基于各节点的相关信息，以及各节点包括的容器组的相关信息，确定第一缓存数据；

第四处理模块504，用于若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则将待测容器集群的节点数量进行调整。

在一个实施例中，第一处理模块501，还用于：

获取至少一种虚拟节点的相关信息，至少一种虚拟节点的相关信息包括至少一种虚拟节点的数量；

基于至少一种虚拟节点的相关信息，构建至少一种虚拟节点对应的各虚拟节点；

基于至少一种虚拟节点的数量、各节点的相关信息，以及各节点包括的容器组的相关信息，确定第二缓存数据；

若基于第二缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点和各虚拟节点，则将至少一种虚拟节点的数量进行累加处理，并更新至少一种虚拟节点的数量；

重复执行基于至少一种虚拟节点的数量、各节点的相关信息，以及各节点包括的容器组的相关信息，确定第二缓存数据、若基于第二缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点和各虚拟节点，则将至少一种虚拟节点的数量进行累加处理，并更新至少一种虚拟节点的数量，直至得到至少一种虚拟节点的更新后的数量，以及至少一种虚拟节点对应的新增的虚拟节点，且任一虚拟容器组能调度到新增的虚拟节点，则将至少一种虚拟节点的更新后的数量确定为待测容器集群的新增节点数量。

在一个实施例中，第一处理模块501，还用于：

获取至少一种虚拟节点的相关信息；

基于至少一种虚拟节点的相关信息，构建至少一种虚拟节点对应的各虚拟节点，并确定第三缓存数据；

若基于第三缓存数据确定至少一个虚拟容器组中任一虚拟容器组能调度到各虚拟节点，则基于至少一种虚拟节点的相关信息，以及至少一个虚拟工作负载的相关信息，构建新的容器集群。

在一个实施例中，至少一个虚拟工作负载的相关信息包括至少一个虚拟工作负载中每个虚拟工作负载的名称、每个虚拟工作负载中虚拟容器组的数量、每个虚拟工作负载中虚拟容器组的相关信息；第二处理模块502，具体用于：

基于每个虚拟工作负载的名称、每个虚拟工作负载中虚拟容器组的数量、每个虚拟工作负载中虚拟容器组的相关信息，构建每个虚拟工作负载中至少一个虚拟容器组，每个虚拟工作负载中虚拟容器组的相关信息包括所需资源量和调度约束中至少一项。

在一个实施例中，各节点的相关信息包括各节点的标签和各节点的资源量，各节点包括的容器组的相关信息包括各节点中容器组的标签和各节点中容器组的资源量；第三处理模块503，具体用于：

基于各节点的标签、各节点的资源量、各节点中容器组的标签和各节点中容器组的资源量，确定第一缓存数据。

在一个实施例中，第四处理模块504，具体用于：

通过预设调度算法，若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组的所需资源量大于各节点的资源量、各节点的标签不满足任一虚拟容器组的调度约束、各节点中容器组的标签不满足任一虚拟容器组的调度约束中的任意一项，则确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，并增加待测容器集群的节点数量。

在一个实施例中，待测容器集群为Kubernetes集群，第一缓存数据为调度器缓存数据。

应用本申请实施例，至少具有如下有益效果：

获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及各节点包括的容器组的相关信息；基于至少一个虚拟工作负载的相关信息，构建至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组；基于各节点的相关信息，以及各节点包括的容器组的相关信息，确定第一缓存数据；若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则将待测容器集群的节点数量进行调整；如此，可以准确的确定待测容器集群(例如Kubernetes集群)能不能容纳虚拟工作负载，若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则准确的确定待测容器集群中各节点的剩余可用资源是不能满足虚拟工作负载(新增业务)需求，从而准确的确定要对待测容器集群进行扩容，提升了确定待测容器集群是否能部署新增业务的准确度。

本申请实施例还提供了一种电子设备，该电子设备的结构示意图如图6所示，图6所示的电子设备4000包括：处理器4001和存储器4003。其中，处理器4001和存储器4003相连，如通过总线4002相连。可选地，电子设备4000还可以包括收发器4004，收发器4004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本申请实施例的限定。

处理器4001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线4002可包括一通路，在上述组件之间传送信息。总线4002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器4003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质，在此不做限定。

存储器4003用于存储执行本申请实施例的计算机程序，并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的计算机程序，以实现前述方法实施例所示的步骤。

其中，电子设备包括但不限于：服务器等。

应用本申请实施例，至少具有如下有益效果：

获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及各节点包括的容器组的相关信息；基于至少一个虚拟工作负载的相关信息，构建至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组；基于各节点的相关信息，以及各节点包括的容器组的相关信息，确定第一缓存数据；若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则将待测容器集群的节点数量进行调整；如此，可以准确的确定待测容器集群(例如Kubernetes集群)能不能容纳虚拟工作负载，若基于第一缓存数据确定至少一个虚拟容器组中任一虚拟容器组不能调度到各节点，则准确的确定待测容器集群中各节点的剩余可用资源是不能满足虚拟工作负载(新增业务)需求，从而准确的确定要对待测容器集群进行扩容，提升了确定待测容器集群是否能部署新增业务的准确度。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请实施例还提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

基于与本申请实施例提供的方法相同的原理，本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述本申请任一可选实施例中提供的方法。

应该理解的是，虽然本申请实施例的流程图中通过箭头指示各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明，否则在本申请实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本申请实施例对此不限制。

以上所述仅是本申请部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请的方案技术构思的前提下，采用基于本申请技术思想的其他类似实施手段，同样属于本申请实施例的保护范畴。

Claims (11)

1.一种容器集群的管理方法，其特征在于，包括：

获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及所述各节点包括的容器组的相关信息；

基于所述至少一个虚拟工作负载的相关信息，构建所述至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组；

基于所述各节点的相关信息，以及所述各节点包括的容器组的相关信息，确定第一缓存数据；

若基于所述第一缓存数据确定所述至少一个虚拟容器组中任一虚拟容器组不能调度到所述各节点，则将所述待测容器集群的节点数量进行调整。

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

获取至少一种虚拟节点的相关信息，所述至少一种虚拟节点的相关信息包括所述至少一种虚拟节点的数量；

基于所述至少一种虚拟节点的相关信息，构建所述至少一种虚拟节点对应的各虚拟节点；

基于所述至少一种虚拟节点的数量、所述各节点的相关信息，以及所述各节点包括的容器组的相关信息，确定第二缓存数据；

若基于所述第二缓存数据确定所述至少一个虚拟容器组中任一虚拟容器组不能调度到所述各节点和所述各虚拟节点，则将所述至少一种虚拟节点的数量进行累加处理，并更新所述至少一种虚拟节点的数量；

重复执行基于所述至少一种虚拟节点的数量、所述各节点的相关信息，以及所述各节点包括的容器组的相关信息，确定第二缓存数据、若基于所述第二缓存数据确定所述至少一个虚拟容器组中任一虚拟容器组不能调度到所述各节点和所述各虚拟节点，则将所述至少一种虚拟节点的数量进行累加处理，并更新所述至少一种虚拟节点的数量，直至得到所述至少一种虚拟节点的更新后的数量，以及所述至少一种虚拟节点对应的新增的虚拟节点，且所述任一虚拟容器组能调度到所述新增的虚拟节点，则将所述至少一种虚拟节点的更新后的数量确定为所述待测容器集群的新增节点数量。

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

获取至少一种虚拟节点的相关信息；

基于所述至少一种虚拟节点的相关信息，构建所述至少一种虚拟节点对应的各虚拟节点，并确定第三缓存数据；

若基于所述第三缓存数据确定所述至少一个虚拟容器组中任一虚拟容器组能调度到所述各虚拟节点，则基于所述至少一种虚拟节点的相关信息，以及至少一个虚拟工作负载的相关信息，构建新的容器集群。

4.根据权利要求1所述的方法，其特征在于，所述至少一个虚拟工作负载的相关信息包括所述至少一个虚拟工作负载中每个虚拟工作负载的名称、所述每个虚拟工作负载中虚拟容器组的数量、所述每个虚拟工作负载中虚拟容器组的相关信息；所述基于所述至少一个虚拟工作负载的相关信息，构建所述至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组，包括：

基于所述每个虚拟工作负载的名称、所述每个虚拟工作负载中虚拟容器组的数量、所述每个虚拟工作负载中虚拟容器组的相关信息，构建所述每个虚拟工作负载中至少一个虚拟容器组，所述每个虚拟工作负载中虚拟容器组的相关信息包括所需资源量和调度约束中至少一项。

5.根据权利要求1所述的方法，其特征在于，所述各节点的相关信息包括所述各节点的标签和所述各节点的资源量，所述各节点包括的容器组的相关信息包括所述各节点中容器组的标签和所述各节点中容器组的资源量；所述基于所述各节点的相关信息，以及所述各节点包括的容器组的相关信息，确定第一缓存数据，包括：

基于所述各节点的标签、所述各节点的资源量、所述各节点中容器组的标签和所述各节点中容器组的资源量，确定第一缓存数据。

6.根据权利要求1所述的方法，其特征在于，所述若基于所述第一缓存数据确定所述至少一个虚拟容器组中任一虚拟容器组不能调度到所述各节点，则将所述待测容器集群的节点数量进行调整，包括：

通过预设调度算法，若基于所述第一缓存数据确定所述至少一个虚拟容器组中任一虚拟容器组的所需资源量大于所述各节点的资源量、所述各节点的标签不满足所述任一虚拟容器组的调度约束、所述各节点中容器组的标签不满足所述任一虚拟容器组的调度约束中的任意一项，则确定所述至少一个虚拟容器组中任一虚拟容器组不能调度到所述各节点，并增加所述待测容器集群的节点数量。

7.根据权利要求1-6中任一项所述的方法，其特征在于，所述待测容器集群为Kubernetes集群，所述第一缓存数据为调度器缓存数据。

8.一种容器集群的管理装置，其特征在于，包括：

第一处理模块，用于获取至少一个虚拟工作负载的相关信息、待测容器集群的各节点的相关信息，以及所述各节点包括的容器组的相关信息；

第二处理模块，用于基于所述至少一个虚拟工作负载的相关信息，构建所述至少一个虚拟工作负载中每个虚拟工作负载包括的至少一个虚拟容器组；

第三处理模块，用于基于所述各节点的相关信息，以及所述各节点包括的容器组的相关信息，确定第一缓存数据；

第四处理模块，用于若基于所述第一缓存数据确定所述至少一个虚拟容器组中任一虚拟容器组不能调度到所述各节点，则将所述待测容器集群的节点数量进行调整。

9.一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，其特征在于，所述处理器执行所述计算机程序以实现权利要求1-7中任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-7中任一项所述方法的步骤。

11.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-7中任一项所述方法的步骤。