CN114385366A - 容器云平台的容器组弹性扩容方法、系统、介质和设备 - Google Patents

Abstract

本申请提供了一种容器云平台的容器组弹性扩容方法、系统、计算机可读存储介质和电子设备。该容器云平台的容器组弹性扩容方法包括：对容器应用所在容器组的资源使用率进行监测；响应于所述资源使用率出现增长，对所述容器应用所在容器组进行复制，以生成至少一个容器组副本；响应于所述资源使用率的增长率达到预设阈值，增大所述容器应用所在容器组的资源占用。籍此，解决了在容器应用的访问流量增长过快时，新生成的容器组副本因存在“冷启动”问题使得部署在容器组副本中的容器应用实例无法分担访问流量压力的问题，实现了对容器应用可使用资源的快速扩容和容器应用在可使用资源扩容后对新增访问流量的快速响应。

Description

容器云平台的容器组弹性扩容方法、系统、介质和设备

技术领域

本申请涉及容器云技术领域，特别涉及一种容器云平台的容器组弹性扩容方法、系统、计算机可读存储介质和电子设备。

背景技术

Kubernetes是Google开源的一个容器编排引擎，支持自动化部署、大规模可伸缩、应用容器化管理，Kubernetes系统作为一个典型的容器云平台，能够对容器化部署在Kubernetes集群中的应用进行自动部署和管理。

其中，可伸缩主要体现在当某个应用的访问流量增大时，自动增加该应用可使用的资源，当某个应用的访问流量减小时，自动减小该应用可使用的资源。通过对部署在Kubernetes集群中的每个应用进行弹性伸缩的资源分配，使得Kubernetes集群的硬件资源得到充分利用。

目前，以Kubernetes系统为例的容器云平台的资源弹性伸缩主要依靠容器组水平自动扩缩(Horizontal Pod Autoscaler，简称HPA)机制调整部署应用实例的容器组(Pod)副本数量，进而对应用可使用的资源进行扩缩。具体来说，当应用的访问流量增大时，HPA机制通过对部署该应用的Pod进行复制来增加该应用可使用的资源，但复制生成的容器组副本从开始创建到启动完成，即从容器组副本开始创建到部署在容器组副本中的应用实例能够对访问流量进行响应，需要一段时间，也就是存在“冷启动”问题。

因此，当某个应用的访问流量在短时间内突然增大时，HPA机制无法实现该应用可使用资源的快速扩容，导致该应用可使用资源不足，使得该应用无法对全部访问流量进行正常响应。

因此，需要提供一种针对上述现有技术不足的改进技术方案。

发明内容

本申请的目的在于提供一种容器云平台的容器组弹性扩容方法、系统、计算机可读存储介质和电子设备，以解决或缓解上述现有技术中存在的问题。

为了实现上述目的，本申请提供如下技术方案：

本申请提供了一种容器云平台的容器组弹性扩容方法,包括：对容器应用所在容器组的资源使用率进行监测；响应于所述资源使用率出现增长，对所述容器应用所在容器组进行复制，以生成至少一个容器组副本；响应于所述资源使用率的增长率达到预设阈值，增大所述容器应用所在容器组的资源占用。

优选的，所述容器云平台为Kubernetes系统，所述对容器应用所在容器组的资源使用率进行监测，具体为：所述Kubernetes系统的Kubelet组件对所述容器应用所在容器组的资源使用率进行收集，并发送至所述Kubernetes系统的Metrics-Server组件，所述Metrics-Server组件对所述资源使用率进行监测。

优选的，响应于所述资源使用率出现增长，对所述容器应用所在容器组进行复制，以生成至少一个容器组副本，包括：响应于所述资源使用率出现增长，根据所述容器应用对应的预设指标，计算待生成的所述容器组副本的数量；根据计算出的所述容器组副本的数量，对所述容器应用所在容器组进行复制。

优选的，所述响应于所述资源使用率出现增长，根据所述容器应用对应的预设指标，计算待生成的所述容器组副本的数量，包括：响应于所述资源使用率出现增长，计算增长后的资源使用率与所述容器应用对应的预设指标之间的差值；根据所述差值对应的资源需求量，计算待生成的所述容器组副本的数量。

优选的，所述响应于所述资源使用率的增长率达到预设阈值，增大所述容器应用所在容器组的资源占用，具体为：响应于所述资源使用率的增长率达到预设阈值，设置所述容器应用所在容器组的资源占用增大至少一倍。

优选的，所述容器云平台的容器组弹性扩容方法还包括：如果所述容器应用所在容器组所在节点的剩余可用资源小于所述容器应用所在容器组的资源占用，则设置所述容器应用所在容器组占满所述容器应用所在容器组所在节点的剩余可用资源。

优选的，在所述增大所述容器应用所在容器的资源占用之后，还包括：当至少一个所述容器组副本启动完成后，减小所述容器应用所在容器组的资源占用。

本申请实施例还提供一种容器云平台的容器组弹性扩容系统，包括：资源监测单元，配置为对容器应用所在容器组的资源使用率进行监测；复制单元，配置为响应于所述资源使用率出现增长，对所述容器应用所在容器组进行复制，以生成至少一个容器组副本；扩容单元，配置为响应于所述资源使用率的增长率达到预设阈值，增大所述容器应用所在容器组的资源占用。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序为如上任一所述的容器云平台的容器组弹性扩容方法。

本申请实施例还提供一种电子设备，包括：存储器、处理器、以及存在所述存储器中并可在处理器上运行的程序，所述处理器执行所述程序时实现如上任一所述的容器云平台的容器组弹性扩容方法。

有益效果：

本申请提供的技术方案中，对容器应用所在容器组的资源使用率进行检测，当资源使用率出现增长时，对容器应用所在容器组进行复制，生成至少一个容器组副本，即当容器应用的访问流量增长时，通过复制生成容器组副本的方式实现容器应用可使用资源的快速扩容；当资源使用率的增长率达到预设阈值时，增大容器应用所在容器组的资源占用，即当容器应用的访问流量增大过快时，调高容器应用所在容器组的资源占用，实现容器应用在可使用资源扩容后对新增访问流量的快速响应。籍此，解决了在容器应用的访问流量增长过快时，新生成的容器组副本因存在“冷启动”问题使得部署在容器组副本中的容器应用实例无法分担访问流量压力的问题，实现了对容器应用可使用资源的快速扩容和容器应用在可使用资源扩容后对新增访问流量的快速响应。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。其中：

图1为根据本申请的一些实施了提供的一种容器云平台的容器组弹性扩容方法的流程示意图；

图2为根据本申请的一些实施例提供的一种Kubernetes集群的容器组弹性扩容方法的技术逻辑图；

图3为根据本申请的一些实施例提供的一种容器云平台的容器组弹性扩容系统的结构示意图；

图4为根据本申请的一些实施例提供的电子设备的结构示意图；

图5为根据本申请的一些实施例提供的电子设备的硬件结构。

具体实施方式

下面将参考附图并结合实施例来详细说明本申请。各个示例通过本申请的解释的方式提供而非限制本申请。实际上，本领域的技术人员将清楚，在不脱离本申请的范围或精神的情况下，可在本申请中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本申请包含归入所附权利要求及其等同物的范围内的此类修改和变型。

示例性方法

图1为根据本申请的一些实施了提供的一种容器云平台的容器组弹性扩容方法的流程示意图；如图1所示，该容器云平台的容器组弹性扩容方法包括：

步骤S101、对容器应用所在容器组的资源使用率进行监测。

其中，容器应用是指能够在容器中直接运行的应用，以区别于直接在操作系统中直接运行的传统应用。

需要说明的是，容器技术作为一种新型的虚拟化技术，能够将单个操作系统的资源划分到孤立的容器中，但传统应用不能直接在容器中运行。因此，容器应用可以是应用开发人员直接开发出的能够在容器中直接运行的应用，也可以是应用开发人员对开发出的传统应用进行容器化处理后所生成的能够在容器中直接运行的应用，对传统应用进行容器化处理可以采取已有的各种方案实现，本申请实施例对此不做限定。

此外，对于以Kubernetes系统为例的容器云平台，容器组(Pod)为其中创建和管理的最小单元，也就是说，容器云平台能够操作的最小单元为容器组，因此本申请实施例也以容器组为单元对容器应用可使用资源进行扩容。

在本申请实施例中，容器应用容器化部署在容器云平台中，具体部署在容器云平台中的至少一个容器组中，由服务(Service)组件为部署有该容器应用实例的全部容器组提供统一的访问入口，并且将容器应用的访问流量根据各个容器组的负载情况进行分发。因此，请求访问容器应用的访问流量首先由容器云平台的入口组件转发至容器应用对应的服务组件，再由服务组件将访问流量分发至部署有容器应用实例的各个容器组。

鉴于服务组件基于负载均衡对访问流量进行分发，部署有相同容器应用实例的各个容器组的资源使用情况基本保持一致。此外，考虑到容器组所使用的资源主要是CPU和内存，因此，通过对部署该容器应用的某个容器组工作时实际使用的CPU、内存等资源的资源使用率进行监测，即可获取容器应用所在容器组的平均资源使用率。

可以理解，当容器应用的访问流量增大时，实际对访问流量进行处理和响应的承担者是该容器应用所在全部容器组，该容器应用所在全部容器组的资源使用率将出现增长，因此通过对容器应用所在容器组的资源使用率进行监测，可以间接地对容器应用的访问流量的变化情况进行监测。

具体地，以Kubernetes系统为例进行说明，当容器云平台为Kubernetes系统时，对容器应用所在容器组的资源使用率进行监测，具体为Kubernetes系统的Kubelet组件对容器应用所在容器组的资源使用率进行收集，并发送至Kubernetes系统的Metrics-Server组件，Metrics-Server组件对资源使用率进行监测。

如图2所示，Kubernetes系统将Kubernetes集群(部署有Kubernetes系统的节点集群)中的节点按照功能不同划分为控制节点和工作节点，在控制节点上运行集群管理相关的进程，自动完成整个Kubernetes集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力。

Kubernetes系统在集群中的每个节点上安装有Kubelet组件，用于对部署其上容器组进行管理。相应地，在将容器应用容器化部署在Kubernetes集群中的节点上后，由Kubernetes系统的Kubelet组件对容器应用所在容器组进行管理，同时Kubelet组件还可以对容器应用所在容器组实际使用CPU、内存等资源的资源使用率进行收集，并发送至Metrics-Server组件。

可以理解，每个节点上可以部署多个容器应用，而Kubernetes集群中包括多个节点，Metrics-Server组件作为Kubernetes系统的核心组件，用于接收各个节点上的Kubelet组件上报的所在节点上全部容器组的资源使用情况，并进行汇总和加工处理，并提供给Kubernetes系统中的其他组件使用。

由Metrics-Server组件对任一容器应用所在容器组实际使用的CPU、内存等资源的资源使用率进行监测，Kubernetes系统中的其他组件通过访问Metrics-Server提供给的API接口，即可获取任一容器应用所在容器组的平均资源使用率。

步骤S102、响应于资源使用率出现增长，对容器应用所在容器组进行复制，以生成至少一个容器组副本。

基于前述说明，可以知道，在本申请实施例中，当容器应用的访问流量增大时，增大的访问流量经由容器应用对应的服务组件分发至部署该容器应用的所有容器组，使得部署该容器应用的所有容器组的资源使用率增大，相应地，平均资源使用率也将增大。

当容器云平台监测到某个容器应用所在容器组的资源使用率出现增长时，说明该容器应用的访问流量正在增大，需要为该容器应用增加可使用资源。具体是对容器应用所在容器进行复制，以生成至少一个容器组副本，所生成的容器组副本中部署有该容器应用的实例，将作为新的部署有该容器应用的容器组，接收该容器应用对应的服务组件分发的访问流量，并对访问流量进行响应，以分担原容器应用所在容器组的访问流量压力。

在一些可选实施例中，响应于资源使用率出现增长，对容器应用所在容器组进行复制，以生成至少一个容器组副本，包括：响应于资源使用率出现增长，根据容器应用对应的预设指标，计算待生成的容器组副本的数量，并根据计算出的容器组副本的数量，对容器应用所在容器组进行复制。

可以理解，在本申请实施例中，对容器应用所在容器组进行复制时，需要先计算待生成的容器副本的数量，再根据计算出的容器组副本的数量，对容器应用所在容器组进行复制。

本方案实施例允许应用管理员为容器应用预先设置资源使用率指标，即容器应用对应的预设指标，包括但不限于CPU使用率指标、内存使用率指标。当容器应用所在容器组的资源使用率出现增长，超过容器应用对应的预设指标时，通过复制生成至少一个容器组副本，以分担原容器应用所在容器组的访问流量压力，使得容器应用所在容器组的资源使用率与预设指标保持一致。

进一步地，为了让容器应用所在容器组的资源使用率恢复至预设指标，一种可能的实现方式是，响应于资源使用率出现增长，根据容器应用对应的预设指标，计算待生成的容器组副本的数量，包括：响应于资源使用率出现增长，计算增长后的资源使用率与容器应用对应的预设指标之间的差值，并根据差值对应的资源需求量，计算待生成的容器组副本的数量。

首先，计算访问流量增长后容器应用所在容器组的资源使用率与预设指标之间的差值，以确定单个容器组增加的资源使用率，再根据单个容器组的资源占用，确定单个容器组增加的资源使用量。再根据容器应用所在全部容器组的数量，确定访问流量增长后容器应用整体增加的资源需求量，进而根据单个容器组副本能够满足的资源需求量，计算待生成的容器组副本的数量。

需要特别说明的是，由于单个容器组和容器组副本中维持容器组正常运行的相关进程也要占用一定的资源，因此在计算待生成的容器组副本的数量时，需要将这部分资源占用考虑在内。

在上述实施例中，需要先根据容器应用对应的预设指标，计算所需的容器组副本的数量，再对容器应用所在容器组进行复制，本申请实施例也可以不计算所需的容器副本的数量，而是动态地复制容器组副本。在一些可选实施例中，响应于资源使用率出现增长，对容器应用所在容器组进行复制，以生成至少一个容器组副本，包括：响应于资源使用率出现增长，对容器应用所在容器组进行复制，以生成单个容器组副本，直至容器应用所在容器组的资源使用率恢复至预设指标。

可以理解，在本申请实施例中，每当监测到容器应用的资源使用率超过容器应用的预设指标时，立即复制生成一个容器组副本，来分担原容器应用所在容器组的访问流量压力，从而使得容器应用所在容器组的资源使用率有所下降，如果复制一次后容器应用的资源使用率还是超过容器应用的预设指标，继续复制生成一个容器组副本，继续分担访问流量压力，直至容器应用所在容器组的资源使用率恢复至预设指标。也就是说，本申请实施例不先对所需的容器组副本的数量进行计算，而直接对容器应用所在容器组进行复制，通过反馈机制决定是否需要继续对容器应用所在容器组复制，在容器应用所在容器组的资源使用率恢复至预设指标之前，无法确定待生成的容器组副本的数量。

具体地，可以以Kubernetes系统为例进行说明，基于前述对背景技术的说明，可以知道，以Kubernetes系统为例的容器云平台的资源弹性伸缩主要依靠容器组水平自动扩缩机制调整部署应用实例的容器组副本数量，进而对应用可使用的资源进行扩缩。

如图2所示，本申请实施例对Kubernetes系统中用于实现容器组水平自动扩缩机制的容器组水平自动扩缩控制器进行功能拓展，称为容器组副本生成器，与容器组资源占用控制器和全局控制器一起作为可用资源控制器模块。

应用管理员在将容器应用部署在Kubernetes集群中的节点上以后，可以为容器应用设置对应的预设指标，上述的全局控制器可以通过访问Metrics-Server提供给的API接口获取该容器应用所在容器组的资源使用率，根据该容器应用对应的预设指标和该容器应用所在容器组的资源使用率，计算需要新增的容器组副本的数量，并指示RC/Deployment组件对该容器应用所在容器组进行复制，以生成至少一个容器组副本。

在RC/Deployment组件对该容器应用所在容器组进行复制，生成至少一个容器组副本后，由容器应用对应的服务组件将部分访问流量分发至新增的容器组副本，由新增的容器组副本分担原容器应用所在容器组的访问流量压力。

也就是说，容器组副本生成器是本申请实施例中具体实现容器组水平自动扩缩机制的组件。具体来说，当容器应用的访问流量增大时，增大的访问流量经由容器应用对应的服务组件分发至部署该容器应用所在容器组,使得该容器应用所在容器组的资源使用率增大，容器组副本生成器指示RC/Deployment组件对部署该容器应用的容器组进行复制，服务组件将部分访问流量分发至新增的容器组副本，使得部署该容器应用的容器组的资源使用率恢复至预先设置的资源使用率指标。同样，当该容器应用的访问流量减小时，容器组副本生成器将指示RC/Deployment组件对容器应用所在容器组的至少一个副本进行删除，在此不再一一赘述。

步骤S103、响应于资源使用率的增长率达到预设阈值，增大容器应用所在容器组的资源占用。

其中，预设阈值可以由应用管理员手动设定，也可以对资源使用率的历史数据进行分析后自动生成并动态调整，本申请实施例对此不做限定。

可以理解，基于对背景技术的说明，可以知道，对容器应用所在容器组进行复制所生成的至少一个容器组副本从开始创建到启动完成，能够对访问流量进行响应，需要一段时间，即存在“冷启动”问题，部署在容器组副本中的容器应用实例无法分担访问流量压力，在新生成的容器组副本启动完成之前，原容器应用所在容器组的资源使用率将不断升高，影响容器应用对访问流量的处理和响应能力。

因此，在访问流量增长过快的情况下，急需在短时间内提升容器应用的可使用资源，以提升容器应用对访问流量的处理和响应能力。

基于此，当监测到容器应用所在容器组的资源使用率的增长率达到预设阈值时，即容器应用的访问流量增长过快，需要增大该容器应用所在容器组的资源占用，以实现对现有容器组可使用资源的扩容，来增加整个容器应用的可使用资源，籍以对提升容器应用对访问流量的处理和响应能力。

基于此，本申请实施例通过增大容器应用所在容器组的资源占用的方式来实现对现有容器组可使用资源的扩容，具体为对该容器应用所在容器组设置更大的资源限制数值，使现有容器组无需重启即可增大可使用资源。

在一些可选实施例中，响应于资源使用率的增长率达到预设阈值，增大容器应用所在容器组的资源占用，具体为：响应于资源使用率的增长率达到预设阈值，设置容器应用所在容器组的资源占用增大至少一倍。

在本申请实施例中，在访问流量快速增长，而复制生成的容器组副本还未完全启动的情况下，通过增大容器应用所在容器组的资源占用，即对该容器应用所在容器组设置更大的资源限制数值，比如，将容器应用所在容器组的资源限制数值设置为当前资源限制数值的2倍，实现对容器应用可使用资源的快速扩容，使容器应用能够对新增访问流量进行快速响应。

需要说明的是，当资源使用率的增长率达到预设阈值时，说明对容器应用可使用资源的扩容已迫在眉睫，因此需要设置容器应用所在容器组的资源占用增大至少一倍，即至少变为当前资源限制数值的二倍，以防容器应用因可使用资源不足而发生故障。

进一步的，如果容器应用所在容器组所在节点的剩余可用资源小于容器应用所在容器组的资源占用，则设置容器应用所在容器组占满容器应用所在容器组所在节点的剩余可用资源。

在一种特殊的情况下，该容器应用所在容器组所在节点的剩余可用资源不足，即节点的剩余可用资源小于当前资源限制数值，此时，可以将节点剩余可用资源全部分配给该容器应用使用，但设置的资源限制数值不能超过节点剩余可用资源与当前资源限制数值之和，以防该容器应用被Kubernetes系统重调度至集群中的其他节点上，而导致容器应用因重调度而在一段时间内处于不可用状态。

在一些可选实施例中，在增大容器应用所在容器组的资源占用之后，还包括：当至少一个容器组副本启动完成后，减小容器应用所在容器组的资源占用。

在本申请实施例中，Kubernetes系统的Kubelet组件能够对容器组副本是否启动进行检测，当复制生成的容器组副本完全启动后，新生成的容器组副本就可以对访问流量进行响应。此时，可以将原容器应用所在容器组的资源限制数值进行恢复，避免将可使用资源和整个容器应用的故障风险集中在单个容器组上，有效避免因单个容器组发生故障而引起整个容器应用的故障和崩溃，降低整个容器应用运行过程中的风险系数。

具体地，可以以Kubernetes系统为例进行说明，如图2所示，本申请实施例在Kubernetes系统中增加容器组资源占用控制器来设置容器应用所在容器组的资源占用，容器组资源占用控制器与全局控制器、容器组副本生成器一起组成可用资源控制器模块。

全局控制器通过访问Metrics-Server提供的API接口获取容器应用所在容器组的资源使用情况，并以此计算出适合该容器应用所在容器组的资源限制数值，容器组资源占用控制器对该容器应用所在容器组设置计算出的资源限制数值，进而实现该容器应用所在容器组的资源弹性伸缩。

当容器应用的访问流量增大时，容器组资源占用控制器通过增大容器应用所在容器组的资源限制数值，来增加该容器应用可使用的资源，但当单个容器组的资源限制数值过大时，虽然能够实现增大该容器应用可使用的资源的目的，但被分发至该单个容器组的访问流量将非常大，一旦该单个容器组出现故障，对整个容器应用响应访问流量所产生的影响也非常大。此外，单个容器组本身也存在性能瓶颈，当单个容器组的访问流量过大时，整个系统的不确定性和崩溃风险都大大提高。因此在容器组副本启动完成后，需要减小容器应用所在容器组的资源限制数值，以降低前述风险，具体可以恢复至原数值。

进一步地，在本申请实施例中，根据容器应用所在容器组的资源使用历史数据，确定容器应用所在容器组的资源限制数值。具体地，收集容器应用所在容器组的多次资源限制数值调整的历史数据，确定在相同总资源量的条件下单个容器组的最佳资源占用(资源限制数值)设置，使得在总资源量一定的条件下，全部容器组能够响应最多的访问流量。

基于前述说明，可以知道，本申请实施例中的容器组可使用资源主要是CPU和内存，通过设置不同的CPU和内存的资源限制数值，以将相同总资源量分配给不同数量的容器组，通过对不同的资源限制数值进行组合，得到最佳资源占用设置。

为了更加清楚地说明本申请实施例所提出的容器云平台的容器组弹性扩容方法，下面以Kubernetes系统为例进行整体说明。

如图2所示，在Kubernetes系统中设置可用资源控制器模块来实现本申请实施例所提出的容器云平台的容器组弹性扩容方法。可用资源控制器模块包括全局控制器、容器组副本生成器和容器组资源占用控制器三个组件。容器组副本生成器用于根据容器应用所在容器组的资源使用情况自动伸缩部署容器应用实例的容器组副本的数量。容器组资源占用控制器用于根据容器应用所在容器组的资源使用情况自动调整容器应用所在容器组的资源限制数值。

具体地，把应用容器化部署在Kubernetes集群上后，应用管理员可以预先设置资源使用率指标，即容器应用对应的预设指标，包括但不限于CPU使用率指标、内存使用率指标，并由Metrics-Server对部署该应用的所有容器组实际使用的CPU、内存等资源的资源使用情况进行监测，全局控制器通过访问Metrics-Server提供的API接口获取部署容器应用所在容器中的资源使用情况，来间接监测容器应用的访问流量变化情况。

当容器应用的访问流量迅速增大时，容器组副本生成器通过对该容器应用所在容器组的数量进行调整，来对容器应用可使用的资源进行扩容。容器组资源占用控制器通过对该容器应用所在容器组设置资源限制数值，来对该容器应用可使用的资源进行扩容。

进一步地，通过在Kubernetes集群中部署全局控制器，通过访问Metrics-Server提供的API接口收集容器应用所在容器组的多次资源限制数值调整的历史数据，并以此计算出该容器应用所在容器组的最佳资源限制数值，容器组资源占用控制器对该容器应用所在容器组设置最佳资源限制数值，从而实现该容器应用所在容器组的资源最佳利用。

在本申请实施例中，在Kubernetes集群中通过部署全局控制器进行全局控制，实现容器应用所在容器组的资源弹性扩容，解决了在容器应用的访问流量增长过快时，新生成的容器组副本因存在“冷启动”问题使得部署在容器组副本中的容器应用实例无法分担访问流量压力的问题，实现了对容器应用可使用资源的快速扩容和容器应用在可使用资源扩容后对新增访问流量的快速响应，提高系统可靠性。

在本申请实施例中，Metrics-Server组件通过每个节点的Kubelet组件获取全部节点的所有容器组的资源使用情况，包括但不限于容器组的CPU、内存资源的实时使用情况。可用资源控制器模块中的全局控制器对Metrics-Server组件收集的容器应用所在容器组的资源使用率进行分析，判定是否需要对该容器应用能够使用的资源进行扩容，并指示容器组副本生成器和容器组资源占用控制器执行扩容操作。

此时，容器组副本生成器根据预先设置资源使用率指标和该容器应用所在容器组的资源使用率，计算需要新增的容器组副本的数量，并指示RC/Deployment组件对该容器应用所在容器组进行复制，以生成至少一个容器组副本。同时，容器组资源占用控制器设置容器应用所在容器组的资源限制数值增大至少一倍。需要说明的是，如果该容器应用所在容器组所在节点的剩余可用资源不足，即节点的剩余可用资源小于当前资源限制数值，则将资源限制数值设置为当前资源限制数值与节点剩余可用资源之和。

在此需要指出的是，如果可用资源控制器模块中的全局控制器对Metrics-Server组件收集的容器应用所在容器组的资源使用率进行分析，检测到某个容器应用所在容器组的资源使用率出现缓慢增长的情况，则只需要依靠容器组水平自动扩缩机制对该容器组进行资源扩容即可，即容器组副本生成器根据预先设置资源使用率指标和该容器应用所在容器组的资源使用率，计算需要新增的容器组副本数量，指示RC/Deployment组件对该容器应用所在容器组进行复制，以生成至少一个容器组副本。容器组资源占用控制器无需执行任何操作。

在一具体的应用场景中，Kubernetes集群中，单个容器组能够使用的资源为1单位CPU和1G内存，可以响应100单位的访问流量，通常情况下，容器应用的访问流量为1000单位，需要10个容器组进行响应。

当访问流量在短时间内突然增加至10000单位时，如果单独采用容器组水平自动扩缩机制对容器应用所在容器组进行资源扩容，需要将容器应用所在容器组的数量增加至100个，新增的90个容器组副本因存在“冷启动”问题而无法在立即完成启动，在容器组副本启动完成前容器应用只能对1000单位的访问流量进行正常响应，剩余9000单位的访问流量无法正常响应。

当访问流量在短时间内突然增加至10000单位时，如果单独采用增大容器组的资源占用的方式对容器应用所在容器组进行资源扩容，需要将容器应用所在容器组能够使用的资源增加至10单位CPU和10G内存，单个容器组使用的资源过大，单个容器组出现故障将导致1000单位的访问流量受影响。

为了克服上述两种扩容方式存在的弊端，当访问流量在短时间内突然增加至10000单位时，可以在将单个容器应用所在容器组可使用的资源增大至10单位CPU和10G内存的同时，创建并运行90个容器组副本，当新增的90个容器组副本启动完成且能够对访问流量进行响应时，再将原有的10个容器应用所在容器组可使用的资源减小至1单位CPU和1G内存，最终使得100个可使用的资源为1单位CPU和1G内存的容器组或者容器组副本都能够对访问流量进行响应，并且避免了容器组水平自动扩缩机制存在的“冷启动”问题。

示例性系统

图3为根据本申请的一些实施例提供的一种容器云平台的容器组弹性扩容系统的结构示意图；如图3所示，该容器云平台的容器组弹性扩容系统包括：资源监测单元301，配置为对容器应用所在容器的资源使用率进行监测；复制单元302，配置为响应于资源使用率出现增长，对容器应用所在容器进行复制，以生成至少一个容器副本；扩容单元303，配置为响应于资源使用率增长达到预设阈值，增大容器应用所在容器的资源占用。

本申请实施例提供的容器云平台的容器组弹性扩容系统能够实现上述任一实施例的容器云平台的容器组弹性扩容方法的步骤、流程，并达到相同的技术效果，在此不再一一赘述。

示例性设备

图4为根据本申请的一些实施例提供的电子设备的结构示意图；如图4所示，该电子设备包括：

一个或多个处理器401；

计算机可读介质，可以配置为存储一个或多个程序402，一个或多个处理器401执行一个或多个程序402时，实现如下步骤：对容器应用所在容器的资源使用率进行监测；响应于资源使用率出现增长，对容器应用所在容器进行复制，以生成至少一个容器副本；响应于资源使用率的增长率达到预设阈值，增大容器应用所在容器的资源占用。

图5为根据本申请的一些实施例提供的电子设备的硬件结构，如图5所示，该电子设备的硬件结构可以包括：处理器501、通信接口502、计算机可读介质503和通信总线504。

其中，处理器501、通信接口502、计算机可读介质503通过通信总线504完成相互间的通信。

可选地，通信接口502可以为通信模块的接口，如GSM模块的接口。

其中，处理器501具体可以配置为：对容器应用所在容器的资源使用率进行监测；响应于资源使用率出现增长，对容器应用所在容器进行复制，以生成至少一个容器副本；响应于资源使用率的增长率达到预设阈值，增大容器应用所在容器的资源占用。

处理器501可以是通用处理器，包括中央处理器(central processing unit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如：iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

需要指出，根据实施的需要，可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的容器云平台的容器组弹性扩容方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其它实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述得设备及系统实施例仅仅是示意性的，其中作为分离不见说明的单元可以使或者也可以不是物理上分开的，作为单元提示的不见可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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

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

Claims (10)

1.一种容器云平台的容器组弹性扩容方法，其特征在于，包括：

对容器应用所在容器组的资源使用率进行监测；

响应于所述资源使用率出现增长，对所述容器应用所在容器组进行复制，以生成至少一个容器组副本；

响应于所述资源使用率的增长率达到预设阈值，增大所述容器应用所在容器组的资源占用。

2.根据权利要求1所述的容器云平台的容器组弹性扩容方法，其特征在于，所述容器云平台为Kubernetes系统，所述对容器应用所在容器组的资源使用率进行监测，具体为：所述Kubernetes系统的Kubelet组件对所述容器应用所在容器组的资源使用率进行收集，并发送至所述Kubernetes系统的Metrics-Server组件，所述Metrics-Server组件对所述资源使用率进行监测。

3.根据权利要求1所述的容器云平台的容器组弹性扩容方法，其特征在于，响应于所述资源使用率出现增长，对所述容器应用所在容器组进行复制，以生成至少一个容器组副本，包括：

响应于所述资源使用率出现增长，根据所述容器应用对应的预设指标，计算待生成的所述容器组副本的数量；

根据计算出的所述容器组副本的数量，对所述容器应用所在容器组进行复制。

4.根据权利要求3所述的容器云平台的容器组弹性扩容方法，其特征在于，所述响应于所述资源使用率出现增长，根据所述容器应用对应的预设指标，计算待生成的所述容器组副本的数量，包括：

响应于所述资源使用率出现增长，计算增长后的资源使用率与所述容器应用对应的预设指标之间的差值；

根据所述差值对应的资源需求量，计算待生成的所述容器组副本的数量。

5.根据权利要求1所述的容器云平台的容器组弹性扩容方法，其特征在于，所述响应于所述资源使用率的增长率达到预设阈值，增大所述容器应用所在容器组的资源占用，具体为：

响应于所述资源使用率的增长率达到预设阈值，设置所述容器应用所在容器组的资源占用增大至少一倍。

6.根据权利要求5所述的容器云平台的容器组弹性扩容方法，其特征在于，所述容器云平台的容器组弹性扩容方法还包括：

如果所述容器应用所在容器组所在节点的剩余可用资源小于所述容器应用所在容器组的资源占用，则设置所述容器应用所在容器组占满所述容器应用所在容器组所在节点的剩余可用资源。

7.根据权利要求1-6中任一项所述一种容器云平台的容器组弹性扩容方法，其特征在于，在所述增大所述容器应用所在容器的资源占用之后，还包括：

当至少一个所述容器组副本启动完成后，减小所述容器应用所在容器组的资源占用。

8.一种容器云平台的容器组弹性扩容系统，其特征在于，包括：

资源监测单元，配置为对容器应用所在容器组的资源使用率进行监测；

复制单元，配置为响应于所述资源使用率出现增长，对所述容器应用所在容器组进行复制，以生成至少一个容器组副本；

扩容单元，配置为响应于所述资源使用率的增长率达到预设阈值，增大所述容器应用所在容器组的资源占用。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序为如权利要求1-7任一所述的容器云平台的容器组弹性扩容方法。

10.一种电子设备，其特征在于，包括：存储器、处理器、以及存在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如权利要求1-7任一所述的容器云平台的容器组弹性扩容方法。

Images