CN116610419A - 自定义资源的管理方法及装置、非易失性存储介质 - Google Patents

Abstract

本申请公开了一种自定义资源的管理方法及装置、非易失性存储介质。其中，该方法包括：通过Kubernetes集群的接口组件，接收多个不同的自定义资源；确定与目标自定义资源的资源类型对应的目标控制器，并利用目标控制器监听目标自定义资源的实际状态，其中，目标自定义资源为多个不同的自定义资源中任意一个自定义资源；在目标自定义资源的实际状态与目标自定义资源的期望状态不匹配的情况下，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态。本申请解决了由于无法对自定义资源的发布与运行进行一体化管理造成的管理效率低下的技术问题。

Description

自定义资源的管理方法及装置、非易失性存储介质

技术领域

本申请涉及计算机应用技术领域，具体而言，涉及一种自定义资源的管理方法及装置、非易失性存储介质。

背景技术

近年，应用***架构从单体架构到微服务架构的演进以及云原生技术的快速发展，微服务在分布式***越来越普及。微服务应用具备可扩展性、敏捷性和容错性的天然优势，也具有独立性、隔离性、服务独立维护和分工明确等鲜明特点，这些优势和特点让微服务架构成为目前分布式软件***中主流的解决方案。

微服务的优势和特点是把双刃剑，在拥有架构优势的同时也造成微服务软件***部署运维的复杂性。容器技术对微服务应用分发方式的革新，并没有能够让微服务***本身的定义与描述发生本质变化，即使基于Kubernetes形成的微服务应用管理体验，也没有让业务研发侧与运维侧的工作变得更简单。在微服务软件***中，自定义资源的发布与运行仍存在不统一的情况。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种自定义资源的管理方法及装置、非易失性存储介质，以至少解决由于无法对自定义资源的发布与运行进行一体化管理造成的管理效率低下的技术问题。

根据本申请实施例的一个方面，提供了一种自定义资源的管理方法，包括：通过Kubernetes集群的接口组件，接收多个不同的自定义资源；确定与目标自定义资源的资源类型对应的目标控制器，并利用目标控制器监听目标自定义资源的实际状态，其中，目标自定义资源为多个不同的自定义资源中任意一个自定义资源；在目标自定义资源的实际状态与目标自定义资源的期望状态不匹配的情况下，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态。

可选地，通过Kubernetes集群的接口组件，接收多个不同的自定义资源，包括：通过接口组件，接收第一自定义资源，其中，第一自定义资源至少包括：第一信息，第一信息至少包括：构建自定义资源所需的代码仓库和制品镜像仓库的鉴权信息；通过接口组件，接收第二自定义资源，其中，第二自定义资源至少包括：自定义资源发布时的制品镜像构建需求；通过接口组件，接收第三自定义资源，其中，第三自定义资源至少包括：自定义资源在上传至Kubernetes集群的过程中所运行的第一预设模板。

可选地，通过Kubernetes集群的接口组件，接收多个不同的自定义资源，包括：通过接口组件，接收第四自定义资源，其中，第四自定义资源至少包括：自定义资源运行过程中所引用的组件；通过接口组件，接收第五自定义资源，其中，第五自定义资源至少包括：自定义资源在Kubernetes集群发布过程中输出的目标声明；通过接口组件，接收第六自定义资源，其中，第六自定义资源至少包括：自定义资源在Kubernetes集群发布过程中所需的工程服务。

可选地，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态，包括：利用目标控制器对目标自定义资源运行时的目标数据进行采集；获取并分析目标自定义资源在预设时长内的日志文件，得到第一分析结果；根据采集到的目标数据和第一分析结果，确定目标自定义资源在运行过程中可能出现的全部故障；对目标自定义资源在运行过程中可能出现的全部故障进行分析，确定可能出现的全部故障中每个可能出现的故障的原因和位置；根据每个可能出现的故障的原因和位置，确定第二分析结果；根据第二分析结果，执行目标操作或目标脚本，直至目标自定义资源达到期望状态。

可选地，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态，包括：在第一预设时长内，利用目标控制器每隔预设时间间隔对目标自定义资源的负载参数进行采集，其中，负载参数至少包括：中央处理器使用率、内存使用率和网络带宽；对采集到负载参数和目标自定义资源的历史负载参数进行分析，确定第三分析结果，其中，第三分析结果至少包括：目标自定义资源在第二预设时长后的负载参数；根据第三分析结果，调整当前目标自定义资源的负载参数，直至目标自定义资源达到期望状态。

可选地，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态，包括：根据获取到的仓库链资源信息，获取目标标签对应的目标代码，其中，目标标签用于表征对目标控制器进行更新，仓库链资源信息至少包括：构建目标自定义资源所需的代码仓库和制品镜像仓库的鉴权信息；根据目标代码，执行Kubernetes集群中目标控制器对象的镜像制品；在执行镜像制品之后，通过监听服务持续监听目标控制器对象的工作负载，在工作负载不满足预设条件的情况下，在第三预设时长内调整目标控制器对象的工作负载，直至目标自定义资源达到期望状态。

可选地，通过Kubernetes集群的接口组件，接收多个不同的自定义资源，包括：通过Kubernetes集群的接口组件，以声明式的资源方式，接收多个不同的自定义资源。

根据本申请实施例的再一方面，还提供了一种自定义资源的管理装置，包括：输入模块，用于通过Kubernetes集群的接口组件，接收多个不同的自定义资源；监听模块，用于确定与目标自定义资源的资源类型对应的目标控制器，并利用目标控制器监听目标自定义资源的实际状态，其中，目标自定义资源为多个不同的自定义资源中任意一个自定义资源；执行模块，用于在目标自定义资源的实际状态与目标自定义资源的期望状态不匹配的情况下，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态。

根据本申请实施例的再一方面，还提供了一种非易失性存储介质，存储介质包括存储的程序，其中，程序运行时控制存储介质所在的设备执行以上的自定义资源的管理方法。

根据本申请实施例的再一方面，还提供了一种电子设备，包括：存储器和处理器，处理器用于运行存储在存储器中的程序，其中，程序运行时执行以上的自定义资源的管理方法。

在本申请实施例中，采用通过Kubernetes集群的接口组件，接收多个不同的自定义资源；确定与目标自定义资源的资源类型对应的目标控制器，并利用目标控制器监听目标自定义资源的实际状态，其中，目标自定义资源为多个不同的自定义资源中任意一个自定义资源；在目标自定义资源的实际状态与目标自定义资源的期望状态不匹配的情况下，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态的方式，通过利用目标控制器监听目标自定义资源的实际状态，在目标自定义资源的实际状态与目标自定义资源的期望状态不匹配的情况下，利用目标控制器对目标自定义资源进行处理，达到了对自定义资源的发布与运行进行一体化管理的目的，从而实现了提升管理效率的技术效果，进而解决了由于无法对自定义资源的发布与运行进行一体化管理造成的管理效率低下的技术问题。

附图说明

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

图1是根据本申请实施例的一种自定义资源的管理方法的流程图；

图2是根据本申请实施例的一种自定义资源的管理方法的工作流时序图；

图3是根据本申请实施例的一种自定义资源的管理装置的结构图；

图4是根据本申请实施例的一种自定义资源的管理方法的计算机终端(或电子设备)的硬件结构框图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本申请实施例，提供了一种自定义资源的管理方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本申请实施例的一种自定义资源的管理方法的流程图，如图1所示，该方法包括如下步骤：

步骤S102，通过Kubernetes集群的接口组件，接收多个不同的自定义资源。

根据本申请的一个可选的实施例，Kubernetes集群的接口组件例如的应用程序接口(Application Programming Interface，API)服务器，Kubernetes集群的API服务器是一个核心组件，是控制平面的中心点。API服务器负责处理整个集群的请求和响应，以及管理所有资源对象。在Kubernetes***中，所有基于REST API的操作都通过API服务器进行。由于API服务器的重要性，其被设计为高度可扩展和可配置，并具有许多安全特性。还支持插件机制来实现自定义功能和扩展。对于大规模部署，一般使用多个API服务器节点来提高性能和容错性。另外，在网络拓扑结构上将这些节点分散到不同区域也可以提供更好的健壮性。需要注意的是，在搭建完整Kubernetes集群之前，需先部署正确配置了API服务器组件的etcd存储服务。

步骤S104，确定与目标自定义资源的资源类型对应的目标控制器，并利用目标控制器监听目标自定义资源的实际状态，其中，目标自定义资源为多个不同的自定义资源中任意一个自定义资源。

根据本申请的另一个可选的实施例，Kubernetes中的控制器用于管理和维护应用程序或服务的状态。控制器监视集群中对象的状态，并尝试将实际状态与期望状态进行匹配。如果存在差异，控制器会采取相应的操作来使实际状态达到期望状态。例如：

1.ReplicaSet控制器：确保Pod的副本数与指定数量一致。

2.Deployment控制器：管理应用程序部署，可以自动升级、回滚等。

3.StatefulSet控制器：提供有序、唯一命名和持久化存储的Pod集合。

4.DaemonSet控制器：在每个节点上运行一个Pod实例，通常用于运行守护进程或日志收集等任务。

5.Job和CronJob控制器：管理批处理作业和计划任务。

通过使用这些控制器，Kubernetes可以自动处理大量复杂性和冗余工作，并确保应用程序或服务始终处于所需的健康状态。

步骤S106，在目标自定义资源的实际状态与目标自定义资源的期望状态不匹配的情况下，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态。

将自定义资源(Custom Resource Definition，CRD)的实际状态调整至期望状态，举例而言，可以通过以下步骤实现：首先，编写Kubernetes控制器，用于监视和管理CRD资源对象的创建、更新和删除事件。

其次，在控制器中编写逻辑代码，根据期望状态和当前实际状态之间的差异，采取相应的操作来使它们一致。例如：如果某个字段在期望状态中被设置为True，但是在当前实际状态中为False，则需要对该字段进行更新操作；如果某个子资源在期望状态中存在但是在当前实际状态中不存在，则需要创建该子资源；如果某个子资源在期望状态中不存在但是在当前实际状态中存在，则需要删除该子资源。

再次，使用Kubernetes API客户端库与Kubernetes API服务器通信，并提交修改后的CRD对象到API服务器上。API服务器会根据新提交的对象来更新集群内部存储的CRD实例。

最后，控制器会反复执行以上过程，直到所有CRD的实际状态都达到了预期。如果出现错误或异常情况，控制器会记录日志并尝试自动恢复或者发出警报提示管理员处理。

根据上述步骤，通过利用目标控制器监听目标自定义资源的实际状态，在目标自定义资源的实际状态与目标自定义资源的期望状态不匹配的情况下，利用目标控制器对目标自定义资源进行处理，达到了对自定义资源的发布与运行进行一体化管理的目的，从而实现了提升管理效率的技术效果。

根据本申请的一些可选的实施例，通过Kubernetes集群的接口组件，接收多个不同的自定义资源，包括以下步骤：通过接口组件，接收第一自定义资源，其中，第一自定义资源至少包括：第一信息，第一信息至少包括：构建自定义资源所需的代码仓库和制品镜像仓库的鉴权信息；通过接口组件，接收第二自定义资源，其中，第二自定义资源至少包括：自定义资源发布时的制品镜像构建需求；通过接口组件，接收第三自定义资源，其中，第三自定义资源至少包括：自定义资源在上传至Kubernetes集群的过程中所运行的第一预设模板。

可以理解的是，制品镜像仓库是一种用于存储软件构建产物和相关元数据的集中式容器。通常包含构建工具生成的二进制文件、依赖项、文档以及其他必要的文件。这些构建产物可以被多个开发者或团队使用，从而提高了代码重复利用率和生产力。

代码仓库的鉴权信息通常需要提供代码仓库的访问密钥或者用户名密码等认证方式，用于在构建过程中拉取相关源码。制品镜像仓库的鉴权信息通常需要提供制品镜像仓库的访问密钥或者用户名密码等认证方式，用于在构建过程中推送最终生成的Docker镜像。这些鉴权信息以环境变量、配置文件或者其他安全可靠且方便管理的方式进行存储和传递。同时，在实际使用时也需要注意保护这些敏感信息不被泄露出去。

在本申请的一些可选的实施例，通过Kubernetes集群的接口组件，接收多个不同的自定义资源，可以通过以下方法实现：通过接口组件，接收第四自定义资源，其中，第四自定义资源至少包括：自定义资源运行过程中所引用的组件；通过接口组件，接收第五自定义资源，其中，第五自定义资源至少包括：自定义资源在Kubernetes集群发布过程中输出的目标声明；通过接口组件，接收第六自定义资源，其中，第六自定义资源至少包括：自定义资源在Kubernetes集群发布过程中所需的工程服务。

作为本申请的一些可选的实施例，自定义资源运行过程中所引用的组件例如：Admission Webhook，其中，Admission Webhooks是一种机制，可以通过Webhook方式对Kubernetes API请求进行拦截，并执行某些操作或者验证某些条件。在使用自定义资源时，可以利用Admission Webhooks对创建、更新和删除操作进行验证或者添加额外的信息。Controller Manager，其中，Controller Manage是一个独立进程，在Kubernetes集群中负责控制器的管理和维护。当使用自定义资源时，需要编写相应的控制器逻辑，并将其注册到Controller Manager中。etcd存储***：etcd是一个高可靠性、分布式键值存储***，在Kubernetes集群中被广泛应用。当使用自定义资源CRD时，所有与该Custom Resource相关联的状态都会被持久化到etcd中。kubectl命令行工具：kubectl是Kubernetes命令行工具之一，在使用自定义资源CRD时可以借助kubectl快速地创建、修改、删除以及查询CustomResource对象。

可选地，自定义资源在Kubernetes集群发布过程中所需的工程服务包括以下几个方面：

1.编写自定义资源定义文件：编写YAML或JSON格式的自定义资源定义文件，描述要创建的新资源类型。该文件应指定API版本、种类、元数据和规范等信息。

2.创建控制器：创建一个用于管理和操作新自定义资源类型的控制器。该控制器可以是基于控制器模式实现的，也可以是简单地使用客户端库与API服务器进行交互。

3.部署控制器：将创建好的控制器部署到Kubernetes集群中，并确保其能够成功连接到API服务器以获取并操作目标对象。

4.测试验证：对新建立的自定义资源进行测试验证，确保其正常运行并符合预期功能要求。

5.升级维护：随着业务需求变化或***升级迭代，可能需要对已经存在的自定义资源进行修改或更新。因此，在发布之后还需要及时维护和更新相应组件，并做好版本管理工作。

在本申请的一些可选的实施例中，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态，通过以下方法实现：利用目标控制器对目标自定义资源运行时的目标数据进行采集；获取并分析目标自定义资源在预设时长内的日志文件，得到第一分析结果；根据采集到的目标数据和第一分析结果，确定目标自定义资源在运行过程中可能出现的全部故障；对目标自定义资源在运行过程中可能出现的全部故障进行分析，确定可能出现的全部故障中每个可能出现的故障的原因和位置；根据每个可能出现的故障的原因和位置，确定第二分析结果；根据第二分析结果，执行目标操作或目标脚本，直至目标自定义资源达到期望状态。

目标自定义资源运行时的目标数据例如：1.资源文件：包括图片、音频、视频等媒体文件；2.配置文件：用于设置和配置应用程序的各种参数，例如数据库连接信息、网络配置等；3.脚本文件：可以是JavaScript、Python或其他脚本语言编写的代码，用于控制应用程序的行为和交互；4.模板文件：通常是HTML或XML格式，用于显示动态生成的页面内容；5.数据库文件：如果应用程序需要使用数据库存储数据，则需要将相关数据库文件打包进自定义资源中。

自定义资源在运行过程中可能出现的故障例如：1.资源加载失败：自定义资源可能无法正确加载，导致程序崩溃或异常；2.内存泄漏：如果自定义资源没有被正确释放，会导致内存泄漏问题；3.兼容性问题：自定义资源可能与***环境、硬件设备等存在兼容性问题，导致不稳定的运行情况；4.文件损坏：由于各种原因(例如网络传输中断、磁盘故障等)，自定义资源文件可能出现损坏，影响程序正常运行；5.安全风险：如果自定义资源代码存在安全漏洞或恶意代码，则有可能对***造成安全风险。

在一些可选的实施例中，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态，包括以下步骤：在第一预设时长内，利用目标控制器每隔预设时间间隔对目标自定义资源的负载参数进行采集，其中，负载参数至少包括：中央处理器使用率、内存使用率和网络带宽；对采集到负载参数和目标自定义资源的历史负载参数进行分析，确定第三分析结果，其中，第三分析结果至少包括：目标自定义资源在第二预设时长后的负载参数；根据第三分析结果，调整当前目标自定义资源的负载参数，直至目标自定义资源达到期望状态。

根据本申请的一些可选的实施例，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态，可以通过以下方法实现：根据获取到的仓库链资源信息，获取目标标签对应的目标代码，其中，目标标签用于表征对目标控制器进行更新，仓库链资源信息至少包括：构建目标自定义资源所需的代码仓库和制品镜像仓库的鉴权信息；根据目标代码，执行Kubernetes集群中目标控制器对象的镜像制品；在执行镜像制品之后，通过监听服务持续监听目标控制器对象的工作负载，在工作负载不满足预设条件的情况下，在第三预设时长内调整目标控制器对象的工作负载，直至目标自定义资源达到期望状态。

自定义资源的期望状态取决于该资源的用途和特性。一般而言，一个自定义资源应该具备以下特点：1.状态明确：自定义资源应当有清晰、易懂的状态描述，使用户能够快速地了解它当前所处的状态；2.可扩展性强：自定义资源可以根据实际需求进行拓展，以满足不同场景下的使用要求；3.数据持久化：自定义资源中包含重要数据时需要支持数据持久化，以保证在异常情况下也能够恢复到之前的状态；4.安全可靠：对于涉及敏感信息或重要业务流程的自定义资源，在设计时需要考虑安全性和可靠性等因素，并采取相应措施来保护其完整性和稳定性；5.实现简单：在设计自定义资源时，尽可能避免过度复杂或繁琐的实现方式，以提高可维护性和易用性。

在本申请的一些可选的实施例，通过Kubernetes集群的接口组件，接收多个不同的自定义资源，通过以下方法实现：通过Kubernetes集群的接口组件，以声明式的资源方式，接收多个不同的自定义资源。

可以理解的是，声明式的资源方式是通过配置文件或代码中定义的规则来描述***中需要使用或管理的资源，而不是直接编写命令来操作这些资源。例如，在Kubernetes中，可以使用YAML文件声明应用程序所需的容器、服务和其他资源，并将其提交给集群进行部署和管理。这种方式可以提高可维护性和可靠性，同时减少了手动干预造成的错误和风险。其中，YAML(Yet Another Markup Language)是一种轻量级的数据序列化格式，它以易读性为主要特点。YAML文件基于缩进和键值对的方式表示数据，可用于配置文件、日志记录、数据交换等场景。

图2是根据本申请实施例的一种自定义资源的管理方法的工作流时序图，如图2所示，具体地，

仓库链模块(SunMoonSkyTool)，以Kubernetes的CRD资源形式将微服务构建时所需要的代码仓库、制品镜像仓库的鉴权等信息以声明式的资源方式注入至Kubernetes-APIServer中，并通过对应的控制器对其进行监听与相应的调协。以提供给代码构建模块调用，并提供在发布前进行构建制品镜像的能力。例如代码库和制品仓库用户名密码、TAG信息、编程语言类型、仓库地址、制品仓库地址等。

代码构建模块(SunMoonSkyBuild)，以Kubernetes的CRD资源形式将应用发布时的制品镜像构建需求以声明式的资源方式注入至Kubernetes-APIServer中，并通过对应的控制器对其进行监听与相应的调协。以提供给后续应用部分的模块进行调用，并提供其在发布前进行构建的能力。

发布类型模块(SunMoonSkyDeploymentTemplate)，以Kubernetes的CRD资源形式将微服务上云时运行相关的常规Yaml预设模板以声明式的资源方式注入至Kubernetes-APIServer中，并通过对应的控制器对其进行监听与相应的调协。以提供给后续发布部分和应用部分的调用，简化其编写内容并间接提供“标准”制定。例如指定工作负载的发布类型、服务发现类型等。

调度策略模块(SunMoonSkyDispatchTemplate)，以Kubernetes的CRD资源形式将微服务上云时调度相关的常规Yaml预设模板以声明式的资源方式注入至Kubernetes-APIServer中，并通过对应的控制器对其进行监听与相应的调协。以提供给后续发布部分和应用部分的调用，简化其编写内容并间接提供“标准”制定。例如指定信创与非信创发布比例、调度指定节点等策略。

组件管理模块(SunMoonSkyComponet)，以Kubernetes的CRD资源形式，将运行微服务时所引用的中间件等组件的常规注入配置以声明式的资源方式注入至Kubernetes-APIServer中，并通过对应的控制器对其进行监听与相应的调协。以提供给后续应用部分在创建时对于发布部分中的组件声明内容引用并提供对于某一种组件或中间件在使用时的“标准”定制。例如预设redis、kafka等中间件。

架构定制模块(SunMoonSkyApplicationTemplate)，以Kubernetes的CRD资源形式将对于应用发布时的常规Yaml预设模板以声明式的资源方式注入至Kubernetes-APIServer中，并通过对应的控制器对其进行监听与相应的调协。以提供给后续发布部分和应用部分的调用，简化其编写内容并间接提供“标准”制定。

应用编排模块(SunMoonSkyApplication)，以Kubernetes的CRD资源形式将对于应用发布时的部分声明以声明式的资源方式注入至Kubernetes-APIServer中，并通过对应的控制器对其进行监听与相应的调协。从而将应用整体及其相关资源发布至Kubernetes中并且在发布粒度中以应用发布模块作为发布的最小粒度，从而可以引用上述全部资源。

应用发布模块(SunMoonSkyPublish)，以Kubernetes的CRD资源形式将对于应用发布时的工程服务以声明式的资源方式注入至Kubernetes-APIServer中，并通过对应的控制器对其进行监听与相应的调协。从而将服务工程应用及其相关资源发布至Kubernetes中，并且可以引用发布类型模块、调度策略模块和代码构建模块。

应用监测模块(SunMoonSkyApplicationMonitoring)，以Kubernetes的CRD资源形式将对于应用发布时的工程服务以声明式的资源方式注入至Kubernetes-APIServer中，并通过对应的控制器对其进行监听与相应的调协。应用监测模块用于监测服务程序运行状态和性能的模块，帮助运维人员实时获取应用程序的信息，包括应用程序的运行状态、错误情况、响应时间、资源利用情况等等。

告警通知模块(SunMoonSkyAlarmNotification)，以Kubernetes的CRD资源形式将对于应用发布时的工程服务以声明式的资源方式注入至Kubernetes-APIServer中，并通过对应的控制器对其进行监听与相应的调协。告警通知模块通过收集实时数据和分析运行日志等方式，以检测和警示***中出现的异常和故障情况。当软件***出现异常时，告警通知模块会自动发送警报通知给相关人员，以便及时采取相应措施。

故障自愈模块(SunMoonSkySelfHealing)，以Kubernetes的CRD资源形式将对于应用发布时的工程服务以声明式的资源方式注入至Kubernetes-APIServer中，并通过对应的控制器对其进行监听与相应的调协。故障自愈模块包括故障检测、故障诊断、故障解决、异常事件记录等。对***运行时的各种数据进行实时监测和收集，以及分析日志文件，从而快速检测出可能存在的故障，对检测到的故障进行自动或半自动分析和诊断，确定故障原因和位置，根据诊断结果，自动或半自动地执行必要操作或运行脚本，快速恢复***的正常运行状态。最终记录诊断过程以及故障解决过程中的操作和事件，以帮助用户更好地理解问题和解决方案。

智能伸缩模块(SunMoonSkyScaling)，以Kubernetes的CRD资源形式将对于应用发布时的工程服务以声明式的资源方式注入至Kubernetes-APIServer中，并通过对应的控制器对其进行监听与相应的调协。对微服务应用的负载进行监控，根据预设的策略和算法，自动调整***的资源分配策略，包括：中央处理器、内存、存储等资源。并且能够通过对历史数据的分析和预测，预测未来的负载情况，以提前做出资源调整的决策。最终基于预测和实时监控数据，自动调整***的规模和资源配置，以适应不同的工作负载和流量。

图3是根据本申请实施例的一种自定义资源的管理装置的结构图，如图3所示，该装置包括：

输入模块30，用于通过Kubernetes集群的接口组件，接收多个不同的自定义资源；

监听模块32，用于确定与目标自定义资源的资源类型对应的目标控制器，并利用目标控制器监听目标自定义资源的实际状态，其中，目标自定义资源为多个不同的自定义资源中任意一个自定义资源；

执行模块34，用于在目标自定义资源的实际状态与目标自定义资源的期望状态不匹配的情况下，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态。

需要说明的是，上述图3中的各个模块可以是程序模块(例如是实现某种特定功能的程序指令集合)，也可以是硬件模块，对于后者，其可以表现为以下形式，但不限于此：上述各个模块的表现形式均为一个处理器，或者，上述各个模块的功能通过一个处理器实现。

需要说明的是，图3所示实施例的优选实施方式可以参见图1所示实施例的相关描述，此处不再赘述。

图4示出了一种用于实现自定义资源的管理方法的计算机终端(或移动设备)的硬件结构框图。如图4所示，计算机终端40(或移动设备40)可以包括一个或多个(图中采用402a、402b，……，402n来示出)处理器402(处理器402可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器404、以及用于通信功能的传输模块406。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为BUS总线的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图4所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端40还可包括比图4中所示更多或者更少的组件，或者具有与图4所示不同的配置。

应当注意到的是上述一个或多个处理器402和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算机终端40(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器404可用于存储应用软件的软件程序以及模块，如本申请实施例中的自定义资源的管理方法对应的程序指令/数据存储装置，处理器402通过运行存储在存储器404内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的自定义资源的管理方法。存储器404可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器404可进一步包括相对于处理器402远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端40。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输模块406用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端40的通信供应商提供的无线网络。在一个实例中，传输模块406包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输模块406可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与计算机终端40(或移动设备)的用户界面进行交互。

此处需要说明的是，在一些可选实施例中，上述图4所示的计算机设备(或电子设备)可以包括硬件元件(包括电路)、软件元件(包括存储在计算机可读介质上的计算机代码)、或硬件元件和软件元件两者的结合。应当指出的是，图4仅为特定具体实例的一个实例，并且旨在示出可存在于上述计算机设备(或电子设备)中的部件的类型。

需要说明的是，图4所示的电子设备用于执行图1所示的自定义资源的管理方法，因此上述命令的执行方法中的相关解释说明也适用于该电子设备，此处不再赘述。

本申请实施例还提供了一种非易失性存储介质，非易失性存储介质包括存储的程序，其中，程序运行时控制存储介质所在的设备执行以上的自定义资源的管理方法。

非易失性存储介质执行以下功能的程序：通过Kubernetes集群的接口组件，接收多个不同的自定义资源；确定与目标自定义资源的资源类型对应的目标控制器，并利用目标控制器监听目标自定义资源的实际状态，其中，目标自定义资源为多个不同的自定义资源中任意一个自定义资源；在目标自定义资源的实际状态与目标自定义资源的期望状态不匹配的情况下，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态。

本申请实施例还提供了一种电子设备，包括：存储器和处理器，处理器用于运行存储在存储器中的程序，其中，程序运行时执行以上的自定义资源的管理方法。

处理器用于运行执行以下功能的程序：通过Kubernetes集群的接口组件，接收多个不同的自定义资源；确定与目标自定义资源的资源类型对应的目标控制器，并利用目标控制器监听目标自定义资源的实际状态，其中，目标自定义资源为多个不同的自定义资源中任意一个自定义资源；在目标自定义资源的实际状态与目标自定义资源的期望状态不匹配的情况下，利用目标控制器对目标自定义资源进行处理，以将目标自定义资源的实际状态调整至期望状态。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对相关技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种自定义资源的管理方法，其特征在于，包括：

通过Kubernetes集群的接口组件，接收多个不同的自定义资源；

确定与目标自定义资源的资源类型对应的目标控制器，并利用所述目标控制器监听所述目标自定义资源的实际状态，其中，所述目标自定义资源为所述多个不同的自定义资源中任意一个自定义资源；

在所述目标自定义资源的所述实际状态与所述目标自定义资源的期望状态不匹配的情况下，利用所述目标控制器对所述目标自定义资源进行处理，以将所述目标自定义资源的所述实际状态调整至所述期望状态。

2.根据权利要求1所述的方法，其特征在于，通过Kubernetes集群的接口组件，接收多个不同的自定义资源，包括：

通过所述接口组件，接收第一自定义资源，其中，所述第一自定义资源至少包括：第一信息，所述第一信息至少包括：构建所述自定义资源所需的代码仓库和制品镜像仓库的鉴权信息；

通过所述接口组件，接收第二自定义资源，其中，所述第二自定义资源至少包括：所述自定义资源发布时的制品镜像构建需求；

通过所述接口组件，接收第三自定义资源，其中，所述第三自定义资源至少包括：所述自定义资源在上传至所述Kubernetes集群的过程中所运行的第一预设模板。

3.根据权利要求2所述的方法，其特征在于，通过Kubernetes集群的接口组件，接收多个不同的自定义资源，包括：

通过所述接口组件，接收第四自定义资源，其中，所述第四自定义资源至少包括：所述自定义资源运行过程中所引用的组件；

通过所述接口组件，接收第五自定义资源，其中，所述第五自定义资源至少包括：所述自定义资源在所述Kubernetes集群发布过程中输出的目标声明；

通过所述接口组件，接收第六自定义资源，其中，所述第六自定义资源至少包括：所述自定义资源在所述Kubernetes集群发布过程中所需的工程服务。

4.根据权利要求1所述的方法，其特征在于，利用所述目标控制器对所述目标自定义资源进行处理，以将所述目标自定义资源的所述实际状态调整至所述期望状态，包括：

利用所述目标控制器对所述目标自定义资源运行时的目标数据进行采集；

获取并分析所述目标自定义资源在预设时长内的日志文件，得到第一分析结果；

根据采集到的所述目标数据和所述第一分析结果，确定所述目标自定义资源在运行过程中可能出现的全部故障；

对所述目标自定义资源在运行过程中所述可能出现的全部故障进行分析，确定所述可能出现的全部故障中每个可能出现的故障的原因和位置；

根据所述每个可能出现的故障的原因和位置，确定第二分析结果；

根据所述第二分析结果，执行目标操作或目标脚本，直至所述目标自定义资源达到所述期望状态。

5.根据权利要求4所述的方法，其特征在于，利用所述目标控制器对所述目标自定义资源进行处理，以将所述目标自定义资源的所述实际状态调整至所述期望状态，包括：

在第一预设时长内，利用所述目标控制器每隔预设时间间隔对所述目标自定义资源的负载参数进行采集，其中，所述负载参数至少包括：中央处理器使用率、内存使用率和网络带宽；

对采集到所述负载参数和所述目标自定义资源的历史负载参数进行分析，确定第三分析结果，其中，所述第三分析结果至少包括：所述目标自定义资源在第二预设时长后的负载参数；

根据所述第三分析结果，调整当前所述目标自定义资源的所述负载参数，直至所述目标自定义资源达到所述期望状态。

6.根据权利要求4所述的方法，其特征在于，利用所述目标控制器对所述目标自定义资源进行处理，以将所述目标自定义资源的所述实际状态调整至所述期望状态，包括：

根据获取到的仓库链资源信息，获取目标标签对应的目标代码，其中，所述目标标签用于表征对所述目标控制器进行更新，所述仓库链资源信息至少包括：构建所述目标自定义资源所需的代码仓库和制品镜像仓库的鉴权信息；

根据所述目标代码，执行所述Kubernetes集群中目标控制器对象的镜像制品；

在执行所述镜像制品之后，通过监听服务持续监听所述目标控制器对象的工作负载，在所述工作负载不满足预设条件的情况下，在第三预设时长内调整所述目标控制器对象的所述工作负载，直至所述目标自定义资源达到所述期望状态。

7.根据权利要求1所述的方法，其特征在于，通过Kubernetes集群的接口组件，接收多个不同的自定义资源，包括：

通过所述Kubernetes集群的所述接口组件，以声明式的资源方式，接收所述多个不同的自定义资源。

8.一种自定义资源的管理装置，其特征在于，包括：

输入模块，用于通过Kubernetes集群的接口组件，接收多个不同的自定义资源；

监听模块，用于确定与目标自定义资源的资源类型对应的目标控制器，并利用所述目标控制器监听所述目标自定义资源的实际状态，其中，所述目标自定义资源为所述多个不同的自定义资源中任意一个自定义资源；

执行模块，用于在所述目标自定义资源的所述实际状态与所述目标自定义资源的期望状态不匹配的情况下，利用所述目标控制器对所述目标自定义资源进行处理，以将所述目标自定义资源的所述实际状态调整至所述期望状态。

9.一种非易失性存储介质，其特征在于，所述非易失性存储介质包括存储的程序，其中，在所述程序运行时控制所述非易失性存储介质所在设备执行权利要求1至7中任意一项所述的自定义资源的管理方法。

10.一种电子设备，其特征在于，包括：存储器和处理器，所述处理器用于运行存储在所述存储器中的程序，其中，所述程序运行时执行权利要求1至7中任意一项所述的自定义资源的管理方法。