CN117806775B - Kubernetes集群的容器资源处理方法和装置 - Google Patents

Abstract

本申请涉及一种Kubernetes集群的容器资源处理方法和装置，Kubernetes集群包括至少一个节点，节点中部署至少一个容器，其特征在于，节点中还部署有容器监控组件、代理组件和容器引擎，方法包括：容器监控组件监测到目标容器需要扩容或者缩容时，向代理组件发送扩容或者缩容请求；代理组件获取容器引擎套接字文件，并根据容器引擎套接字文件将扩容或者缩容请求发送至容器引擎；容器引擎根据扩容或者缩容请求执行目标容器的扩容或者缩容操作。采用本方法能够以单个容器进行扩容，解决了传统技术中，以一组容器整体进行扩容操作带来的，资源浪费的问题。

Description

Kubernetes集群的容器资源处理方法和装置

技术领域

本申请涉及服务器扩容技术领域，特别是涉及一种Kubernetes集群的容器资源处理方法和装置。

背景技术

kubernetes，简称K8s，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful），Kubernetes提供了应用部署，规划，更新，维护的一种机制。

Kubernetes具备pod（容器组）级别的水平扩缩容能力。传统技术中，在扩缩容时，根据扩缩容条件，进行整个容器组级别的扩缩容。但是，通常情况下，用户仅仅希望对部分或者个别有用的容器或用户希望的容器进行扩容。因此，采用传统技术中的整个容器组级别的扩缩容，容易导致不必要的资源浪费。

发明内容

基于此，有必要针对上述技术问题，提供一种Kubernetes集群的容器资源处理方法和装置。

第一方面，本申请提供了一种Kubernetes集群的容器资源处理方法，Kubernetes集群包括至少一个节点，节点中部署至少一个容器，节点中还部署有容器监控组件、代理组件和容器引擎，方法包括：

容器监控组件监测到目标容器需要扩容或者缩容时，向代理组件发送扩容或者缩容请求；

代理组件获取容器引擎套接字文件，并根据容器引擎套接字文件将扩容或者缩容请求发送至容器引擎；

容器引擎根据扩容或者缩容请求执行目标容器的扩容或者缩容操作。

在其中一个实施例中，代理组件获取容器引擎套接字文件，并根据容器引擎套接字文件将扩容或者缩容请求发送至容器引擎，包括：

代理组件获取容器引擎套接字文件，并根据容器引擎套接字文件中的通信接口将扩容或者缩容请求发送至容器引擎。

在其中一个实施例中，上述的Kubernetes集群的容器资源处理方法还包括：

代理组件获取目标容器的配置信息；

根据容器引擎套接字文件将扩容或者缩容请求发送至容器引擎，包括：

代理组件根据容器引擎套接字文件中的通信接口，将目标容器的配置信息携带于扩容或者缩容请求中发送至容器引擎。

在其中一个实施例中，上述的Kubernetes集群的容器资源处理方法还包括：

容器监控组件采集各容器的流量，当目标容器的流量达到第一预设阈值时，确定目标容器需要扩容；

容器监控组件监测到目标容器需要扩容或者缩容时，向代理组件发送扩容或者缩容请求，包括：

容器监控组件监测到目标容器需要扩容时，向代理组件发送扩容请求；

容器引擎根据扩容或者缩容请求执行目标容器的扩容或者缩容操作，包括：

容器引擎根据扩容请求执行目标容器的扩容操作。

在其中一个实施例中，上述的节点中还部署有各容器所在的容器组，容器组包括多个，容器引擎根据扩容请求执行目标容器的扩容操作，包括：

容器引擎在目标容器所在的容器组中创建目标容器的副本；

上述的Kubernetes集群的容器资源处理方法还包括：

当目标容器所在的容器组中的剩余资源量与目标容器所需资源量不匹配时，容器监控组件获取与目标容器所需资源量匹配的容器组，向代理组件发送扩容请求时，将目标容器所需资源量匹配的容器组携带于扩容请求中；

容器引擎根据扩容请求执行目标容器的扩容操作，包括：

容器引擎根据扩容请求在目标容器所需资源量匹配的容器组中创建目标容器的副本。

在其中一个实施例中，上述的Kubernetes集群的容器资源处理方法还包括：

当目标容器所在的节点中不存在与目标容器所需资源量匹配的容器组时，容器监控组件创建新的容器组，向代理组件发送扩容请求时，将新的容器组携带于扩容请求中；

容器引擎根据扩容请求执行目标容器的扩容操作，包括：

容器引擎根据扩容请求在新的容器组中创建目标容器的副本。

在其中一个实施例中，上述的Kubernetes集群的容器资源处理方法还包括：

容器监控组件获取各节点中各个容器组的流量，当目标容器组的流量低于第二预设阈值时，确定目标容器组需要缩容；

容器监控组件获取目标容器组中负载最低的容器，确定为需要缩容的目标容器；

容器监控组件监测到目标容器需要扩容或者缩容时，向代理组件发送扩容或者缩容请求，包括：

容器监控组件监测到目标容器需要缩容时，向代理组件发送缩容请求；

容器引擎根据扩容或者缩容请求执行目标容器的扩容或者缩容操作，包括：

容器引擎根据缩容请求控制需要缩容的目标容器停止运行。

在其中一个实施例中，上述的Kubernetes集群的容器资源处理方法还包括：

容器监控组件获取各节点中各个容器组的流量，当目标容器组的流量低于第二预设阈值时，确定目标容器组需要缩容；

容器监控组件获取目标容器组中创建时间最近的容器，确定为需要缩容的目标容器；

容器监控组件监测到目标容器需要扩容或者缩容时，向代理组件发送扩容或者缩容请求，包括：

容器监控组件监测到目标容器需要缩容时，向代理组件发送缩容请求；

容器引擎根据扩容或者缩容请求执行目标容器的扩容或者缩容操作，包括：

容器引擎根据缩容请求控制需要缩容的目标容器停止运行。

在其中一个实施例中，上述的Kubernetes集群的容器资源处理方法还包括：

容器引擎为目标容器的副本创建访问地址，以便根据访问地址调用目标容器的副本。

在其中一个实施例中，各节点中的容器包括管理容器，各管理容器内的用户身份与预先设定的各个操作系统的用户身份之间存在映射关系，各操作系统的用户身份配置有不同的访问权限。

在其中一个实施例中，代理组件获取容器引擎套接字文件，并根据容器引擎套接字文件将扩容或者缩容请求发送至容器引擎，包括：

代理组件获取容器引擎套接字文件，并通过谷歌远程过程调用协议向容器引擎发送扩容或者缩容请求。

在其中一个实施例中，容器引擎包括docker，容器引擎套接字文件包括docker套接字文件。

第二方面，本申请提供了一种Kubernetes集群的容器资源处理装置，Kubernetes集群包括至少一个节点，节点中部署至少一个容器，节点中还部署有容器监控组件、代理组件和容器引擎，上述的装置包括：

容器监控组件，用于监测到目标容器需要扩容或者缩容时，向代理组件发送扩容或者缩容请求；

代理组件，用于获取容器引擎套接字文件，并根据容器引擎套接字文件将扩容或者缩容请求发送至容器引擎；

容器引擎，用于根据扩容或者缩容请求执行目标容器的扩容或者缩容操作。

第三方面，本申请提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中处理器执行计算机程序时实现在第一方面本公开任一实施例中的Kubernetes集群的容器资源处理方法的步骤。

第四方面，本申请提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现在第一方面本公开任一实施例中的Kubernetes集群的容器资源处理方法的步骤。

上述的Kubernetes集群的容器资源处理方法和装置，通过部署在Kubernetes集群的节点上的容器监控组件、代理组件和容器引擎三者之间的交互，实现容器级别的扩缩容。具体而言，通过容器监控组件对各个容器进行监控，当监控到某个目标容器需要扩容或者缩容时，容器监控组件会调用代理组件，通过代理组件调用容器引擎来创建目标容器，这种方式相较于传统技术中的整个容器组进行扩缩容的方式而言，扩缩容的控制粒度更小，精确地根据扩缩需求执行扩缩容操作，不会造成资源的浪费。

另一方面，本申请通过代理组件调用容器引擎执行容器的扩缩容，无需将容器引擎的套接字文件挂载在某个容器内，也无需容器具备特权模式，避免了容器具备特权模式后具有访问宿主机所有文件的能力，进而避免了数据泄露，从而解决了数据安全问题。

总之，本申请在保证了数据安全的前提下，实现了容器级别的扩容。

附图说明

图1为一个实施例中Kubernetes集群的容器资源处理方法的流程示意图；

图2为传统技术中，容器扩容的原理示意图；

图3为一个实施例中管理容器和用户容器之间的关系示意图；

图4为一个实施例中容器监控组件、代理组件以及容器引擎之间的交互示意图；

图5为一个实施例中Kubernetes集群的容器资源处理装置的结构框图；

图6为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

第一方面，如图1所示，本申请提供了一种Kubernetes集群的容器资源处理方法，Kubernetes集群包括至少一个节点，节点中部署至少一个容器，节点中还部署有容器监控组件、代理组件和容器引擎，Kubernetes集群的容器资源处理方法可以包括：

S11、容器监控组件监测到目标容器需要扩容或者缩容时，向代理组件发送扩容或者缩容请求。

本申请中，容器资源处理包括容器的扩容和容器的缩容。Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，是一种容器编排框架，在分布式容器领域被视为既定标准。Kubernetes的目标是让部署容器化的应用简单并且高效，Kubernetes提供了应用部署，规划，更新，维护的一种机制。

其中，节点是指Kubernetes集群中的独立服务器或者是多个服务器组成的服务器集群。容器是指一个标准的软件单元，它打包代码及其所有依赖项。本申请中，在Kubernetes上运行的程序被打包成Linux（操作系统内核）容器。

容器监控组件负责对容器进行监控，具体可以监控容器的运行状态以及运行指标等。代理组件负责接收容器监控组件发送的容器扩缩容请求，并根据容器扩缩容请求调用容器引擎，本申请中的代理组件主要负责与容器监控组件进行通信，以实现将扩容或者缩容转发至容器引擎。

容器引擎是Kubernetes最重要的组件之一，负责管理镜像和容器的生命周期。容器监控组件通过与容器引擎交互，以管理镜像和容器。

扩容请求是指创建新的容器的请求。缩容请求是指对已有的容器控制器停止运行的请求。

容器监控组件实时对各个容器进行指标监测，根据指标信息确定目标容器是需要扩容或者缩容。其中，目标容器是指满足扩容要求的容器，或者满足缩容要求的容器。

S12、代理组件获取容器引擎套接字文件，并根据容器引擎套接字文件将扩容或者缩容请求发送至容器引擎。

其中，容器引擎套接字文件提供了一种进程间通信的机制，基于该通信机制，代理组件可以与容器引擎进行通信以实现容器的创建、启动以及删除等操作，一般位于节点的文件系统中。

具体地，容器监控组件可以通过与容器引擎套接字文件建立连接，向容器引擎发送容器的创建或者删除请求，并接收来自容器引擎的响应。

传统技术中，在容器中启动一个容器时，需要与容器引擎通信，当需要与容器引擎进行通信时，通常是将节点上的 容器引擎套接字文件挂载到容器内的相应路径，以便容器内的进程可以通过该文件与容器引擎进行通信，同时还需要容器具备特权模式。然而，当容器具备有特权模式后，则该容器具有访问节点上所有文件的能力，这就会导致至少以下问题：

其一，数据安全问题，容器内部可以获取系统中所有的文件，会产生数据泄露的可能；

其二，系统安全问题，如果容器中的服务有漏洞，则影响范围会扩展到整个宿主机集群。

而本申请中，通过代理组件读取节点上的容器引擎套接字文件，通过容器引擎套接字文件调用容器引擎，无需将引擎套接字文件挂载到目标容器内，也无需目标容器具备特权模式，就能实现容器级别的扩容，解决的传统技术中容器级别的扩容可能带来的数据安全问题。

其中，这里的容器级别的扩容是指对单个容器进行扩容或者缩容的操作，区别与传统技术中的以多个容器为扩容单位进行的扩容。

请参考图2，图2为传统技术中，容器扩容的原理示意图。在图2中，进行扩容时，对多个容器整体进行复制，得到一个副本。在该新的副本中各个容器都被复制，使得用户所需要扩容的容器以外的其他容器也被复制，导致了资源的浪费。

S13、容器引擎根据扩容或者缩容请求执行目标容器的扩容或者缩容操作。

在容器的创建过程中，容器引擎用于管理和运行容器。具体地，容器引擎可以管理容器的镜像，负责创建和管理容器的生命周期以及处理资源分配和网络配置等。

在其中一个实施例中，代理组件获取容器引擎套接字文件，并根据容器引擎套接字文件将扩容或者缩容请求发送至容器引擎，包括：

代理组件获取容器引擎套接字文件，并根据容器引擎套接字文件中的通信接口将扩容或者缩容请求发送至容器引擎。

本申请中，容器引擎套接字文件提供了一组用于管理和操作容器、镜像以及网络等的接口和方法。通过容器引擎套接字文件，代理组件可以向容器引擎发送请求来执行各种容器的操作。

具体地，容器引擎套接字文件中的通信接口可以包括以下具体接口：

容器管理接口：如创建容器、启动容器、停止容器以及删除容器等。

容器信息接口：如获取容器列表、获取容器详情以及获取容器日志等。

除此之外，还包括如镜像管理接口、镜像信息接口以及网络管理接口等。

本申请通过代理组件获取容器引擎套接字文件，无需将容器引擎套接字文件挂载到目标容器内，避免了目标容器具备访问节点上其他文件的权限，解决了数据安全问题。

在其中一个实施例中，上述的方法还可以包括：

代理组件获取目标容器的配置信息；

根据容器引擎套接字文件将扩容或者缩容请求发送至容器引擎，包括：

代理组件根据容器引擎套接字文件中的通信接口，将目标容器的配置信息携带于扩容或者缩容请求中发送至容器引擎。

本申请中，上述的配置信息是指与容器创建相关的配置信息。例如，这里的配置信息可以包括容器的名称、镜像、环境变量、命令以及挂载点等。

代理组件使用容器引擎套接字文件中的通信接口，通过与容器引擎进行交互，向其发送创建容器的请求或者删除容器的请求，请求中包含目标容器的配置信息，容器引擎接收到请求后，根据配置信息启动并创建容器或者删除容器。

在其中一个实施例中，上述的方法还可以包括：

容器监控组件采集各容器的流量，当目标容器的流量达到第一预设阈值时，确定目标容器需要扩容；

容器监控组件监测到目标容器需要扩容或者缩容时，向代理组件发送扩容或者缩容请求，包括：

容器监控组件监测到目标容器需要扩容时，向代理组件发送扩容请求；

容器引擎根据扩容或者缩容请求执行目标容器的扩容或者缩容操作，包括：

容器引擎根据扩容请求执行目标容器的扩容操作。

本申请中，容器监控组件负责采集各个容器的运行指标，其中运行指标可以包括流量。采集流量后将各个容器的流量与第一预设阈值进行比较，根据比较结果确定目标容器。其中，将达到第一预设阈值的容器确定为需要扩容的目标容器。这里的第一预设阈值可以根据实际需求或者实际应用场景进行设定，在此不做具体限定。

在其中一个实施例中，上述的节点中还部署有各容器所在的容器组，容器组包括多个，容器引擎根据扩容请求执行目标容器的扩容操作，包括：

容器引擎在目标容器所在的容器组中创建目标容器的副本；

Kubernetes集群的容器资源处理方法还包括：

当目标容器所在的容器组中的剩余资源量与目标容器所需资源量不匹配时，容器监控组件获取与目标容器所需资源量匹配的容器组，向代理组件发送扩容请求时，将目标容器所需资源量匹配的容器组携带于扩容请求中；

容器引擎根据扩容请求执行目标容器的扩容操作，包括：

容器引擎根据扩容请求在目标容器所需资源量匹配的容器组中创建目标容器的副本。

本申请中，Kubernetes集群可以包括多个节点，各节点上运行有至少一个容器组，各容器组中包括至少一个容器。

其中，这里的容器组为pod。这里的pod是指部署在单个节点上的一个或多个容器组成的容器组，是Kubernetes调度的最小单位。

本申请中，容器监控组件具体可以包括自动缩放组件以及控制组件。由自动缩放组件采集各个容器的流量，并将流量与预设阈值进行比较，根据比较结果确定需要扩容或者缩容的目标容器。进一步地，自动缩放组件向控制组件发送调度请求，控制组件根据调度请求查找目标容器所在的pod是否满足目标容器的所需资源量，若满足，则确定在目标容器所在的pod中创建目标容器的副本，若不满足，则控制组件会从节点上的其他pod中筛选出与目标容器匹配的pod，并将该pod携带于扩容请求中，发送给代理组件。

本申请通过自动缩放组件以及控制组件之间的交互实现了容器指标的采集以及容器所在pod的调度。

在其中一个实施例中，上述的方法还可以包括：

当目标容器所在的节点中不存在与目标容器所需资源量匹配的容器组时，容器监控组件创建新的容器组，向代理组件发送扩容请求时，将新的容器组携带于扩容请求中；

容器引擎根据扩容请求执行目标容器的扩容操作，包括：

容器引擎根据扩容请求在新的容器组中创建目标容器的副本。

其中，当控制组件监测到目标容器所在节点上每个pod均不满足目标容器的所需资源量时，控制组件创建新的pod，后续创建目标容器的副本时，将目标容器的副本创建于新的pod中。

在其中一个实施例中，上述的方法还可以包括：

容器监控组件获取各节点中各个容器组的流量，当目标容器组的流量低于第二预设阈值时，确定目标容器组需要缩容；

容器监控组件获取目标容器组中负载最低的容器，确定为需要缩容的目标容器；

容器监控组件监测到目标容器需要扩容或者缩容时，向代理组件发送扩容或者缩容请求，包括：

容器监控组件监测到目标容器需要缩容时，向代理组件发送缩容请求；

容器引擎根据扩容或者缩容请求执行目标容器的扩容或者缩容操作，包括：

容器引擎根据缩容请求控制需要缩容的目标容器停止运行。

其中，容器监控组件可以采集各个容器的运行指标，还可以采集各个pod的运行指标，当根据pod的运行指标确定目标pod（目标容器组）需要缩容时，根据各个容器的负载状态确定需要缩容的目标容器。具体地，可以获取目标容器组中负载最低的容器，确定为需要缩容的目标容器。

在其中一个实施例中，上述的Kubernetes集群的容器资源处理方法还包括：

容器监控组件获取各节点中各个容器组的流量，当目标容器组的流量低于第二预设阈值时，确定目标容器组需要缩容；

容器监控组件获取目标容器组中创建时间最近的容器，确定为需要缩容的目标容器；

容器监控组件监测到目标容器需要扩容或者缩容时，向代理组件发送扩容或者缩容请求，包括：

容器监控组件监测到目标容器需要缩容时，向代理组件发送缩容请求；

容器引擎根据扩容或者缩容请求执行目标容器的扩容或者缩容操作，包括：

容器引擎根据缩容请求控制需要缩容的目标容器停止运行。

其中，本申请还可以根据各个容器的创建时间确定需要缩容的目标容器。具体地，可以获取目标容器组中创建时间最近的容器，确定为需要缩容的目标容器，通过代理组件调用容器引擎控制该需要缩放的目标容器停止运行，以释放算力。

在其中一个实施例中，上述的方法还可以包括：

容器引擎为目标容器的副本创建访问地址，以便根据访问地址调用目标容器的副本。

其中，在创建目标容器的副本后，会为这个新的容器创建一个访问地址以及分配对应的端口号，以便后续根据访问地址调用目标容器的副本，进行流量的分派。

在其中一个实施例中，各节点中的容器包括管理容器，各管理容器内的用户身份与预先设定的各个操作系统的用户身份之间存在映射关系，各操作系统的用户身份配置有不同的访问权限。

本申请中，节点上的容器可以包括管理容器以及用户容器。其中，管理容器是指与用户容器配合工作的辅助容器，用于提供管理和辅助功能。管理容器通常由Kubernetes系统或相关工具自动创建和管理，不直接由应用开发者定义。管理容器负责处理与用户容器相关的管理任务，例如监控、日志收集、配置管理、服务发现以及负载均衡等。

用户容器是指运行应用程序或服务的主要容器，它们承载着实际的业务逻辑。用户容器通常由应用开发者或管理员创建和管理，其中包含应用程序、库、依赖项以及相关的配置和数据。用户容器负责处理应用程序的逻辑，例如，数据库以及消息队列等。

其中，管理容器与用户容器之间的关系，如图3所示。其中，一个管理容器下面管控多个用户容器。

进一步地，上述的管理容器内的用户身份是指应用程序在容器中运行时所使用的用户身份。每个容器都会配置有一个默认的用户，并且可以使用USER（用户）指令设置特定的用户。

本申请中可以通过将各个管理容器的用户身份映射到操作系统的用户空间内，即预先创建各个管理容器的用户身份与各个操作系统的用户身份之间的映射关系。示例性地，管理容器X映射到操作系统用户X，管理容器Y映射到操作系统用户Y，管理容器Z映射到操作系统用户Z。

通过将各个管理容器的用户身份映射到操作系统的用户空间内，每个容器都会有自己的用户身份和权限，与其他容器以及宿主操作系统进行隔离。这种权限隔离能力使得每个容器在运行时具有自己独立的用户环境，包括用户身份、用户组以及文件访问权限等。这样可以确保不同容器之间的相互内容无法直接访问，从而增加了容器的安全性和隔离性。

另外，通过将管理容器限制在特定的用户空间内，还可以存在以下优势：

其一，容器内的进程以容器内部的用户身份运行，与其他容器和宿主操作系统的进程隔离。这样，即使一个容器被攻击或受到恶意代码的影响，攻击者仅仅能够在容器的用户空间内进行操作，而无法直接访问其他容器或宿主系统的敏感资源。

其二，每个容器都有自己独立的文件系统视图。容器内的文件系统是通过挂载宿主操作系统的文件系统或者使用专门的容器镜像构建而成。这样，即使容器内部的恶意代码修改或删除了容器内的文件，不会影响其他容器或宿主系统的文件。

其三，每个容器可以被分配特定的资源配额，例如CPU、内存等。通过限制容器的资源使用，可以防止容器过度消耗系统资源，提高整体系统的稳定性和可靠性。

在其中一个实施例中，上述的容器引擎包括docker，容器引擎套接字文件包括docker套接字文件。

其中，本申请中的容器引擎可以包括docker、CRI-O以及Containerd，等。

其中，docker是一个开源的容器化平台，它允许用户在容器中打包、分发和运行应用程序及其依赖项。而docker守护进程则是docker的核心组件之一，负责管理和运行容器。本申请具体是通过代理组件与docker守护进程之间进行通信，以实现容器的创建、删除或者停止运行。CRI-O是一个开源的社区驱动的容器引擎。Containerd是容器内核引擎，是docker中自带的容器引擎。

上述的docker套接字文件是指docker.sock文件。其中，docker.sock文件是docker守护进程的Unix域套接字（Unix domain socket），它用于与宿主机上运行的docker容器引擎进行通信。

具体地，docker.sock文件中包含了docker守护进程的API（ApplicationProgramming Interface，应用程序编程接口）接口，通过该接口可以执行各种与docker相关的操作，例如创建、启动、停止和删除容器，构建和推送镜像，查看日志和状态信息，管理网络和存储等。

在其中一个实施例中，上述的代理组件获取容器引擎套接字文件，并根据容器引擎套接字文件将扩容或者缩容请求发送至容器引擎，可以包括：

代理组件获取容器引擎套接字文件，并通过谷歌远程过程调用协议向容器引擎发送扩容或者缩容请求。

其中，谷歌远程过程调用协议是指gRPC（Google Remote Procedure Call）。本申请根据gRPC协议预先定义gRPC服务接口，该接口定义了容器监控组件可以调用的方法和参数。这些方法对应于docker的不同操作，如创建容器、启动容器等。根据定义的gRPC服务接口向容器引擎发送扩容或者缩容请求。

在其中一个实施例中，请参考4，图4为Kubernetes集群的容器资源处理方法的应用环境图。在图4中，节点上部署有容器监控组件、代理组件、容器引擎以及多个pod，每个pod中包括多个容器。其中，容器监控组件包括控制组件以及自动缩放组件。容器包括管理容器以及多个用户容器。

自动缩放组件采集各个容器的流量，并根据流量与预设阈值比较后确定需要扩容或者缩容的目标容器，向控制组件发起容器调度请求；

控制组件根据调度请求确定需要与目标容器的资源需求量匹配的pod，根据与目标容器的资源需求量匹配的pod生成扩容或者缩容请求，将扩容或者缩容请求发送至代理组件；

代理组件根据容器引擎套接字文件，调用容器引擎进行容器的创建、停止运行或者删除操作，将操作后的结果反馈至代理组件，并由代理组件反馈至容器监控组件。

本申请通过实现容器级别的扩容，还带来了以下几方面的技术效果：

其一，通过实现容器级别的扩缩容，在pod数量限制的情况下，可以支持更多的微服务运行（即单个pod可以动态运行多个容器），突破k8s对集群pod的限制。

其二，每个pod占用一个IP地址，通过实现容器级别的扩缩容，实现了多个容器复用pod，可以为每个容器分配不同的端口号，从而解决IP数量限制的问题。

其三，在一种可能的应用场景中，用户可能会需要注入一些sidecar（边车）来达到一些额外的功能。其中，sidecar是一种用来在k8s的pod中扩展服务能力的方式，它可以在不侵入主容器的前提下，扩展主容器的能力，是一种很好的服务能力扩展手段。本申请通过实现容器级别的扩缩容，实现了目标容器的副本与目标容器共用边车资源。因此，本申请能够实现多个用户容器共享pod，解决了每个微服务单独注入sidecar所导致的资源开销。

其四，在Kubernetes中，pod相当于虚拟机，pod内部的容器可以共用此pod的资源。本申请通过实现容器级别的扩容，实现了目标容器的副本与目标容器共用加速卡资源，从而实现了多个用户容器可以共用pod的加速卡资源，进而解决了一个应用独占一张加速卡的情况。

第二方面，如图5所示，本申请提供了一种Kubernetes集群的容器资源处理装置，Kubernetes集群包括至少一个节点，节点中部署至少一个容器，其特征在于，节点中还部署有容器监控组件11、代理组件12和容器引擎13，装置包括：

容器监控组件11，用于监测到目标容器需要扩容或者缩容时，向代理组件发送扩容或者缩容请求；

代理组件12，用于获取容器引擎套接字文件，并根据容器引擎套接字文件将扩容或者缩容请求发送至容器引擎；

容器引擎13，用于根据扩容或者缩容请求执行目标容器的扩容或者缩容操作。

在其中一个实施例中，上述的代理组件12，还可以获取容器引擎套接字文件，并根据容器引擎套接字文件中的通信接口将扩容或者缩容请求发送至容器引擎。

在其中一个实施例中，代理组件12还可以获取目标容器的配置信息，代理组件12还可以根据容器引擎套接字文件中的通信接口，将目标容器的配置信息携带于扩容或者缩容请求中发送至容器引擎。

在其中一个实施例中，容器监控组件11还可以采集各容器的流量，当目标容器的流量达到第一预设阈值时，确定目标容器需要扩容，容器监控组件监测到目标容器需要扩容时，向代理组件发送扩容请求，容器引擎13还可以容器引擎根据扩容请求执行目标容器的扩容操作。

在其中一个实施例中，节点中还部署有各容器所在的容器组，容器组包括多个，容器引擎13可以在目标容器所在的容器组中创建目标容器的副本，当目标容器所在的容器组中的剩余资源量与目标容器所需资源量不匹配时，容器监控组件11还可以获取与目标容器所需资源量匹配的容器组，向代理组件发送扩容请求时，将目标容器所需资源量匹配的容器组携带于扩容请求中，容器引擎13可以容器引擎根据扩容请求在目标容器所需资源量匹配的容器组中创建目标容器的副本。

在其中一个实施例中，当目标容器所在的节点中不存在与目标容器所需资源量匹配的容器组时，容器监控组件11还可以创建新的容器组，向代理组件发送扩容请求时，将新的容器组携带于扩容请求中，容器引擎13可以根据扩容请求在新的容器组中创建目标容器的副本。

在其中一个实施例中，容器监控组件11还可以获取各节点中各个容器组的流量，当目标容器组的流量低于第二预设阈值时，确定目标容器组需要缩容，获取目标容器组中负载最低的容器，确定为需要缩容的目标容器，容器监控组件11监测到目标容器需要缩容时，向代理组件发送缩容请求，容器引擎13可以根据缩容请求控制需要缩容的目标容器停止运行。

在其中一个实施例中，容器监控组件11还可以获取各节点中各个容器组的流量，当目标容器组的流量低于第二预设阈值时，确定目标容器组需要缩容，容器监控组件11获取目标容器组中创建时间最近的容器，确定为需要缩容的目标容器，容器监控组件11监测到目标容器需要缩容时，向代理组件发送缩容请求，容器引擎13根据缩容请求控制需要缩容的目标容器停止运行。

在其中一个实施例中，容器监控组件11还可以为目标容器的副本创建访问地址，以便根据访问地址调用目标容器的副本。

在其中一个实施例中，各节点中的容器包括管理容器，各管理容器内的用户身份与预先设定的各个操作系统的用户身份之间存在映射关系，各操作系统的用户身份配置有不同的访问权限。

在其中一个实施例中，代理组件12可以获取容器引擎套接字文件，并通过谷歌远程过程调用协议向容器引擎发送扩容或者缩容请求。

在其中一个实施例中，容器引擎包括docker，容器引擎套接字文件包括docker套接字文件。

第三方面，本申请提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储智能家居设备的运行数据等数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现Kubernetes集群的容器资源处理方法。

在一个实施例中，计算机设备可以包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现在第一方面任一实施例中的Kubernetes集群的容器资源处理方法。

第四方面，本申请提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现在第一方面任一实施例中的Kubernetes集群的容器资源处理方法。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双数据率SDRAM（DDRSDRAM）、增强型SDRAM（ESDRAM）、同步链路（Synchlink） DRAM（SLDRAM）、存储器总线（Rambus）直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (15)

1.一种Kubernetes集群的容器资源处理方法，所述Kubernetes集群包括至少一个节点，所述节点中部署至少一个容器，其特征在于，所述节点中还部署有容器监控组件、代理组件和容器引擎，所述方法包括：

所述容器监控组件监测到目标容器需要扩容或者缩容时，向所述代理组件发送扩容或者缩容请求；

所述代理组件获取容器引擎套接字文件，并根据所述容器引擎套接字文件将所述扩容或者缩容请求发送至所述容器引擎；

所述容器引擎根据所述扩容或者缩容请求执行所述目标容器的扩容或者缩容操作。

2.根据权利要求1所述的方法，其特征在于，所述代理组件获取容器引擎套接字文件，并根据所述容器引擎套接字文件将所述扩容或者缩容请求发送至所述容器引擎，包括：

所述代理组件获取所述容器引擎套接字文件，并根据所述容器引擎套接字文件中的通信接口将所述扩容或者缩容请求发送至所述容器引擎。

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

所述代理组件获取所述目标容器的配置信息；

所述根据所述容器引擎套接字文件将所述扩容或者缩容请求发送至所述容器引擎，包括：

所述代理组件根据所述容器引擎套接字文件中的通信接口，将所述目标容器的配置信息携带于所述扩容或者缩容请求中发送至所述容器引擎。

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

所述容器监控组件采集各所述容器的流量，当所述目标容器的流量达到第一预设阈值时，确定所述目标容器需要扩容；

所述容器监控组件监测到目标容器需要扩容或者缩容时，向所述代理组件发送扩容或者缩容请求，包括：

所述容器监控组件监测到目标容器需要扩容时，向所述代理组件发送扩容请求；

所述容器引擎根据所述扩容或者缩容请求执行所述目标容器的扩容或者缩容操作，包括：

所述容器引擎根据所述扩容请求执行所述目标容器的扩容操作。

5.根据权利要求1所述的方法，其特征在于，所述节点中还部署有各所述容器所在的容器组，所述容器组包括多个，所述容器引擎根据所述扩容请求执行所述目标容器的扩容操作，包括：

所述容器引擎在所述目标容器所在的容器组中创建所述目标容器的副本；

所述方法还包括：

当所述目标容器所在的容器组中的剩余资源量与所述目标容器所需资源量不匹配时，所述容器监控组件获取与所述目标容器所需资源量匹配的容器组，向所述代理组件发送扩容请求时，将所述目标容器所需资源量匹配的容器组携带于所述扩容请求中；

所述容器引擎根据所述扩容请求执行所述目标容器的扩容操作，包括：

所述容器引擎根据所述扩容请求在所述目标容器所需资源量匹配的容器组中创建所述目标容器的副本。

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

当所述目标容器所在的节点中不存在与所述目标容器所需资源量匹配的容器组时，所述容器监控组件创建新的容器组，向所述代理组件发送扩容请求时，将所述新的容器组携带于所述扩容请求中；

所述容器引擎根据所述扩容请求执行所述目标容器的扩容操作，包括：

所述容器引擎根据所述扩容请求在所述新的容器组中创建所述目标容器的副本。

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

所述容器监控组件获取各所述节点中各个容器组的流量，当目标容器组的流量低于第二预设阈值时，确定所述目标容器组需要缩容；

所述容器监控组件获取所述目标容器组中负载最低的容器，确定为需要缩容的目标容器；

所述容器监控组件监测到目标容器需要扩容或者缩容时，向所述代理组件发送扩容或者缩容请求，包括：

所述容器监控组件监测到目标容器需要缩容时，向所述代理组件发送缩容请求；

所述容器引擎根据所述扩容或者缩容请求执行所述目标容器的扩容或者缩容操作，包括：

所述容器引擎根据所述缩容请求控制所述需要缩容的目标容器停止运行。

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

所述容器监控组件获取各所述节点中各个容器组的流量，当目标容器组的流量低于第二预设阈值时，确定所述目标容器组需要缩容；

所述容器监控组件获取所述目标容器组中创建时间最近的容器，确定为需要缩容的目标容器；

所述容器监控组件监测到目标容器需要扩容或者缩容时，向所述代理组件发送扩容或者缩容请求，包括：

所述容器监控组件监测到目标容器需要缩容时，向所述代理组件发送缩容请求；

所述容器引擎根据所述扩容或者缩容请求执行所述目标容器的扩容或者缩容操作，包括：

所述容器引擎根据所述缩容请求控制所述需要缩容的目标容器停止运行。

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

所述容器引擎为所述目标容器的副本创建访问地址，以便根据所述访问地址调用所述目标容器的副本。

10.根据权利要求4所述的方法，其特征在于，各所述节点中的容器包括管理容器，各所述管理容器内的用户身份与预先设定的各个操作系统的用户身份之间存在映射关系，各所述操作系统的用户身份配置有不同的访问权限。

11.根据权利要求1所述的方法，其特征在于，所述代理组件获取容器引擎套接字文件，并根据所述容器引擎套接字文件将所述扩容或者缩容请求发送至所述容器引擎，包括：

所述代理组件获取容器引擎套接字文件，并通过谷歌远程过程调用协议向所述容器引擎发送所述扩容或者缩容请求。

12.根据权利要求1所述的方法，其特征在于，所述容器引擎包括docker，所述容器引擎套接字文件包括docker套接字文件。

13.一种Kubernetes集群的容器资源处理装置，所述Kubernetes集群包括至少一个节点，所述节点中部署至少一个容器，其特征在于，所述节点中还部署有容器监控组件、代理组件和容器引擎，所述装置包括：

所述容器监控组件，用于监测到目标容器需要扩容或者缩容时，向所述代理组件发送扩容或者缩容请求；

所述代理组件，用于获取容器引擎套接字文件，并根据所述容器引擎套接字文件将所述扩容或者缩容请求发送至所述容器引擎；

所述容器引擎，用于根据所述扩容或者缩容请求执行所述目标容器的扩容或者缩容操作。

14.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至12中任一项所述方法的步骤。

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