CN112346926A

CN112346926A - 资源状态监控方法、装置及电子设备

Info

Publication number: CN112346926A
Application number: CN202011110131.7A
Authority: CN
Inventors: 马浩原; 杨帆
Original assignee: Beijing Kingsoft Cloud Network Technology Co Ltd
Current assignee: Beijing Kingsoft Cloud Network Technology Co Ltd
Priority date: 2020-10-16
Filing date: 2020-10-16
Publication date: 2021-02-09

Abstract

本申请公开了一种资源状态监控方法，应用于Kubernetes集群的资源状态监控服务器，包括：接收应用程序发送的、对所述Kubernetes集群中的资源对象的状态进行监控的数据请求，其中，所述数据请求中包括所述应用程序对所述资源对象的期望状态；响应于所述数据请求，对所述资源对象的状态进行监控；在所述资源对象的状态变更为所述期望状态的情况下，向所述应用程序发送所述资源对象的状态已变更为所述期望状态的通知消息。该方法可以向应用程序提供可靠的资源状态，并且还可以降低集群的运行压力，提升集群性能。

Description

资源状态监控方法、装置及电子设备

技术领域

本公开涉及云计算技术领域，更具体地，涉及一种资源状态监控方法、装置、设备及介质。

背景技术

Kubernetes，简称K8S，是一种基于容器的集群管理平台，Kubernetes集群一般包括主节点(Master)，以及分别与主节点通信连接的多个计算节点(Node)，其中，主节点一般用于管理和控制多个计算节点，计算节点作为工作负载节点，其包含直接部署在节点中的原应用程序和多个容器组(Pod)，每个容器组中封装有一个或多个用于承载应用程序的容器(Container)，Pod是Kubernetes的基本操作单元，是最小的可创建、调试和管理的部署单元。

目前，在应用程序需要获取Kubernetes集群中资源的状态时，一般是通过集群的接口服务器，即apiserver获取该资源的状态；同时，集群内部的各节点中的资源对象之间也需要通过接口服务器进行通信，因此，在Kubernetes集群中，接口服务器通常面临巨大的运行压力，其中，apiserver为Kubernetes集群的一个系统组件，其提供了Kubernetes集群中各类资源对象的增加、删除、修改、查询以及监控服务的http rest接口，是Kubernetes集群的数据总线和数据中心。

然而，目前在应用程序需要获取Kubernetes集群中资源的某一特定状态时，通常是采用轮询接口服务器的方法来获取该特定状态，这样通常会对接口服务器带来极大负担，可能导致接口服务器对集群中的其它对象的数据请求的响应延迟，进而间接影响集群性能。

发明内容

本公开实施例的一个目的是提供一种用于资源状态监控的新技术方案。

根据本公开的第一方面，提供了一种资源状态监控方法，应用于Kubernetes集群的资源状态监控服务器，该方法包括：

接收应用程序发送的、对所述Kubernetes集群中的资源对象的状态进行监控的数据请求，其中，所述数据请求中包括所述应用程序对所述资源对象的期望状态；

响应于所述数据请求，对所述资源对象的状态进行监控；

在所述资源对象的状态变更为所述期望状态的情况下，向所述应用程序发送所述资源对象的状态已变更为所述期望状态的通知消息。

可选地，所述响应于所述数据请求，对所述资源对象的状态进行监控，包括：

响应于所述数据请求，生成记录所述资源对象的状态变化的状态对象，其中，所述状态对象包括所述资源对象的标识信息、所述资源对象的实时状态；

根据所述状态对象，对所述资源对象的状态进行监控。

可选地，所述根据所述状态对象，对所述资源对象的状态进行监控，包括：

获取与所述资源对象对应的超时时长；

在所述超时时长内，根据所述状态对象，对所述资源对象的状态进行监控。

可选地，所述在所述超时时长内，根据所述状态对象，对所述资源对象的状态进行监控，包括：

若在所述超时时长内，所述状态对象中的所述实时状态被更新为所述期望状态，则结束对所述资源对象的状态的监控。

可选地，所述方法通过以下步骤更新所述状态对象中的所述实时状态：

向所述Kubernetes集群的接口服务器发送监听所述资源对象的状态的数据请求；

根据所述接口服务器提供的、针对所述资源对象的状态数据，更新所述状态对象中的所述实时状态。

可选地，在所述结束对所述资源对象的状态的监控步骤之后，所述方法还包括：

存储所述资源对象的实时状态至本地缓存区中。

可选地，所述Kubernetes集群包括多个资源状态监控服务器；

所述方法还包括：

所述多个资源状态监控服务器同时对所述资源对象的状态进行监控，并在所述资源对象的状态变更为所述期望状态的情况下，由所述多个资源状态监控服务器中的主资源状态监控服务器向所述目标对象发送所述资源对象的状态已变更为所述期望状态的通知消息。

可选地，所述主资源状态监控服务器由所述多个资源状态监控服务器基于共识算法确定。

根据本公开的第二方面，提供一种资源状态监控装置，应用于Kubernetes集群的资源状态监控服务器，包括：

数据请求接收模块，用于接收应用程序发送的、对所述Kubernetes集群中的资源对象的状态进行监控的数据请求，其中，所述数据请求中包括所述应用程序对所述资源对象的期望状态；

监控模块，用于响应于所述数据请求，对所述资源对象的状态进行监控；

通知模块，用于在所述资源对象的状态变更为所述期望状态的情况下，向所述应用程序发送所述资源对象的状态已变更为所述期望状态的通知消息。

根据本公开的第三方面，还提供了一种电子设备，包括第二方面所述的装置；或者，

所述电子设备包括：

存储器，用于存储可执行的指令；

处理器，用于根据所述指令的控制运行所述电子设备执行如第一方面任意一项所述的方法。

根据本公开的第四方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有可被计算机读取执行的计算机程序，所述计算机程序用于在被所述计算机读取运行时，执行如第一方面任意一项所述的方法。

根据本公开的实施例，在应用程序需要获取Kubernetes集群中的资源对象的某个期望状态时，只需要向Kubernetes集群的资源状态监控服务器发送对该资源对象的状态进行监控的数据请求；之后，由该服务器响应于该数据请求，对该资源对象的状态进行监控，并在该资源对象的状态变更为该应用程序期望获得的期望状态时，向该应用程序发送对应的通知消息，该应用程序即可方便的获得该资源对象的状态。该方法可以不对Kubernetes集群的接口服务器进行轮询，而是由资源状态监控服务器响应应用程序的数据请求，对资源对象的状态进行监控，不仅可以向应用程序提供可靠的资源状态，而且还可以降低集群的运行压力，提升集群性能。

通过以下参照附图对本公开的示例性实施例的详细描述，本公开的其它特征及其优点将会变得清楚。

附图说明

被结合在说明书中并构成说明书的一部分的附图示出了本公开的实施例，并且连同其说明一起用于解释本公开的原理。

图1是根据一个实施例的资源状态监控方法的流程示意图。

图2是根据一个实施例的资源状态监控方法的处理示意图。

图3是根据一个实施例的资源状态监控处理的第一结构示意图。

图4是根据一个实施例的资源状态监控处理的第二结构示意图。

图5是根据一个实施例的资源状态监控装置的原理框图。

图6是根据一个实施例的电子设备的硬件结构示意图。

具体实施方式

现在将参照附图来详细描述本公开的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。

在这里示出和讨论的所有例子中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它例子可以具有不同的值。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

<方法实施例>

请参看图1，其是根据一个实施例的资源状态监控方法的流程示意图。本实施例提供的资源状态监控方法可以应用于Kubernetes集群的资源状态监控服务器中，该服务器可以位于Kubernetes集群中的任意一个节点中。如图1所示，该方法可以包括如下步骤S1100-S1300，以下予以详细说明。

步骤S1100，接收应用程序发送的、对所述Kubernetes集群中的资源对象的状态进行监控的数据请求，其中，所述数据请求中包括所述应用程序对所述资源对象的期望状态。

在本实施例中，应用程序，可以是Kubernetes集群之外的应用程序，即，外部应用，该应用程序可以在获取到关注的资源对象的状态变更为期望状态时，进行后续业务处理。

例如，该应用程序可以是用于对集群进行统一纳管处理的纳管服务器中的应用程序，该应用程序可以根据接收到的用户触发操作，通过调用Kubernetes集群的接口服务器，即apiserver，在该Kubernetes集群中创建一个资源对象，例如，创建一个容器组；在应用程序创建了该容器组之后，可以在该容器组被创建并变更为正常运行，即，进入running状态时，该应用程序向用户所使用的终端设备发出该容器组已被成功创建且正常运行的提示消息。

在本实施例中，Kubernetes集群中的资源对象可以是Kubernetes集群中的应用(APP)，例如，部署(Deployment)、状态副本集(StatefulSet)，以及路由(Ingress)、容器组(pod)、容器(container)、服务(Service)、复制控制器(RC，ReplicationController)等资源中的一种或多种。

在具体实施时，应用程序在向资源状态监控服务器发送针对资源对象的状态进行监控的数据请求时，可以同时发送对多个资源对象的状态进行监控的数据请求，例如，在一个数据请求中，可以同时请求对容器组1、容器组2、容器组3的状态进行监控，并且，该请求中，包含对容器组1的期望状态、容器组2的期望状态以及容器组3的期望状态。

需要说明的是，在本实施例中，为方便说明，以资源对象为容器组，即Pod进行举例说明。

在步骤S1100之后，执行步骤S1200，响应于所述数据请求，对所述资源对象的状态进行监控。

请参看图2，其是根据一个实施例的资源状态监控方法的处理示意图。在具体实施时，所述响应于所述数据请求，对所述资源对象的状态进行监控，包括：响应于所述数据请求，生成记录所述资源对象的状态变化的状态对象，其中，所述状态对象包括所述资源对象的标识信息、所述资源对象的实时状态；根据所述状态对象，对所述资源对象的状态进行监控。

具体来讲，在资源状态监控服务器接收到应用程序发送的数据请求之后，可以实例化一个针对该数据请求中的资源对象进行监控的状态对象，例如，可以通过图2所示的Reflector()函数实例化一个与该资源对象对应的状态对象，该状态对象中可以包括该资源对象的标识信息、该资源对象的实时状态等信息。

在资源状态监控服务器实例化与资源对象对应的状态对象之后，由于资源状态监控服务器可能同时对多个不同资源对象的状态进行监控，因此，资源状态监控服务器可以在自身的本地缓存区中维护一个状态变化队列，并将上述状态对象加入该队列中，其中，该队列可以是图2所示的DeltaFIFO队列，具体的，该队列可以为一个用于记录资源对象的状态变化的先进先出队列，在资源对象的状态变更为期望状态时，资源状态监控服务器向应用程序发送对应的通知消息。

在具体实施时，应用程序在向资源状态监控服务器发送针对资源对象的状态进行监控的数据请求时，可以对应的设置一个超时时长，仅当在该超时时长内，应用程序等待资源状态监控服务器提供对应的通知消息，而在等待时长超过该超时时长时，应用程序可以认为该数据请求的处理结果为异常，此时，应用程序可以根据情况或是向用户所使用的终端设备发送该资源对象的状态出现异常的提示信息，或是可以再次向资源状态监控服务器发送针对该资源对象的状态进行监控的数据请求。

即，所述根据所述状态对象，对所述资源对象的状态进行监控，包括：获取与所述资源对象对应的超时时长；在所述超时时长内，根据所述状态对象，对所述资源对象的状态进行监控。

在本实施例中，该超时时长可以在所述数据请求中获得；当然，在具体实施时，也可以预先为不同的资源对象预设不同的超时时长，此处不做特殊限定。

在本实施例中，所述在所述超时时长内，根据所述状态对象，对所述资源对象的状态进行监控，包括：若在所述超时时长内，所述状态对象中的所述实时状态被更新为所述期望状态，则结束对所述资源对象的状态的监控，

如图2所示，在本实施例中，针对不同的资源对象，资源状态监控服务器在根据实例化的状态对象对资源对象的状态进行监控时，可以对应的创建不同的事件，该事件具体可以为创建事件，即Event:Create、更新事件，即Event:Update以及删除事件，即Event:Delete，并将该事件加入到处理队列，即，Workqueue中，以供事件处理框架，即图2所示的prcessItem针对不同的事件进行处理。

创建事件，是指针对应用程序发送的一个数据请求，在实例化针对该数据请求中的资源对象的状态对象之后，创建的、针对该状态对象的状态进行监控的事件，即，Event:Create，在该事件中，设置超时时长，并在该时长范围内，对该资源对象的状态进行监控，如果在该超时时长内，该资源对象的状态，即，其对应的状态对象中的实时状态变更为期望状态，则向应用程序发送通知消息。

另外，针对一个资源对象的创建事件，通常对应的存在多个更新事件，例如，在创建容器组时，根据创建时的不同阶段，该容器组通常对应多个状态，例如，可能对应预处理完成状态、创建成功状态、正常运行状态等状态；在具体实施时，在资源对象的状态发生变更时，可以根据触发的更新事件，更新该资源对象对应的状态对象中的实时状态，并在该实时状态变更为期望状态时，结束对该资源对象的监控，以避免重复的向应用程序发送通知消息。

在具体实施时，本实施例的资源状态监控方法通过以下步骤更新所述状态对象中的所述实时状态：向所述Kubernetes集群的接口服务器发送监听所述资源对象的状态的数据请求；根据所述接口服务器提供的、针对所述资源对象的状态数据，更新所述状态对象中的所述实时状态。

具体来讲，区别于现有技术中轮询接口服务器，以获取资源对象的实时状态的方法，本实施例提供的方法在需要获取资源对象的实时状态时，不需要使用轮询的方式，而是通过向接口服务器发送监听资源对象的状态的数据请求，在接口服务器接收到该数据请求时，设置监听任务监听该资源对象的状态，并在该资源对象的状态发生变更的情况下，将变更后的实时状态发送给资源监控服务器。

例如，当接口服务器接收到用于获取资源对象的实时状态的数据请求时，可以使用ListerWatcher()接口实例化与该资源对象对应的监听对象；之后，接口服务器将该监听对象加入到监听任务列表(List)中，以监听该资源对象的状态；当接口服务器通过实例化的监听对象监听到该资源对象的状态发生变更时，可以使用watchHandler将该资源对象更新后的状态以消息的形式发送给资源监控服务器，其中，ListerWatcher()是Kubernetes的client-go开发库中的接口函数，其用于持续获取资源对象的增量变化信息，watchHandler是用于传递监听消息的消息句柄。

在本实施例中，接口服务器在监听到资源对象的状态发生变更的情况下，可以通过调用与该数据请求对应的回调函数，向接口服务器发送该资源对象的实时状态。

当然，当接口服务器监听到资源对象的状态发生变更时，也可以使用其他方法将该状态发送给资源监控服务器，此处不再赘述。

另外，在资源调度服务器监控到资源对象的状态变更为应用程序的期望状态并结束对该资源对象的状态的监控之后，还可以将该状态存储到本地缓存区中，即，在所述结束对所述资源对象的状态的监控步骤之后，所述方法还包括：存储所述资源对象的实时状态至本地缓存区中。

在步骤S1200之后，执行步骤S1300，在所述资源对象的状态变更为所述期望状态的情况下，向所述应用程序发送所述资源对象的状态已变更为所述期望状态的通知消息。

请参看图3，其是根据一个实施例提供的资源状态监控处理的第一结构示意图。如图3所示，可以在Kubernetes集群中设置一个资源状态监控服务器，该服务器可以是该集群中的任意一个节点服务器。在该资源状态监控服务器监控到资源对象的状态变更为应用程序的期望状态时，则可以向该应用程序发送该资源对象的状态已变更为期望状态的通知消息，以供该应用程序根据该通知消息进行后续处理。

需要说明的是，所述Kubernetes集群可以同时包括多个资源状态监控服务器；所述方法还包括：所述多个资源状态监控服务器同时对所述资源对象的状态进行监控，并在所述资源对象的状态变更为所述期望状态的情况下，由所述多个资源状态监控服务器中的主资源状态监控服务器向所述目标对象发送所述资源对象的状态已变更为所述期望状态的通知消息。

请参看图4，其是根据一个实施例提供的资源状态监控处理的第二结构示意图。具体来讲，为了能够稳定的向应用程序提供被监控的资源对象的状态，可以在Kubernetes集群中设置多个资源状态监控服务器，例如图4所示的资源状态监控服务器1、资源状态监控服务器2、…资源状态监控服务器n，该多个资源状态监控服务器可以分别位于Kubernetes集群的多个节点中；该多个资源状态监控服务器可以同时运行，以及同时对接收到的、应用程序发送的针对Kubernetes集群中的资源对象进行监控的数据请求进行响应，并对该资源对象的状态进行监控，以及在各自的本地缓存区中缓存获取到的该资源对象的状态；另外，为了保证同一时刻仅有一个资源状态监控服务器向应用程序提供状态通知服务，该多个资源状态监控服务器可以基于共识算法(ConsensusGlgorithm)，例如，可以基于Raft协议选取主资源状态监控服务器，例如，可以选取资源状态监控服务器2为主资源状态监控服务器，并在同一时间内，由该主资源状态监控服务器向应用程序提供通知服务，其中，在本实施例中，共识算法中的共识，是指多个资源状态监控服务器对某个任务达成一致的认识，即使是在部分服务器存在故障、网络延时或者网络分割的情况下。

根据以上步骤S4100-S4300可知，本实施例的方法在应用程序需要获取Kubernetes集群中的资源对象的某个期望状态时，只需要向Kubernetes集群的资源状态监控服务器发送对该资源对象的状态进行监控的数据请求；之后，由该服务器响应于该数据请求，对该资源对象的状态进行监控，并在该资源对象的状态变更为该应用程序期望获得的期望状态时，向该应用程序发送对应的通知消息，该应用程序即可方便的获得该资源对象的状态。该方法可以不对Kubernetes集群的接口服务器进行轮询，而是由资源状态监控服务器响应应用程序的数据请求，对资源对象的状态进行监控，不仅可以向应用程序提供可靠的资源状态，而且还可以降低集群的运行压力，提升集群性能。

<装置实施例>

与上述方法实施例相对应，在本实施例中，还提供一种资源状态监控装置，其可以应用于Kubernetes集群的资源状态监控服务器中，如图5所示，该装置5000可以包括数据请求接收模块5100、监控模块5200和通知模块5300。

数据请求接收模块5100，用于接收应用程序发送的、对所述Kubernetes集群中的资源对象的状态进行监控的数据请求，其中，所述数据请求中包括所述应用程序对所述资源对象的期望状态。

监控模块5200，用于响应于所述数据请求，对所述资源对象的状态进行监控。

在一个实施例中，该监控模块5200在响应于所述数据请求，对所述资源对象的状态进行监控时，可以用于：

根据所述状态对象，对所述资源对象的状态进行监控。

在一个实施例中，该监控模块5200在根据所述状态对象，对所述资源对象的状态进行监控时，可以用于：

获取与所述资源对象对应的超时时长；

在一个实施例中，在所述超时时长内，该监控模块5200在根据所述状态对象，对所述资源对象的状态进行监控时，可以用于：

在一个实施例中，该装置5000还包括状态更新模块，用于：

在一个实施例中，该装置5000还包括状态存储模块，用于在所述监控模块5200结束对所述资源对象的状态的监控之后，存储所述资源对象的实时状态至本地缓存区中。

通知模块5300，用于在所述资源对象的状态变更为所述期望状态的情况下，向所述应用程序发送所述资源对象的状态已变更为所述期望状态的通知消息。

<设备实施例>

与上述方法实施例相对应，在本实施例中，还提供一种电子设备，其可以包括根据本公开任意实施例的资源状态监控装置5000，用于实施本公开任意实施例的资源状态监控方法。

如图6所示，该电子设备6000还可以包括处理器6200和存储器6100，该存储器6100用于存储可执行的指令；该处理器6200用于根据指令的控制运行电子设备以执行根据本公开任意实施例的资源状态监控方法。

以上装置6000的各个模块可以由处理器6200运行该指令以执行根据本公开任意实施例的资源状态监控方法来实现。

<介质实施例>

在本实施例中，还提供一种计算机可读存储介质，该计算机可读存储介质存储有可被计算机读取并运行的计算机程序，所述计算机程序用于在被所述计算机读取运行时，执行如本公开以上任意实施例所述的方法。

本公开可以是系统、方法和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于使处理器实现本公开的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本公开的各个方面。

这里参照根据本公开实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。对于本领域技术人员来说公知的是，通过硬件方式实现、通过软件方式实现以及通过软件和硬件结合的方式实现都是等价的。

以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。本公开的范围由所附权利要求来限定。

Claims

1.一种资源状态监控方法，其特征在于，应用于Kubernetes集群的资源状态监控服务器，包括：

响应于所述数据请求，对所述资源对象的状态进行监控；

2.根据权利要求1所述的方法，其特征在于，所述响应于所述数据请求，对所述资源对象的状态进行监控，包括：

根据所述状态对象，对所述资源对象的状态进行监控。

3.根据权利要求2所述的方法，其特征在于，所述根据所述状态对象，对所述资源对象的状态进行监控，包括：

获取与所述资源对象对应的超时时长；

4.根据权利要求3所述的方法，其特征在于，所述在所述超时时长内，根据所述状态对象，对所述资源对象的状态进行监控，包括：

5.根据权利要求4所述的方法，其特征在于，所述方法通过以下步骤更新所述状态对象中的所述实时状态：

6.根据权利要求4所述的方法，其特征在于，在所述结束对所述资源对象的状态的监控步骤之后，所述方法还包括：

存储所述资源对象的实时状态至本地缓存区中。

7.根据权利要求1所述的方法，其特征在于，所述Kubernetes集群包括多个资源状态监控服务器；

所述方法还包括：

8.根据权利要求7所述的方法，其特征在于，所述主资源状态监控服务器由所述多个资源状态监控服务器基于共识算法确定。

9.一种资源状态监控装置，其特征在于，应用于Kubernetes集群的资源状态监控服务器，包括：

10.一种电子设备，其特征在于，包括权利要求9所述的装置；或者，

所述电子设备包括：

存储器，用于存储可执行的指令；

处理器，用于根据所述指令的控制运行所述电子设备执行如权利要求1-8任意一项所述的方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有可被计算机读取执行的计算机程序，所述计算机程序用于在被所述计算机读取运行时，执行根据权利要求1-8中任意一项所述的方法。