CN113296872A - 容器状态查询方法、装置、设备、存储介质和*** - Google Patents

Abstract

本发明提供一种容器状态查询方法、装置、设备、存储介质和***，该容器状态查询***包括N个容器组，管控***，以及与应用程序对应的虚拟节点和缓存空间，N个容器组中包含与所述应用程序对应的M个容器组。虚拟节点定时向管控***发送包括增量查询标识的第一查询请求。管控***根据增量查询标识和M个容器组的最新状态信息各自对应的状态更新时间，从M个容器组中确定在虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的K个容器组，将K个容器组的最新状态信息反馈至虚拟节点。虚拟节点将K个容器组的最新状态信息更新到缓存空间。通过该方案可以实现容器组状态的便捷、高效查询。

Description

容器状态查询方法、装置、设备、存储介质和***

技术领域

本发明涉及互联网技术领域，尤其涉及一种容器状态查询方法、装置、设备、存储介质和***。

背景技术

现在，虚拟化技术已经成为一种被大家广泛认可的服务器资源共享方式，但是，每个虚拟机都需要运行一个完整的操作***以及在其中安装好大量的依赖环境。而在实际的应用程序开发过程中，如果每次部署一个应用程序，开发者都需要先搭建一个完整的操作***和依赖环境，势必会导致任务变动繁重且低效。因此出现了一种称为容器(Container)的新型虚拟化技术来帮助解决这些问题。

容器技术的最终目的在于：让开发者更多关注应用程序本身的开发，底层的操作***和环境可以共享和复用。目前，已经有多种容器编排***(也称为容器管理***、容器***)产生。在一种典型的容器编排***的***架构中，会包含由众多工作节点构成的节点集群以及控制节点，工作节点可以是物理主机也可以是虚拟机。

一个工作节点上会运行有多个容器组，容器组(通常称为pod)是容器编排***中的最基本操作单元，包括一个或多个紧密相关的容器。开发者可以根据应用程序的需求，创建一个或多个pod来部署应用程序。在一些容器编排***的架构中，每个工作节点上会运行用于启动和管理pod的服务进程——kubelet，当然还会运行有其他一些服务进程。

虽然开发者可以通过容器技术实现应用程序的便捷部署，但是应用程序部署后还需要进行应用程序的运行维护。在运维过程中，运维人员及时地了解pod状态信息，以便根据pod状态信息进行相应的运维操作。但是目前，运维人员需要了解容器编排***的内部详细工作机制，自行对容器编排***进行复杂的查询操作才能查询得到pod状态信息，实现难度大、效率低。

发明内容

本发明实施例提供一种容器状态查询方法、装置、设备、存储介质和***，用以实现容器组状态的便捷、高效查询。

第一方面，本发明实施例提供一种容器状态查询方法，应用于与应用程序对应的虚拟节点，该方法包括：

定时向用于管理N个容器组的管控***发送第一查询请求，所述第一查询请求中包括增量查询标识；

接收所述管控***反馈的K个容器组的最新状态信息，其中，所述管控***根据所述增量查询标识和M个容器组的最新状态信息各自对应的状态更新时间，从所述M个容器组中确定出在所述虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的所述K个容器组，所述M个容器组是所述N个容器组中与所述应用程序对应的容器组，N>M>1，M≥K；

将所述K个容器组的最新状态信息更新到与所述应用程序对应的缓存空间中。

第二方面，本发明实施例提供一种容器状态查询装置，应用于与应用程序对应的虚拟节点，该装置包括：

发送模块，用于定时向用于管理N个容器组的管控***发送第一查询请求，所述第一查询请求中包括增量查询标识；

接收模块，用于接收所述管控***反馈的K个容器组的最新状态信息，其中，所述管控***根据所述增量查询标识和M个容器组的最新状态信息各自对应的状态更新时间，从所述M个容器组中确定出在所述虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的所述K个容器组，所述M个容器组是所述N个容器组中与所述应用程序对应的容器组，N>M>1，M≥K；

存储模块，用于将所述K个容器组的最新状态信息更新到与所述应用程序对应的缓存空间中。

第三方面，本发明实施例提供一种电子设备，其中包括处理器、存储器、通信接口，其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器至少可以实现第一方面中的容器状态查询方法。

第四方面，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器至少可以实现第一方面中的容器状态查询方法。

第五方面，本发明实施例提供一种容器状态查询方法，应用于用于管理N个容器组的管控***，该方法包括：

接收虚拟节点发送的第一查询请求，所述第一查询请求中包括增量查询标识，所述虚拟节点对应于应用程序；

从所述N个容器组中确定与所述虚拟节点对应的M个容器组，N>M>1；

根据所述增量查询标识和所述M个容器组的最新状态信息各自对应的状态更新时间，从所述M个容器组中确定在所述虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的所述K个容器组，M≥K；

将所述K个容器组的最新状态信息反馈至所述虚拟节点。

第六方面，本发明实施例提供一种容器状态查询装置，应用于用于管理N个容器组的管控***，该装置包括：

接收模块，用于接收虚拟节点发送的第一查询请求，所述第一查询请求中包括增量查询标识，所述虚拟节点对应于应用程序；

获取模块，用于从所述N个容器组中确定与所述虚拟节点对应的M个容器组，N>M>1，以及，根据所述增量查询标识和所述M个容器组的最新状态信息各自对应的状态更新时间，从所述M个容器组中确定在所述虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的所述K个容器组，M≥K；

发送模块，用于将所述K个容器组的最新状态信息反馈至所述虚拟节点。

第七方面，本发明实施例提供一种电子设备，其中包括处理器、存储器、通信接口，其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器至少可以实现第五方面中的容器状态查询方法。

第八方面，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器至少可以实现第五方面中的容器状态查询方法。

第九方面，本发明实施例提供了一种容器状态查询***，包括：

N个容器组，管控***，以及与应用程序对应的虚拟节点和缓存空间；其中，所述N个容器组中包含与所述应用程序对应的M个容器组，N>M>1；

所述虚拟节点，用于定时向所述管控***发送第一查询请求，所述第一查询请求中包括增量查询标识，接收所述管控***反馈的K个容器组的最新状态信息，将所述K个容器组的最新状态信息更新到所述缓存空间中，M≥K；

所述管控***，用于确定与所述虚拟节点对应的所述M个容器组，根据所述增量查询标识和所述M个容器组的最新状态信息各自对应的状态更新时间，从所述M个容器组中确定在所述虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的所述K个容器组，将所述K个容器组的最新状态信息反馈至所述虚拟节点。

在本发明实施例中，构建了一种容器状态查询***，在该容器状态查询***中除了包含大量的容器组(称为N个容器组)外，还包含用于管理全部的N个容器组的管控***，以及与开发者的应用程序对应的虚拟节点和缓存空间。该虚拟节点中封装有***提供的自动查询相对应容器组的状态信息的查询逻辑。缓存空间用于存储相应虚拟节点查询到的容器组的最新状态信息。

基于此，当应用程序对应的用户(本文中的用户一般为应用程序的运维人员或开发人员)想要查询容器组的状态信息时，仅需要通过容器状态查询***提供的标准接口触发查询请求，便可以从缓存空间中直接获得容器组的最新状态信息。由此可见，用户无需关注***内部的容器组状态信息查询逻辑，***会定时地自动获取各应用程序对应的容器组的最新状态信息并缓存，以备用户查询，用户无需执行复杂操作。

而且，以某应用程序为例，假设N个容器组中包含与该应用程序对应的M个容器组，虚拟节点在通过管控***查询这M个容器组的最新状态信息时，可以增量查询并更新的方式降低虚拟节点与管控***之间的通信量，以便实现高效查询目的。具体地，管控***可以获得M个容器组的最新状态信息及对应的状态更新时间。当接收到虚拟节点发送的第一查询请求时，管控***只需从M个容器组中确定在虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的K个容器组，仅将这K个容器组的最新状态信息反馈至虚拟节点即可。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一实施例提供的容器状态查询***的架构图；

图2为本发明一实施例提供的容器组状态查询原理的示意图；

图3为本发明一实施例提供的执行增量查询机制的流程图；

图4为本发明一实施例提供的分页查询方式的原理示意图；

图5为本发明一实施例提供的执行全量查询机制的流程图；

图6为本发明一实施例提供的执行用户查询过程的示意图；

图7为本发明一实施例提供的容器状态查询装置的结构示意图；

图8为与图7所示实施例提供的容器状态查询装置对应的电子设备的结构示意图；

图9为本发明一实施例提供的容器状态查询装置的结构示意图；

图10为与图9所示实施例提供的容器状态查询装置对应的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多个”一般包含至少两个。

另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

本发明实施例提供了一种容器状态查询***，该容器状态查询***是在现有一些容器编排***的基础上进行些许改造得到的，该容器编排***比如为经典的kubernetes、无服务器化的kubernetes(Serverless kubernetes)。

其中，Serverless：无服务器化，是一种软件架构概念，可让开发人员专注于服务代码(即应用程序)的本身逻辑上，无需关注代码部署的资源、维护等问题，从而可提高开发效率。

本发明实施例提供的容器状态查询***对传统容器编排***的改造，主要目的在于：提供一种新的容器组状态信息的查询方案，以使用户(本文中的用户一般为应用程序的运维人员或开发人员)可以便捷、高效地完成对自身应用程序所涉及的多个容器组的状态信息的查询。

为实现该目的，如图1中所示，该容器状态查询***包括：

N个容器组，管控***，以及与应用程序对应的虚拟节点和缓存空间。

其中，假设目前该***中一共具有N个容器组，并且，针对任一用户开发的任一应用程序X来说，假设这N个容器组内包含与该应用程序X对应的M个容器组，N>M>1。

先简单介绍下应用程序X与M个容器组的关系。为便于描述，先不考虑冗余备份的情况，此时，可以认为完整地部署应用程序X需要使用M个容器组，其中，每个容器组中包含一个或多个容器。实际上，由于应用程序X中往往会包含多种功能模块，可以认为几个功能上紧密相关的功能模块被部署在同一个容器组内，也就是由同一个容器组内的不同容器承载这几个功能模块。从物理载体的角度来说，这M个容器组可以位于同一物理主机或虚拟机中，也可以位于不同的物理主机或虚拟机中。而如果考虑冗余备份的情况，针对应用程序X对应的任一容器组来说，该容器组会被复制几份(如2份、3份)，复制的容器组位于其他物理主机或虚拟机中。

本文中，假设上述M个容器组是应用程序X对应的所有容器组，即包括冗余备份的容器组在内的所有容器组。

为实现前文所述方便应用程序对应的用户可以便捷、高效地完成查询自身应用程序所涉及的多个容器组的状态信息的目标，在该容器状态查询***中设置了用于管理全部N个容器组的管控***以及与应用程序对应的虚拟节点和缓存空间。

在图1中，仅示意了与应用程序X对应的虚拟节点x。在一可选实施例中，与应用程序X对应的缓存空间可以位于虚拟节点x本地。当然，可选地，该缓存空间也可以位于虚拟节点x的外部，比如可以位于管控***所在的物理主机中，或者独立于虚拟节点x和管控***外的其他某个物理主机中。

实际应用中，虚拟节点x所对应的物理载体可以是物理主机也可以是虚拟机。而且，虚拟节点x所处于的物理主机或虚拟机，与应用程序X所对应的M个容器组所位于的物理主机或虚拟机不同。

如图1中所示，为与现有的标准的容器编排***兼容，本发明实施例提供的容器状态查询***中还可以包括与传统控制节点中所提供的API Server(接口服务)相兼容的接口服务器，比如表示为图1中示意的Serverless kubernetes API Server，其作为容器状态查询***的入口，其中封装了对核心对象(如虚拟节点等)的增删改查等操作，以某种接口方式提供给外部用户和内部组件调用。

如果按照层级结构来说，容器状态查询***自上而下包括：Serverlesskubernetes API Server层、虚拟节点层、管控***层以及容器组层。从物理载体上来说，不同层对应的物理载体不同。比如，管控***可能部署在一个或多个物理主机上，该一个或多个物理主机与任一虚拟节点所在的物理主机不相同。

本发明实施例中，管控***是用于全面管理和控制N个容器组的***。实际上，容器状态查询***中还可以包括与管控***对应的数据库，管控***可以对该数据库进行读取、写入的操作。概括来说，该数据库用于存储N个容器组的状态信息。从上层往下看，管控***可以接收上层下发的各种请求，进行诸如创建、删除、更新等容器组操作。从下层往上看，管控***可以收集容器组的状态信息，以存储到数据库中。

本发明实施例中，虚拟节点中运行有虚拟的Kubelet，可以表示为：(VirtualKubelet，简称VK)。传统的Kubelet是运行于工作节点中的一个程序，用于管理同一工作节点内的容器组，如对容器组进行生命周期管理。本文中的VK可以认为是Kubelet的一个实现，它会伪装成一个Kubelet，以与传统的容器编排***兼容。只是，该VK不在运行于工作节点中，而是运行于虚拟节点中。另外，在虚拟节点中提供了设定的查询功能(或者称为查询逻辑)，VK可以运行该查询功能。基于该查询功能，虚拟节点可以自动地通过管控***查询获得与该虚拟节点对应的多个容器组的最新状态信息，并将查询结果存入到缓存空间中存储。另外，为了实现与上层的Serverless kubernetes API Server以及下层的管控***之间的交互，虚拟节点中还封装有相应的调用接口。为方便描述，下文中将该接口服务器简称为API接口。

以上述举例的应用程序X为例，先简单介绍与应用程序X对应的虚拟节点x的创建过程。实际应用中，应用程序X对应的用户可以通过调用API接口向容器状态查询***触发创建虚拟节点的请求，该请求中可以包括诸如名称等配置信息。基于该请求，容器状态查询***创建一个虚拟节点x，并配置对应的IP地址、名称等，可以将创建结果注册到API接口中，以便后续用户通过该API接口调用虚拟节点x。另外，如果容器状态查询***中还未创建与该应用程序X对应的容器组，则可以提示用户进行容器组的创建，假设虚拟节点x调用管控***创建出了上述M个容器组，则虚拟节点x和管控***中可以存储这M个容器组与该虚拟节点x的对应关系。

仍以上述举例的应用程序X为例，对于应用程序X对应的用户来说，为了保证应用程序X稳定运行，需要及时、准确地了解该应用程序X对应的M个容器组的运行状态，以便根据这M个容器组的运行状态做出扩展容器组、删除容器组、更新容器组等措施，保证应用程序X的稳定运行。

本文中，容器组的状态信息用于表示容器组所处于哪种状态，实际应用中，容器组的状态一般包括：挂起(pending)、运行中(running)、成功(succeeded)、失败(failed)、未知(unknown)。

下面以应用程序X为例，介绍虚拟节点x如何基于上述查询功能来自动地查询应用程序X对应的M个容器组的状态信息。

概括来说，该查询功能中提供了一种增量查询机制，基于该增量查询机制，可以降低虚拟节点x与管控***之间的通信量。另外，在一可选实施例中，该查询功能中还提供了一种全量查询机制，该全量查询机制作为一种补偿机制，可以保证在特殊情形下，虚拟节点x获得的容器组状态信息依旧准确。该特殊情形比如为：虚拟节点x与管控***之间的通信出现异常，等等。

首先，结合图2概括示意这两种查询机制的主要思想，之后，再结合其他实施例对每种查询机制的执行过程进行详细说明。

如图2中所示，虚拟节点x可以以较短时间间隔定时调用增量查询机制，从管控***中查询在一个时间间隔期间M个容器组内状态信息发生改变的容器组的最新状态信息，并将获得的这部分容器组的最新状态信息更新到缓存空间中。另外，虚拟节点x还可以以较长时间间隔定时调用全量查询机制，或者在用户触发特定的某些容器组操作时(图2中简单表示为关键操作时刻)调用全量查询机制，从管控***中查询当前M个容器组的状态信息，即M个容器组的最新状态信息，并将获得的M个容器组的最新状态信息更新到缓存空间中。

下面先结合图3来示例性说明增量查询机制的工作过程。

图3为本发明一实施例提供的执行增量查询机制的流程图，如图3所示，该查询过程可以包括如下步骤：

301、虚拟节点x定时向管控***发送第一查询请求，第一查询请求中包括增量查询标识。

302、管控***确定与虚拟节点x对应的M个容器组，根据增量查询标识和M个容器组的最新状态信息各自对应的状态更新时间，从M个容器组中确定在虚拟节点x上一次查询时间到本次查询时间之间状态信息发生改变的K个容器组。

303、管控***将K个容器组的最新状态信息反馈至虚拟节点x。

304、虚拟节点x将K个容器组的最新状态信息更新到缓存空间中。

本实施例中，虚拟节点x被配置为以设定的较短时间间隔定时地向管控***发送第一查询请求，该时间间隔比如为5秒，10秒等预设值。

其中，第一查询请求中包含的增量查询标识，用以表征虚拟节点x当前调用的是增量查询机制，亦即反映该第一查询请求的类型，以与下文提到的第二查询请求、第三查询请求相区别。本文中，对这些不同查询请求的响应过程是不同的。概括来说，这些查询请求都是用于查询虚拟节点x对应的M个容器组的最新状态信息的，但是，这些查询请求的触发方不同，响应过程也不同。本实施例中先介绍第一查询请求的响应过程。

实际应用中，上述增量查询标识可以为预设的某种字符，也可以通过在第一查询请求中携带触发第一查询请求时的时间戳(即查询时间)作为该增量查询标识。

另外，该第一查询请求中还可以包含虚拟节点x的标识，比如为名称，以使管控***得知是哪个虚拟节点x触发的第一查询请求。

管控***可以根据第一查询请求中携带的虚拟节点x的标识，以及预先存储的虚拟节点标识与容器组标识之间的对应关系，确定与虚拟节点x对应的M个容器组。

本实施例中，与增量查询机制对应的第一查询请求的响应过程，概括来说就是：针对虚拟节点x本次触发的第一查询请求，管控***仅将M个容器组中状态发生改变的那K个容器组当前的状态信息(即为最新状态信息)反馈给虚拟节点x，其中，该状态发生改变是指自上一次虚拟节点触发第一查询请求到本次触发第一查询请求之间，M个容器组中有K个容器组的状态信息发生了改变，M≥K，K≥0。

值得说明的是，在虚拟节点x首次查询M个容器组的状态信息，以初始化对应的缓存空间时，由于此时虚拟节点x并未触发过查询请求，因此，此时管控***实际上只是查询获得M个容器组此时的状态信息，并将查询结果反馈给虚拟节点x，虚拟节点x将M个容器组最初的状态信息初始化到缓存空间中。而实际应用中，由于此时管控***的查询行为实际上就是查询并反馈全部M个容器组的状态信息，所以针对首次查询来说，虚拟节点x既可以触发上述第一查询请求，也可以触发下文中提到的第二查询请求。

举例来说，假设M个容器组由第一容器组和第二容器组构成，初始T0时刻，虚拟节点x通过触发一次第一查询请求或第二查询请求，使得在虚拟节点x对应的缓存空间中记录有：TO时刻，第一容器组的状态信息为a，第二容器组的状态信息为a。之后，虚拟节点x在T1时刻触发了第一查询请求，假设管控***发现在T0到T1期间，第一容器组的状态信息仍为a，第二容器组的状态信息变为了b，则管控***此时仅将第二容器组的最新状态信息b反馈给虚拟节点x，虚拟节点x将第二容器组的最新状态信息b更新到缓存空间中，此时，缓存空间中记录有：T1时刻，第一容器组的状态信息为a，第二容器组的状态信息为b。之后，虚拟节点x在T2时刻触发了第一查询请求，假设管控***发现在T1到T2期间，第一容器组的状态信息仍为a，第二容器组的状态信息变为了c，则管控***此时仅将第二容器组的最新状态信息c反馈给虚拟节点x，虚拟节点x将第二容器组的最新状态信息c更新到缓存空间中，此时，缓存空间中记录有：T2时刻，第一容器组的状态信息为a，第二容器组的状态信息为c。

基于上述举例可知，管控***需要得知在两次第一查询请求对应的查询时间之间，M个容器组中哪些容器组的状态信息发生了改变。这就涉及到管控***本身对容器组状态信息的维护过程。

如图1中所示，管控***对应有一个用于存储N个容器组的状态信息的数据库，该数据库可以位于管控***本地，也可以位于其他位置。为了实现对N个容器组的状态信息的维护，管控***可以定时与N个容器组交互，以获取N个容器组的最新状态信息。从而，对于N个容器组中的任一容器组，若该任一容器组的最新状态信息与数据库中已存储的状态信息不同，则将任一容器组的最新状态信息更新到数据库中，并记录对应的状态更新时间。

举例来说，对于任一容器组i，假设初始时刻Ta时，管控***获取该容器组i的状态信息为a，管控***会向数据库中写入如下一条记录：

{Ta，容器组i，a}，表明在Ta时刻，容器组i的状态信息为a。

之后，间隔设定时间如5秒钟之后的Tb时刻，管控***再次与容器组i交互，得到容器组i在Tb时刻对应的最新状态信息为b，此时，管控***查询数据库发现，此前容器组i的状态信息为a，状态发生了改变，此时，将数据库中与该容器组i对应的记录更新为：{Tb，容器组i，b}，表明在Tb时刻，容器组i的状态信息为b。之后，间隔设定时间如5秒钟之后的Tc时刻，管控***再次与容器组i交互，得到容器组i在Tc时刻对应的最新状态信息为b，此时，管控***查询数据库发现，此前容器组i的状态信息也为b，状态未发生了改变，此时，将数据库中与该容器组i对应的记录仍旧保持为：{Tb，容器组i，b}不变。

有上述举例可知，基于上述过程，管控***对应的数据库中存储有N个容器组各自对应的最新状态信息以及该最新状态信息对应的状态更新时间。

基于此，当管控***某时刻接收到虚拟节点x发送的第一查询请求时，从数据库中查询得到M个容器组的最新状态信息及各自对应的状态更新时间，以便从中筛选出从上一次接收到第一查询请求的时刻到本次接收到第一查询请求的时刻之间，状态信息发生改变的K个容器组。其中，可以认为接收到第一查询请求的时间与虚拟节点x发出第一查询请求的时间无延时。

举例来说，假设上一次触发第一查询请求的时间(即上一次查询时间)为T1，本次触发第一查询请求的时间(即本次查询时间)为T2，那么，根据数据库中M个容器组各自对应的状态更新时间，可以认为对应的状态更新时间位于T1至T2之间的容器组为所述K个容器组。

值得说明的是，管控***定时与N个容器组交互以获得其各自的最新状态信息，并更新到数据库中的过程，与虚拟节点x定时向管控***发送第一查询请求的过程，是两个相对独立的过程。因为实际上，管控***除了会为虚拟节点x提供查询服务外，还会为其他主体提供其他服务，而这些服务中也有可能会需要使用到管控***所维护的数据库。另外，实际应用中，管控***定时更新数据库的时间间隔与虚拟节点x定时向管控***发送第一查询请求的时间间隔可以相同，也可以不同。

另外，虽然上述以M个容器组仅包含两个容器组为例进行了原理性的示例说明，但是实际上，应用程序X对应的容器组的个数M其实往往是比较大的，可能成百上千。在这种情形下，上述增量查询机制可以有效降低虚拟节点x与管控***之间的通信量。

其中，该通信量可以具有两层含义：其一，虚拟节点x与管控***之间的通信次数的降低；其二，虚拟节点x与管控***之间的传输的数据量的降低。

为便于更加直观地理解这两层含义，下面结合图4来示例性说明虚拟节点x与管控***之间如何完成一次第一查询请求的完整执行过程。

概括来说，管控***在某时刻接收到虚拟节点x发送的第一查询请求，通过上文中的处理过程得到K个容器组的最新状态信息后，可以采用分页查询方式，逐页地将K个容器组的最新状态信息反馈至虚拟节点x，其中，每页最多反馈设定数量的容器组的最新状态信息。

为说明何谓分页查询方式，结合图4来说明。其中，先假设上述每页最多反馈的设定数量为20个，并假设M＝1000，K＝200，由此可知，管控***一共通过10页能够将这200个容器组的最新状态信息反馈给虚拟节点x。

如图4中所示，管控***在收到第一查询请求，并从数据库中获得上述200个容器组的最新状态信息后，生成令牌1，向虚拟节点x发送响应消息1，在响应消息1中携带有20个容器组的最新状态信息以及令牌1。虚拟节点x解析出接收到的响应消息1中包含的20个容器组的最新状态信息以及令牌1后，一方面将这20个容器组的最新状态信息更新到缓存空间中，另一方面向管控***发送子请求1，该子请求1中包含有令牌1。管控***接收到子请求1后，解析出其中包含的令牌1，从而根据令牌1得知该子请求1是用于请求上述200个容器组中另外20个容器组的最新状态信息，此时，管控***生成令牌2,向虚拟节点x发送响应消,2，在响应消息2中携带有另外20个容器组的最新状态信息以及令牌2。虚拟节点x解析出接收到的响应消息2中包含的20个容器组的最新状态信息以及令牌2后，一方面将这20个容器组的最新状态信息更新到缓存空间中，另一方面向管控***发送子请求2，该子请求2中包含有令牌2。以此类推，直到管控***将200个容器组的最新状态信息都传输至虚拟节点x为止。

由图4中的示意可知，如果不采用上述增量查询机制，若要将虚拟节点x对应的1000个容器组的最新状态信息按照分页查询方式传输至虚拟节点x，并且每页最多只能传20个容器组的最新状态信息，那么虚拟节点x与管控***之间的通信次数将远远大于只传输200个容器组的最新状态信息所需的通信次数，而且，1000个容器组的最新状态信息所对应的数据量大于200个容器组的最新状态信息所对应的数据量。

下面结合图5来示例性说明全量查询机制的工作过程。

图5为本发明一实施例提供的执行全量查询机制的流程图，如图5所示，该查询过程可以包括如下步骤：

501、若预设事件发生，则虚拟节点x向管控***发送第二查询请求，第二查询请求中包括全量查询标识。

502、管控***确定与虚拟节点x对应的M个容器组，根据全量查询标识获取M个容器组的最新状态信息。

503、管控***将M个容器组的最新状态信息反馈至虚拟节点x。

504、虚拟节点x将M个容器组的最新状态信息更新到缓存空间中。

本实施例中，触发虚拟节点x向管控***发送上述第二查询请求的预设事件包括如下至少一种：距离上一次触发第二查询请求的时间间隔达到设定时间间隔(即定时以较长时间间隔向管控***触发第二查询请求)，应用程序X对应的用户触发的容器组操作行为符合设定条件。

其中，所述用户触发的容器组操作行为符合设定条件，包括：

用户创建大于设定数量的容器组，或者，用户删除大于设定数量的容器组。

也就是说，当该用户删除M个容器组中的大量容器组时，或者该用户又新创建与应用程序X对应的大量容器组时，可以执行全量查询机制。

可以理解的是，相邻两次第二查询请求的时间间隔大于相邻两次第一查询请求的时间间隔，比如：相邻两次第二查询请求的时间间隔为10分钟，相邻两次第一查询请求的时间间隔为10秒钟。

另外，实际应用中，虚拟节点x首次触发向管控***发送查询请求以初始化缓存空间的时候，也可以向该管控***发送第二查询请求。

其中，第二查询请求中包含的全量查询标识，用以表征虚拟节点x当前调用的是全量查询机制。

实际应用中，上述全量查询标识可以为预设的某种字符，也可以通过在第二查询请求中缺省第二查询请求对应的时间戳(即查询时间)来表明第二查询请求是调用全量查询机制的查询请求。

另外，该第二查询请求中还可以包含虚拟节点x的标识，管控***可以根据第二查询请求中携带的虚拟节点x的标识，以及预先存储的虚拟节点标识与容器组标识之间的对应关系，确定与虚拟节点x对应的M个容器组。

本实施例中，与全量查询机制对应的第二查询请求的响应过程，概括来说就是：针对虚拟节点x本次触发的第二查询请求，管控***只需将数据库中存储的这M个容器组的最新状态信息读取出来并反馈给虚拟节点x即可。

综上各实施例提供的方案，通过增量查询机制可以有效降低虚拟节点与管控***之间的通信量，而以全量查询机制作为补充，可以保证在增量查询机制的执行过程中出现某些异常情况时，虚拟节点获得的容器组状态信息仍旧准确。

由上述各实施例提供的方案可知，虚拟节点x可以定时地不断获取自身对应的M个容器组的最新状态信息并存储到缓存空间中以备用户随时查询。

图6为本发明一实施例提供的执行用户查询过程的示意图，如图6中所示，用户可以通过调用相关接口触发第三查询请求，该第三查询请求中可以携带应用程序X的标识，从而，Serverless kubernetes API Server确定与之对应的虚拟节点x，将该第三查询请求发送至虚拟节点x。此时，虚拟节点x只需要从缓存空间中获取与该应用程序X对应的前述M个容器组的最新状态信息并反馈给用户即可，不需再执行与管控***的通信交互，对于用户来说，查询响应的及时性更高。

以下将详细描述本发明的一个或多个实施例的容器状态查询装置。本领域技术人员可以理解，这些容器状态查询装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图7为本发明一实施例提供的容器状态查询装置的结构示意图，该容器状态查询装置位于前述实施例中与应用程序对应的虚拟节点中。如图7所示，该容器状态查询装置包括：发送模块11、接收模块12、存储模块13。

发送模块11，用于定时向用于管理N个容器组的管控***发送第一查询请求，所述第一查询请求中包括增量查询标识。

接收模块12，用于接收所述管控***反馈的K个容器组的最新状态信息，其中，所述管控***根据所述增量查询标识和M个容器组的最新状态信息各自对应的状态更新时间，从所述M个容器组中确定出在所述虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的所述K个容器组，所述M个容器组是所述N个容器组中与所述应用程序对应的容器组，N>M>1，M≥K。

存储模块13，用于将所述K个容器组的最新状态信息更新到与所述应用程序对应的缓存空间中。

可选地，所述发送模块11还用于：若预设事件发生，则向所述管控***发送第二查询请求，所述第二查询请求中包括全量查询标识。所述接收模块12还用于：接收所述管控***反馈的所述M个容器组的最新状态信息。所述存储模块13还用于：将所述M个容器组的最新状态信息更新到所述缓存空间中。

可选地，所述预设事件包括如下至少一种：所述虚拟节点的启动，距离上一次触发第二查询请求的时间间隔达到设定时间间隔，所述应用程序对应的用户触发的容器组操作行为符合设定条件。

其中，相邻两次第二查询请求的时间间隔大于相邻两次第一查询请求的时间间隔。

可选地，所述缓存空间位于所述虚拟节点本地，或者，所述缓存空间位于所述虚拟节点外部。

在一可选实施例中，所述装置还包括：获取模块。

此时，所述接收模块12还用于：接收所述应用程序对应的用户触发的第三查询请求。所述获取模块用于：从所述缓存空间中获取所述M个容器组的最新状态信息；将所述M个容器组的最新状态信息反馈至所述用户。

图7所示容器状态查询装置可以执行前述图1至图6所示实施例中虚拟节点x所执行的各个步骤，本实施例未详细描述的部分，可参考前述实施例的相关说明，在此不再赘述。

在一个可能的设计中，上述图7所示的容器状态查询装置的结构可实现为一电子设备。如图8所示，该电子设备可以包括：第一处理器21、第一存储器22、第一通信接口23。其中，第一存储器22上存储有可执行代码，当所述可执行代码被第一处理器21执行时，至少使第一处理器21可以实现如前述图1至图6所示实施例中虚拟节点x所执行的各个步骤。

另外，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行前述图1至图6所示实施例中虚拟节点x所执行的各个步骤。

图9为本发明一实施例提供的容器状态查询装置的结构示意图，该容器状态查询装置位于用于管理N个容器组的管控***中。如图9所示，该容器状态查询装置包括：接收模块31、获取模块32、发送模块33。

接收模块31，用于接收虚拟节点发送的第一查询请求，所述第一查询请求中包括增量查询标识，所述虚拟节点对应于应用程序；

获取模块32，用于从所述N个容器组中确定与所述虚拟节点对应的M个容器组，N>M>1，以及，根据所述增量查询标识和所述M个容器组的最新状态信息各自对应的状态更新时间，从所述M个容器组中确定在所述虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的所述K个容器组，M≥K；

发送模块33，用于将所述K个容器组的最新状态信息反馈至所述虚拟节点。

可选地，所述发送模块33具体可以用于：采用分页查询方式，逐页地将所述K个容器组的最新状态信息反馈至所述虚拟节点，其中，每页最多反馈设定数量的容器组的最新状态信息。

可选地，所述接收模块31还用于：接收所述虚拟节点在预设事件发生时发送的第二查询请求，所述第二查询请求中包括全量查询标识。所述获取模块32还用于：根据所述全量查询标识获取所述M个容器组的最新状态信息。所述发送模块33还用于：将所述M个容器组的最新状态信息反馈至所述虚拟节点。

可选地，所述获取模块32还用于：定时获取所述N个容器组的最新状态信息；对于所述N个容器组中的任一容器组，若所述任一容器组的最新状态信息与数据库中已存储的状态信息不同，则将所述任一容器组的最新状态信息更新到所述数据库中，并记录对应的状态更新时间，所述数据库与所管控***对应。

图9所示容器状态查询装置可以执行前述图1至图6所示实施例中管控***所执行的各个步骤，本实施例未详细描述的部分，可参考前述实施例的相关说明，在此不再赘述。

在一个可能的设计中，上述图9所示的容器状态查询装置的结构可实现为一电子设备。如图10所示，该电子设备可以包括：第二处理器41、第二存储器42、第二通信接口43。其中，第二存储器42上存储有可执行代码，当所述可执行代码被第二处理器41执行时，至少使第二处理器41可以实现如前述图1至图6所示实施例中管控***所执行的各个步骤。

另外，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行前述图1至图6所示实施例中管控***所执行的各个步骤。

其中，第一处理器21和第二处理器41可以是中央处理器(Central ProcessingUnit，简称CPU)，也可以是现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)、图形处理器(Graphics Processing Unit，简称GPU)、网络处理器(network processunits，简称NPU)、人工智能芯片等具有计算能力的器件。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的各个模块可以是或者也可以不是物理上分开的。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (27)

1.一种容器状态查询***，包括：

N个容器组，管控***，以及与应用程序对应的虚拟节点和缓存空间；其中，所述N个容器组中包含与所述应用程序对应的M个容器组，N>M>1；

所述虚拟节点，用于定时向所述管控***发送第一查询请求，所述第一查询请求中包括增量查询标识，接收所述管控***反馈的K个容器组的最新状态信息，将所述K个容器组的最新状态信息更新到所述缓存空间中，M≥K；

所述管控***，用于确定与所述虚拟节点对应的所述M个容器组，根据所述增量查询标识和所述M个容器组的最新状态信息各自对应的状态更新时间，从所述M个容器组中确定在所述虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的所述K个容器组，将所述K个容器组的最新状态信息反馈至所述虚拟节点。

2.根据权利要求1所述的***，在确定所述K个容器组的过程中，所述管控***具体用于：

从所述M个容器组中确定对应的状态更新时间在所述上一次查询时间到本次查询时间之间的容器组作为所述K个容器组。

3.根据权利要求1所述的***，在将所述K个容器组的最新状态信息反馈至所述虚拟节点的过程中，所述管控***具体用于：

采用分页查询方式，逐页地将所述K个容器组的最新状态信息反馈至所述虚拟节点，其中，每页最多反馈设定数量的容器组的最新状态信息。

4.根据权利要求1所述的***，所述虚拟节点还用于：

若预设事件发生，则向所述管控***发送第二查询请求，所述第二查询请求中包括全量查询标识，接收所述管控***反馈的所述M个容器组的最新状态信息，将所述M个容器组的最新状态信息更新到所述缓存空间中；

所述管控***还用于：根据所述全量查询标识获取所述M个容器组的最新状态信息，将所述M个容器组的最新状态信息反馈至所述虚拟节点。

5.根据权利要求4所述的***，所述预设事件包括如下至少一种：距离上一次触发第二查询请求的时间间隔达到设定时间间隔，所述应用程序对应的用户触发的容器组操作行为符合设定条件；

其中，相邻两次第二查询请求的时间间隔大于相邻两次第一查询请求的时间间隔。

6.根据权利要求5所述的***，所述用户触发的容器组操作行为符合设定条件，包括：

所述用户创建大于设定数量的容器组，或者，所述用户删除大于设定数量的容器组。

7.根据权利要求1所述的***，所述缓存空间位于所述虚拟节点本地，或者，所述缓存空间位于所述虚拟节点外部。

8.根据权利要求1至7中任一项所述的***，还包括：与所述管控***对应的数据库；

所述管控***还用于：

定时获取所述N个容器组的最新状态信息；

对于所述N个容器组中的任一容器组，若所述任一容器组的最新状态信息与所述数据库中已存储的状态信息不同，则将所述任一容器组的最新状态信息更新到所述数据库中，并记录对应的状态更新时间。

9.根据权利要求8所述的***，所述管控***还用于：在接收到所述第一查询请求时，从所述数据库中查询得到所述M个容器组的最新状态信息及各自对应的状态更新时间。

10.根据权利要求1至7中任一项所述的***，所述虚拟节点还用于：

接收所述应用程序对应的用户触发的第三查询请求；

从所述缓存空间中获取所述M个容器组的最新状态信息；

将所述M个容器组的最新状态信息反馈至所述用户。

11.一种容器状态查询方法，应用于与应用程序对应的虚拟节点，所述方法包括：

定时向用于管理N个容器组的管控***发送第一查询请求，所述第一查询请求中包括增量查询标识；

接收所述管控***反馈的K个容器组的最新状态信息，其中，所述管控***根据所述增量查询标识和M个容器组的最新状态信息各自对应的状态更新时间，从所述M个容器组中确定出在所述虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的所述K个容器组，所述M个容器组是所述N个容器组中与所述应用程序对应的容器组，N>M>1，M≥K；

将所述K个容器组的最新状态信息更新到与所述应用程序对应的缓存空间中。

12.根据权利要求11所述的方法，所述方法还包括：

若预设事件发生，则向所述管控***发送第二查询请求，所述第二查询请求中包括全量查询标识；

接收所述管控***反馈的所述M个容器组的最新状态信息；

将所述M个容器组的最新状态信息更新到所述缓存空间中。

13.根据权利要求12所述的方法，所述预设事件包括如下至少一种：所述虚拟节点的启动，距离上一次触发第二查询请求的时间间隔达到设定时间间隔，所述应用程序对应的用户触发的容器组操作行为符合设定条件；

其中，相邻两次第二查询请求的时间间隔大于相邻两次第一查询请求的时间间隔。

14.根据权利要求11所述的方法，所述缓存空间位于所述虚拟节点本地，或者，所述缓存空间位于所述虚拟节点外部。

15.根据权利要求11至14中任一项所述的方法，所述方法还包括：

接收所述应用程序对应的用户触发的第三查询请求；

从所述缓存空间中获取所述M个容器组的最新状态信息；

将所述M个容器组的最新状态信息反馈至所述用户。

16.一种容器状态查询装置，应用于与应用程序对应的虚拟节点，所述装置包括：

发送模块，用于定时向用于管理N个容器组的管控***发送第一查询请求，所述第一查询请求中包括增量查询标识；

接收模块，用于接收所述管控***反馈的K个容器组的最新状态信息，其中，所述管控***根据所述增量查询标识和M个容器组的最新状态信息各自对应的状态更新时间，从所述M个容器组中确定出在所述虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的所述K个容器组，所述M个容器组是所述N个容器组中与所述应用程序对应的容器组，N>M>1，M≥K；

存储模块，用于将所述K个容器组的最新状态信息更新到与所述应用程序对应的缓存空间中。

17.根据权利要求16所述的装置，所述发送模块还用于：若预设事件发生，则向所述管控***发送第二查询请求，所述第二查询请求中包括全量查询标识；

所述接收模块还用于：接收所述管控***反馈的所述M个容器组的最新状态信息；

所述存储模块还用于：将所述M个容器组的最新状态信息更新到所述缓存空间中。

18.一种电子设备，包括：存储器、处理器、通信接口；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求11至15中任一项所述的容器状态查询方法。

19.一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求11至15中任一项所述的容器状态查询方法。

20.一种容器状态查询方法，应用于用于管理N个容器组的管控***，所述方法包括：

接收虚拟节点发送的第一查询请求，所述第一查询请求中包括增量查询标识，所述虚拟节点对应于应用程序；

从所述N个容器组中确定与所述虚拟节点对应的M个容器组，N>M>1；

根据所述增量查询标识和所述M个容器组的最新状态信息各自对应的状态更新时间，从所述M个容器组中确定在所述虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的所述K个容器组，M≥K；

将所述K个容器组的最新状态信息反馈至所述虚拟节点。

21.根据权利要求20所述的方法，所述将所述K个容器组的最新状态信息反馈至所述虚拟节点，包括：

采用分页查询方式，逐页地将所述K个容器组的最新状态信息反馈至所述虚拟节点，其中，每页最多反馈设定数量的容器组的最新状态信息。

22.根据权利要求20所述的方法，所述方法还包括：

接收所述虚拟节点在预设事件发生时发送的第二查询请求，所述第二查询请求中包括全量查询标识；

根据所述全量查询标识获取所述M个容器组的最新状态信息；

将所述M个容器组的最新状态信息反馈至所述虚拟节点。

23.根据权利要求20至22中任一项所述的方法，所述方法还包括：

定时获取所述N个容器组的最新状态信息；

对于所述N个容器组中的任一容器组，若所述任一容器组的最新状态信息与数据库中已存储的状态信息不同，则将所述任一容器组的最新状态信息更新到所述数据库中，并记录对应的状态更新时间，所述数据库与所管控***对应。

24.一种容器状态查询装置，应用于用于管理N个容器组的管控***，所述装置包括：

接收模块，用于接收虚拟节点发送的第一查询请求，所述第一查询请求中包括增量查询标识，所述虚拟节点对应于应用程序；

获取模块，用于从所述N个容器组中确定与所述虚拟节点对应的M个容器组，N>M>1，以及，根据所述增量查询标识和所述M个容器组的最新状态信息各自对应的状态更新时间，从所述M个容器组中确定在所述虚拟节点上一次查询时间到本次查询时间之间状态信息发生改变的所述K个容器组，M≥K；

发送模块，用于将所述K个容器组的最新状态信息反馈至所述虚拟节点。

25.根据权利要求24所述的装置，所述接收模块还用于：接收所述虚拟节点在预设事件发生时发送的第二查询请求，所述第二查询请求中包括全量查询标识；

所述获取模块还用于：根据所述全量查询标识获取所述M个容器组的最新状态信息；

所述发送模块还用于：将所述M个容器组的最新状态信息反馈至所述虚拟节点。

26.一种电子设备，包括：存储器、处理器、通信接口；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求20至23中任一项所述的容器状态查询方法。

27.一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求20至23中任一项所述的容器状态查询方法。

Images