CN112306567B - 集群管理系统和容器管控方法 - Google Patents

Abstract

本申请提供的集群管理系统和容器管控方法，涉及集群管理技术领域。其中，所述集群管理系统包括主节点和与该主节点通信连接的从节点，所述主节点包括接口服务组件，所述从节点包括应用容器和监控组件。所述接口服务组件，用于在接收到更新指令时对所述应用容器的配置元数据进行更新处理。所述监控组件，用于对所述配置元数据是否发生更新进行监测，并在监测到所述配置元数据发生更新时，基于更新后的配置元数据对所述应用容器的配置信息进行更新处理。通过上述设置，可以改善现有技术中主节点由于未参与应用容器的垂直扩容处理而存在难以准确地判断应用容器是否发生垂直扩容的问题。

Description

集群管理系统和容器管控方法

技术领域

本申请涉及集群管理技术领域，具体而言，涉及一种集群管理系统和容器管控方法。

背景技术

kubernetes是一种容器编排引擎，用于在集群管理系统中构建容器管理平台。其中，集群管理系统包括主节点(master node)和从节点(slave node)，从节点上封装有一个或多个应用容器。

经发明人研究发现，现有技术中一般是通过从节点上的docker daemon组件(一个开源的应用容器引擎)的api(application programming interface，应用程序接口)对应用容器的配置信息进行更新，从而实现应用容器的垂直扩容。但是，该技术存在着主节点由于未参与应用容器的垂直扩容处理而难以准确地判断应用容器是否发生垂直扩容的问题。

发明内容

有鉴于此，本申请的目的在于提供一种集群管理系统和容器管控方法，以改善现有技术中主节点由于未参与应用容器的垂直扩容处理而存在难以准确地判断应用容器是否发生垂直扩容的问题。

为实现上述目的，本申请实施例采用如下技术方案：

一种集群管理系统，包括主节点和与该主节点通信连接的从节点，所述主节点包括接口服务组件，所述从节点包括应用容器和监控组件，其中：

所述接口服务组件，用于在接收到更新指令时对所述应用容器的配置元数据进行更新处理；

所述监控组件，用于对所述配置元数据是否发生更新进行监测，并在监测到所述配置元数据发生更新时，基于更新后的配置元数据对所述应用容器的配置信息进行更新处理。

在本申请实施例较佳的选择中，在上述集群管理系统中，所述主节点还包括调度组件和调度扩展组件，其中：

所述调度组件，用于从所述接口服务组件获取所述应用容器当前的配置元数据，并发送给所述调度扩展组件；

所述调度扩展组件，用于根据所述当前的配置元数据得到所述应用容器的资源使用参数，并根据该资源使用参数和预设的计算公式计算得到所述从节点的资源使用分值。

在本申请实施例较佳的选择中，在上述集群管理系统中，所述监控组件通过插件的形式配置于所述从节点，所述调度扩展组件通过插件的形式配置于所述主节点。

在本申请实施例较佳的选择中，在上述集群管理系统中，所述监控组件还用于：

检测所述应用容器当前的配置信息与当前的配置元数据是否匹配，并在检测到所述当前的配置信息与所述当前的配置元数据不匹配时，生成报警信息并发送至所述接口服务组件。

本申请实施例还提供了一种容器管控方法，应用于集群管理系统中的主节点，该集群管理系统还包括与该主节点通信连接的从节点，该从节点包括应用容器和监控组件，所述主节点包括接口服务组件，所述容器管控方法包括：

所述接口服务组件在接收到更新指令时，对所述应用容器的配置元数据进行更新处理，以使所述监控组件能够在监测到所述配置元数据发生更新时，基于更新后的配置元数据对所述应用容器的配置信息进行更新处理。

在本申请实施例较佳的选择中，在上述容器管控方法中，所述接口服务组件在接收到更新指令时，对所述应用容器的配置元数据进行更新处理的步骤，包括：

所述接口服务组件在接收到更新指令时，将与该更新指令对应的更新数据配置于所述应用容器的配置元数据中的注解部分。

在本申请实施例较佳的选择中，在上述容器管控方法中，所述主节点还包括调度组件和调度扩展组件，所述容器管控方法还包括：

所述调度组件从所述接口服务组件获取所述应用容器当前的配置元数据，并发送给所述调度扩展组件；

所述调度扩展组件根据所述当前的配置元数据得到所述应用容器的资源使用参数，并根据该资源使用参数和预设的计算公式计算得到所述从节点的资源使用分值。

本申请实施例还提供了另一种容器管控方法，应用于集群管理系统的从节点，该集群管理系统还包括与该从节点通信连接的主节点，该主节点包括接口服务组件，所述从节点包括应用容器和监控组件，所述容器管控方法包括：

所述监控组件监测所述接口服务组件是否对所述应用容器的配置元数据进行更新处理，并在监测到所述接口服务组件对所述配置元数据进行更新处理后，基于更新后的配置元数据对所述应用容器的配置信息进行更新处理。

在本申请实施例较佳的选择中，在上述容器管控方法中，所述从节点还包括容器管理组件，所述基于更新后的配置元数据对所述应用容器的配置信息进行更新处理的步骤，包括：

所述监控组件通过所述容器管理组件的容器更新接口，基于更新后的配置元数据对所述应用容器的配置信息进行更新处理。

在本申请实施例较佳的选择中，在上述容器管控方法中，还包括：

所述监控组件每间隔预设时长检测所述应用容器当前的配置信息与当前的配置元数据是否匹配；

所述监控组件在检测到所述当前的配置信息与所述当前的配置元数据不匹配时，生成报警信息并发送至所述接口服务组件。

本申请提供的集群管理系统和容器管控方法，通过在需要对应用容器的配置信息进行更新处理时，先基于主节点的接口服务组件对配置信息对应的配置元数据进行更新处理，使得监控组件基于配置元数据的更新对该配置信息进行相应的更新处理。如此，在保证可以对应用容器进行热更新的同时，还可以使得主节点可以准确地判断应用容器是否有进行垂直扩容(配置信息的更新)，从而改善现有技术中主节点由于未参与应用容器的垂直扩容处理而存在难以准确地判断应用容器是否发生垂直扩容的问题，具有较高的实用价值。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

图1为本申请实施例提供的集群管理系统的方框示意图。

图2为本申请实施例提供的集群管理系统的主从节点之间的交互示意图。

图3为本申请实施例提供的集群管理系统的另一方框示意图。

图4为本申请实施例提供的容器管控方法的流程示意图。

图5为本申请实施例提供的集群管理系统的另一方框示意图。

图标：10-集群管理系统；100-主节点；110-接口服务组件；130-调度组件；150-调度扩展组件；200-从节点；210-应用容器；230-监控组件；250-容器管理组件。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例只是本申请的一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

如图1和图2所示，本申请实施例提供了一种集群管理系统10，可以包括主节点100(master node)和从节点200(slave node)。其中，所述主节点100和所述从节点200通信连接。

详细地，所述主节点100可以包括接口服务组件110(apiserver组件)，所述从节点200可以包括应用容器210(container)和监控组件230(vscaled组件)。所述接口服务组件110，用于在接收到更新指令时对所述应用容器210的配置元数据进行更新处理。所述监控组件230，用于对所述配置元数据是否发生更新进行监测，并在监测到所述配置元数据发生更新时，基于更新后的配置元数据对所述应用容器210的配置信息进行更新处理。

其中，所述主节点100的数量不受限制，可以根据实际应用需求进行选择。例如，在一种可以替代的示例中，所述主节点100可以为一个。

同理，所述从节点200的数量也不受限制，可以根据系统需要处理的数据量进行选择，例如，在数据量较大时，可以选择设置较多的从节点200，且各所述从节点200分别与所述主节点100通信连接。

其中，所述主节点100可以是一种服务器。该服务器可以包括处理器和与该处理器直接或间接电性连接的存储器，且该存储器上存储有计算机程序。

所述存储器可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。

所述处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)、片上系统(System on Chip,SoC)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

同理，所述从节点200也可以是一种服务器，也可以包括处理器和与该处理器直接或间接电性连接的存储器，且该存储器上存储有计算机程序。

需要说明的是，在上述主节点100的存储器和从节点200的存储器上存储的计算机程序，可以包括上述的各个组件，例如，所述接口服务组件110和所述监控组件230。

并且，上述的计算机程序还可以包括一个或多个软件功能模块。上述主节点100和从节点200的处理器执行该软件功能模块对应的程序时，可以实现本申请实施例提供的容器管控方法。

基于上述设置，由于在对应用容器210的配置信息更新时，需要先对位于主节点100上的该应用容器210的配置元数据进行更新处理，如此，可以通过判断该配置元数据是否进行更新，以判断应用容器210的配置信息是否更新，从而实现对应用容器210是否发生垂直扩容进行准确判断的目的，进而改善了现有技术中因通过从节点200直接对应用容器210的配置信息进行更新而导致主节点100难以对应用容器210是否发生垂直扩容进行准确判断的问题。

进一步地，为了避免所述接口服务组件110对应用容器210的配置元数据进行更新之后，所述监控组件230没有对该应用容器210的配置信息进行更新的问题，在本实施例中，所述监控组件230还可以检测所述应用容器210当前的配置信息与当前的配置元数据是否匹配，并在检测到所述当前的配置信息与所述当前的配置元数据不匹配时，生成报警信息并发送至所述接口服务组件110。

如此设置，一方面，使得所述监控组件230可以在检测到所述应用容器210当前的配置信息与当前的配置元数据不匹配时，基于该当前的配置元数据对该当前的配置信息进行更新处理，进而保证应用容器210的配置信息的更新能够有效地完成。另一方面，还可以使得所述接口服务组件110也可以基于所述报警信息对应用容器210的配置信息的更新故障进行记录，从而使得用户也可以获取到该更新故障，以进行相应的维护。

进一步地，考虑到主节点100对应用容器210是否发生垂直扩容进行判断的目的可以是，有效地对从节点200的物理资源调度进行管控。因此，结合图3，在一种可以替代的示例中，所述主节点100还可以包括调度组件130(scheduler组件，是kubernetes控制面的核心组件之一，负责容器资源和宿主的调度和绑定)和调度扩展组件150(vscale extender组件)。

其中，所述调度组件130，用于从所述接口服务组件110获取所述应用容器210当前的配置元数据，并发送给所述调度扩展组件150。所述调度扩展组件150，用于根据所述当前的配置元数据得到所述应用容器210的资源使用参数，并根据该资源使用参数和预设的计算公式计算得到所述从节点200的资源使用分值。

也就是说，所述调度组件130在获取到应用容器210当前的配置元数据之后，可以调用所述调度扩展组件150，使得可以通过调度扩展组件150基于该当前的配置元数据得到所述应用容器210的资源使用参数，并基于该资源使用参数和预设的计算公式计算得到所述从节点200的资源使用分值。

如此，所述调度组件130可以基于该资源使用分值对所述从节点200上的资源(如CPU资源、存储资源等)进行有效的管控，从而避免某一个或多个CPU出现计算任务过重，或者，某一个或多个存储器出现存储任务过重的问题。

需要说明的是，上述的监控组件230和调度扩展组件150，是本申请发明人为了解决现有的集群管理系统10存在的技术问题，进行开发的。并且，所述监控组件230和调度扩展组件150与现有的集群管理系统10的关系不受限制，可以根据实际应用需求进行选择。

例如，在一种可以替代的示例中，可以是直接对现有的集群管理系统10的代码或组件进行相应的修改以形成所述监控组件230和所述调度扩展组件150。

又例如，在另一种可以替代的示例中，可以是将所述监控组件230和所述调度扩展组件150以插件的形式(plugin)集成于现有的集群管理系统10，从而得到本申请实施例提供的集群管理系统10。

详细地，在本实施例中，可以将所述调度扩展组件150通过插件的形式配置于所述主节点100，并可以将所述监控组件230通过插件的形式配置于所述从节点200。

如此设置，可以使得对集群管理系统10的核心代码不会发生改动，从而使得之后需要对该核心代码进行更新时，可以单独进行更新而不用考虑上述的调度扩展组件150和监控组件230，进而便于集群管理系统10后期的维护与更新，实用价值较高。

本申请实施例还提供一种容器管控方法，可应用于上述集群管理系统10的主节点100。其中，所述集群管理系统10还包括与所述主节点100通信连接的从节点200，该从节点200包括应用容器210和监控组件230，所述主节点100包括接口服务组件110。

详细地，所述容器管控方法可以包括以下步骤：

所述接口服务组件110在接收到更新指令时，对所述应用容器210的配置元数据进行更新处理。

也就是说，在需要对应用容器210的配置信息进行更新时，用户可以向所述接口服务组件110发送与更新的内容相关的更新指令。所述接口服务组件110可以基于接收到的更新指令，对所述应用容器210的配置元数据进行更新处理。如此，可以使得所述监控组件230能够在监测到所述配置元数据发生更新时，基于更新后的配置元数据对所述应用容器210的配置信息进行更新处理。

例如，若需要将一个应用容器210的从使用一个中央处理器更改到使用两个中央处理器(如从使用CPU1更改到使用CPU1和CPU2)，此时，所述更新指令可以包括将该应用容器210使用的中央处理器从CPU1更改到CPU1和CPU2的信息。

又例如，若需要将一个应用容器210产生的数据从存储于一个存储器更改到存储于两个存储器(如从存储于Memory1更改到存储于Memory1和Memory2)，此时，所述更新指令可以包括将该应用容器210产生的数据从存储于Memory1更改到存储于Memory1和Memory2的信息。

可选地，对所述配置元数据进行更新处理的方式不受限制，可以根据实际应用需求进行选择。

例如，在一种可以替代的示例中，可以通过注解的方式进行配置元数据的更新。也就是说，上述进行更新处理的步骤可以包括：所述接口服务组件110在接收到更新指令时，将与该更新指令对应的更新数据配置于所述应用容器210的配置元数据中的注解部分。

详细地，在一种可以替代的示例中，可以通过所述接口服务组件110对所述配置元数据进行修改操作(patch操作)，将垂直扩容的相应配置(或者说需要更新的数据)以json格式配置于应用容器210的配置元数据中的注解部分(如pod.metadata.annotations)。

通过上述方法，可以使得主节点100能够基于配置元数据的更新准确地判断应用容器210的配置信息是否发生更新，从而可以有效地对应用容器210使用的物理资源进行有效地监控，进而使得在进行物理资源的调度控制时，采用的依据是合理的，避免出现物理资源严重倾斜的问题。

其中，对应用容器210使用的物理资源进行有效地监控的方式可以根据实际应用需求进行选择。

例如，在一种可以替代的示例中，可以计算所述应用容器210的宿主(所在的从节点200)的资源使用分值，以实现资源使用的监控。也就是说，所述容器管控方法还可以包括以下步骤：

首先，所述调度组件130从所述接口服务组件110获取所述应用容器210当前的配置元数据，并发送给所述调度扩展组件150。其次，所述调度扩展组件150根据所述当前的配置元数据得到所述应用容器210的资源使用参数，并根据该资源使用参数和预设的计算公式计算得到所述从节点200的资源使用分值。

也就是说，所述调度组件130在获取到所述应用容器210当前的配置元数据之后，可以基于调用所述调度扩展组件150进行相应的计算或判断。

例如，首先，所述调度扩展组件150可以基于所述当前的配置元数据获得对应的资源使用率(如配置元数据未发生更新，该资源使用率可以是预先配置的值，如配置元数据发生更新，该资源使用率可以通过对更新后的配置元数据进行解析得到)。其次，在获得所述资源使用率之后，可以基于预设的计算公式计算得到相应的资源使用分值。

在一种可以替代的示例中，上述的计算公式可以包括：

Sc＝maS+(miS-maS)*(Ut-miU)/(maU-miU)；

其中，Sc为资源使用分值，maS为预先确定的最大使用分值，miS为预先确定的最小使用分值，Ut为资源使用率，maU为预先确定的最大使用率，miU为预先确定的最小使用率。

需要说明的是，所述最大使用分值、所述最小使用分值、所述最大使用率和所述最小使用率的具体数值不受限制，可以根据实际应用需求进行选择。

例如，在一种可以替代的示例中，所述最大使用分值可以为10，所述最小使用分值可以为0，所述最大使用率可以为100，所述最小使用率可以为0。如此设置，可以使得计算得到的资源使用分值在区间[0，10]之间。并且，计算得到的资源使用分值越小，表示相应的物理资源使用的量越大。

结合图4，本申请实施例还提供另一种容器管控方法，可应用于上述集群管理系统10的从节点200。其中，所述集群管理系统10还包括与所述从节点200通信连接的主节点100节点，该主节点100包括接口服务组件110，所述从节点200包括应用容器210和监控组件230。

详细地，所述容器管控方法可以包括步骤S110和步骤S120，以对应用容器210的配置信息进行更新处理。

步骤S110，所述监控组件230监测所述接口服务组件110是否对所述应用容器210的配置元数据进行更新处理。

步骤S120，所述监控组件230在监测到所述接口服务组件110对所述配置元数据进行更新处理后，基于更新后的配置元数据对所述应用容器210的配置信息进行更新处理。

基于上述方法，一方面可以使得应用容器210的配置信息的更新可以在不重启封装该应用容器210的pod的情况下进行，另一方面可以使得主节点100可以基于配置元数据的更新准确判断应用容器210的配置信息是否进行更新。

可选地，执行步骤S110判断是否对配置元数据进行更新处理的方式不受限制，可以根据实际应用需求进行选择。

例如，在一种可以替代的示例中，可以实时获取当前的配置元数据，并将该配置元数据与上一次获取的配置元数据进行比较，以判断所述接口服务组件110是否对所述应用容器210的配置元数据进行更新处理。

又例如，在另一种可以替代的示例中，所述接口服务组件110在对配置元数据进行更新处理之后，可以向所述监控组件230发送相应的更新提示信息。如此，所述监控组件230可以基于是否接收到该更新提示信息，判断所述接口服务组件110是否对所述应用容器210的配置元数据进行更新处理。

可选地，执行步骤S120对配置信息进行更新处理的方式也不受限制，可以根据实际应用需求进行选择。

例如，在一种可以替代的示例中，步骤S120可以包括以下步骤：

首先，所述监控组件230在监测到所述接口服务组件110对所述配置元数据进行更新处理后，可以对该配置元数据进行解析。然后，再基于解析得到的数据对应用容器210的配置信息进行更新处理。

详细地，在一种可以替代的示例中，结合图5，所述从节点200还可以包括容器管理组件250(docker daemon组件)。所述监控组件230可以通过所述容器管理组件250的容器更新接口(update container接口)，基于更新后的配置元数据对所述应用容器210的配置信息进行更新处理。

需要说明的是，对所述应用容器210的配置信息进行更新处理，可以是对该应用容器210的控制组(cgroup，control group)的内容进行修改。

其中，考虑到所述控制组是系统内核提供的一种可以限制、记录、隔离进程组所使用的物理资源的机制，且该物理资源可以包括中央处理器(CPU)、存储器(Memory)、IO等。因此，在需要对控制组的内容进行修改时，还需要根据解析后的配置元数据确定对应的修改路径。

例如，若需要对使用的CPU进行修改，可以基于CPU对应的路径进行修改。若需要对使用的Memory进行修改，可以基于Memory对应的路径进行修改。

进一步地，未避免所述接口服务组件110对应用容器210的配置元数据进行更新之后，该应用容器210的配置信息却没有被更新，进而导致主节点100也无法基于配置元数据准确地判断配置信息是否被更新的问题。在本实施例中，所述容器管控方法还可以包括以下步骤：

首先，所述监控组件230每间隔预设时长检测所述应用容器210当前的配置信息与当前的配置元数据是否匹配。然后，所述监控组件230在检测到所述当前的配置信息与所述当前的配置元数据不匹配时，生成报警信息并发送至所述接口服务组件110。

也就是说，所述监控组件230基于对配置信息进行修改的目的会通过容器管理组件250与应用容器210形成一信息传输通断，并且，还会基于对应用容器210当前的配置信息是否与当前的配置元数据匹配进行检测的目的，直接与应用容器210形成另一信息传输通道。

需要说明的是，上述将配置信息和配置元数据进行是否匹配的比较，在一种可以替代的示例中，可以是指将配置信息中表示应用容器210使用的物理资源和配置元数据中应用容器210使用的物理资源是否一致进行比较。

其中，上述的预设时长的具体数据不受限制，可以根据实际应用需求进行选择。例如，该预设时长可以基于所述调度组件130计算资源使用分值的周期进行设置，使得在计算资源使用分值时，可以根据所述报警信息准确的确定资源使用率，从而保证计算得到的资源使用分值具有较高的可靠性。

并且，所述接口服务组件110在接收到所述报警信息之后，可以通过事件的方式(event)将该报警信息记录在封装该报警信息对应的应用容器210的pod事件中，以便于后续用户的查询等操作。

综上所述，本申请提供的集群管理系统10和容器管控方法，通过在需要对应用容器210的配置信息进行更新处理时，先基于主节点100的接口服务组件110对配置信息对应的配置元数据进行更新处理，使得监控组件230基于配置元数据的更新对该配置信息进行相应的更新处理。如此，在保证可以对应用容器210进行热更新的同时，还可以使得主节点100可以准确地判断应用容器210是否有进行垂直扩容(配置信息的更新)，从而改善现有技术中主节点100由于未参与应用容器210的垂直扩容处理而存在难以准确地判断应用容器210是否发生垂直扩容的问题，以便于后续操作的有效进行，具有较高的实用价值。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (6)

1.一种集群管理系统，其特征在于，包括主节点和与该主节点通信连接的从节点，所述主节点包括接口服务组件、调度组件和调度扩展组件，所述从节点包括应用容器和监控组件，其中：

所述接口服务组件，用于在接收到更新指令时对所述应用容器的配置元数据进行更新处理；

所述监控组件，用于对所述配置元数据是否发生更新进行监测，并在监测到所述配置元数据发生更新时，基于更新后的配置元数据对所述应用容器的配置信息进行更新处理；

所述主节点通过判断所述配置元数据是否进行更新以判断所述应用容器的配置信息是否更新；

其中：

所述调度组件，用于从所述接口服务组件获取所述应用容器当前的配置元数据，并发送给所述调度扩展组件；

所述调度扩展组件，用于根据所述当前的配置元数据得到所述应用容器的资源使用参数，并根据该资源使用参数和预设的计算公式计算得到所述从节点的资源使用分值；

所述监控组件还用于：

检测所述应用容器当前的配置信息与当前的配置元数据是否匹配，并在检测到所述当前的配置信息与所述当前的配置元数据不匹配时，生成报警信息并发送至所述接口服务组件。

2.根据权利要求1所述的集群管理系统，其特征在于，所述监控组件通过插件的形式配置于所述从节点，所述调度扩展组件通过插件的形式配置于所述主节点。

3.一种容器管控方法，其特征在于，应用于集群管理系统中的主节点，该集群管理系统还包括与该主节点通信连接的从节点，该从节点包括应用容器和监控组件，所述主节点包括接口服务组件、调度组件和调度扩展组件，所述容器管控方法包括：

所述接口服务组件在接收到更新指令时，对所述应用容器的配置元数据进行更新处理，以使所述监控组件能够在监测到所述配置元数据发生更新时，基于更新后的配置元数据对所述应用容器的配置信息进行更新处理；

所述主节点通过判断所述配置元数据是否进行更新以判断所述应用容器的配置信息是否更新；

所述容器管控方法还包括：

所述调度组件从所述接口服务组件获取所述应用容器当前的配置元数据，并发送给所述调度扩展组件；

所述调度扩展组件根据所述当前的配置元数据得到所述应用容器的资源使用参数，并根据该资源使用参数和预设的计算公式计算得到所述从节点的资源使用分值；

所述监控组件检测所述应用容器当前的配置信息与当前的配置元数据是否匹配，并在检测到所述当前的配置信息与所述当前的配置元数据不匹配时，生成报警信息并发送至所述接口服务组件。

4.根据权利要求3所述的容器管控方法，其特征在于，所述接口服务组件在接收到更新指令时，对所述应用容器的配置元数据进行更新处理的步骤，包括：

所述接口服务组件在接收到更新指令时，将与该更新指令对应的更新数据配置于所述应用容器的配置元数据中的注解部分。

5.一种容器管控方法，其特征在于，应用于集群管理系统的从节点，该集群管理系统还包括与该从节点通信连接的主节点，该主节点包括接口服务组件、调度组件和调度扩展组件，所述从节点包括应用容器和监控组件，所述容器管控方法包括：

所述监控组件监测所述接口服务组件是否对所述应用容器的配置元数据进行更新处理，并在监测到所述接口服务组件对所述配置元数据进行更新处理后，基于更新后的配置元数据对所述应用容器的配置信息进行更新处理；

所述主节点通过判断所述配置元数据是否进行更新以判断所述应用容器的配置信息是否更新；

所述调度组件从所述接口服务组件获取所述应用容器当前的配置元数据，并发送给所述调度扩展组件；

所述调度扩展组件根据所述当前的配置元数据得到所述应用容器的资源使用参数，并根据该资源使用参数和预设的计算公式计算得到所述从节点的资源使用分值；

所述监控组件每间隔预设时长检测所述应用容器当前的配置信息与当前的配置元数据是否匹配；

所述监控组件在检测到所述当前的配置信息与所述当前的配置元数据不匹配时，生成报警信息并发送至所述接口服务组件。

6.根据权利要求5所述的容器管控方法，其特征在于，所述从节点还包括容器管理组件，所述基于更新后的配置元数据对所述应用容器的配置信息进行更新处理的步骤，包括：

所述监控组件通过所述容器管理组件的容器更新接口，基于更新后的配置元数据对所述应用容器的配置信息进行更新处理。