资源管理方法、装置和系统

本申请涉及云计算技术领域，特别涉及一种资源管理方法、装置、计算设备和存储介质。

Kubernetes(简称K8s)是部署、扩展和管理容器化应用程序的开源系统，提供了应用部署、规划、更新、维护的机制。Helm Charts是一种包结构，是描述相关的一组Kubernetes资源的文件集合，包含一个或多个可以运行在Kubernetes平台上的服务。

这些服务的运行大多需要依赖于一系列的基础资源，比如数据库、DNS、VIP、物理IP、Volumes等。为了获取相关资源，Helm Charts需要描述清晰，并且能够被Kubernetes认知，以便于为其准备基础资源，并为各个服务创建基础资源。然而，随着互联网络的快速发展，有些服务可能需要引用全局资源或者其它服务的资源，传统的应用部署及管理机制已逐渐难以满足需求。

因此，需要一种改进的资源管理方案，以提升资源管理效率。

本公开的目的是提供一种资源管理方法、装置和系统，以提升资源管理效率。

根据本公开的第一个方面，提供了一种资源管理方法，包括：获取资源描述包，所述资源描述包包括用于资源申请的第一描述信息和用于资源引用的第二描述信息，所述第一描述信息包括所申请的资源的资源变量，所述第二描述信息包括对资源的资源变量进行引用的引用变量；以及基于所述第一描述信息，获取所述第二描述信息中的引用变量的实际值。

可选地，获取所述第二描述信息中的引用变量的实际值的步骤可以包括：基于所述第一描述信息和全局资源描述信息，获取所述第二描述信息中的引用变量的实际值。

可选地，所述获取资源描述包的步骤可以包括：获取一个或多个资源描述包，所述方法还可以包括：确定所述一个或多个资源描述包之间的资源依赖关系，其中，所述资源依赖关系表征所述一个或多个资源描述包之间的资源引用关系。

可选地，可以基于所述一个或多个资源描述包的第二描述信息所包括的引用变量，确定所述一个或多个资源描述包之间的资源依赖关系。

可选地，还可以包括：构建表征所述资源引用关系的关系图，在所述关系图中，包含被引用的资源变量的一个资源描述包，指向引用了所述一个资源描述包中的资源变量的另一个资源描述包。

可选地，所述关系图是有向无环图。

可选地，还包括：基于所述资源依赖关系，依次对所述一个或多个资源描述包进行处理，以便获取所述一个或多个资源描述包的第二描述信息中的引用变量的实际值。

可选地，所述依次对所述一个或多个资源描述包进行处理的步骤包括：在资源描述包的引用变量中存在预定关键词的情况下，将所述资源描述包中的引用变量赋值为其所要引用的资源变量；在资源描述包的引用变量中不存在预定关键词的情况下，将所述资源描述包中的引用变量赋值为全局资源变量，其中，所述预定关键词表示存在对其它资源描述包的引用关系。

可选地，该方法还可以包括：将所述一个或多个资源描述包所声明暴露的资源变量存储在全局资源变量中；以及基于所述第一描述信息和全局资源描述信息，获取所述第二描述信息中的引用变量的实际值。

可选地，所述第二描述信息包括下述的至少一项：针对资源描述包自身申请的资源的资源变量的引用变量；针对其它资源描述包暴露的资源变量的引用变量；针对全局资源变量的引用变量。

可选地，所述第一描述信息还包括所申请的资源的资源属性，所述第二描述信息中的引用变量的实际值包括所述资源属性。或者，所述第一描述信息还包括所申请的资源的资源类型信息。

可选地，该方法还可以包括：维护资源列表，所述资源列表包括所述一个或多个资源描述包的名称、版本信息以及所申请的资源的资源属性信息，其中，所述资源列表用于获取资源和/或依赖分析。

可选地，该方法还可以包括：在终端上部署所述资源描述包的运行环境；获取所述资源描述包所申请的资源；以及基于所述运行环境以及所申请的资源，在所述终端上部署所述资源描述包所对应的服务。

可选地，所述资源描述包是Chart包；并且/或者所述第一描述信息和/或第二描述信息基于yaml文件表征；并且/或者所述方法应用于Kubernetes。

根据本公开的第二个方面，还提供了一种资源管理方法，包括：准备资源描述包，所述资源描述包包括用于资源申请的第一描述信息和用于资源引用的第二描述信息，所述第一描述信息包括所申请的资源的资源变量，所述第二描述信息包括对资源的资源变量进行引用的引用变量；以及将所述资源描述包发送给资源管理设备。

可选地，该方法还可以包括：所述资源申请设备接收所述资源管理设备返回的资源描述包，其中，所述资源管理设备所返回的资源描述包包括的第二描述信息为引用变量的实际值。

根据本公开的第三个方面，还提供了一种资源管理方法。资源申请设备准备资源描述包，并将所述资源描述包发送给资源管理设备，所述资源描述包包括用于资源申请的第一描述信息和用于资源引用的第二描述信息，所述第一描述信息包括所申请的资源的资源变量，所述第二描述信息包括对资源的资源变量进行引用的引用变量。资源管理设备从资源申请设备获取所述资源描述包，基于所述第一描述信息获取所述第二描述信息中的引用变量的实际值，并对资源描述包进行处理使得其中的第二描述信息为引用变量的实际值，将处理后的资源描述包返回给资源申请设备。资源申请设备接收所述资源管理设备返回的资源描述包，并基于所返回的资源描述包获取资源描述包所申请的资源以及/或者部署资源描述包所对应的服务。

根据本公开的第四个方面，还提供了一种服务部署方法。资源管理设备从资源申请设备获取资源描述包，所述资源描述包包括用于资源申请的第一描述信息和用于资源引用的第二描述信息，所述第一描述信息包括所申请的资源的资源变量，所述第二描述信息包括对资源的资源变量进行引用的引用变量。资源管理设备基于所述第一描述信息，获取所述第二描述信息中的引用变量的实际值，并对资源描述包进行处理使得其中的第二描述信息为引用变量的实际值，将处理后的资源描述包返回给资源申请设备。资源申请设备在终端上部署所述资源描述包的运行环境，基于所返回的资源描述包获取所述资源描述包所申请的资源，基于所述运行环境以及所申请的资源，在所述终端上部署所述资源描述包所对应的服务。

根据本公开的第五个方面，还提供了一种资源管理系统，包括：资源申请设备，用于准备资源描述包，并将所述资源描述包发送给资源管理设备，其中，所述资源描述包包括用于资源申请的第一描述信息和用于资源引用的第二描述信息，所述第一描述信息包括所申请的资源的资源变量，所述第二描述信息包括对资源的资源变量进行引用的引用变量；资源管理设备，用于获取所述资源描述包，并基于所述第一描述信息，获取所述第二描述信息中的引用变量的实际值，并向所述资源申请设备返回资源描述包，其中，所返回的所述资源描述包包括的第二描述信息为引用变量的实际值。

可选地，所述资源申请设备可以：在终端上部署所述资源描述包的运行环境；基于所述资源管理设备所返回的资源描述包，获取所述资源描述包所申请的资源；以及基于所述运行环境以及所申请的资源，在所述终端上部署所述资源描述包所对应的服务。

根据本公开的第六个方面，还提供了一种资源管理装置，包括：资源描述包获取装置，用于获取资源描述包，所述资源描述包包括用于资源申请的第一描述信息和用于资源引用的第二描述信息，所述第一描述信息包括所申请的资源的资源变量，所述第二描述信息包括对资源的资源变量进行引用的引用变量；以及处理装置，用于基于所述第一描述信息，获取所述第二描述信息中的引用变量的实际值。

根据本公开的第七个方面，还提供了一种计算设备，包括：处理器；以及存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如上所述的方法。

根据本公开的第八个方面，还提供了一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如上所述的方法。

由此，通过提供一套完整体系的资源管理方案，其定义了资源描述包所涉及的多种资源的描述信息，使得通过静态地对这些描述信息进行分析处理，即可方便地获取所需的资源，静态地解决了资源的申请和/或创建。并且，提供了基于上述资源描述包的资源依赖处理方式，使得在部署资源描述包所对应的服务时，无需等待并查询资源创建过程，即可直接进行部署，极大地加快了产品乃至整个运行环境的部署。

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1示出了根据本公开一个实施例的资源管理系统的示意图。

图2示出了根据本公开一个实施例的资源管理的流程示意图。

图3示出了根据本公开一个实施例的关系图的示意图。

图4示出了根据本公开一个实施例的资源管理方法的流程示意图。

图5示出了根据本公开一个实施例的资源管理装置的结构示意图。

图6示出了根据本公开一个实施例的计算设备的结构示意图。

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

Kubernetes(简称K8s)是部署、扩展和管理容器化应用程序的开源系统，提供了应用部署、规划、更新、维护的机制，其目的是使得部署容器化的应用简单并且高效。

Helm是一种管理Kubernetes应用包的工具，通常使用称为chart的包装格式。Charts是Helm使用的一种包结构，是描述相关的一组Kubernetes资源的文件集合，包含一个或多个可以运行在Kubernetes平台上的服务(或应用)。在本公开实施例中，Charts又可以称为“Helm Charts”。

Charts所代表的服务的运行大多需要依赖于一系列的基础资源，比如数据库、DNS、VIP、物理IP、Volumes等。为了获取相关资源，这些Helm Charts需要描述清晰，并且能够被Kubernetes解析，以便于准备基础资源，并为各个服务创建基础资源。

本公开提供了一套完整体系的资源管理方案，其定义了资源描述包所涉及的多种资源的描述信息，使得通过静态地对这些描述信息进行分析处理，即可方便地获取所需的资源，静态地解决了资源的申请和/或创建。并且，提供了基于上述资源描述包的资源依赖处理方式，使得在部署资源描述包所对应的服务时，无需等待并查询资源创建过程，即可直接进行部署，极大地加快了产品乃至整个运行环境的部署。

上述资源管理方案可以适用于自动部署、扩展和管理容器化应用程序的开源系统，例如Kubernetes。

在本公开如下示例中，将以Kubernetes作为示例，来对本公开的资源管理方案进行说明。应当理解的是，本公开的资源管理方案的应用场景不限于此。

图1示出了根据本公开一个实施例的资源管理系统的示意图。

如图1所示，本公开的资源管理系统可以包括资源申请设备110和资源管理设备120。资源申请设备110申请资源可以用于在终端130上进行相应服务部署。

资源申请设备110可以准备资源描述包，并能够将所准备的资源描述包发送给资源管理设备120。

该资源描述包可以为Chart包，每个Chart包可以对应于一个或多个服务，例如wordpress、数据库、DNS或VIP、信息处理服务、数据处理服务等。

资源申请设备110所准备的资源描述包可以包括描述相关资源的文件集合，例如资源申请文件、资源引用文件等。其中，资源申请文件可以包括用于资源申请的第一描述信息，第一描述信息可以包括所申请的资源的资源变量。资源引用文件可以包括用于资源引用的第二描述信息，第二描述信息可以包括对资源的资源变量进行引用的引用变量。

资源管理设备120，能够接收资源申请设备110所发送的资源描述包，并能够对该资源描述包进行分析处理，使得该资源描述包能够被用于产品部署。

在本公开实施例中，上述分析处理，例如可以包括对资源描述包之间的资源依赖分析、基础资源获取、资源变量渲染等相关处理。这些处理可以理解为静态处理，即仅针对资源描述包所包含的描述信息和/或全局资源描述信息实现上述处理。

经过处理后的资源描述包，可以被发送给资源申请设备，使得该资源申请设备可以在相关终端上部署和运行相应的服务。这里，上述终端可以是任何能够运行上述资源描述包所代表的服务的终端设备，包括但不限于计算机、智能电话、平板电脑等。

具体地，资源申请设备可以先在终端上部署资源描述包的运行环境，然后可以基于所述资源管理设备所返回的资源描述包，获取所述资源描述包所申请的资源，之后，即可基于所述运行环境以及所申请的资源，在所述终端上部署所述资源描述包所对应的服务。

在一个实施例中，上述资源管理设备120可以是云平台。该云平台可以是面向企业级用户的全栈云平台，其可以基于云产品的分布式架构，针对企业级市场的使用特点，为用户提供开放、统一、可信的企业级云平台。并且，使得用户可以在任何地方与环境进行开发和部署，自由延伸云平台的线上与本地化部署。

图2示出了根据本公开一个实施例的资源管理的流程示意图。

参见图2，该资源管理的整个流程可以包括准备资源描述包阶段21、资源描述包处理阶段22以及基于资源描述包的服务部署阶段23。

另外，在一个实施例中，服务部署阶段可以包括上述准备资源描述包阶段、资源描述包处理阶段和服务部署阶段。本公开的资源管理方案实现方式较为灵活，本公开对其具体实现中的细节不做限制。应当理解的是，本公开实施例至少为了对本公开的实现流程加以说明，而非限定。

下面将以图2所示的流程图为例，来对图1所示的资源管理系统所实现的整个资源管理方案进行详细说明。应当理解的是，下文述及的内容仅是对本公开的资源描述方案的举例说明而非限定，本工公开的资源管理方案还可以通过其它任何适合的方式或方法实现，本公开对此不做限制。

准备资源描述包阶段

结合图1和图2，首先，在步骤S210，准备资源描述包。

这里，可以由资源申请设备110基于相关规范准备资源描述包。也可以由资源申请设备向资源管理设备提供资源描述文件(包括针对其需求的资源类型、定义资源变量的引用等信息)，而由资源管理设备打包得到相应的资源描述包，本公开对于资源描述包的来源不做限制。

资源申请设备110可以是任意的资源申请设备，例如可以是服务开发者。

在本公开实施例中，可以由一个资源申请设备准备一个或多个资源描述包。或者，也可以由多个资源申请设备分别准备多个资源描述包，还可以由资源管理设备基于资源申请设备提供的资源描述文件，分别打包得到一个或多个资源描述包，本公开对此不做限制。

在一个实施例中，资源描述包可以为Charts包。Chart可以被组织为一个目录内的文件集合，目录名称即为Chart的名称。

所准备的一个或多个资源描述包例如可以是图2所示的Chart A、Chart B、ChartC、……、Chart O、Chart P等。每个资源描述包可以具有相同的实现方式，例如固定的语法实现。

1)Charts结构

以WordPress应用程序为例，描述WordPress的Chart可以被存储在wordpress/目录中。在这个目录里面，Charts结构描述可以如下所示：

其中，Chart.yaml为YAML格式，用于描述chart基础信息，包括chart名。

values.yaml用于存储templates目录中模板文件中用到的变量。

resource.yaml为YAML格式，用于描述对各种资源的需求。

values-adapter.yaml为values.yaml里变量的一个子集，用于引用resource.yaml中的资源变量(例如DNS域名、数据库用户名等)。

Templates用于存储Chart模板文件，主要可以包括各个对Kubernetes资源(resource)的描述文件。其中，模板文件例如可以是Go模板。

NOTES.txt为介绍文档，用于向部署该Chart的终端介绍Chart部署后的一些信息，例如介绍如何使用这个chart、列出缺省的设置等。

2)资源申请

在上述Charts结构中，对各种资源的需求即资源申请，可以定义在resource.yaml里。

在本公开实施例中，该resource.yaml至少可以包括两个部分：所需资源(resource Required)部分和服务注册(service Registration)部分。

所需资源(resource Required)部分可以包括声明所需要申请的资源的一些信息，例如可以包括资源类型、资源属性以及资源属性的值等。

服务注册(service Registration)部分可以包括暴露的资源变量以及暴露的资源变量的值等。基于一个Chart是service Registration部分，其它Chart可以对该一个Chart所暴露的资源变量对应的资源进行引用。其中，Chart对外暴露的资源变量也可以称为一种全局资源变量。

例如，以数据库资源为例，其Chart的resource.yaml可以包括下述内容：

在上述resourceRequired部分，“db”即资源类型-数据库；“name”、“user”、“password”即为资源属性，分别为数据库名称、数据库用户名、数据库密码；“mq”、“msg”、“Te83_yr3&Y”即为资源属性的值，分别对应于数据库名称、数据库用户名、数据库密码。

在上述serviceRegistration部分，“db_name”、“db_user”、“db_password”即为暴露的资源变量；“${db.mq.name}”、“${db.mq.user}”、“${db.mq.password}”即为暴露的资源变量的值。

以DNS/VIP资源为例，其Chart的resource.yaml可以包括下述内容：

与上述以数据库资源作为示例的Chart的resource.yaml相似，在以DNS/VIP资源为例的Chart的resource.yaml中，resourceRequired部分描述了对于DNS资源和/或VIP资源的需求的一些信息，而serviceRegistration描述了对外暴露的资源变量以及暴露的资源变量的值，使得外部(例如其它Chart)可以通过proxy_endpoint来访问名为wordpress的DNS的域名。在此不再赘述。

在一个实施例中，resource.yaml中例如还可以包括一些全局变量，这些全局变量例如可以用于定义Docker Registry地址、平台根域名和网络类型等的需求描述。

在这一部分，全局变量的定义方法例如可以为${global:RESOURCE_NAME}。例如，以${global:dockerRegistry}来描述Docker Registry地址。在此不再赘述。

3)资源引用

在上述Charts结构中，对各种资源的引用即资源引用，可以在values-adapter.yaml文件里描述。其中，该values-adapter.yaml文件可以用于确定该Chart与其所申请的资源或者其它Chart所申请的资源或者是全局资源之间的资源依赖关系。

在本公开实施例中，values-adapter.yaml里述及的资源引用可以包括多个方面的资源引用，例如，Chart对自身申请的资源变量的引用、Chart对其它Chart暴露的资源变量的引用、或者Chart对全局资源变量的引用等。

在一个实施例中，例如可以以引用变量的形式描述上述资源引用。

例如，可以以下述引用变量，来描述Chart对自身申请的资源变量的引用：

“${RESOURCE_TYPE.RESOURCE_NAME.RESOURCE_ATTRIBUTE}”

其中，“RESOURCE_TYPE”表示引用的资源类型，“RESOURCE_NAME”表示引用的资源名称，“RESOURCE_ATTRIBUTE”表示引用的资源属性。

或者，例如可以以下述引用变量，来描述Chart对其它Chart暴露的资源变量的引用：

“${chart:CHART_NAME:SERVICEREGISTRATION_VAR}”

其中，“CHART_NAME”表示所引用的Chart的Chart名称，“SERVICEREGISTRATION_VAR”表示其它Chart对外暴露的资源变量的名称。

“${chart:}”可以作为表示存在对其它资源描述包的引用关系，当在一个Chart中查到该预定关键词的情况下，即可得出，该一个Chart引用了其它Chart暴露的资源变量涉及的资源。

基于上述通过固定的语法实现的信息，在编写时能够显示指定资源类型、名称和属性，不同服务之间进行资源引用时，无需明确资源属性的Binding的Secret名称及其类型等信息。

至此，已经结合图1和图2详细描述了本公开的资源描述包。

与Kubernetes社区对Helm Charts的结构描述相比，本公开上述的资源描述包即Charts包，仅在与values.yaml在同级目录下增加了resource.yaml和values-adapter.yaml这两个yaml文件，其它结构相同或相似。

本公开的资源描述包，可以通过在resource.yaml的resourceRequired里定义各种资源类型，并在values-adapter.yaml里描述资源引用。这种定义方式并不会限定同一个资源的具体实现方式，并可以屏蔽具体资源实体实现细节。例如，对于数据库资源，可以定义其资源类型为db，而无需关心其底层是Mysql实现还是MariaDB实现还是其它实现，都可以适配，并且也无需更改Chart基线。

并且，本公开的Charts包结构简单，遵循Kubernetes社区规范，并且能够兼容Kubernetes社区Charts结构。

并且，基于本公开的Charts结构，在处理完成并进行服务部署时，通过Helm Chart安装命令(helm install CHART-f values-adapter.yaml)，values-adapter.yaml中变量可以生效，完成部署。

资源描述包处理阶段

资源申请设备110在完成资源描述包的准备后，可以将所准备的资源描述包提供(例如发送)给资源管理设备120。如前所述，也可以由资源管理设备基于资源申请设备提供的资源描述文件准备上述资源描述包并进行相应的处理。

资源管理设备120能够获取资源申请设备110所发送的资源描述包，并在步骤S220，对该资源描述包进行分析处理，使得该资源描述包能够被用于产品部署。

在本公开实施例中，上述分析处理，例如可以包括对资源描述包之间的资源依赖分析、基础资源获取、资源变量渲染等相关处理。其中，这些处理为静态处理，即仅针对资源描述包所包含的描述信息和全局资源描述信息进行静态分析而实现上述处理。

1)资源依赖分析

参见图2，在步骤S220，可以对多个资源描述包进行依赖分析处理。

一方面，可以对各个资源描述包的values-adapter.yaml文件进行分析，确定两个或更多个资源描述包之间的资源依赖关系。资源依赖关系可以表征一个或多个资源描述包之间的资源引用关系。

另一方面，可以对各个资源描述包进行全局分析，将对各个资源描述包所包含的信息进行汇总并以列表的形式实现。

在上述分析处理过程中，可以通过跨Chart之间的变量引用进行分析。依赖分析处理后可以得到表征Chart之间对资源依赖的关系图以及Chart列表。

在该关系图中，可以包含被引用的资源变量的一个资源描述包，指向引用了所述一个资源描述包中的资源变量的另一个资源描述包。

在该Chart列表中，例如可以以Chart名称作为key，汇总各个Chart所包含的信息。

基于该Chart资源依赖关系图和Chart列表，便于在之后的处理中，实现对各个Chart所申请的基础资源的获取或者实现各个Chart之间的依赖分析，将在下文详述，在此不再赘述。

应当理解的是，在上述分析处理过程中，可以先执行获得Chart列表的处理再执行获得关系图的处理，也可以先执行获得关系图的处理再执行获得Chart列表的处理，还可以同时执行获得关系图和获得Chart列表的处理，本公开对此不做限制。

关系图

上述关系图可以表征Chart之间的资源依赖关系。在对各个资源描述包的values-adapter.yaml文件进行分析时，可以构建表征资源引用关系的关系图。并且，在该关系图中，可以包含被引用的资源变量的一个资源描述包，指向引用了所述一个资源描述包中的资源变量的另一个资源描述包。

在一个实施例中，上述关系图可以是如图3所示的有向无环图。

参见图3所示，ChartA指向ChartB、ChartB指向ChartC和ChartO、ChartC和ChartO指向ChartP，即表明在该有向无环图中，ChartB引用ChartA所涉及的资源、ChartC和ChartO引用ChartB所涉及的资源、ChartP引用ChartC和ChartO所涉及的资源。

应当理解的是，图3仅以多个Chart例如ChartA、ChartB、ChartC、ChartO、ChartP作为示例，示意性示出了多个Chart之间的资源依赖关系，而非对其资源依赖关系的任何限定。在实际应用中，结合多个Chart的实际内容获得相应的有向无环图。在Chart数量较多或者Chart之间的引用关系更加复杂的情况下，本公开的表征资源引用关系的有向无环图也更为复杂，在此不再赘述。

Chart列表

上述Chart列表可以是对多个资源描述包所包含的信息的汇总，包括但不限于在上文对资源描述包的结构进行描述时所涉及的多个文件所包含的信息，例如，资源描述包的自身信息(例如Chart名称、Chart版本等)、申请的资源信息、声明要暴露的资源变量、表征资源应用的引用变量等。

在一个实施例中，Chart列表可以包括多个Chart对象，每个Chart对象对应于一个Chart包(即资源描述包)。在其它实施例中，也可以对应于每个资源描述包即得到一个Chart列表，本公开对其具体实现形式不做限制。

以一个Chart列表汇总对应于多个资源描述包所包含的信息为例，Chart列表结构例如可以如下所示：

其中，该Chart列表中包括多个Chart对象，即上述“0＝{Chart}<>”、“1＝{Chart}<>”、“1＝{Chart}<>”……。

每个Chart对象可以包括以下数据结构：

其中，“name”对应于Chart名称，“version”对应于Chart版本，“values_adapter”对应于Chart的values_adapter.yaml文件中所办卡的内容，“resource_variables”对应于为一个Chart申请的所有资源的属性信息，“service_registration_variables”对应于该Chart声明暴露的资源变量。

基于上述Chart列表，在之后的分析处理中，可以便于实现对各个资源描述包所申请的资源的获取，以及实现对各个资源描述包的依赖分析，而无需再基于各个Chart分别进行处理。

换言之，本公开实施例中，将基于“.yaml”文件的资源描述包处理为Chart对象的列表，在之后的分析处理甚至是产品部署过程中，无需等待并查询资源创建过程，即可方便地获得相应的基础资源或者完成产品部署。

2)基础资源获取

这里，“获取”可以认为是静态获取，即通过对这些Chart中的描述信息进行分析处理，得到该如何获取这些Chart所申请的资源的描述文件，例如资源申请变量信息列表和基础资源申请信息集，以方便后续服务部署阶段23获取所需的资源，静态地解决了资源的申请和/或创建。

资源申请变量信息列表

基于上述Chart列表，可以处理得到资源申请变量信息列表。该资源申请变量信息列表可以包括各个Chart所申请的所有资源变量及其相应的实际值。

其中，可以从上述Chart列表中分别获得各个Chart对象的“resource_variables”，并获得该“resource_variables”所涉及的资源对应的实际值，以得到上述资源申请变量信息列表。

该资源申请变量信息列表的结构例如可以如下所示：

chart-a

-dns

-vip

chart-b

-dns

-vip

chart-c

-dns

-vip

……

其中，以数据库资源为例，例如可以通过以下方式实现对Chart所申请的资源的属性信息的获取，从而得到上述基础资源申请信息集：

其中，上述内容表示，从Chart的“resource_required”中获取Chart申请的资源；判断该Chart是否申请了数据库资源；从Chart申请的资源中获取所有数据库类型的资源；赋值，即将所获取的数据库资源的实际值填充到“resource_variables”中，以获得资源申请变量信息列表。

所得到的资源申请变量信息列表可以作为输入，用于随后的资源变量渲染阶段。

基础资源申请信息集

在上述资源申请变量信息列表的基础上，可以获得对应于多个资源描述包(即Chart包)的基础资源申请信息集。

其中，该基础资源申请信息集例如可以按照资源分类，汇总多个资源描述包所期望申请的资源的资源信息。

该基础资源申请信息集的结构例如可以如下所示：

db:

-name:

user:

password:

-name:

user:

password:

dns:

vip:

……

基于上述基础资源申请信息集，在后续服务部署阶段23可以申请并获得多个资源描述包所申请的资源。

3)资源变量渲染

随后，基于上述有向无环图、资源申请变量信息列表以及全局资源描述信息，在步骤S230，可以对资源描述包的values-adapter.yaml文件中的变量进行渲染，以得到渲染后的values-adapter.yaml文件。基于包括该values-adapter.yaml文件的Chart包，可以部署Chart所代表的服务，完成产品部署和运行。

其中，上述全局资源描述信息可以包括全局资源变量及其对应的实际值，还可以包括在对各个Chart包进行处理的过程中存储以作为全局资源变量的Chart对外暴露的变量及其对应的实际值。

具体地，结合图3所示的有向无环图，可以先处理Chart A，之后处理Chart B，之后处理Chart C和Chart O，最后处理ChartP。

其中，可以首先处理Chart A的“service_registration_variables”部分，该部分表示的是Chart A对外暴露的资源变量。

即，在Chart A存在需要对外暴露的资源变量的情况下，针对Chart A所声明暴露的每一个变量进行预处理，使得Chart A的对外暴露的service_registration_variables规范化。

其中，在Chart A的对外暴露的资源变量中包含预定关键词的情况下，例如表示存在对其它资源描述包的引用关系的关键词"${chart"，将Chart A对外暴露的资源变量赋值为chart之间需要暴露的变量。在Chart A的对外暴露的资源变量中不包含预定关键词的情况下，将Chart A对外暴露的资源变量赋值为全局资源变量。

并且，在这个过程中，还可以以Chart名称作为key，将Chart A对外暴露的所有变量存储在全局资源变量(universal_variables)中，这样在后续对Chart B进行处理时，即可获取Chart B对Chart A资源的引用。

同时，基于资源申请变量(resource_variables)和全局资源变量(universal_variables)将values-adapter.yaml文件中对资源的引用变量，渲染成相应的实际值。

之后，基于与上述针对Chart A相同的处理方式，处理Chart B、ChartC和O、ChartP，完成对所有Chart的变量渲染。

在完成上述处理后，可以分别打包上述多个Chart，其中，各个Chart中包括的为渲染后的values-adapter.yaml文件。这样，经过对资源描述包(chart包)进行处理，使得其中的引用变量渲染为引用变量的实际值。然后，可以将处理后的资源描述包返回给资源申请设备110。在此基础上，即可部署各个Chart所代表的服务。

在此，由于之前的处理，使得基础依赖资源已经就绪，部署时，通过Helm Chart安装命令(helm install CHART-f values-adapter.yaml)，values-adapter.yaml中变量可以生效，完成部署和运行。

服务部署阶段

在本阶段，可以在已经部署了资源描述包的运行环境(例如Kubernetes平台)的终端上部署各Chart所代表的服务。

其中，在如前处理的基础上，在步骤S241，可以通过基础资源申请信息集，提交资源申请，以便为相关Chart创建其所申请的资源，并获取资源描述包所申请的资源。

之后，在步骤S242，可以基于运行环境(运行态)以及所申请的资源，即在所述终端上部署所述资源描述包(即Chart)所对应的服务，完成部署和运行。

至此，已经结合附图1-3详细说明了本公开的资源管理方案。

本公开的资源管理方案提供了一套完整体系的解决资源申请、引用的方案，能够覆盖Kubernetes产品依赖的DNS、VIP、数据库、物理IP、磁盘等多种资源的依赖描述，同时提供了Kubernetes产品对这些资源的引用方案，并且也提供了一个Kubernetes产品对其他Kubernetes产品暴露的资源变量的引用方案。

本公开的资源管理方案可以实现跨应用的资源引用和暴露，不局限于单个应用管理，更方便与平台级资源配置。应用方(例如资源申请设备)只需要申明需要的资源类型、定义资源变量的引用，平台方(例如资源管理方)进行统一的依赖分析、变量渲染和资源创建，无需针对每一个应用单独处理资源的申明、创建和引用。

本公开的资源管理方案通过在resource.yaml的resourceRequired定义各种资源类型，并不会限定同一个资源的具体实现方式，屏蔽了具体资源实体实现细节，无需关心资源本身的具体实现，也无需更改Chart基线。并且，本公开具有统一的资源变量渲染机制，能够对所有应用的所有的资源进行统一处理，而无需对每一种资源做开发和适配。

并且，本公开的资源管理方案对资源依赖的处理方式，静态地解决了资源的申请和创建，在进行产品部署时，不用等待并查询资源创建过程，可以直接进行部署，加快了部署Kubernetes产品的速度，甚至加快了整个Kubernetes平台的部署过程。

如前所述的资源管理方案还可以实现为一种资源管理方法，该资源管理方法可以由一种资源管理装置实现。图4示出了根据本公开一个实施例的资源管理方法的流程示意图。图5示出了根据本公开一个实施例的资源管理装置500的结构示意图。

如图4所示，在步骤S410，例如可由图5所示的资源描述包获取装置510，获取资源描述包，所述资源描述包包括用于资源申请的第一描述信息和用于资源引用的第二描述信息，所述第一描述信息包括所申请的资源的资源变量，所述第二描述信息包括对资源的资源变量进行引用的引用变量。

在步骤S420，例如可由图5所示的处理装置520，基于所述第一描述信息，获取所述第二描述信息中的引用变量的实际值。

在本公开实施例中，获取所述第二描述信息中的引用变量的实际值的步骤可以包括：基于所述第一描述信息和全局资源描述信息，获取所述第二描述信息中的引用变量的实际值。

在本公开实施例中，获取资源描述包的步骤可以包括：获取一个或多个资源描述包，所述资源管理方法还可以包括：确定所述一个或多个资源描述包之间的资源依赖关系，其中，所述资源依赖关系表征所述一个或多个资源描述包之间的资源引用关系。

在本公开实施例中，可以基于所述一个或多个资源描述包的第二描述信息所包括的引用变量，确定所述一个或多个资源描述包之间的资源依赖关系。

在本公开实施例中，还可以构建表征所述资源引用关系的关系图，在所述关系图中，包含被引用的资源变量的一个资源描述包，指向引用了所述一个资源描述包中的资源变量的另一个资源描述包。优选地，该关系图为有向无环图。

在本公开实施例中，还可以基于所述资源依赖关系，依次对所述一个或多个资源描述包进行处理，以便获取所述一个或多个资源描述包的第二描述信息中的引用变量的实际值。

在本公开实施例中，所述依次对所述一个或多个资源描述包进行处理的步骤包括：在资源描述包的引用变量中存在预定关键词的情况下，将所述资源描述包中的引用变量赋值为其所要引用的资源变量；在资源描述包的引用变量中不存在预定关键词的情况下，将所述资源描述包中的引用变量赋值为全局资源变量，其中，所述预定关键词表示存在对其它资源描述包的引用关系。

在本公开实施例中，还可以将所述一个或多个资源描述包所声明暴露的资源变量存储在全局资源变量中，然后可以基于所述第一描述信息和全局资源描述信息，获取所述第二描述信息中的引用变量的实际值。

在本公开实施例中，所述第二描述信息包括下述的至少一项：针对资源描述包自身申请的资源的资源变量的引用变量；针对其它资源描述包暴露的资源变量的引用变量；针对全局资源变量的引用变量。

在本公开实施例中，第一描述信息还可以包括所申请的资源的资源属性，第二描述信息中的引用变量的实际值包括所述资源属性。或者，第一描述信息还可以包括所申请的资源的资源类型信息。

在本公开实施例中，还可以维护资源列表，所述资源列表包括所述一个或多个资源描述包的名称、版本信息以及所申请的资源的资源属性信息，其中，所述资源列表可以用于获取资源和/或依赖分析。

在本公开实施例中，还可以在终端上部署所述资源描述包的运行环境；获取所述资源描述包所申请的资源；以及基于所述运行环境以及所申请的资源，在所述终端上部署所述资源描述包所对应的服务。

在本公开实施例中，资源描述包可以是Chart包。第一描述信息和/或第二描述信息可以基于yaml文件表征。本公开的资源管理方法可以应用于Kubernetes。

在另一个实施例中，还可以实现为由资源申请设备实现的资源管理方法。

具体地，资源申请设备可以准备资源描述包，所述资源描述包包括用于资源申请的第一描述信息和用于资源引用的第二描述信息，所述第一描述信息包括所申请的资源的资源变量，所述第二描述信息包括对资源的资源变量进行引用的引用变量，并将所述资源描述包发送给资源管理设备。

之后，资源申请设备能够接收所述资源管理设备返回的资源描述包，其中，所述资源管理设备所返回的资源描述包包括的第二描述信息为引用变量的实际值。基于所接收到的资源管理设备返回的资源描述包，可以进行针对资源描述包对应的相关服务的部署。

例如，可以在终端上部署所述资源描述包的运行环境；基于所述资源管理设备所返回的资源描述包，获取所述资源描述包所申请的资源；以及基于所述运行环境以及所申请的资源，在所述终端上部署所述资源描述包所对应的服务。

图6示出了根据本公开一个实施例的计算设备的结构示意图。

参见图6，计算设备600包括存储器610和处理器620。

处理器620可以是一个多核的处理器，也可以包含多个处理器。在一些实施例中，处理器620可以包含一个通用的主处理器以及一个或多个特殊的协处理器，例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中，处理器620可以使用定制的电路实现，例如特定用途集成电路(ASIC，Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA，Field Programmable Gate Arrays)。

存储器610可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器620或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器610可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器610可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器610上存储有可处理代码，当可处理代码被处理器620处理时，可以使处理器620执行上文述及的资源管理方法。

上文中已经参考附图详细描述了根据本公开的资源管理方法、装置和系统。

此外，根据本公开的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本公开的上述方法中限定的上述各步骤的计算机程序代码指令。

或者，本公开还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时，使所述处理器执行根据本公开的上述方法的各个步骤。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

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

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