资源回收方法、装置、设备、介质和程序产品

技术领域

本公开涉及容器技术领域，特别是涉及一种资源回收方法、装置、设备、介质和程序产品。

背景技术

随着云平台的迅猛发展，能够简化应用程序的构建、部署以及运行过程的容器(Container)技术应运而生，使得越来越多的应用程序得以实现“容器化”，需要由资源申请者申请计算资源，实现容器的启动和部署，将应用程序整合到容器中并且运行。在研发环境中，对计算资源的申请量呈几何级地速度增长，加剧了原本就相对有限的资源供给量与不断增长的资源需求量之间的矛盾。

在相关技术中也提供了一些通过对资源进行回收，以便于其他资源申请者对资源的申请来缓解上述资源供需矛盾的解决方案，例如由资源申请者主动归还，或到期归还。但是在实现本公开构思的过程中，发明人发现现有技术中至少存在如下问题：这些“被动式”的资源回收方式，依然存在资源不合理的占用，或者闲置资源的浪费的问题。

发明内容

有鉴于此，为了至少部分地克服相关技术利用“被动式”的资源回收方式存在的上述技术问题，本公开提供了一种“主动式”的资源回收方式，可以提高容器的资源回收效率，避免资源的不合理占用，加速闲置资源的滚动。本公开提供了一种用于容器的资源回收方法、装置、设备、介质和程序产品。

为了实现上述目标，本公开的一个方面提供了一种用于容器的资源回收方法，该方法可以包括：采集目标容器的性能指标数据，其中，上述性能指标数据用于表征上述目标容器的资源使用情况，上述目标容器为运行其中的应用程序提供计算资源，采集上述目标容器的运行环境数据，其中，上述运行场景用于表征上述目标容器的硬件运行环境和软件运行环境，基于对上述性能指标数据和/或上述运行场景数据的统计结果，确定上述目标容器是否满足资源回收条件，以及若满足上述资源回收条件，则回收上述目标容器的资源。

根据本公开的实施例，上述采集目标容器的性能指标数据可以包括：采集目标容器与处理器资源对应的第一性能指标数据，采集目标容器与内存资源对应的第二性能指标数据，采集目标容器与文件系统资源对应的第三性能指标数据，以及采集目标容器与网络资源对应的第四性能指标数据。

根据本公开的实施例，上述基于对上述性能指标数据的统计结果，确定上述目标容器是否满足资源回收条件可以包括：基于对上述第一性能指标数据在第一统计周期内的统计结果，确定与上述处理器资源对应的第一波动值，基于对上述第二性能指标数据在第二统计周期内的统计结果，确定与上述内存资源对应的第二波动值，基于对上述第三性能指标数据在第三统计周期内的统计结果，确定与上述文件系统资源对应的第三波动值，基于对上述第四性能指标数据在第四统计周期内的统计结果，确定与上述网络资源对应的第四波动值，以及基于上述第一波动值、上述第二波动值、上述第三波动值和上述第四波动值，确定上述目标容器是否满足资源回收条件，其中，上述第一统计周期、第二统计周期、第三统计周期以及第四统计周期可以相同，也可以不相同。

根据本公开的实施例，上述基于上述第一波动值、上述第二波动值、上述第三波动值和上述第四波动值，确定上述目标容器是否满足资源回收条件可以包括：在上述第一波动值小于第一阈值的情况下，确定上述处理器资源满足资源回收条件，在上述第二波动值小于第二阈值的情况下，确定上述内存资源满足资源回收条件，在上述第三波动值小于第三阈值的情况下，确定上述文件系统资源满足资源回收条件，在上述第四波动值小于第四阈值的情况下，确定上述网络资源满足资源回收条件，以及在上述处理器资源、上述内存资源、上述文件系统资源以及上述网络资源中的至少两种满足资源回收条件的情况下，确定上述目标容器是否满足资源回收条件，其中，上述第一阈值、第二阈值、第三阈值以及第四阈值可以相同，也可以不相同。

根据本公开的实施例，上述采集上述目标容器的运行环境数据可以包括：采集上述目标容器与日志指标对应的日志数据，以及采集上述目标容器的版本数据，其中，上述版本数据用于表征上述应用程序的版本信息。

根据本公开的实施例，上述基于对上述运行场景数据的统计结果，确定上述目标容器是否满足资源回收条件可以包括：基于对上述日志数据在第五统计周期内的统计结果，确定与上述日志指标对应的第五波动值，以及基于上述第五波动值和上述版本数据，确定上述目标容器是否满足资源回收条件，其中，上述第五统计周期与上述第一统计周期、第二统计周期、第三统计周期以及第四统计周期可以相同，也可以不相同。

根据本公开的实施例，上述基于上述第五波动值和上述版本数据，确定上述目标容器是否满足资源回收条件可以包括：在上述第五波动值小于第五阈值的情况下，确定上述目标容器满足资源回收条件，以及在上述版本数据表征与上述应用程序的版本信息不一致的情况下，确定上述目标容器满足资源回收条件，其中，上述第五阈值与上述第一阈值、第二阈值、第三阈值以及第四阈值可以相同，也可以不相同。

根据本公开的实施例，上述回收上述目标容器的资源可以包括：按照回收优先级，先释放上述目标容器占用的处理器资源和内存资源，以及在上述文件系统资源占用超过预设时长的情况下，释放上述目标容器对上述文件系统资源的占用。

为了实现上述目标，本公开的另一个方面提供了一种用于容器的资源回收装置，该装置可以包括：第一采集模块，用于采集目标容器的性能指标数据，其中，上述性能指标数据用于表征上述目标容器的资源使用情况，上述目标容器为运行其中的应用程序提供计算资源，第二采集模块，用于采集上述目标容器的运行环境数据，其中，上述运行场景用于表征上述目标容器的硬件运行环境和软件运行环境，确定模块，用于基于对上述性能指标数据和/或上述运行场景数据的统计结果，确定上述目标容器是否满足资源回收条件，以及回收模块，用于若满足上述资源回收条件，则回收上述目标容器的资源。

根据本公开的实施例，上述第一采集模块可以包括：第一采集子模块，用于采集目标容器与处理器资源对应的第一性能指标数据，第二采集子模块，用于采集目标容器与内存资源对应的第二性能指标数据，第三采集子模块，用于采集目标容器与文件系统资源对应的第三性能指标数据，以及第四采集子模块，用于采集目标容器与网络资源对应的第四性能指标数据。

根据本公开的实施例，上述确定模块可以包括：第一波动值确定子模块，用于基于对上述第一性能指标数据在第一统计周期内的统计结果，确定与上述处理器资源对应的第一波动值，第二波动值确定子模块，用于基于对上述第二性能指标数据在第二统计周期内的统计结果，确定与上述内存资源对应的第二波动值，第三波动值确定子模块，用于基于对上述第三性能指标数据在第三统计周期内的统计结果，确定与上述文件系统资源对应的第三波动值，第四波动值确定子模块，用于基于对上述第四性能指标数据在第四统计周期内的统计结果，确定与上述网络资源对应的第四波动值，以及第一回收条件确定子模块，用于基于上述第一波动值、上述第二波动值、上述第三波动值和上述第四波动值，确定上述目标容器是否满足资源回收条件，其中，上述第一统计周期、第二统计周期、第三统计周期以及第四统计周期可以相同，也可以不相同。

根据本公开的实施例，上述第一回收条件确定子模块可以包括：第一回收条件确定单元，用于在上述第一波动值小于第一阈值的情况下，确定上述处理器资源满足资源回收条件，第二回收条件确定单元，用于在上述第二波动值小于第二阈值的情况下，确定上述内存资源满足资源回收条件，第三回收条件确定单元，用于在上述第三波动值小于第三阈值的情况下，确定上述文件系统资源满足资源回收条件，第四回收条件确定单元，用于在上述第四波动值小于第四阈值的情况下，确定上述网络资源满足资源回收条件，以及第五回收条件确定单元，用于在上述处理器资源、上述内存资源、上述文件系统资源以及上述网络资源中的至少两种满足资源回收条件的情况下，确定上述目标容器是否满足资源回收条件，其中，上述第一阈值、第二阈值、第三阈值以及第四阈值可以相同，也可以不相同。

根据本公开的实施例，上述第二采集模块可以包括：第五采集子模块，用于采集上述目标容器与日志指标对应的日志数据，以及第六采集子模块，用于采集上述目标容器的版本数据，其中，上述版本数据用于表征上述应用程序的版本信息。

根据本公开的实施例，上述确定模块可以包括：第五波动值确定子模块，用于基于对上述日志数据在第五统计周期内的统计结果，确定与上述日志指标对应的第五波动值，以及第二回收条件确定子模块，用于基于上述第五波动值和上述版本数据，确定上述目标容器是否满足资源回收条件，其中，上述第五统计周期与上述第一统计周期、第二统计周期、第三统计周期以及第四统计周期可以相同，也可以不相同。

根据本公开的实施例，上述第二回收条件确定子模块可以包括：第六回收条件确定单元，用于在上述第五波动值小于第五阈值的情况下，确定上述目标容器满足资源回收条件，以及第七回收条件确定单元，用于在上述版本数据表征与上述应用程序的版本信息不一致的情况下，确定上述目标容器满足资源回收条件，其中，上述第五阈值与上述第一阈值、第二阈值、第三阈值以及第四阈值可以相同，也可以不相同。

根据本公开的实施例，上述回收模块可以包括：第一释放子模块，用于按照回收优先级，先释放上述目标容器占用的处理器资源和内存资源，以及第二释放子模块，用于在上述文件系统资源占用超过预设时长的情况下，释放上述目标容器对上述文件系统资源的占用。

为了实现上述目标，本公开的另一方面提供了一种电子设备，包括：一个或多个处理器，存储器，用于存储一个或多个程序，其中，当上述一个或多个程序被上述一个或多个处理器执行时，使得上述一个或多个处理器实现如上所述的用于容器的资源回收方法。

为了实现上述目标，本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，上述指令在被执行时用于实现如上所述的用于容器的资源回收方法。

为了实现上述目标，本公开的另一方面提供了一种计算机程序，上述计算机程序包括计算机可执行指令，上述指令在被执行时用于实现如上所述的用于容器的资源回收方法。

根据本公开提供的一种“主动式”的资源回收方式，不仅能够实时监控获得容器的性能数据，还可以根据性能数据的分析结果，确定该容器是否符合资源回收条件，若符合则将该容器资源及时进行回收，可以至少部分地克服相关技术中由资源申请者主动归还资源，或者到期归还资源的那些“被动式”的资源回收方式，导致资源不合理被占用，或者闲置资源被浪费的技术问题，并因此可以实现容器资源的及时回收，不仅可以避免闲置资源被不合理占用造成的资源浪费，还可以解除资源归还对人工的依赖，实现资源释放的自动化，提高容器资源的回收效率的技术效果。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了适用于本公开实施例的可以应用于容器的资源回收方法和装置的应用场景；

图2示意性示出了根据本公开实施例的可以应用于容器的资源回收方法的流程图；

图3示意性示出了根据本公开另一实施例的可以应用于容器的资源回收方法的流程图；

图4示意性示出了根据本公开另一实施例的可以应用于容器的资源回收方法的流程图；

图5示意性示出了根据本公开实施例的可以应用于容器的资源回收装置的框图；

图6示意性示出了根据本公开实施例的适于实现上文描述的可以应用于容器的资源回收方法的计算机可读存储介质产品的示意图；以及

图7示意性示出了根据本公开实施例的适于实现上文描述的可以应用于容器的资源回收方法的电子设备的框图。

在附图中，相同或对应的标号表示相同或对应的部分。

应该注意的是，附图并未按比例绘制，并且出于说明目的，在整个附图中类似结构或功能的元素通常用类似的附图标记来表示。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了上述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

附图中示出了一些方框图和/或流程图。应理解，方框图和/或流程图中的一些方框或其组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其他可编程容器资源回收装置的处理器，从而这些指令在由该处理器执行时可以创建用于实现这些方框图和/或流程图中所说明的功能/操作的装置。本公开的技术可以硬件和/或软件(包括固件、微代码等)的形式来实现。本公开的技术可以采取存储有指令的计算机可读存储介质上的计算机程序产品的形式，该计算机程序产品可供指令执行系统使用或者结合指令执行系统使用。

容器云是近两年在云计算中新兴的一种产品形态，容器在计算形态上是一种轻量级的虚拟化技术，容器服务是进程级的虚拟化形态封装，容器的启动和部署迅速，能够在应用层面根据资源需求快速部署和调度，生命周期变化速度快。将应用整合到容器中并且运行起来的过程称之为“容器化”，容器是为应用而生的，具体来说，容器能够简化应用的构建、部署和运行过程。相关技术所提供的资源回收方法，需要人工干预进行处理或在资源到期后回收，使得已经闲置但是尚未到期的资源无法及时回收再利用，导致闲置资源被不合理的占用，无法及时滚动，同时其他资源申请者容器也无法去申请这些原本可以被利用的浪费，严重影响资源的利用率。

因此，本公开提供了一种可以应用于容器的资源回收方法，该回收方法可以包括数据采集阶段和资源回收阶段。其中在数据采集阶段，一方面需要采集目标容器的性能指标数据，该性能指标数据用于表征目标容器的资源使用情况，目标容器为运行其中的应用程序提供计算资源，另一方面还需要采集目标容器的运行环境数据，该运行场景用于表征目标容器的硬件运行环境和软件运行环境。在资源回收阶段，首先要基于对性能指标数据和/或运行场景数据的统计结果，确定目标容器是否满足资源回收条件，其次要在满足资源回收条件的情况下，回收目标容器的资源，实现资源的及时回收。

由于本公开提供的是一种“主动式”的资源回收方式，不仅能够实时监控获得每个容器的性能数据，还可以根据性能数据的分析结果，确定符合资源回收条件的容器，并将该容器资源及时进行回收，因此通过本公开不仅可以至少部分地克服相关技术中由资源申请者主动归还资源，或者到期归还资源的那些“被动式”的资源回收方式，导致资源不合理被占用，或者闲置资源被浪费的技术问题，还可以至少部分地实现容器资源的及时回收，以实现不仅可以避免闲置资源被不合理占用造成的资源浪费，还可以解除资源归还对人工的依赖，使得自动化释放资源，提高容器资源的回收效率的技术效果。

需要说明的是，本公开提供的用于容器的资源回收方法和装置可以用于金融领域中，也可以用于除金融领域之外的任意领域中。因此，对本公开所提供的用于容器的资源回收方法和装置的应用领域不做限定。

图1示意性示出了适用于本公开实施例的可以应用于容器的资源回收方法和装置的应用场景100。需要注意的是，图1所示仅为可应用本公开实施例的应用场景的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他应用场景。

如图1所示，可以应用于容器的资源回收方法和装置的应用场景100可以包括容器集中监控管理平台110、容器120以及应用程序130。

图1所示的容器集中监控管理平台110可以集成有容器监控平台111、日志平台112、应用版本管理系统113以及监控回收功能模块114。其中，容器监控平台111可以是容器虚拟化的监控平台1111，也可以是自研容器性能监控平台1112。容器监控平台111用于通过容器虚拟化的监控平台1111或者自研容器性能监控平台1112，提供容器动态指标对应的指标数据，动态指标可以包括但不限于CPU、内存、文件系统和网络流量。日志平台112用于提供容器日志，包括但不限于操作日志、系统日志以及应用日志。应用版本管理系统113用于提供容器所在的版本信息。监控回收功能模块114用于提供容器相关数据的采集功能和资源回收决策和执行功能，以实现资源是否回收的决策以及自动回收，提高资源利用率。

图1所示的容器120可以是部署在云平台上的多个容器，可以包括但不限于容器121、容器122、容器123、容器124、容器125以及容器126。容器可以是Linux容器，该容器基于内核轻量级的操作系统层虚拟化技术，是开发、部署和管理应用方式的又一次飞跃，主要由起到隔离作用的命名空间(Namespace)和起到资源管理控制作用的Cgroup(ControlGroups)这两大机制来保证实现。Linux容器镜像提供了可移植性和版本控制，确保能够在开发人员的笔记本电脑上运行的应用，同样也能在生产环境中正常运行。相较于虚拟机，Linux容器在运行时所占用的资源更少，使用的是标准接口(启动、停止、环境变量等)，并会与应用隔离开；此外，作为(包含多个容器)大型应用的一部分时更加易于管理，而且这些多容器应用可以跨多个云环境进行编排。容器也可以是Docker容器，Docker通过Cgroup来控制容器使用的资源配额，包括CPU、内存(Memory)和磁盘三大方面，基本覆盖常见的资源配额和使用量控制。Cgroup是Linux内核提供的一种可以限制、记录、隔离进程组所使用的物理资源，可以包括但不限于CPU、Memory、磁盘输入/输出(Input/Output，I/O)，被LXC、Docker等很多项目用于实现进程资源控制。容器还可以是其他容器。需要说明的是，上述多个容器可以是相同类型的容器，也可以是不同类型的容器。

图1所示的应用程序130可以是整合在容器中的应用程序，可以包括但不限于应用程序131、应用程序132、应用程序133、应用程序134、应用程序135以及应用程序136。其中应用程序131可以整合在容器121中，应用程序132可以整合在容器122中，应用程序133可以整合在容器123中，应用程序134可以整合在容器124中，应用程序135可以整合在容器125中，应用程序136可以整合在容器126中。

需要说明的是，根据应用程序的实际情况，一个应用程序可以整合在一个容器中，也可以整合在多个容器中，图1仅示出一个应用程序整合在一个容器中的情况，但是并不应该被理解为对应用程序与容器这两者整合关系数量的一种限定。图1中所示的容器和应用程序的数量仅仅是示意性的。根据实现需要，可以具有任意数量的容器和应用程序，本公开对此不做限定。

图2示意性示出了根据本公开实施例的可以应用于容器的资源回收方法的流程图。如图2所示，该方法200可以包括操作S210～操作S240。

在操作S210，采集目标容器的性能指标数据。

根据本公开的实施例，容器是与系统其他部分隔离开的一系列进程，则可共享同一个操作系统内核，将应用进程与系统其他部分隔离开来。目标容器可以是部署在云平台上多个容器中的任意一个容器。例如可以是LXC容器、也可以是Docker容器。

根据本公开的实施例，性能指标数据用于表征目标容器的资源使用情况，目标容器为运行其中的应用程序提供计算资源。

需要说明的是，在默认情况下，每个Docker容器的CPU份额都是1024kb，单独一个容器的份额是没有意义的，只有在同时运行多个容器时，容器的CPU加权的效果才能体现出来。例如，两个容器A、B的CPU份额分别为1000kb和500kb，在CPU进行时间片分配的时候，容器A比容器B多一倍的机会获得CPU的时间片，但分配的结果取决于当时主机和其他容器的运行状态，实际上也无法保证容器A一定能获得CPU时间片。比如容器A的进程一直是空闲的，那么容器B是可以获取比容器A更多的CPU时间片的。极端情况下，比如说主机上只运行一个容器，即使它的CPU份额只有50kb，它也可以独占整个主机的CPU资源。因此Cgroup只有在容器分配的资源紧缺时，也就是说在需要对容器使用的资源进行限制时才会生效。因此无法单独根据某个容器的CPU份额来确定有多个CPU资源分配给它，资源分配结果取决于同时运行的其他容器的CPU分配和容器中进程的运行情况。

根据本公开的实施例，可以按照一定的采集频率，通过图1中所示的容器监控平台111中的容器虚拟化的监控平台1111采集目标容器的性能指标数据，也可以通过图1中所示的容器监控平台111中的自主研发的容器性能监控平台1112采集目标容器的性能指标数据。例如，可以每秒采集性能指标数据。例如，可以每秒从容器虚拟化的监控平台或自研容器性能监控平台中采集容器的CPU指标数、内存指标数据和文件系统指标数据。本公开中的采集频率可以根据情况人为设定。

在操作S220，采集目标容器的运行环境数据。

根据本公开的实施例，运行场景用于表征目标容器的硬件运行环境和软件运行环境。其中硬件运行环境可以为该容器是否被执行启动操作、销毁操作、以及其他操作情况，软件运行环境可以为该容器中所运行的应用程序的软件信息，包括但不限于版本信息。运行环境数据可以是容器的日志数据和版本数据，其中日志数据可以包括但不限于应用日志、系统日志和用户日志。

根据本公开的实施例，可以按照一定的采集频率采集目标容器的运行环境数据。例如，可以每分钟从日志平台，采集容器的应用日志，系统日志，用户日志，可以每小时从版本信息管理系统，采集容器的所在版本。需要说明的是，应用日志和容器的所在版本的采集频率可以相同，也可以不同，采集频率可以根据容器的生命周期数据确定，也可以根据人为经验确定，本公开对此不做限定。

在操作S230，基于对性能指标数据和/或运行场景数据的统计结果，确定目标容器是否满足资源回收条件。

根据本公开的实施例，可以基于对性能指标数据的统计结果，确定目标容器是否满足资源回收条件。具体实施时，在性能指标数据的统计结果表征目标容器的计算资源使用率低，且使用率变化波动小时，表明计算资源已经使用完成，或在一定统计周期内处于未被使用的状态，此时则可以确定目标容器满足资源回收条件，而在统计结果表征目标容器的计算资源使用率高，且使用率变化波动小时，表明计算资源并未使用完成，或在一定统计周期内处于正在使用的状态，此时则可以确定目标容器不满足资源回收条件。

根据本公开的实施例，可以基于对运行场景数据的统计结果，确定目标容器是否满足资源回收条件。具体实施时，在运行场景数据的统计结果表征目标容器的硬件或软件资源使用率低，且使用率变化波动小时，表明硬件或软件资源已经使用完成，或在一定统计周期内处于未被使用的状态，此时则可以确定目标容器满足资源回收条件，而在统计结果表征目标容器的硬件或软件资源使用率高，且使用率变化波动小时，表明硬件或软件资源并未使用完成，或在一定统计周期内处于正在使用的状态，此时则可以确定目标容器不满足资源回收条件。

根据本公开的实施例，还可以基于对性能指标数据和运行场景数据的统计结果，确定目标容器是否满足资源回收条件。具体实施时，在性能指标数据的统计结果表征目标容器的计算资源使用率低，且使用率变化波动小，在运行场景数据的统计结果表征目标容器的硬件或软件资源使用率低，且使用率变化波动小时，表明计算资源、硬件或软件资源已经使用完成，或在一定统计周期内处于未被使用的状态，此时则可以确定目标容器满足资源回收条件，而在统计结果表征目标容器的计算资源使用率高，使用率变化波动小时，在统计结果表征目标容器的硬件或软件资源使用率高，且使用率变化波动小时，表明计算资源、硬件或软件资源并未使用完成，或在一定统计周期内处于正在使用的状态，此时则可以确定目标容器不满足资源回收条件。

需要说明的是，虽然资源使用率的高和低是相对的，但是为了实施方便，在具体实施时可以为资源使用率设置阈值，来确定资源使用率的高和低，以便将使用率的高低进行量化。例如，对内存指标为例，可以设置内存资源使用率的第一阈值50％和第二阈值10％，若内存使用率高于第一阈值50％，则可以确定内存资源使用率高，若内存使用率低于第二阈值10％，则可以确定内存资源使用率低。可以理解的是，根据资源指标的不同，相应的资源使用率的阈值可以相同，也可以不同，本公开对此不做限定。

在操作S240，若满足资源回收条件，则回收目标容器的资源。

根据本公开的实施例，由于目标容器向平台申请的资源主要是为运行在其中的应用程序提供的计算资源，因此对目标容器的资源回收自然也是针对之前申请到的那些计算资源，可以包括但不限于CPU、内存(Memory)、磁盘资源和网络资源。具体实施容器资源回收时的回收流程可以是将该容器下线，删除该容器，以释放其所在宿主机的资源，最后删除与该容器相关系统的台账信息，这样就可以及时回收资源，使得被回收的资源可以提供给其他容器申请试用。

通过本公开的实施例，提供了一种“主动式”的资源回收方式，不仅能够实时监控获得容器的性能数据，还可以根据性能数据的分析结果，确定该容器是否符合资源回收条件，若符合则将该容器资源及时进行回收，可以至少部分地克服相关技术中由资源申请者主动归还资源，或者到期归还资源的那些“被动式”的资源回收方式，导致资源不合理被占用，或者闲置资源被浪费的技术问题，并因此可以实现容器资源的及时回收，不仅可以避免闲置资源被不合理占用造成的资源浪费，还可以解除资源归还对人工的依赖，实现资源释放的自动化，提高容器资源的回收效率的技术效果。

作为一种可选的实施例，前述操作S210(采集目标容器的性能指标数据)可以包括：采集目标容器与处理器资源对应的第一性能指标数据。采集目标容器与内存资源对应的第二性能指标数据。采集目标容器与文件系统资源对应的第三性能指标数据。以及采集目标容器与网络资源对应的第四性能指标数据。

根据本公开的实施例，性能指标可以是容器的动态指标，与动态指标对应的动态指标数据可以用于表征所述目标容器的资源使用情况。可选地，动态指标可以包括但不限于容器CPU指标、容器内存指标、容器文件系统指标以及容器网络指标。

可选地，容器CPU指标可以包括但不限于系统CPU累积占用时间(container_cpu_system_seconds_total，单位：秒)，用户CPU累积占用时间(container_cpu_user_seconds_total，单位：秒)，容器在每个CPU内核上的累积占用时间(container_cpu_usage_seconds_total，单位：秒)。可选地，容器内存指标可以包括但不限于容器的最大内存使用量(container_memory_max_usage_bytes，单位：字节)，容器当前的内存使用量(container_memory_usage_bytes，单位：字节)，容器的内存使用量限制(container_spec_memory_limit_bytes)，以及当前主机的内存总量(machine_memory_bytes)。可选地，容器文件系统指标可以包括但不限于容器中文件系统的使用量(container_fs_usage_byte，单位：字节)，容器可以使用的文件系统总量(container_fs_limit_bytes，单位：字节)，容器累积读取数据的总量(container_fs_reads_bytes_total，单位：字节)，以及容器累积写入数据的总量(container_fs_writes_bytes_total，单位：字节)。可选地，容器网络指标可以包括但不限于容器网络累积接收数据总量(container_network_receive_bytes_total，单位：字节)，以及容器网络累积传输数据总量(container_network_transmit_bytes_to tal，单位：字节)。

本公开的实施例从表征目标容器的资源使用情况的角度考虑数据采集的广度和深度，分别采集与处理器资源对应的第一性能指标数据、与内存资源对应的第二性能指标数据、与文件系统资源对应的第三性能指标数据以及与网络资源对应的第四性能指标数据，基于处理器资源、内存资源、文件系统资源以及网络资源的多维度的指标数据，为资源使用情况提供多维度的数据支撑，有助于提高回收决策的准确性。

作为一种可选的实施例，前述操作S230(基于对性能指标数据的统计结果，确定目标容器是否满足资源回收条件)可以包括：基于对第一性能指标数据在第一统计周期内的统计结果，确定与处理器资源对应的第一波动值。基于对第二性能指标数据在第二统计周期内的统计结果，确定与内存资源对应的第二波动值。基于对第三性能指标数据在第三统计周期内的统计结果，确定与文件系统资源对应的第三波动值。基于对第四性能指标数据在第四统计周期内的统计结果，确定与网络资源对应的第四波动值。以及基于第一波动值、第二波动值、第三波动值和第四波动值，确定目标容器是否满足资源回收条件，其中，第一统计周期、第二统计周期、第三统计周期以及第四统计周期可以相同，也可以不相同。

根据本公开的实施例，执行操作S230前，还需要统计性能指标数据，以获得统计结果，该统计结果的获取过程描述为：针对多个性能指标，以多个时间周期为时间统计维度进行指标数据的统计和分析，可以得到在多个时间周期内与每个性能指标对应的性能指标数据的统计值，即性能指标数据的统计结果。多个时间周期可以是1天，2天，3天，也可以是1天，2天，3天，4天和5天，可以根据不同的性能指标选择时间周期的数量，本公开对此不做限定。通常时间周期的数量越多，统计数据的样本越多，统计结果的可信度也会越高，但是考虑到计算效率，并保证统计结果的合理性和有效性，时间周期通常不会超过30天。下面以1天，2天，3天，4天和5天为时间周期，计算CPU的使用率、内存的使用量、文件系统的读取写入量、网络接收和发送数据量为例，简要阐述如何获得性能指标数据的统计结果。

具体实施时，针对容器CPU指标中的CPU累积占用时间进行统计，可以得到系统CPU在1天，2天，3天，4天，5天内的累积占用时间，用户CPU在1天，2天，3天，4天，5天内的累积占用时间以及容器CPU在1天，2天，3天，4天，5天内的累积占用时间。针对容器内存指标中的容器当前的内存使用量进行统计，可以得到在1天，2天，3天，4天，5天内的容器当前的内存使用量。针对容器文件系统指标中的容器中文件系统的使用量、容器累积读取数据的总量和容器累积写入数据的总量进行数据统计，可以得到在1天，2天，3天，4天，5天内的文件系统的使用量，容器累积读取数据的总量，以及容器累积写入数据的总量。针对容器网络指标中的容器网络累积接收数据总量和容器网络累积传输数据总量进行数据统计，可以得到在1天，2天，3天，4天，5天内的容器网络累积接收数据总量和容器网络累积传输数据总量。

在获得统计结果之后，可以任选上述多个时间周期中两个以上连续的时间周期，确定在这两个以上连续的时间周期内该性能指标数据的统计值的波动值，基于与每个性能指标对应的波动值，确定目标容器是否满足资源回收条件。多个时间周期可以以1天，2天，3天，4天，5天为周期，任选两个以上连续的时间周期可以是连续两个时间周期，也可以是连续三个时间周期，还可以是连续四个时间周期，可以根据不同的性能指标选择，本公开对此不做限定。

具体实施时，基于系统CPU、用户CPU以及容器CPU累积占用时间的统计结果可以确定其在1天，2天，3天连续三个周期(1天，2天，3天)内的第一波动值。基于容器当前的内存使用量的统计结果可以确定其在1天，2天，3天连续四个周期(1天，2天，3天，4天或2天，3天，4天，5天)内的第二波动值。基于容器文件系统使用量和累积读取、写入数据总量的统计结果，可以确定其在连续两个周期(1天，2天或2天，3天)内的第三波动值。基于容器网络累积接收、传输数据总量的统计结果，可以确定其在连续两个周期内(1天，2天或2天，3天)的第四波动值。

需要说明的是，由于CPU和内存往往是最稀缺的资源，因此在确定目标容器是否满足资源回收条件时，相对于文件系统和网络资源指标占有更高的权重值，即CPU设置最高的权重，内存次之，文件系统再次之，网络资源设置最低的权重。

通过本公开的实施例，可以基于对各性能指标数据在对应统计周期内的统计结果，确定与各性能指标对应的波动值，基于多个性能指标对应的波动值，确定目标容器是否满足资源回收条件，可以通过在一定时间范围内使用容器资源的波动数据，确定容器是否回收，可以解耦人工确认流程，提高资源使用效率。

作为一种可选的实施例，基于第一波动值、第二波动值、第三波动值和第四波动值，确定目标容器是否满足资源回收条件可以包括：在第一波动值小于第一阈值的情况下，确定处理器资源满足资源回收条件。在第二波动值小于第二阈值的情况下，确定内存资源满足资源回收条件。在第三波动值小于第三阈值的情况下，确定文件系统资源满足资源回收条件。在第四波动值小于第四阈值的情况下，确定网络资源满足资源回收条件。以及在处理器资源、内存资源、文件系统资源以及网络资源中的至少两种满足资源回收条件的情况下，确定目标容器是否满足资源回收条件，其中，第一阈值、第二阈值、第三阈值以及第四阈值可以相同，也可以不相同。

根据本公开的实施例，在确定出与各性能指标数据对应的波动值之后，可以为各性能指标设置对应的指标阈值，该阈值用于表征资源回收的下限值，在波动值低于该指标阈值的情况下，则确定相应资源没有使用，进一步结合其他性能指标确定是否满足资源回收条件。

具体实施时，第一阈值可以是1％，那么如果系统、用户、容器CPU累积占用时间在连续三个周期内的波动值在1％以内，则认为容器的CPU资源没有使用。第二阈值可以是1％，那么如果容器内存当前的内存使用量在连续四个周期内波动值在1％以内，则认为容器的内存资源没有使用。第三阈值可以是10％，那么如果容器文件系统使用量和累积读取、写入数据总量在连续两个周期内波动值在10％以内，则认为容器的磁盘资源没有使用。第四阈值可以5％，那么如果容器网络累积接收、传输数据总量在连续两个周期内波动值在5％以内，则认为容器的网络资源没有使用。需要说明的是，与性能指标对应的阈值可以根据经验设定，本公开对此不做限定。

通过本公开的实施例，通过判断与各性能指标数据对应的波动值和预设阈值，可以根据资源使用率的波动情况，确定目标容器是否满足资源回收条件，无需申请者主动归还或者到期回收，及时发现处于闲置状态的可回收资源，可以提高资源的使用效率，加速资源滚动。

作为一种可选的实施例，采集目标容器的运行环境数据可以包括：采集目标容器与日志指标对应的日志数据。以及采集目标容器的版本数据，其中，版本数据用于表征应用程序的版本信息。

根据本公开的实施例，可以从如图1所示的日志平台112中获取容器日志，容器日志可以包括操作日志、系统日志以及应用日志。

通过本公开的实施例，除了获取容器的性能指标之外，还获取容器日志信息和版本信息，从多角度多维度的数据出发，确定目标容器是否满足资源回收条件，可以提高资源回收决策的准确性，避免误判和漏判，提高资源回收成功率。

作为一种可选的实施例，基于对运行场景数据的统计结果，确定目标容器是否满足资源回收条件可以包括：基于对日志数据在第五统计周期内的统计结果，确定与日志指标对应的第五波动值。以及基于第五波动值和版本数据，确定目标容器是否满足资源回收条件，其中，第五统计周期与第一统计周期、第二统计周期、第三统计周期以及第四统计周期可以相同，也可以不相同。

根据本公开的实施例，为了实现数据统计周期的一致性，本公开中沿用前文对性能指标数据进行统计时采用的多个时间周期，对运行场景数据进行统计，以获得统计结果。

具体实施时，针对容器日志，分别可以得到应用日志、系统日志和用户日志在1天，2天，3天，4天，5天内的应用日志、系统日志和用户日志的文件大小。

在获得文件大小的统计结果之后，可以针对上述多个时间周期，任选两个以上连续的时间周期，确定在这两个以上连续的时间周期内该日志的文件大小的统计值的波动值，即日志数据的统计结果。具体实施时，基于应用日志、系统日志和用户日志的文件大小的统计结果可以确定其在1天，2天，3天连续三个周期(1天，2天，3天)内的第五波动值。此外，本公开实施例还可以从如图1所示的应用版本管理系统113中获取容器版本信息。

通过本公开的实施例，还可以基于版本信息和日志信息确定文件大小的波动值，确定目标容器是否满足资源回收条件，提供多种回收决策的方式，灵活多样，满足不同的回收场景。

作为一种可选的实施例，基于第五波动值和版本数据，确定目标容器是否满足资源回收条件可以包括：在第五波动值小于第五阈值的情况下，确定目标容器满足资源回收条件。以及在版本数据表征与应用程序的版本信息不一致的情况下，确定目标容器满足资源回收条件，其中，第五阈值与第一阈值、第二阈值、第三阈值以及第四阈值可以相同，也可以不相同。

根据本公开的实施例，在确定出与容器日志对应的波动值之后，可以为日志文件指标设置对应的指标阈值，该阈值用于表征资源回收的下限值，在波动值低于该指标阈值的情况下，则确定容器内没有业务交易，即相应资源没有使用，进一步结合容器版本信息确定是否满足资源回收条件。

具体实施时，第五阈值可以是1％，那么如果应用日志、系统日志和用户日志的日志大小在连续三个周期内波动值在1％以内，则认为容器没有业务交易。

通过本公开的实施例，结合容器的日志信息和版本信息，确定是否满足回收条件，为回收决策的判断提供多维度的判断准则，有助于提高资源回收决策的准确性，避免误判和漏判，提高资源回收成功率。

作为一种可选的实施例，回收目标容器的资源可以包括：按照回收优先级，先释放目标容器占用的处理器资源和内存资源。以及在文件系统资源占用超过预设时长的情况下，释放目标容器对文件系统资源的占用。

根据本公开的实施例，在确定出该容器资源需要回收的情况下，具体的回收流程可以是：调用云平台接口对容器进行下线，立即删除容器以释放所在宿主机的CPU和内存资源。而对于容器磁盘文件可以延后三天删除，以便误删恢复。最后，在三天后删除宿主机上已下线的容器磁盘文件，还需要删除容器相关系统的台账信息。

通过本公开的实施例，按照资源的重要性，对资源进行分步分批次的释放，可以实现容器资源的平稳释放，提高资源回收的成活率。

图3示意性示出了根据本公开另一实施例的用于容器的资源回收方法的流程图。如图3所示，该资源回收方法300可以包括旧的回收流程310以及新的回收流程320。其中，旧的回收流程310包括操作S311、操作S311以及操作S330。新的回收流程320包括操作S321、操作S322、操作S323以及操作S330。在操作S311，到期归还。在操作S312，主动归还。在操作S330，执行回收。在操作S321，采集数据。在操作S322，回收决策。在操作S323，判断是否满足回收条件，若满足，则执行操作S330。否则执行操作S321。

通过本公开的实施例，容器资源回收流程发起时，无需人工确认，达到释放人力的目的，即可以自动实时地多维度监控容器资源情况，回收过程对用户无感，可以实现资源的高效利用。

图4示意性示出了根据本公开另一实施例的用于容器的资源回收方法的流程图。如图4所示，该方法400可以包括操作S410～操作S490。

在操作S410，将容器回收流程从旧流程剔除。在操作S420，将容器回收流程改成新回收路径。在操作S430，设计并部署一个容器监控模块，包含采集功能(容器的性能容量数据、日志数据、版本数据、容器生命周期数据)和回收决策功能(判断是否满足资源回收条件)。在操作S440，容器监控模块的采集数据(容器的性能容量数据、日志数据、版本数据、容器生命周期数据)。传给容器回收决策功能。在操作S450，容器监控模块的决策回收功能接收数据，进行回收决策。在操作S460，容器回收决策功能判断容器回收是否满足条件，如满足回收条件，将容器回收信息传给回收流程，发起回收申请。如果不满足回收条件，则执行步骤S440，继续执行轮循的采集作业。如果满足回收条件，则执行步骤S470。在操作S470，容器监控模块将回收容器的信息传给执行回收模块。在操作S480，发起回收申请，对容器关机，备份等释放资源的动作。在操作S490，容器监控模块在容器清单剔除已回收的容器信息。

通过本公开的实施例，可以避免容器资源回收过程中对人工的依赖和闲置资源的浪费，相关的资源回收也无需人工处理或到期回收，可以提高资源利用率，加速资源回滚以再次循环利用。

图5示意性示出了根据本公开实施例的用于容器的资源回收装置的框图。如图5所示，该资源回收装置500可以包括第一采集模块510、第二采集模块520、确定模块530以及回收模块540。

第一采集模块510，用于采集目标容器的性能指标数据，性能指标数据用于表征目标容器的资源使用情况，目标容器为运行其中的应用程序提供计算资源。可选地，第一采集模块510例如可以用于执行图2描述的操作S210，在此不再赘述。

第二采集模块520，用于采集目标容器的运行环境数据，运行场景用于表征目标容器的硬件运行环境和软件运行环境。可选地，第二采集模块520例如可以用于执行图2描述的操作S220，在此不再赘述。

确定模块530，用于基于对性能指标数据和/或运行场景数据的统计结果，确定目标容器是否满足资源回收条件。可选地，确定模块530例如可以用于执行图2描述的操作S230，在此不再赘述。

回收模块540，用于若满足资源回收条件，则回收目标容器的资源。可选地，回收模块540例如可以用于执行图2描述的操作S240，在此不再赘述。

作为一种可选的实施例，前述第一采集模块510可以包括：第一采集子模块，用于采集目标容器与处理器资源对应的第一性能指标数据。第二采集子模块，用于采集目标容器与内存资源对应的第二性能指标数据。第三采集子模块，用于采集目标容器与文件系统资源对应的第三性能指标数据。第四采集子模块，用于采集目标容器与网络资源对应的第四性能指标数据。

作为一种可选的实施例，前述确定模块530可以包括：第一波动值确定子模块，用于基于对第一性能指标数据在第一统计周期内的统计结果，确定与处理器资源对应的第一波动值。第二波动值确定子模块，用于基于对第二性能指标数据在第二统计周期内的统计结果，确定与内存资源对应的第二波动值。第三波动值确定子模块，用于基于对第三性能指标数据在第三统计周期内的统计结果，确定与文件系统资源对应的第三波动值。第四波动值确定子模块，用于基于对第四性能指标数据在第四统计周期内的统计结果，确定与网络资源对应的第四波动值。第一回收条件确定子模块，用于基于第一波动值、第二波动值、第三波动值和第四波动值，确定目标容器是否满足资源回收条件，其中，第一统计周期、第二统计周期、第三统计周期以及第四统计周期可以相同，也可以不相同。

作为一种可选的实施例，第一回收条件确定子模块可以包括：第一回收条件确定单元，用于在第一波动值小于第一阈值的情况下，确定处理器资源满足资源回收条件。第二回收条件确定单元，用于在第二波动值小于第二阈值的情况下，确定内存资源满足资源回收条件。第三回收条件确定单元，用于在第三波动值小于第三阈值的情况下，确定文件系统资源满足资源回收条件。第四回收条件确定单元，用于在第四波动值小于第四阈值的情况下，确定网络资源满足资源回收条件。第五回收条件确定单元，用于在处理器资源、内存资源、文件系统资源以及网络资源中的至少两种满足资源回收条件的情况下，确定目标容器是否满足资源回收条件，其中，第一阈值、第二阈值、第三阈值以及第四阈值可以相同，也可以不相同。

作为一种可选的实施例，前述第二采集模块520可以包括：第五采集子模块，用于采集目标容器与日志指标对应的日志数据。以及第六采集子模块，用于采集目标容器的版本数据，其中，版本数据用于表征应用程序的版本信息。

作为一种可选的实施例，前述确定模块530可以包括：第五波动值确定子模块，用于基于对日志数据在第五统计周期内的统计结果，确定与日志指标对应的第五波动值。以及第二回收条件确定子模块，用于基于第五波动值和版本数据，确定目标容器是否满足资源回收条件，其中，第五统计周期与第一统计周期、第二统计周期、第三统计周期以及第四统计周期可以相同，也可以不相同。

作为一种可选的实施例，第二回收条件确定子模块可以包括：第六回收条件确定单元，用于在第五波动值小于第五阈值的情况下，确定目标容器满足资源回收条件。以及第七回收条件确定单元，用于在版本数据表征与应用程序的版本信息不一致的情况下，确定目标容器满足资源回收条件，其中，第五阈值与第一阈值、第二阈值、第三阈值以及第四阈值可以相同，也可以不相同。

作为一种可选的实施例，前述回收模块540可以包括：第一释放子模块，用于按照回收优先级，先释放目标容器占用的处理器资源和内存资源。以及第二释放子模块，用于在文件系统资源占用超过预设时长的情况下，释放目标容器对文件系统资源的占用。

需要说明的是，用于容器的资源回收装置的部分实施例中各模块的实施方式、解决的技术问题、实现的功能、以及达到的技术效果分别与用于容器的资源回收方法部分各实施例中各对应的步骤的实施方式、解决的技术问题、实现的功能、以及达到的技术效果相同或类似，在此不再赘述。

根据本公开的实施例的模块、子模块、单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FNGA)、可编程逻辑阵列(NLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，第一采集模块、第二采集模块、确定模块、回收模块、第一采集子模块、第二采集子模块、第三采集子模块、第四采集子模块、第五采集子模块、第六采集子模块、第一波动值确定子模块、第二波动值确定子模块、第三波动值确定子模块、第四波动值确定子模块、第一回收条件确定子模块、第五波动值确定子模块、第二回收条件确定子模块、第一释放子模块、第二释放子模块、第一回收条件确定单元、第二回收条件确定单元、第三回收条件确定单元、第四回收条件确定单元、第五回收条件确定单元、第六回收条件确定单元以及第七回收条件确定单元可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，第一采集模块、第二采集模块、确定模块、回收模块、第一采集子模块、第二采集子模块、第三采集子模块、第四采集子模块、第五采集子模块、第六采集子模块、第一波动值确定子模块、第二波动值确定子模块、第三波动值确定子模块、第四波动值确定子模块、第一回收条件确定子模块、第五波动值确定子模块、第二回收条件确定子模块、第一释放子模块、第二释放子模块、第一回收条件确定单元、第二回收条件确定单元、第三回收条件确定单元、第四回收条件确定单元、第五回收条件确定单元、第六回收条件确定单元以及第七回收条件确定单元中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FNGA)、可编程逻辑阵列(NLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，第一采集模块、第二采集模块、确定模块、回收模块、第一采集子模块、第二采集子模块、第三采集子模块、第四采集子模块、第五采集子模块、第六采集子模块、第一波动值确定子模块、第二波动值确定子模块、第三波动值确定子模块、第四波动值确定子模块、第一回收条件确定子模块、第五波动值确定子模块、第二回收条件确定子模块、第一释放子模块、第二释放子模块、第一回收条件确定单元、第二回收条件确定单元、第三回收条件确定单元、第四回收条件确定单元、第五回收条件确定单元、第六回收条件确定单元以及第七回收条件确定单元中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图6示意性示出了根据本公开实施例的适于实现上文描述的用于容器的资源回收方法的计算机可读存储介质产品的示意图。

在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在设备上运行时，程序代码用于使设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的用于容器的资源回收方法中的前述各项操作(或步骤)。例如，电子设备可以执行如图2中所示的操作S210～操作S240。电子设备也可以执行如图3所示的操作S311、操作S312、操作S321、操作S322、操作S323以及操作S330。电子设备也可以执行如图4所示的操作S410～操作S490。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、系统或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(ENROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

如图6所示，描述了根据本发明的实施方式的用于容器的资源回收方法的程序产品600，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、系统或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、系统或者器件使用或者与其结合使用的程序。可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆，RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，程序设计语言包括面向对象的程序设计语言-诸如Java，C++等，还包括常规的过程式程序设计语言-诸如“C”，语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAA)或广域网(WAA)一连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

图7示意性示出了根据本公开实施例的适于实现上文描述的用于容器的资源回收方法的电子设备的框图。图7示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图7所示，根据本公开实施例的电子设备700包括处理器701，其可以根据存储在只读存储器(ROM)702中的程序或者从存储部分708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。处理器701例如可以包括通用微处理器(例如CNU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器701还可以包括用于缓存用途的板载存储器。处理器701可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 703中，存储有电子设备700操作所需的各种程序和数据。处理器701、ROM702以及RAM 703通过总线704彼此相连。处理器701通过执行ROM 702和/或RAM 703中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 702和RAM 703以外的一个或多个存储器中。处理器701也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例图2中所示的操作S210～操作S240，或者也可以执行如图3所示的操作S311、操作S312、操作S321、操作S322、操作S323以及操作S330，或者也可以执行如图4所示的操作S410～操作S490。

根据本公开的实施例，电子设备700还可以包括输入/输出(I/O)接口705，输入/输出(I/O)接口705也连接至总线704。系统700还可以包括连接至I/O接口705的以下部件中的一项或多项：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如LAA卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被处理器701执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的用于容器的资源回收方法，包括图2中所示的操作S210～操作S240。电子设备也可以执行如图3所示的操作S311、操作S312、操作S321、操作S322、操作S323以及操作S330，或者也可以执行如图4所示的操作S410～操作S490。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(ENROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 702和/或RAM 703和/或ROM 702和RAM 703以外的一个或多个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目标，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。