一种基于CMDB的Kubernetes资源监控方法及系统

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于CMDB的Kubernetes资源监控方法及系统。

背景技术

随着容器化技术的广泛应用，Kubernetes作为一个开源的容器编排平台，为应用程序的部署、扩展和管理提供了便捷的解决方案。然而，随之而来的是资源的高度动态性和复杂性，这使得传统的资源管理和监控手段显得力不从心。在这一背景下，面临着对资源自动发现和实时跟踪的需求，需要解决如何有效地实现Kubernetes API资源的自动发现和实时跟踪，传统的跟踪机制往往无法满足Kubernetes集群资源动态变化的实时性要求。

发明内容

鉴于以上技术问题，本发明提供了一种基于CMDB的Kubernetes资源监控方法及系统，以解决现有技术中传统的跟踪机制往往无法满足Kubernetes集群资源动态变化的实时性要求的问题。

本发明的其他特征和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

根据本发明的一方面，公开一种基于CMDB的Kubernetes资源监控方法，所述方法包括：

建立CMDB与Kubernetes的API的通信，使得所述CMDB获取并解释、存储所述Kubernetes以JSON形式返回的资源信息，轮询所述Kubernetes的API，对当前轮询和上一次轮询结果进行对比，以使得新增、删除或更新的资源信息反映至所述CMDB中，或/和，通过事件监视器实时订阅所述Kubernetes的资源变更事件和建立使得所述CMDB更新相应的资源信息的异步更新机制；

将数据采集工具部署至所述Kubernetes中，以对所述Kubernetes的资源进行采集，以及基于Label标签或/和Annonation注解，对采集到的资源进行应用信息标记后关联到相应的应用和业务系统的资源上，所采集的资源包括基础资源、存储资源、网络资源、访问控制资源、工作负载资源和配置资源；

将采集到的资源以可视化的台账形式展示于所述CMDB中，并基于预设的监控指标和警报规则，对所述Kubernetes进行监控。

进一步的，所述建立CMDB与Kubernetes的API的通信，包括：

基于所述Kubernetes的gPRC协议与所述Kubernetes的API通信，以及在通信时，建立连接池机制，复用所述CMDB与所述Kubernetes的API的连接，以降低频繁建立和连接的开销；

以及在通信时，通过自动重试机制，使得在所述Kubernetes的API调用失败时自动重试，并在调佣失败次数超过阈值时延长重试时间。

进一步的，在通信时，通过非阻塞方式处理多个请求，以实现异步API调用，并集成所述Kubernetes的API聚合层。

进一步的，在轮询所述Kubernetes的API时，基于所述Kubernetes的gPRC协议进行轮询，或通过监听所述Kubernetes的API返回的信息，在有实际变更时触发轮询。

进一步的，在通过所述事件监视器实时订阅所述Kubernetes的资源变更事件时，包括：

根据当前负载和资源变更频率调整监听精度；

对不同的资源类型、关键词进行细粒度过滤，以提高监听效率。

进一步的，所述CMDB通过Prometheus Operator工具采集所述Kubernetes的资源。

进一步的，在对采集到的资源进行应用信息标记时，包括：

基于机器学习算法，分析资源的历史使用情况，预测和生成新的业务标签；

在将采集到的资源标记并关联到相应的应用和业务系统的资源后，包括：

基于在应用或业务系统的资源变更时，实时更新关联关系。

进一步的，所述基础资源包括：Cluster、Namespace、Node；

所述存储资源包括：StorageClass、Persistent Volume、PersistentVolumeClaim；

所述网络资源包括：Ingress、NetworkPolicy、Endpoints、PortForwarding、Service、IngressClass；

所述访问控制资源包括：ServiceAccount、ClusterRole、ClusterRole Bonding、PodSecurity Policy、Role、RoleBonding；

所述工作负载资源包括：Pod Workload、ReplicationController、ReplicaSet；

所述配置资源包括：ConfigMap、LimitRange、PriorityClass、Secret、HPA、RuntimeClass、ResourceQuota、PodDisruption Budget、Lease。

根据本公开的另一方面，提供一种基于CMDB的Kubernetes资源监控系统，包括：

资源跟踪模块，用于建立CMDB与Kubernetes的API的通信，使得所述CMDB获取并解释、存储所述Kubernetes以JSON形式返回的资源信息，轮询所述Kubernetes的API，对当前轮询和上一次轮询结果进行对比，以使得新增、删除或更新的资源信息反映至所述CMDB中，或/和，通过事件监视器实时订阅所述Kubernetes的资源变更事件和建立使得所述CMDB更新相应的资源信息的异步更新机制；

资源采集和关联模块，用于将数据采集工具部署至所述Kubernetes中，以对所述Kubernetes的资源进行采集，以及基于Label标签或/和Annonation注解，对采集到的资源进行应用信息标记后关联到相应的应用和业务系统的资源上，所采集的资源包括基础资源、存储资源、网络资源、访问控制资源、工作负载资源和配置资源；

可视化监控模块，用于将采集到的资源以可视化的台账形式展示于所述CMDB中，并基于预设的监控指标和警报规则，对所述Kubernetes进行监控。

本公开的技术方案具有以下有益效果：

基于CMDB与Kubernetes的API的通信，在通信时动态发现资源和实时跟踪，提高对Kubernetes集群动态变化的敏感性和实时感知能力，减少资源管理的滞后性，解决资源管理和监控问题，在实时性、通信效率和用户体验等方面带来积极影响。

附图说明

图1为本说明书实施例中的一种基于CMDB的Kubernetes资源监控方法的流程图；

图2为本说明书实施例中基于CMDB的Kubernetes资源监控系统的结构框图；

图3为本说明书实施例中的存储有基于CMDB的Kubernetes资源监控方法的计算机可读存储介质。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特征可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、系统、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器系统和/或微控制器系统中实现这些功能实体。

如图1所示，本说明书实施例提供一种基于CMDB的Kubernetes资源监控方法，该方法的执行主体可以为服务器。该方法具体可以包括以下步骤S101～S103：

在步骤S101中，建立CMDB与Kubernetes的API的通信，使得所述CMDB获取并解释、存储所述Kubernetes以JSON形式返回的资源信息，轮询所述Kubernetes的API，对当前轮询和上一次轮询结果进行对比，以使得新增、删除或更新的资源信息反映至所述CMDB中，或/和，通过事件监视器实时订阅所述Kubernetes的资源变更事件和建立使得所述CMDB更新相应的资源信息的异步更新机制。

在步骤S102中，将数据采集工具部署至所述Kubernetes中，以对所述Kubernetes的资源进行采集，以及基于Label标签或/和Annonation注解，对采集到的资源进行应用信息标记后关联到相应的应用和业务系统的资源上，所采集的资源包括基础资源、存储资源、网络资源、访问控制资源、工作负载资源和配置资源。

在步骤S103中，将采集到的资源以可视化的台账形式展示于所述CMDB中，并基于预设的监控指标和警报规则，对所述Kubernetes进行监控。

作为对步骤S101补充的，在建立CMDB与Kubernetes的API的通信时，基于所述Kubernetes的gPRC协议与所述Kubernetes的API通信，以及在通信时，建立连接池机制，复用所述CMDB与所述Kubernetes的API的连接，以降低频繁建立和连接的开销；以及在通信时，通过自动重试机制，使得在所述Kubernetes的API调用失败时自动重试，并在调佣失败次数超过阈值时延长重试时间。

建立通信所获取的资源信息可以是节点、Pod、服务、存储卷等。CMDB通过数据格式解析器来确保正确解析从Kubernetes API获取的JSON或其他格式的数据。gRPC协议具体是一种高性能、开源的远程过程调用框架。连接池机制具体是一种用于管理和维护网络连接的机制，在通信中，频繁地建立和关闭连接会带来一定的开销，因此连接池被引入以提高效率，连接池会在启动时预先创建一定数量的连接，并保存在池中，当需要进行API通信时，可以从连接池中获取一个可用的连接，使用完毕后将其归还到池中而不是立即关闭，这样可以减少连接的建立和关闭次数，提高资源利用率，同时也能够更好地应对Kubernetes的高并发需求。自动重试机制是指在进行通信时，当出现失败或错误时能够自动进行重试，这有助于提高通信的容错性和稳定性，自动重试机制具体可以包括指数退避策略，即在每次重试失败后，等待时间会按指数级增加，以避免在网络瞬时故障时造成过多的重试请求，在一定程度上处理瞬时的网络问题，确保在面对一些短暂的异常情况时能够自动尝试恢复，提高通信的可靠性。

另外的，在进行API通信时，通过非阻塞方式处理多个请求，以实现异步API调用，并集成所述Kubernetes的API聚合层。非阻塞方式意味着通过采用异步API调用的方式，可以在发送请求后不必等待响应，而是继续执行其他任务，使得可以有效地处理多个请求，提高整体性能和响应速度，最大限度地利用计算资源，提高并发处理能力。这对于Kubernetes集群中处理大量的、并发的请求是非常有益的，能够显著提升系统的性能和吞吐量。

另外地，步骤S101中提出了轮询机制和实时跟踪机制，在轮询Kubernetes API时，基于所述Kubernetes的gPRC协议进行轮询，获取当前Kubernetes集群状态，然后通过比对前后两次轮询的结果，找出新增、删除或更新的资源，这是一个静态的、周期性的过程，是对整个集群状态的快照式的抓取和分析；而实时跟踪机制更注重实时性，通过事件监听器实时订阅Kubernetes API的事件通知，这使得CMDB能够即时感知资源的变更，而不仅仅是在轮询时才发现，这是一个动态、事件驱动的机制，对于即时的、不定时的变更更为敏感。同时，也可以将两者结合，通过实时监听所述Kubernetes的API返回的信息，在有实际变更时触发轮询。以及，在实时跟踪中，建立异步更新机制确保在Kubernetes集群中的资源发生变化时，CMDB系统能够实时获取并更新相应的资源信息，而不需要等待同步完成。

异步更新机制具体是建立一个异步任务队列或消息队列，用于存储从事件监听器接收到的变更事件，当监听器捕获到事件时，将事件信息放入队列，不阻塞主线程的执行。同时设计异步任务处理器，负责从队列中取出事件信息，并执行相应的更新操作，该处理器可以采用多线程或者异步IO等机制，以确保在处理一个事件时不会影响其他事件的处理，即在异步任务处理器中，其实现逻辑是将事件中的变更信息反映到CMDB系统的数据库中。

在通过所述事件监视器实时订阅所述Kubernetes的资源变更事件时，根据当前负载和资源变更频率调整监听精度，对不同的资源类型、关键词进行细粒度过滤，以提高监听效率，以实现自适应事件监听。

在一实施方式中，所述CMDB通过Prometheus Operator工具采集所述Kubernetes的资源。其中，Prometheus Operator为可用于Kubernetes的运维工具，以自定义资源的形式定义Prometheus、ServiceMonitors等配置。CMDB可以通过Prometheus Operator直接与Kubernetes集成，无需额外的部署。

在一实施方式中，在对采集到的资源进行应用信息标记时，基于机器学习算法，分析资源的历史使用情况，预测和生成新的业务标签；在将采集到的资源标记并关联到相应的应用和业务系统的资源后，基于在应用或业务系统的资源变更时，实时更新关联关系，具体可以利用关联历史学习，分析资源与应用之间的关联模式，包括资源被哪些应用使用，应用使用了哪些资源等信息，然后，在CMDB系统中明确定义资源之间的关联规则和关联模型，如资源的父子关系、依赖关系、拓扑关系等，然后通过事件监听器，订阅Kubernetes API提供的事件通知，在CMDB系统中建立专门的关联信息存储区域，用于存储资源之间的关联信息，和设计数据结构和数据库表，以适应不同类型关联信息的存储需求，确保在资源关联变更时立即更新关联关系，并将这些信息实时更新到关联信息存储区域中，使得关联信息能够更加实时地反映系统的动态变化。

在一实施方式中，所述基础资源包括：Cluster(集群)、Namespace(命名空间)、Node(节点)；所述存储资源包括：StorageClass(存储类)、Persistent Volume(持久卷)、Persistent VolumeClaim(持久卷声明)；所述网络资源包括：Ingress(入口)、NetworkPolicy(网络策略)、Endpoints(终结点)、PortForwarding(端口转发)、Service(服务)、IngressClass(入口类)；所述访问控制资源包括：ServiceAccount(服务账户)、ClusterRole(集群角色)、ClusterRole Bonding(集群角色绑定)、PodSecurity Policy(Pod安全策略)、Role(角色)、RoleBonding(角色绑定)；所述工作负载资源包括：PodWorkload(Pod工作负载)、ReplicationController(副本控制器)、ReplicaSet(副本集)；所述配置资源包括：ConfigMap(配置映射)、LimitRange(限制范围)、PriorityClass(优先级类)、Secret(密钥)、HPA(水平自动扩展)、RuntimeClass(运行时类)、ResourceQuota(资源配额)、PodDisruption Budget(Pod中断预算)、Lease(租约)。

在一实施方式中，将采集到的资源以可视化的台账形式展示于CMDB中，可以是在CMDB系统中设计台账模块，将采集到的资源信息以可视化的形式展示，如表格、图表、拓扑图等形式，便于用户直观了解Kubernetes集群中各个资源的状态和关系。在基于预设的监控指标和警报规则对Kubernetes进行监控时，可以根据业务需求和系统性能，预设需要监控的指标，如CPU利用率、内存使用情况、网络流量等，设定触发警报的条件和级别，例如，当某个Pod的CPU利用率超过阈值时，触发警报，这些规则为基于资源的状态、性能指标、事件等多方面的条件的。在监控时，采集资源时进行扩展，定期获取Kubernetes集群中的监控指标数据，或针对实时性要求高的指标，实时监控，确保系统能够及时捕捉变化。

基于同样的思路，如图2所示，本公开的示例性实施方式还提供一种基于CMDB的Kubernetes资源监控系统，包括：资源跟踪模块201，用于建立CMDB与Kubernetes的API的通信，使得所述CMDB获取并解释、存储所述Kubernetes以JSON形式返回的资源信息，轮询所述Kubernetes的API，对当前轮询和上一次轮询结果进行对比，以使得新增、删除或更新的资源信息反映至所述CMDB中，或/和，通过事件监视器实时订阅所述Kubernetes的资源变更事件和建立使得所述CMDB更新相应的资源信息的异步更新机制；资源采集和关联模块202，用于将数据采集工具部署至所述Kubernetes中，以对所述Kubernetes的资源进行采集，以及基于Label标签或/和Annonation注解，对采集到的资源进行应用信息标记后关联到相应的应用和业务系统的资源上，所采集的资源包括基础资源、存储资源、网络资源、访问控制资源、工作负载资源和配置资源；可视化监控模块203，用于将采集到的资源以可视化的台账形式展示于所述CMDB中，并基于预设的监控指标和警报规则，对所述Kubernetes进行监控。

本发明基于CMDB与Kubernetes的API的通信，在通信时动态发现资源和实时跟踪，提高对Kubernetes集群动态变化的敏感性和实时感知能力，减少资源管理的滞后性，解决资源管理和监控问题，在实时性、通信效率和用户体验等方面带来积极影响。。

上述系统中各模块的具体细节在方法部分实施方式中已经详细说明，未披露的细节内容可以参见方法部分的实施方式内容，因而不再赘述。

基于同样的思路，本公开的示例性实施方式还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在终端设备上运行时，程序代码用于使终端设备执行本说明书上述“基于CMDB的Kubernetes资源监控方法”部分中描述的根据本公开各种示例性实施方式的步骤。

参考图3所示，描述了根据本公开的示例性实施方式的用于实现上述方法的程序产品300，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、系统或者器件使用或者与其结合使用。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、系统或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、系统或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，程序设计语言包括面向对象的程序设计语言一诸如Java、C++等，还包括常规的过程式程序设计语言一诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端系统、或者网络设备等)执行根据本公开示例性实施方式的方法。

此外，上述附图仅是根据本公开示例性实施方式的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的示例性实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施方式。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施方式仅被视为示例性的，本公开的真正范围和精神由权利要求指出。