CN115022198A - 资源信息获取方法、设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种资源信息获取方法、设备及存储介质。在本申请实施例中，针对CRD增加CRD的资源定义，在CRD的资源定义中，以CRD定义的CR对象的属性信息在CR中的索引路径，定义该CR对象的属性信息，实现了对不同类型的CRD资源的统一管理。这样，无论CR对象为何种类型的自定义资源，在对CR对象进行管理时，可从CRD的资源定义中，获取CR对象在CR中的索引路径；并根据CR对象的属性信息在CR的索引路径，从CR中获取CR对象的属性信息，实现了对自定义资源信息的统一获取方式，便于后续基于CR对象的信息对CR对象进行管控，有助于提高PaaS平台对自定义资源的管控能力。

Description

资源信息获取方法、设备及存储介质

技术领域

本申请涉及云服务技术领域，尤其涉及一种资源信息获取方法、设备及存储介质。

背景技术

PaaS平台是一个基于容器集群管理系统构建的云平台。自定义资源定义(CustomResource Definition，CRD)是容器集群管理平台为提高可扩展性，让开发者去定制资源的一种方式。

由于自定义资源(Custom Resource，CR)的定义多种多样，缺乏统一的标准化的管控和维护能力，无法采用统一的方式获取自定义资源(Custom Resource，CR)的信息。

发明内容

本申请的多个方面提供一种资源信息获取方法、设备及存储介质，用以针对CRD资源提供一种统一的资源信息获取方式。

本申请实施例提供一种资源信息确定方法，包括：

获取自定义资源定义CRD的资源定义；所述资源定义以自定义资源CR对象的属性信息在所述CRD定义的CR中的索引路径，定义所述CR对象的属性信息；

从所述资源定义中，获取所述CR对象的属性信息在所述CR中的索引路径；

根据所述CR对象的属性信息在所述CR的索引路径，从所述CR中确定所述CR对象的属性信息。

本申请实施例还提供一种计算设备，包括：存储器和处理器；其中，所述存储器，用于存储计算机程序；

所述处理器耦合至所述存储器，用于执行所述计算机程序以用于执行上述资源信息获取方法中的步骤。

本申请实施例还提供一种存储有计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行上述资源信息获取方法中的步骤。

在本申请实施例中，针对CRD增加CRD的资源定义，在CRD的资源定义中，以CRD定义的CR对象的属性信息在CR中的索引路径，定义该CR对象的属性信息，实现了对不同类型的CRD资源的统一管理。这样，无论CR对象为何种类型的自定义资源，在对CR对象进行管理时，可从CRD的资源定义中，获取CR对象在CR中的索引路径；并根据CR对象的属性信息在CR的索引路径，从CR中获取CR对象的属性信息，实现了对自定义资源信息的统一获取方式，便于后续基于CR对象的信息对CR对象进行管控，有助于提高PaaS平台对自定义资源的管控能力。

附图说明

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

图1为容器集群管理系统中一些资源对象的示例；

图2为本申请实施例提供的资源信息获取方法的流程示意图；

图3为本申请实施例提供的CRD的资源定义的系统框架图；

图4为本申请实施例提供的应用状态感知方法的流程示意图；

图5为本申请实施例提供的CRD的控制面管理方法的流程示意图；

图6为本申请实施例提供的计算设备的结构示意图。

具体实施方式

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

PaaS平台可通过统一应用管理、异构资源管理和智能运维等关键能力，支撑PaaS产品。在混合云多版本形态和异构基础设施下的统一交付运维。应用实例(Appinstance)为PaaS平台中应用发布的单位，是一个Charts包部署到平台后的一个实例，其下面包含了各种资源(Resource)。例如，Deployment，Statefulset等工作负载资源，及自定义资源(CR)等。

资源是容器集群管理系统API中的一个端点，其中存储的是某个类别的API对象(又可称为资源对象)的一个集合。例如，容器集群管理系统内置的Pod资源包含一组Pod对象。容器集群管理系统API可使用户使查询和操纵容器集群管理系统API中资源对象(例如：Pod、Namespace、ConfigMap和Event)的状态等。容器集群管理系统中对象(资源对象)是容器集群管理系统中的持久性实体。

自定义资源(Custom Resource，CR)是对容器集群管理系统API的扩展。自定义资源定义(CRD)为自定义资源(CR)的定义，为容器集群管理系统提供给用户的一种扩展资源的方法，CRD对应的资源对象实体为自定义资源，即CR。用户可以通过CRD定义自定义资源。图1给出了容器集群管理系统中一些内置资源和自定义资源。

由于CRD是由用户定制的，不同用户定义CR的方式各式各样，同一用户定义不同类型的CR的方式也有差异。在一些方案中，针对每类自定义资源定制对应的控制器(Controller)，由自定义资源定制对应的控制器对该类自定义资源对象进行资源管理。但是，对不同类型的自定义资源缺乏统一的标准化管理和维护方式，导致无法采用统一的方式获取不同类型的自定义资源的信息，导致PaaS平台对自定义资源的管控能力较差。

为了解决上述技术问题，在本申请一些实施例中，针对CRD增加CRD的资源定义，在CRD的资源定义中，以CRD定义的CR对象的属性信息在CR中的索引路径，定义该CR对象的属性信息，实现了对不同类型的CRD资源的统一管理。这样，无论CR对象为何种类型的自定义资源，在对CR对象进行管理时，可从CRD的资源定义中，获取CR对象在CRD定义的CR中的索引路径；并根据CR对象的属性信息在CR的索引路径，从CR中获取CR对象的属性信息，实现了对自定义资源信息的统一获取方式，便于后续基于CR对象的信息对CR对象进行管控，有助于提高PaaS平台对自定义资源的管控能力。

以下结合附图，详细说明本申请各实施例提供的技术方案。

应注意到：相同的标号在下面的附图以及实施例中表示同一物体，因此，一旦某一物体在一个附图或实施例中被定义，则在随后的附图和实施例中不需要对其进行进一步讨论。

图2为本申请实施例提供的资源信息获取方法的流程示意图。如图2所示，该资源信息获取方法主要包括：

201、获取CRD的资源定义；该资源定义以CR对象的属性信息在CRD对应的CR中的索引路径，定义CR对象的属性信息。

202、从资源定义中，获取CR对象的属性信息在CR中的索引路径。

203、根据CR对象的属性信息在CR的索引路径，从CR中确定CR对象的属性信息。

本申请实施例提供的资源信息获取方法可由CRD的资源定义(CRD Definition)的控制器执行。CRD的资源定义的控制器与CRD的资源定义相结合，实现Operator模式。Operator是容器集群管理系统的扩展软件，可利用自定义资源管理应用及其组件。Operator模式可在不修改容器集群管理系统自身代码的情况下，通过为一个或多个自定义资源关联控制器来扩展集群的能力。Operator是容器集群管理系统API的客户端，充当CR的控制器。

在本申请实施例中，CRD是自定义资源(CR)的资源定义。CR可以yaml文件形式存储于容器集群管理系统中的API服务(API Server)组件中。CR中定义了CR对象的属性信息。其中，CR对象的属性信息是指反映CR对象的属性的信息，包括但不局限于：CR对象的状态信息、工作负载(workload)资源信息(也可称为子资源信息)、硬件资源需求信息及调度属性信息等。

其中，CR对象的状态信息可反映CR对象的健康状态，根据CR对象的状态信息可确定CR对象是否达到终态(即就绪状态)。CR对象的工作负载是指CR对象在容器集群管理系统上运行的应用程序，在容器集群管理系统可以在容器组(如Pod)中运行工作负载。在容器集群管理系统中不需要直接管理每个Pod，可以使用负载资源管理一组Pods。这些工作负载资源配置控制器来确保工作负载资源的状态达到期望状态。

硬件资源需求信息反映CR对象对硬件资源的需求。硬件资源包括但不局限于：计算资源(如CPU核数)、存储资源(如内存量)及磁盘资源等。

CR对象的调度属性信息用于反映CR对象的调度需求，这些影响可影响CR对象在工作节点(worker)上的部署。其中，CR对象的调度属性信息包括但不局限于：运行CR对象的工作负载的容器组的标签(Label)、调度亲和性规则、容忍度规则以及节点选择器(NodeSelector)配置等。

调度亲和性规则是指容器组与其它容器组之间的亲和度规则；对于具有亲和性的应用实例，可部署于同一工作节点(worker)；对于不具有亲和性的容器组，不能部署于同一计算节点。标签用于表明容器组与其它容器组之间的亲和度。

容忍度为定义在容器组(如pod)上的键值型的属性数据，用于配置其可容忍的计算节点的污点，而且调度器仅可将容器组调度至该应用实例能够容忍节点污点的计算节点上。

节点选择器配置用于选择工作节点，由调度器(scheduler)调度节点选择器配置标签(Label)匹配，调度容器组到目标工作节点。

上述实施例提供的CR对象的属性信息仅为示例性说明，并不构成限定。不同类型的自定义资源的CR定义CR对象的属性信息的方式不同。例如，各个CR对象是否到终态往往通过状态字段(status)中的不同字段来定义。比如有些CR是通过status.ready是否为true来表示是否达到终态，而有些CR是通过status.health是否为green来表示等。又例如，对于CR对象的硬件资源需求，有些CR是通过spec.nodes.data.resoures.requests.cpu的字段表示CR对象的CPU需求；有些CR是通过spec.template.cpu的字段表示CR对象的CPU需求等。不同CR定义同一属性的方式不同，导致获取CR对象的属性信息的路径不同。现有PaaS平台对于CRD资源缺乏统一的管理和维护机制，导致PaaS平台感知CR对象的属性信息的复杂度较高。

在本申请实施例中，为了实现对CRD资源的统一管理和维护，针对不同类型的自定义资源(CR)的资源定义，即自定义资源定义(CRD)，增加对CRD的资源定义(CRDDefinition)。CRD的资源定义是将CRD作为一种资源，对CRD进行资源定义。在本申请实施例中，为了实现对CRD资源的统一管理，在CRD的资源定义中，以CRD定义的CR对象的属性信息在该CR中的索引路径，定义CR对象的属性信息。其中，CR对象的属性信息在CR中的索引路径可理解为：在CR中查询或获取到CR对象的属性信息的路由信息，类似于文件目录。CR对象的属性信息在CR中的索引路径可以CR对象的属性信息在CR中的定义路径进行表示。例如，CR示例的部分代码如下所示：

在上述CR示例中，CR对象的状态信息在CRD中的定义路径为“spec.status.health”，即在CRD的spec字段下定义了status字段，status字段下定义了CR对象的状态信息字段health，其中，字段“spec.status.health”的值表示该CR对象的状态信息。相应地，CR对象的状态信息在CR中的索引路径为“spec.status.health”。

CRD的资源定义以CRD定义的CR对象的属性信息在该CR中的索引路径，定义CR对象的属性信息。例如，在一些实施例中，CRD的资源定义的CRD接口定义如下：

在上述CRD的资源定义中，以CR对象的属性信息在CR中的索引路径，定义CR对象的属性信息。上述CRD的资源定义可由用户对CR进行代码梳理来确定CRD的资源定义中CR对象的属性信息的索引路径，并写入CRD的资源定义中相应字段。其中，CRD的资源定义也是一种CRD对应的CR实体，同样可以yaml文件的形式存储于API服务组件中。

基于上述对CR对象统一形式管理的CRD的资源定义，在本申请步骤201中，可获取CRD的资源定义。结合图3示出的CRD的资源定义的系统框架，针对任一CRD，可以CRD的标识在API服务组件中进行查询，以获取CRD的标识对应的CRD的资源定义。其中，CRD的标识是指唯一标识一种CR对象的信息，可用CR对象的组别、版本号和资源类型(Group、Version andKind，GVK)进行表示。

进一步，在步骤202中，可从CRD的资源定义中，获取CR对象的属性信息在CRD定义的CR中的索引路径。CR对象为CRD定义的资源对象；CR为CRD定义的资源实体。例如，从上述CRD的资源定义中，可获取CR对象的状态信息在CR中的索引路径为“object.status.health”。

在确定出CR对象的属性信息在CR中的索引路径之后，在步骤203中，可根据CR对象的属性信息在CR的索引路径，从CR中确定CR对象的属性信息。

在本实施例中，针对CRD增加CRD的资源定义，在CRD的资源定义中以CRD定义的CR对象的属性信息在CRD的资源实体CR中的索引路径，定义该CR对象的属性信息，实现了对不同类型的CRD资源的统一管理。这样，无论CR对象为何种类型的自定义资源，在对CR对象进行管理时，可从CRD的资源定义中，获取CR对象在CR中的索引路径；并根据CR对象的属性信息在CR的索引路径，从CR中获取CR对象的属性信息，实现了对自定义资源信息的统一获取方式，便于后续基于CR对象的信息对CR对象进行管控，有助于提高PaaS平台对自定义资源的管控能力。

下面结合不同的属性信息，对确定CR对象的属性信息的实施方式进行示例性说明。在一些实施例中，CR对象的属性信息包括：CR对象的子资源信息。其中，CR对象的子资源也可称为CR对象的工作负载(workload)。工作负载(Workload)可包括：StatefulSet、Deployment、ReplicaSet、Daemonset等资源，也可包括CRD资源等。在本申请实施例中，可从CRD的资源定义中，确定用于表示CR对象的子资源的标识符。在上述CRD的资源定义示例中，CR对象的子资源的标识符为“topology”。其中，“spec.topology”字段描述了CR对象生成的子资源的部分模板，主要包括：子资源的名称(name)、命名空间(namespace)、标签(label)等等。通过这些模版片段，CRD的资源定义的控制器能够获取CR对象的子资源信息。其中，“spec.topology”字段描述的CR对象的子资源可以CUE模板语言进行表示。CUE是一种服务于云化配置的强类型配置语言。

在确定出表示CR对象的子资源的标识符之后，可从CRD的资源定义中，获取CR对象的子资源的标识符下定义的CR对象的子资源的标识。其中，子资源的标识可以子资源的GVK信息进行表示。例如，上述CRD的资源定义示例中，子资源的标识为“apps.v1.StatefulSet”。进一步，可从CRD的资源定义中，获取CR对象的子资源的标识对应的子资源信息的索引路径。例如，上述CRD的资源定义示例中，子资源的标识为子资源的GVK：“apps.v1.StatefulSet”；则根据子资源的GVK，获取CR对象的子资源的标识对应的子资源信息：命名空间的索引路径为“parameter.namespace”；标签的索引路径为：

labels:{

"elasticsearch.xxx.com/cluster-name":parameter.name

"elasticsearch.xxx.com/role":"data"}。

CRD的资源定义的控制器，可根据CR对象的子资源信息在CR中的索引路径，从CR定义中获取CR对象的子资源信息，实现CR对象的workload拓扑的感知，可为CR对象的子资源进行健康检测、调试及调度等提供参考信息。其中，子资源信息可包括：子资源的标识(如GVK等)、子资源的名称、状态信息及调度属性信息等等。

在一些实施例中，CR对象的属性信息包括：CR对象的状态信息。相应地，结合图3，步骤203可实现为：根据CR对象的状态信息在CR的索引路径，从CR中获取CR对象的状态信息(对应图3中的状态感知)；并根据CR对象的状态信息，及CR中定义的CR对象的终态信息，确定CR对象的状态，实现对CR对象的状态感知。其中，CR中定义的CR对象的终态信息由CR的控制器进行控制。CR的控制器可追踪CR对象。CR中有一个代表期望状态的spec字段。CR的控制器负责确保CR对象的当前状态接近期望状态。

可选地，可判断CR对象的状态信息与CR中定义的CR对象的终态信息是否相同；若判断结果为是，确定CR对象的状态到达终态；相应地，若判断结果为否，则确定CR对象的状态未达到状态。其中，对于上述CRD的资源定义的CRD接口定义，可根据CRD的资源定义中的字段spec.status.healthPolicy定义的CR对象的状态信息在CR中的索引路径“object.status.health”，从CR中获取CR对象的状态信息；进一步，判断CR对象的状态信息与CR中定义的CR对象的终态信息是否相同，来确定CR对象的状态是否达到终态。可选地，可通过CUE表达式来判断对应的CR对象是否到达终态。CUE是一种服务于云化配置的强类型配置语言。

上述实施例示出的CR对象的终态感知方式适用于CR对象无子资源(即无workload拓扑)或者CR对象的子资源不需要健康状态检测的实施例。对于CR对象的子资源设置有健康状态检测机制的实施例来说，在判断结果为CR对象的状态信息与CR中定义的CR对象的终态信息相同的情况下，还可根据CR对象的子资源的状态信息，确定CR对象的状态。

具体地，可从CRD的资源定义中获取CR对象的子资源的状态信息；并根据CR对象的子资源的状态信息，确定CR对象的状态。若根据CR对象的子资源的状态信息，确定CR对象的子资源中存在未达到终态的子资源，可确定CR对象的状态未达到终态。相应地，若在CR对象的状态信息与CR中定义的CR对象的终态信息相同的情况下，CR对象的子资源均达到终态，确定CR对象达到状态。

下面结合PaaS平台的应用实例的状态管理方式进行示例性说明。如图4所示，对于应用实例(App instance)，可获取的apptop资源。该apptop资源以yaml文件的形式存储于API服务组件中。其中，apptop资源中记录了应用实例的子资源，例如，deployment、statefulset等。其中，应用实例进行状态管理主要包括以下步骤：

S11、获取应用实例的apptop资源。

S12、遍历apptop记录的应用实例的子资源是否存在CRD资源。若判断结果为是，执行步骤S13。

S13、判断所有CRD是否检测完成；若判断结果为否，执行步骤S14；若判断结果为是，确定应用实例达到终态。

S14、从尚未检测的CRD中任取一个CRD，作为目标CRD。

S15、利用目标CRD的标识在API服务组件中进行查询；若查询到目标CRD对应的资源定义，则执行步骤S16。

S16、从目标CRD的资源定义中，获取目标CRD对应的CR对象的状态信息在目标CR中的索引路径；目标CR为目标CRD的资源实体。

S17、按照CR对象的状态信息在目标CR中的索引路径，从目标CR中获取CR对象的状态信息。

S18、判断CR对象的状态信息与目标CR中定义的CR状态的终态信息是否相同；若判断结果为是，执行步骤S19；若判断结果为否，执行步骤S113。

S19、从CRD的资源定义中，获取CR对象的子资源信息在目标CR中的索引路径。

S110、按照CR对象的子资源信息在目标CR中的索引路径，从目标CR中获取CR对象的子资源的状态信息。

S111、判断CR对象的子资源是否全部达到状态。若判断结果为是，执行步骤S112；若判断结果为否，执行步骤S113。

S112、确定目标CR的CR对象达到状态；返回执行步骤S13。

S113、确定目标CR的CR对象未达到终态；并确定应用实例未达到终态。

在一些实施例中，CR对象的属性信息还可包括：CR对象的硬件资源需求信息。其中，关于硬件资源的描述可参见上述实施例的相关内容，在此不再赘述。在CRD的资源定义中可采用gjson等模版语言定义CR对象的硬件资源需求。在获取CR对象的硬件资源需求时，可采用统一的方式获取。具体地，对不同的CR采用通用标准的方式来等等对于CR对象的硬件资源需求信息，可根据硬件资源需求信息在CR中的索引路径，从CR中获取CR对象的硬件资源需求信息。具体地，可根据硬件资源需求信息在CR中的索引路径，从CR中获取单个CR对象的硬件资源需求信息；并根据CR对象的副本数在CR中的索引路径，从CR中获取CR对象的副本数量；之后，可根据CR对象的副本数量和单个CR对象的硬件资源需求信息，确定CR对象的硬件资源需求信息。具体地，CR对象的单个维度的硬件资源需求信息等于单个CR对象在该维度的硬件资源需求量乘以CR对象的副本数量。

例如，在一些实施例中，容器组里面的CPU的资源需求分别为：spec.nodes.data.resources.requests.cpu为8000m，副本数spec.nodes.data.replicas为3，另外一个master的CPU资源需求为spec.nodes.master.resources.requests.cpu为2000m，副本数spec.nodes.master.replicas为3，CR对象的CPU资源总需求量为8000m*3+2000m*3＝30000m。其中，“m”表示千分之一核。

通过CR对象的硬件资源需求信息在CR中的索引路径，获取CR对象的硬件资源需求信息，可为后续对CR对象进行调度提供依据。

本申请实施例中，CRD的资源定义除了定义CR对象的状态、子资源、硬件资源需求信息之外，还可定义CR对象的调度属性信息。其中，CR对象的调度属性信息影响CR对象在计算集群中的部署。在CRD的资源定义中可采用gjson等模版语言定义CR对象的调度属性信息。在获取CR对象的调度属性时，可采用统一的方式获取。具体地，可从CRD的资源定义中，获取CR对象的调度属性信息在CR中的索引路径。进一步，可根据CR对象的调度属性信息在CR中的索引路径，从CR中获取CR对象的调度属性信息。其中，CR对象的调度属性信息可为CR对象在计算集群中的调度提供依据和条件。

上述实施例提供的资源信息获取方法可由CRD的资源定义(CRD Definition)的控制器执行。在本申请实施例中，获取CRD定义的CR对象的属性信息之后，可根据CR对象的属性信息，对CR对象进行管控。在本申请实施例中，CRD的资源定义对应的控制器在获取CR定义的CR对象的属性信息之后，可将CR对象的属性信息提供给容器集群管理系统中的其它组件，由其它组件对CR对象的管控机制。下面结合不同的属性信息，对根据CR对象的属性信息，对CR对象进行管控的实施方式进行示例性说明。

在一些实施例中，对CR对象进行管控的组件可为CR的控制器。CR的控制器可根据CR对象的状态信息，对CR对象进行应用状态管理，以使CR对象的状态达到期望状态。或者，CR的控制器还可根据CR对象的子资源的状态信息，对CR对象的子资源进行健康检测；并在检测到CR对象的子资源发生异常事件的情况下，调整CR对象的子资源的状态。例如，CR对象的子资源为Pod资源，CR对象的控制器可将CR对象的子资源和CR对象的状态调整为未就绪状态(unready)等等。或者，CR对象的控制器可重新创建Pod，并在Pod创建完成并达到就绪状态时，将CR对象的状态调整为就绪状态(ready)等。

在另一些实施例中，调度器(Scheduler)根据CR对象的硬件资源需求信息和调度属性信息，对CR对象进行调度等等。例如，调度器可根据CR对象的调度属性信息，从计算集群中确定与CR对象的调度属性信息适配的候选工作节点；并根据CR对象的硬件资源需求信息，从候选工作节点中确定满足硬件资源需求信息的目标工作节点；进一步，可在目标工作节点中部署CR对象对应的容器组(如Pod等)。

在PaaS平台中，应用实例(Appinstance)为PaaS平台中应用发布和下线的单位。在下线应用时，可以AppInstance的应用维度做下线处理。AppInstance的应用下线还可下线对应的控制面资源。但是，如果下线了AppInstance的CR子资源的控制面，比如deployment，关键的服务账号(Service Account，SA)资源或者基于角色的访问控制(RBAC)资源等，那么后续如果其他服务或应用下线CRD对应的CR对象的时候，会导致没有控制面来进行资源下线的处理。例如，移除了CR的finalizer，导致下线finalizer对应CR的时候阻塞了对应appinstance的下线流程。基于此，在本申请实施例中，还可提供控制面下线方法，防止出现上述问题，保证能够下线控制面对应的CR资源。

在本申请实施例中，为了防止出现上述问题，在CRD的资源定义中还可定义控制面管理策略，来对CR对象的控制码资源进行生命周期管理。在本申请实施例中，控制面管理策略可包括：等待CR删除策略(Waiting CR Deleted)和直接下线策略(None)。其中，等待CR删除策略是指等待环境中CRD对应的CR对象都下线之后，才下线CRD的控制面所在的Appinstance(CRD的控制面资源)。其中，CRD的控制面对应的appinstance就是CRDDefinition所在的Appinstance。该策略可防止系统中其他appinstance应用生成这个CRD的CR的时候下线了对应的CRD的控制面，导致其它应用对应的CR因为无CRD的控制面而无法下线的问题。直接下线策略是指在下线应用实例时，直接下线对应的CRD的控制面资源。一般用于处理一些无状态的CR。

上述CRD的资源定义中的控制面管理策略可由用户根据CRD对应的子资源的特性进行配置。在一些实施例中，子资源为静态配置，比如某些CR为静态配置，比如xxxConfig，则删除CRD的控制面资源之后，后续CR及其子资源的回收由容器集群管理系统的controller-manager组件处理。因为静态配置类型的CR，不依赖控制面，甚至一些配置类型的CR并无控制面。对于静态配置类CR，可设置CRD的资源定义中控制面管理策略为“直接下线策略”。

对于动态CR(如Redis等)，CRD的控制面的下线一般要等到CRD对应的所有CR对象都下线之后再进行下线才行。因为这些CR对象都是动态的，在下线CRD的控制面资源时，若其中某些CR对象未达到终态，这时下线CRD的控制面资源，则导致未达到终态的CR对象永远不会达到终态。对于达到终态的CR对象，也会因为缺失控制面导致CR对象的状态无法与API服务组件中的CR实现终态同步。

基于上述CRD的资源定义中定义的控制面管理策略，可从CRD的资源定义中，获取CRD的控制面管理策略；并按照控制面管理策略，对CRD的控制面资源进行管理。在一些实施例中，CRD的控制面管理策略为直接下线，则响应于CRD的下线事件，可直接下线CRD对应的控制面资源。

在另一些实施例中，CRD的控制面管理策略为“等待CR删除策略”。相应地，可响应于针对CRD的下线事件，监测CRD对应的CR对象是否全部下线；并在监测到CRD对应的CR对象全部下线的情况下，下线CRD的控制面资源。

上述CRD的控制面管理策略可由CRD的资源定义对应的控制器进行执行。如图3所示，CRD的资源定义对应的控制器可使用List And Watch的方法，调用List和Watch两种类型的API进行CRD的控制面资源的生命周期。下面以应用实例下线时，控制面的资源管理方法进行示例性说明。如图5所示，主要步骤可包括：

S21、响应于应用实例下线事件，获取应用实例的CRD的资源定义。

S22、监测计算集群中是否存在CRD对应的CR对象。若存在，执行步骤S23；若不存在，执行步骤S24。

S23、保留CRD的资源定义和CRD的控制面资源。

S24、删除CRD的资源定义中的finalizer对应的资源，即CRD的控制面资源。

S25、删除应用实例中的其它资源。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤201和202的执行主体可以为设备A；又比如，步骤201的执行主体可以为设备A，步骤202的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如201、202等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。

相应地，本申请实施例还提供一种存储有计算机指令的计算机可读存储介质，当计算机指令被一个或多个处理器执行时，致使一个或多个处理器执行上述资源信息获取方法中的步骤。

本申请实施例还提供一种计算机程序产品，包括：计算机程序。该计算机程序被一个或多个处理器执行时，致使一个或多个处理器执行上述资源信息获取方法中的步骤。在本申请实施例中，不限定计算机程序产品的具体实现形态。在一些实施例中，计算机程序产品可实现为容器集群管理平台中资源对象的控制器等。

图6为本申请实施例提供的计算设备的结构示意图。如图6所示，该计算设备包括：该计算设备包括：存储器60a和处理器60b。其中，存储器60a，用于存储计算机程序。

处理器60b耦合至存储器60a，用于执行计算机程序以用于：获取自定义资源定义CRD的资源定义；资源定义以自定义资源CR对象的属性信息在CR中的索引路径，定义CR对象的属性信息；CR为CRD的资源实体；从资源定义中，获取CR对象的属性信息在CR中的索引路径；根据CR对象的属性信息在CR的索引路径，从CR中确定CR对象的属性信息。

在一些实施例中，CR对象的属性信息包括：CR对象的状态信息。相应地，处理器60b从CR中确定CR对象的属性信息时，具体用于：根据CR对象的状态信息在CR的索引路径，从CR中获取CR对象的状态信息；根据CR对象的状态信息及CR中定义的CR对象的终态信息，确定CR对象的状态。

可选地，处理器60b在确定CR对象的状态时，具体用于：判断CR对象的状态信息与CR中定义的CR对象的终态信息是否相同；若判断结果为是，确定CR对象的状态到达终态；或者；判断CR对象的状态信息与CR中定义的CR对象的终态信息是否相同；若判断结果为是，根据CR对象的子资源的状态信息，确定CR对象的状态。

在另一些实施例中，CR对象的属性信息包括：CR对象的子资源信息。相应地，处理器60b在从资源定义中，获取CR对象的属性信息在CR中的索引路径时，具体用于：从资源定义中，确定用于表示CR对象的子资源的标识符；从资源定义中，获取子资源的标识符下定义的CR对象的子资源的标识；从资源定义中，获取CR对象的子资源的标识对应的子资源信息的索引路径。

其中，子资源信息包括：子资源的状态信息。处理器60b还用于：根据子资源的状态信息，确定CR对象的状态。

可选地，处理器60b在根据子资源的状态信息，确定CR对象的状态时，具体用于：根据子资源的状态信息，判断子资源中是否存在未达到终态的子资源；若判断结果为子资源中存在未达到终态的子资源，确定CR对象的状态为未达到终态。

在又一些实施例中，CR对象的属性信息包括：CR对象的硬件资源需求信息和调度属性信息。处理器60b还用于：根据CR对象的调度属性信息，在计算集群中为CR对象进行资源调度，以确定与调度属性信息适配的候选工作节点；根据CR对象的硬件资源需求信息，从候选工作节点中确定满足硬件资源需求信息的目标工作节点；在目标工作节点部署CR对象的容器组。

在本申请实施例中，处理器60b还用于：从资源定义中，获取CRD的控制面管理策略；按照控制面管理策略，对CRD的控制面资源进行管理。

在一些实施例中，控制面管理策略为等待CR对象删除后下线。相应地，处理器60b在按照控制面管理策略，对CRD的控制面资源进行管理时，具体用于：响应于CRD的下线事件，监测CRD对应的CR对象是否全部下线；在监测到CRD对应的CR对象全部下线的情况下，删除控制面资源。

在一些可选实施方式中，如图6所示，该计算设备还可以包括：通信组件60c和电源组件60d等可选组件。图6中仅示意性给出部分组件，并不意味着计算设备必须包含图6所示全部组件，也不意味着计算设备只能包括图6所示组件。

本实施例提供的计算设备，可部署上述CRD的资源定义对应的控制器。针对CRD增加CRD的资源定义，在CRD的资源定义中，以CRD定义的CR对象的属性信息在CR中的索引路径，定义该CR对象的属性信息，实现了对不同类型的CRD资源的统一管理。这样，无论CR对象为何种类型的自定义资源，在对CR对象进行管理时，计算设备可从CRD的资源定义中，获取CR对象在CR中的索引路径；并根据CR对象的属性信息在CR的索引路径，从CR中获取CR对象的属性信息，实现了对自定义资源信息的统一获取方式，便于后续基于CR对象的信息对CR对象进行管控，有助于提高PaaS平台对自定义资源的管控能力。

在本申请实施例中，存储器用于存储计算机程序，并可被配置为存储其它各种数据以支持在其所在设备上的操作。其中，处理器可执行存储器中存储的计算机程序，以实现相应控制逻辑。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

在本申请实施例中，处理器可以为任意可执行上述方法逻辑的硬件处理设备。可选地，处理器可以为中央处理器(Central Processing Unit，CPU)、图形处理器(GraphicsProcessing Unit，GPU)或微控制单元(Microcontroller Unit，MCU)；也可以为现场可编程门阵列(Field-Programmable Gate Array，FPGA)、可编程阵列逻辑器件(ProgrammableArray Logic，PAL)、通用阵列逻辑器件(General Array Logic，GAL)、复杂可编程逻辑器件(Complex Programmable Logic Device，CPLD)等可编程器件；或者为先进精简指令集(RISC)处理器(Advanced RISC Machines，ARM)或系统芯片(System on Chip，SOC)等等，但不限于此。

在本申请实施例中，通信组件被配置为便于其所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G或3G，4G，5G或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件还可基于近场通信(NFC)技术、射频识别(RFID)技术、红外数据协会(IrDA)技术、超宽带(UWB)技术、蓝牙(BT)技术或其他技术来实现。

在本申请实施例中，电源组件被配置为其所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机的存储介质为可读存储介质，也可称为可读介质。可读存储介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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

Claims (11)

1.一种资源信息确定方法，其特征在于，包括：

获取自定义资源定义CRD的资源定义；所述资源定义以自定义资源CR对象的属性信息在所述CRD对应的CR中的索引路径，定义所述CR对象的属性信息；

从所述资源定义中，获取所述CR对象的属性信息在所述CR中的索引路径；

根据所述CR对象的属性信息在所述CR的索引路径，从所述CR中确定所述CR对象的属性信息。

2.根据权利要求1所述的方法，其特征在于，所述CR对象的属性信息包括：所述CR对象的状态信息；

所述根据所述CR对象的属性信息在所述CR的索引路径，从所述CR中确定所述CR对象的属性信息，包括：

根据所述CR对象的状态信息在所述CR的索引路径，从所述CR中获取所述CR对象的状态信息；

根据所述CR对象的状态信息及所述CR中定义的所述CR对象的终态信息，确定所述CR对象的状态。

3.根据权利要求2所述的方法，其特征在于，所述根据所述CR对象的状态信息及所述CR中定义的所述CR对象的终态信息，确定所述CR对象的状态，包括：

判断所述CR对象的状态信息与所述CR中定义的所述CR对象的终态信息是否相同；若判断结果为是，确定所述CR对象的状态到达终态；

或者；

判断所述CR对象的状态信息与所述CR中定义的所述CR对象的终态信息是否相同；若判断结果为是，根据所述CR对象的子资源的状态信息，确定所述CR对象的状态。

4.根据权利要求1所述的方法，其特征在于，所述CR对象的属性信息包括：所述CR对象的子资源信息；

所述从所述资源定义中，获取所述CR对象的属性信息在所述CR中的索引路径，包括：

从所述资源定义中，确定用于表示所述CR对象的子资源的标识符；

从所述资源定义中，获取所述子资源的标识符下定义的所述CR对象的子资源的标识；

从所述资源定义中，获取所述CR对象的子资源的标识对应的子资源信息的索引路径。

5.根据权利要求4所述的方法，其特征在于，所述子资源信息包括：所述子资源的状态信息；所述方法还包括：

根据所述子资源的状态信息，确定所述CR对象的状态。

6.根据权利要求3或5所述的方法，其特征在于，所述根据所述子资源的状态信息，确定所述CR对象的状态，包括：

根据所述子资源的状态信息，判断所述子资源中是否存在未达到终态的子资源；

若判断结果为所述子资源中存在未达到终态的子资源，确定所述CR对象的状态为未达到终态。

7.根据权利要求1所述的方法，其特征在于，所述CR对象的属性信息包括：所述CR对象的硬件资源需求信息和调度属性信息；所述方法还包括：

根据所述CR对象的调度属性信息，在计算集群中为所述CR对象进行资源调度，以确定与所述调度属性信息适配的候选工作节点；

根据所述CR对象的硬件资源需求信息，从所述候选工作节点中确定满足所述硬件资源需求信息的目标工作节点；

在所述目标工作节点部署所述CR对象的容器组。

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

从所述资源定义中，获取所述CRD的控制面管理策略；

按照所述控制面管理策略，对所述CRD的控制面资源进行管理。

9.根据权利要求8所述的方法，其特征在于，所述控制面管理策略为等待CR对象删除后下线；

所述按照所述控制面管理策略，对所述CRD的控制面资源进行管理，包括：

响应于所述CRD的下线事件，监测所述CRD对应的CR对象是否全部下线；

在监测到所述CRD对应的CR对象全部下线的情况下，删除所述控制面资源。

10.一种计算设备，其特征在于，包括：存储器和处理器；其中，所述存储器，用于存储计算机程序；

所述处理器耦合至所述存储器，用于执行所述计算机程序以用于执行权利要求1-9任一项所述方法中的步骤。

11.一种存储有计算机指令的计算机可读存储介质，其特征在于，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行权利要求1-9任一项所述方法中的步骤。

Images