CN114884838B

CN114884838B - Kubernetes组件的监控方法及服务器

Info

Publication number: CN114884838B
Application number: CN202210554587.5A
Authority: CN
Inventors: 林智勇
Original assignee: Shanghai Envision Innovation Intelligent Technology Co Ltd; Envision Digital International Pte Ltd
Current assignee: Shanghai Envision Innovation Intelligent Technology Co Ltd; Envision Digital International Pte Ltd
Priority date: 2022-05-20
Filing date: 2022-05-20
Publication date: 2023-05-12
Anticipated expiration: 2042-05-20
Also published as: CN114884838A

Abstract

本申请实施例公开了一种Kubernetes组件的监控方法及服务器，属于云应用技术领域。该方法包括：基于监控内容确定监控pod的监控对象，监控内容为检测监控对象的网络连通性或功能完整性；通过监控pod与监控对象进行网络通信，确定监控对象对应的监控结果；响应于监控结果指示监控对象运行异常，向监控终端发送告警信息，告警信息用于指示异常组件以及异常类型。通过在集群中配置并启动预编写的监控资源文件，调用目标节点设备中的监控pod，即可对集群中的Kubernetes组件的运行状态进行监控，并提供可配置的处理策略，在组件发生故障或存在紧急情况时，对其进行处理以及告警，从而降低监控人员的工作量，节约成本开支。

Description

Kubernetes组件的监控方法及服务器

技术领域

本申请实施例涉及云应用技术领域，特别涉及一种Kubernetes组件的监控方法及服务器。

背景技术

Kubernetes是当前主流的容器编排引擎，集群中存在着数量巨大的组件，例如服务(service)、分离舱(pod)、访问权(ingress)等，在运行过程中各种组件不可避免会出现故障。组件运行时若出现了各种故障，需要及时发出告警使运维人员知晓，以供处理，避免更大损失。

相关技术中，Kubernetes具有监控运行工具，如仪表盘(dashboard)和grafana等，可以查看到Kubernetes集群中部分组件如节点(node)、pod的运行状态等信息。

然而，上述监控运行工具只能简单地查看到pod和node是否处于运行状态，但是对于能否正常运行、正确地对外提供服务等状况无法得知，且只能针对部分组件进行监控，对于service、ingress等组件无法很好地进行监控，并且未与告警系统进行整合。以上缺点导致Kubernetes没有一套覆盖较广、功能完备的组件监控系统，容易在各类组件存在各类功能障碍时，出现漏报、迟报、误报以及无法正确进行处理等情况。

发明内容

本申请实施例提供了一种Kubernetes组件的监控方法及服务器。所述技术方案如下：

一方面，本申请实施例提供了一种Kubernetes组件的监控方法，所述方法应用于运行有Kubernetes的分布式集群中的目标节点设备，所述目标节点设备中创建有监控分离舱pod，所述监控pod是基于监控资源文件创建的，所述分布式集群由至少两个节点设备组成，所述方法包括：

基于监控内容确定所述监控pod的监控对象，所述监控内容为检测所述监控对象的网络连通性或功能完整性，所述监控对象为部署在所述分布式集群中的Kubernetes组件或设备；

通过所述监控pod与所述监控对象进行网络通信，确定所述监控对象对应的监控结果，所述监控结果用于指示所述监控对象的运行状态；

响应于所述监控结果指示所述监控对象运行异常，向监控终端发送告警信息，所述告警信息用于指示异常组件以及异常类型。

另一方面，本申请实施例提供了一种Kubernetes组件的监控装置，所述装置应用于运行有Kubernetes的分布式集群中的目标节点设备，所述目标节点设备中创建有监控分离舱pod，所述监控pod是基于监控资源文件创建的，所述分布式集群由至少两个节点设备组成，所述装置包括：

第一确定模块，用于基于监控内容确定所述监控pod的监控对象，所述监控内容为检测所述监控对象的网络连通性或功能完整性，所述监控对象为部署在所述分布式集群中的Kubernetes组件或设备；

第二确定模块，用于通过所述监控pod与所述监控对象进行网络通信，确定所述监控对象对应的监控结果，所述监控结果用于指示所述监控对象的运行状态；

发送模块，用于响应于所述监控结果指示所述监控对象运行异常，向监控终端发送告警信息，所述告警信息用于指示异常组件以及异常类型。

另一方面，本申请实施例提供了一种服务器，所述服务器包括处理器和存储器；所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上述方面所述的Kubernetes组件的监控方法。

另一方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条计算机程序，所述计算机程序由处理器加载并执行以实现如上述方面所述的Kubernetes组件的监控方法。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。服务器的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该服务器执行上述方面的各种可选实现方式中提供的Kubernetes组件的监控方法。

本申请实施例提供的技术方案至少包括以下有益效果：

本申请实施例中，通过在集群中配置并启动预编写的监控资源文件，调用目标节点设备中的监控pod，即可对集群中的Kubernetes组件的运行状态进行监控，并提供可配置的处理策略，在组件发生故障或存在紧急情况时，对其进行处理以及告警，相比于相关技术中的监控工具，能够基于各类组件的工作特性进行策略配置，不仅能够监控组件的网络连通性，确定其是否运行，还能够监控组件的功能完整性，从而降低监控人员的工作量，节约成本开支。

附图说明

图1是本申请一个示例性实施例提供的实施环境的示意图；

图2是本申请一个示例性实施例提供的Kubernetes组件的监控方法的流程图；

图3是本申请另一个示例性实施例提供的Kubernetes组件的监控方法的流程图；

图4是本申请一个示例性实施例提供的podCheck的流程图；

图5是本申请一个示例性实施例提供的serviceCheck的流程图；

图6是本申请另一个示例性实施例提供的Kubernetes组件的监控方法的流程图；

图7是本申请一个示例性实施例提供的ingressAndNodeCheck的流程图；

图8是本申请一个示例性实施例提供的cephfsCheck的流程图；

图9是本申请一个示例性实施例提供的nodeController监控的流程图；

图10是本申请一个示例性实施例提供的Kubernetes组件的监控装置的结构框图；

图11是本申请一个示例性实施例提供的服务器的结构框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

Kubernetes集群中存在着数量巨大的node、service、pod、ingress等组件，如图1所示，Kubernetes集群由多个node组成，node中部署多个pod，每个pod用于管理多个容器(container)，集群中还包含ingress，用于向service转发集群外的请求，service各自对应多个pod，service与pod进行交互，此外还包含有底层存储组件(ceph)，用于存放集群中的持久化数据。Kubernetes在运行过程中不可避免会出现各种组件故障。相关技术中，Kubernetes存在相关的监控运行工具，如dashboard，可以查看到Kubernetes集群中部分组件(如node和pod)的运行状态信息。然而，Kubernetes中的监控工具只能简单的查看到pod以及node是否处于运行状态，但是对于是否能够正常运行、是否能够正确地对外提供服务则无法得知，且对于service、ingress以及ceph等组件无法进行监控。此外，相关技术中的监控工具并未与告警系统进行整合。以上缺点导致Kubernetes没有一套覆盖较广、功能完备的组件监控系统，容易导致在各类组件出现功能障碍时，出现漏报、迟报、误报以及无法正确处理等问题。

为了解决上述技术问题，本申请实施例提出了一种Kubernetes组件的监控方法，该方法应用于图1所示的实施环境中。通过在集群中部署监控资源文件，目标节点设备运行该文件并创建相应的监控pod，通过监控pod与各个组件或设备进行交互，监控组件的网络交互性或功能完整性，并且在确定组件存在异常时，监控pod执行对应的处理策略或进行告警，从而提高集群的可用性。

图2示出了本申请一个示例性实施例提供的Kubernetes组件的监控方法的流程图。本实施例以该方法应用于运行有Kubernetes的分布式集群中的目标节点设备(服务器)为例进行说明，目标节点设备中创建有监控pod，监控pod是基于监控资源文件创建的，分布式集群由至少两个节点设备组成，该方法包括如下步骤。

步骤201，基于监控内容确定监控pod的监控对象，监控内容为检测监控对象的网络连通性或功能完整性，监控对象为部署在分布式集群中的Kubernetes组件或设备。

在一种可能的实施方式中，针对Kubernetes组件的监控需求，开发人员预设有多种监控内容，该监控内容用于指示具体的监控对象，以及对监控对象的检测项目，检测项目主要包括网络连通性或功能完整性两类，例如，监控内容包括对集群中各个pod的网络连通性的测试以及对监控访问权限组件(ingress)的功能完整性测试等。目标节点设备基于各项监控内容，确定对应的监控对象。

可选的，监控对象为分布式集群中的Kubernetes组件，如pod、ingress、监控服务组件(service)等，或者集群中的实体设备，如节点设备(包括目标节点设备)。

其中，目标节点设备可以是分布式集群中的所有节点设备，即集群中的所有节点设备均执行Kubernetes组件的监控方法中的步骤，对组件或设备进行监控，或者，目标节点设备可以是分布式集群中的一个或某几个节点设备(例如分布式集群中的主节点设备)，开发人员可以基于开发设计需求指定任意一个或几个节点设备作为目标节点设备，在其中部署并运行监控资源文件。不同类型的监控内容所对应的目标节点设备可能不同。

目标节点设备在第一次运行监控资源文件后创建监控pod，后续也通过调用该监控pod实现个各个监控流程。

步骤202，通过监控pod与监控对象进行网络通信，确定监控对象对应的监控结果，监控结果用于指示监控对象的运行状态。

目标节点设备执行监控资源文件中的指令，调用监控pod与监控对象进行相应预设方式的网络通信，基于通信结果确定监控结果，即监控对象的运行状态。例如通过发起网络应答请求检测其网络是否连通，或者通过发送数据查询请求，基于监控对象返回的数据结果检测其相应的功能是否正常。

目标节点设备基于监控结果确定监控对象的运行状态，该运行状态用于指示监控对象运行状态，例如是否正在运行、是否成功连接网络、其具体功能是否完整、功能执行是否正常等。在一种可能的实施方式中，目标节点设备中的监控pod基于监控结果确定监控对象的运行状态，并且能够在监控对象运行异常时，确定其异常类型以及应对策略。

步骤203，响应于监控结果指示监控对象运行异常，向监控终端发送告警信息，告警信息用于指示异常组件以及异常类型。

在一种可能的实施方式中，开发人员通过在监控资源文件中配置相应的处理策略，使目标节点设备在确定组件运行异常时，基于监控结果确定对应的处理策略，以进行功能修复、暂停组件或设备运行、通知相关人员进行维护等，从而提高集群的可用性。

可选的，目标节点设备向监控终端发送告警信息，其中，监控终端可以是运维人员的手机、平板电脑、笔记本电脑、台式电脑等终端设备中的至少一种，告警信息的发送方式包括发送邮件、发送短信、在日志中心添加异常记录等，本申请实施例对此不作限定。

综上所述，本申请实施例中，通过在集群中配置并启动预编写的监控资源文件，调用目标节点设备中的监控pod，即可对集群中的Kubernetes组件的运行状态进行监控，并提供可配置的处理策略，在组件发生故障或存在紧急情况时，对其进行处理以及告警，相比于相关技术中的监控工具，能够基于各类组件的工作特性进行策略配置，不仅能够监控组件的网络连通性，确定其是否运行，还能够监控组件的功能完整性，从而降低监控人员的工作量，节约成本开支。

在一种可能的实施方式中，监控内容包括对集群中pod网络连通性的监控(podCheck)以及service网络连通性的监控(serviceCheck)，此时目标节点设备为分布式集群中的所有节点设备，监控资源文件为守护进程内置资源(DeamonSet)。图3示出了本申请一个示例性实施例提供的Kubernetes组件的监控方法的流程图。本实施例以该方法应用于运行有Kubernetes的分布式集群中的目标节点设备(服务器)为例进行说明，目标节点设备中创建有监控pod，监控pod是基于监控资源文件创建的，分布式集群由至少两个节点设备组成，该方法包括如下步骤。

步骤301，响应于监控内容为监控pod的网络连通性，确定监控对象为分布式集群中的pod。

在一种可能的实施方式中，本申请实施例提供了一种对集群中pod的网络连通性的监控方案，此时目标设备的监控对象为集群中的各个pod。

在Kubernetes集群中，Pod是所有业务类型的基础，也是Kubernetes管理的最小单位级，它是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及如何运行的规范。在Pod中，所有容器都被同一安排和调度，并运行在共享的上下文中。对于具体应用而言，Pod是它们的逻辑主机，Pod包含业务相关的多个应用容器。每一个Pod都会被指派一个唯一的(Internet Protocol，IP)地址，在Pod中的每一个容器共享网络命名空间，包括Ip地址和网络端口。在同一个Pod中的容器可以进行互相通信，当Pod中的容器需要与Pod外的实体进行通信时，则需要通过端口等共享的网络资源。

步骤302，响应于监控内容为监控服务组件service的网络连通性，确定监控对象为分布式集群中的service。

Service是一种可以访问Pod逻辑分组的策略，能够提供负载均衡的能力，通常是通过Label Selector访问Pod组。

在一种可能的实施方式中，本申请实施例提供了一种对集群中service的网络连通性的监控方案，此时目标设备的监控对象为集群中的各个service。

值得注意的是，如流程图所示，步骤301与步骤302为并列关系，并不存在严格的先后顺序。

步骤303，响应于达到监控周期，通过第一监控pod与监控对象进行网络通信，确定监控对象的监控结果，第一监控pod是通过运行DeamonSet文件创建得到的。

在一种可能的实施方式中，开发人员将用于组件监控的DeamonSet文件single-check.Yaml部署在主节点设备中，主节点设备执行该Yaml文件中的指令，在集群中的每个节点设备中部署single-check程序，该single-check程序中包含用于检查pod网络连通性的模块，即podCheck模块，以及用于检查service网络连通性的模块，即serviceCheck。集群中的节点设备首次启动single-check程序，即运行DaemonSet，创建第一监控pod，后续基于第一监控pod进行对pod以及service的监控。DaemonSet的作用是在集群中每个节点内创建一个pod，因此各个目标节点中均创建一个第一监控pod。

可选的，目标节点设备基于同一个第一监控pod对pod以及service进行监控，或者，目标节点设备分别为pod监控和service监控创建不同的第一监控pod，从而实现同步监控，本申请实施例对此不作限定。

在一种可能的实施方式中，各个监控内容均对应有监控周期，例如，集群每隔15分钟进行一次监控，每轮监控持续2分钟，当到达周期检查时间点时，集群开始进行监控任务，若超过监控周期还未执行完成，则等待下一轮监控。

当监控对象为集群中的pod，监控内容为检测pod的网络连通性时，步骤303包括如下步骤：

步骤303a，基于因特网包探索器检测所述第一监控pod与第i个pod之间的网络连通性，i为正整数。

在一种可能的实施方式中，在集群中的程序开始运行后，目标节点设备中的第一监控pod，通过pod调查组件(podInformer)获取集群中所有的pod，并放入待检查列表。

目标节点设备在完成对列表中上一个pod(第i-1个pod的检测)后，若未完成对该列表中所有pod的检测，则从列表中获取第i个pod，基于因特网包探索器(Packet InternetGroper，PING)检测第一监控pod与第i个pod之间的网络连通性。具体的，集群中每个pod具有唯一的IP地址，目标节点设备获取第i个pod的IP地址，并进行PING操作，确定是否能够与第i个pod进行网络连通。

在一种可能的实施方式中，目标节点设备并非直接对集群中的所有pod进行检测，首先需要判断其内部容器是否初始化完成以及该pod是否对应有忽略策略(即用户或运维人员指定无需监控的pod)，上述步骤303a之前，本申请实施例提供的方法还包括如下步骤：

步骤一，获取第i个pod中容器的初始化进度。

通常一个pod中包含多个容器，目标节点设备需获取第i个pod中各个容器的初始化进度。

上述步骤303a可以包括如下步骤：

步骤二，响应于第i个pod中的所有容器初始化完成，基于因特网包探索器检测第一监控pod与第i个pod之间的网络连通性。

当第i个监控pod中所有容器初始化完成时，说明此pod的容器初始化功能正常，继续对该pod进行检测。若pod的初始化功能异常，则即使其网络连通功能正常也无法网络通信，因此该情况下无需继续进行网络连通性测试。

当容器初始化未完成时时，本申请实施例提供的方法还包括如下步骤：

步骤三，响应于第i个pod中存在未初始化的容器，确定第i个pod初始化异常并向监控终端发送告警信息。

响应于第i个pod中存在未初始化的容器，则目标节点设备直接发送告警信息，并跳过对第i个pod的检测，继续对第i+1个pod进行网络连通性检测。若下一轮检测时该pod初始化完成，则目标节点设备撤回告警信息，或者发送告警接触信息，以示该pod的初始化功能恢复正常。

此外，用户或运维人员还可以设置忽略策略，即设置指定的pod使目标节点设备不对该指定的pod进行监控。因此，目标节点设备在获取到第i个pod的IP地址后，首先判断其初始化是否完成，若完成，再判断是否属于忽略策略中的pod，若是则跳过第i个pod，若否则继续进行检测；或者，目标节点设备先判断第i个pod是否属于忽略策略中的pod，若是，则检测容器初始化情况以及网络连通性，若否，则直接获取第i+1个pod。本申请实施例对此不做限定。

步骤303b，响应于第i个pod满足第一网络连通条件，确定第i个pod的监控结果为网络连通正常，对第i+1个pod进行网络连通性检测，第一网络连通条件为连续n次检测中至少一次网络连通成功，n为正整数。

在一种可能的实施方式中，若第一监控pod连续对第i个pod进行n次PING操作，且存在至少一次PING通成功，则目标节点设备确定第i个pod满足第一网络连通条件，即第i个pod的监控结果为网络连通正常，若此时列表中还存在未检测的pod，则获取第i+1个pod进行检测，否则结束本轮监控。

步骤303c，响应于第i个pod不满足第一网络连通条件，且第i个pod不存在或pod标识改变，忽略/跳过第i个pod，对第i+1个pod进行网络连通性检测。

步骤303d，响应于第i个pod不满足第一网络连通条件，第i个pod存在且pod标识未发生变化，对第i个pod进行二次检测，基于二次检测结果确定第i个pod的监控结果。

由于集群中的pod随时可能会发生变化，例如pod被删除，或者IP地址改变，则在第一监控pod对前i-1个pod进行检测的过程中，第i个pod可能会发生变化。若连续n次PING操作后，第一监控pod与第i个pod网络连接均失败，则确定第i个pod不满足第一网络连通条件，此时目标节点设备判断第i个pod是否存在，若不存在则跳过第i个pod继续检测其它pod，第i个pod在下一轮监控流程中进行检测，若存在则判断其IP地址是否发生变化，若变化则同样跳过第i个pod继续检测其它pod，第i个pod在下一轮监控流程中进行检测，若未发生变化则说明第i个pod可能存在网络连通异常，目标节点设备通过第一监控pod对第i个pod进行二次检测，基于二次检测结果确定监控结果，防止因为网络的临时抖动导致的检查错误，避免出现误告警的情况。

相应的，二次检测仍然是对第i个pod执行n次PING操作，若至少一次成功，则确定第i个pod网络连通正常，若二次检测均失败，则确定第i个pod网络连通异常，并进行告警。

图4示出了某一目标节点设备执行对pod的监控流程的流程图。步骤401，在每个节点设备上启动single-check，使用podCheck模块检查。步骤402，判断程序处于运行状态。若是，则执行步骤403，否则结束流程。步骤403，到达预设的周期检查时间点，使用podInformer获取集群中所有pod，放入待检查列表。步骤404，获取带检查列表当前pod，更新其无法PING同次数的缓存。步骤405，判断当前列表是否检查结束。若是则等待进行下一轮检测，若否则执行步骤406。步骤406，检查pod中容器的初始化情况。步骤407，判断是否初始化完成。若是，则执行步骤409，若否则执行步骤408。步骤408，pod容器初始化异常，按预定方式进行告警。步骤409，检查pod能否正常与外部进行通信。步骤410，判断是否存在忽略策略。若是，则执行步骤411，若否，则执行步骤412。步骤411，跳过此pod，继续检查其他pod。步骤412，进行PING操作，并对返回结果进行解析。步骤413，判断3次尝试内能否PING通。若是，则执行步骤414，若否，则执行步骤415。步骤414，确认正常，继续检查其他pod。步骤415，检查此pod当前存在状态。步骤416，判断pod是否仍然存在。若是，则执行步骤418，若否，则执行步骤417。步骤417，跳过此pod，继续检查其他pod。步骤418，检查此pod的IP变化情况。步骤419，判断IP是否发生变化。若是，则执行步骤420，若否，则执行步骤421。步骤420，跳过此pod，继续检查其他pod。步骤421，对此pod做二次检查。步骤422，判断无法PING通次数是否超过上限。若是，则执行步骤424，若否，则执行步骤423。步骤423，确定暂时无法通信，等待下轮检查。步骤424，确定此pod无法与外部进行通信。

每个节点设备中的第一监控pod均执行上述流程，以检测各个节点设备中的pod是否能够与集群中任意一个节点设备中的pod进行通信。例如，集群由节点设备A、节点设备B和节点设备C组成，节点设备A设置有pod1、pod2，节点设备B设置有pod3、pod4，节点设备C设置有pod5、pod6，三个节点设备分别创建第一监控poda、第一监控podb和第一监控podc，第一监控poda检测pod1至pod6共6个pod的网络通信情况，第一监控podb检测pod1至pod6共6个pod的网络通信情况，第一监控podc检测pod1至pod6共6个pod的网络通信情况完成对集群中所有节点设备中的pod与任意一个pod的通信监控。

当监控对象为集群中的service，监控内容为检测service的网络连通性时，步骤303包括如下步骤：

步骤303e，获取service监控列表中第i个service的端点集(endpoints)以及端口，endpoints用于指示service对应的pod的访问地址。

在初次启动程序开始监控时，目标节点设备通过服务调查组件(serviceInformer)获取集群中所有的service并放入service监控列表中，后续按照service监控列表进行service监控。

在一种可能的实施方式中，上述步骤303e之后，本申请实施例提供的方法还包括如下步骤：

步骤四，响应于第i个service所属的命名空间不属于指定命名空间或系统命名空间，获取第i个service的服务类型，指定命名空间为跳过service监控的命名空间。

步骤五，响应于第i个service的服务类型属于集群标识服务，获取endpoints。

步骤六，响应于第i个service绑定有endpoints，对第i个service进行网络连通性监控。

目标节点设备会跳过特定命名空间的service，例如集群的系统命名空间以及用户或运维人员指定忽略的命名空间对应的service，并且会跳过特定类型的service。上述步骤四与步骤五并无严格的先后顺序，其顺序可以调换。此外，对于未绑定有endpoints的service，由于其暂时不执行功能操作，因此也不必进行监控。

步骤303f，基于因特网包探索器检测第一监控pod与endpoints对应的pod之间的网络连通性。

第一监控pod遍历第i个service对应的endpoints，测试第i个service后端每个pod的IP地址之间的网络连通性，例如，通过执行PING操作测试网络连通性。

步骤303g，响应于第i个service满足第二网络连通条件，基于远程终端协议检测第一监控pod与端口之间的网络连通性，第二网络连通条件为连续m次检测中与各个pod之间至少一次网络连通成功，m为正整数。

除了进行IP地址的连通性检测，第一监控pod还需检测第i个service对应端口的网络连通性。在一种可能的实时方式中，当连续m次(例如4次)尝试内能够成功连通第i个service对应的所有pod，则继续对端口连通性进行检测，否则进行告警处理并检测下一个service。

示意性的，第一监控pod基于远程终端协议(clusterIP)检测第一监控pod与端口之间的网络连通性，即clusterIP：Port方式。

步骤303h，响应于第i个service满足第三网络连通条件，确定第i个service的监控结果为网络连通正常，对第i+1个service进行网络连通性检测，第三网络连通条件为连续m次检测中存在至少一次网络连通成功。

步骤303i，响应于第i个service不满足第二网络连通条件或第三网络连通条件，确定第i个service的监控结果为网络连通异常。

若同样连续m次的端口检测，第一监控pod能够成功连通第i个service，则确定第i个service的网络连通正常，并继续对第i+1个service进行检测；若第i个service不满足第二网络连通条件或第三网络连通条件，即不满足任意一个条件，则确定第i个service的网络连通异常，继续检查其他service。

图5示出了一种service的检查流程，该流程包括如下步骤：步骤501，在每个节点设备上启动single-check，使用serviceCheck模块开始检测。步骤502，判断程序处于运行状态。若是，则执行步骤503，若否，则结束流程。步骤503，到达预设的周期检查时间点，用serviceInformer获取所有service并放入待检查列表。步骤504，获取待检查列表的当前service。步骤505，判断当前列表是否检查结束。若是，则执行步骤502，若否，则执行步骤506。步骤506，对service进行命名空间忽略检查。步骤507，判断是否属于kube-system或待忽略的namespace。若是，则执行步骤508，若否，则执行步骤509。步骤508，跳过此service，继续检查其它service。步骤509，获取当前service的类型。步骤510，判断类型是否为ClusterIp。若是，则执行步骤512，若否，则执行步骤511。步骤511，跳过此service，继续检查其它service。步骤512，获取当前service的endpoints。步骤513，判断endpoints是否不存在。若是，则执行步骤514，若否，则执行步骤515。步骤514，跳过此service，继续检查其它service。步骤515，遍历endpoints，测试后端每个pod的网络连通性。步骤516，4次尝试内能否连通所有pod。若是，则执行步骤517，若否，则执行步骤518。步骤517，跳过此service，继续检查其它service。步骤518，使用clusterIP：Port进行连通性测试。步骤519，4次尝试内能否连通service。若是，则执行步骤522，若否，则执行步骤520以及步骤521。步骤520，跳过此service，继续检查其它service。步骤521，统一告警处理。步骤522，确定service工作正常，继续其他service检查。

步骤304，响应于监控结果指示监控对象运行异常，向监控终端发送告警信息，告警信息用于指示异常组件以及异常类型。

步骤304的具体实施方式可以参考上述步骤203，本申请实施例在此不再赘述。

本申请实施例中，集群中所有的节点设备均为目标节点设备，各个目标节点设备通过在本地创建第一监控pod，并控制第一监控pod与集群中的所有pod或service进行通信，检查其网络连通性，实现对集群中所有pod以及service网络连通性的监控。

在一种可能的实施方式中，监控内容包括对集群中ingress和节点设备功能完整性的监控(ingressAndNodeCheck)、分布式文件系统(cephfs)挂载情况的监控(cephfsCheck)以及节点设备的资源分配情况(nodeController)，此时目标节点设备为分布式集群中配置有部署内置资源(Deployment)文件的节点设备，监控资源文件为Deployment文件。图6示出了本申请一个示例性实施例提供的Kubernetes组件的监控方法的流程图。本实施例以该方法应用于运行有Kubernetes的分布式集群中的目标节点设备(服务器)为例进行说明，目标节点设备中创建有监控pod，监控pod是基于监控资源文件创建的，分布式集群由至少两个节点设备组成，该方法包括如下步骤。

步骤601，响应于监控内容为ingress以及节点设备的功能完整性，确定监控对象为分布式集群中的节点设备以及ingress。

步骤602，响应于监控内容为节点设备的分布式文件系统cephfs挂载情况，确定监控对象为pod。

步骤603，响应于监控内容为监控节点设备的资源分配情况，确定监控对象为节点设备。

针对上述三种监控内容，集群需要创建一个用于统一监控的pod，即第二监控pod。在一种可能的实施方式中，开发人员可以指定集群中任意一个节点设备运行Deployment，在本地创建第二监控pod，该节点设备即为目标节点设备。

由于对ingress和节点设备的监控流程中存在较多重复步骤以及重复利用的资源，因此本申请实施例将对对ingress和节点设备的监控流程合并，在其它实施方式中也可以分别监控，本申请对此不作限定。

步骤604，响应于达到监控周期，通过第二监控pod与监控对象进行网络通信，确定监控对象的监控结果，第二监控pod是通过运行Deployment文件创建得到的。

对应上述步骤603，当监控对象为ingress和节点设备，监控内容为ingress和节点设备的功能完整性时，步骤604包括如下步骤：

步骤604a，在分布式集群中创建目标ingress、目标service以及目标Deployment，目标Deployment用于在分布式集群的各个节点设备中创建目标pod。

为了监测集群中的ingress功能是否正常，第二监控pod在集群中创建一个ingress，即目标ingress，通过检测目标ingress功能是否完整，确定集群的ingress功能是否完整。ingress功能的实现需要借助service，因此第二监控pod创建目标service，并通过目标Deployment分别在每个节点设备中创建一个目标pod，目标service对应的端点集即为所有的目标pod。

步骤604b，获取各个初始化状态下的目标Pod的数量，初始化状态包括期望创建状态、已创建状态、初始化完成状态和可用状态。

Pod的初始化分为4个状态，第二监控pod获取期望创建数量(desireNumber)、已创建数量(readyNumber)、初始化完成数量(currentNumber)以及可用数量(ValiableNumber)。

步骤604c，响应于各个初始化状态下的目标Pod数量一致，确定分布式集群中节点设备的监控结果为组件功能正常。

当各个节点设备初始化完成后，若节点设备创建以及初始化pod的功能正常，则各阶段对应的pod数量应相同，即所有的目标pod均经历上述四个阶段，因此第二监控pod判断desireNumber、readyNumber、currentNumber以及availableNumber是否相等，若相等，则节点设备的监控结果为组件功能正常，即节点设备功能完整。

步骤604d，响应于各个初始化状态下的目标Pod数量不一致，确定分布式集群中节点设备的监控结果为组件功能异常。

当四个数量中存在至少一个数量与其它数量不等时，确定集群中的节点设备出现功能异常。此时，第二监控pod需进一步确定存在异常的节点设备，以便上报告警信息，因此步骤604d之后，本申请实施例提供的方法还包括如下步骤：

步骤七，检测第二监控pod与各个目标pod之间的网络连接情况，将无法与第二监控pod连通的目标pod所在的节点设备确定为异常节点设备。

第二监控pod遍历所有DaemonSet中的每个目标pod，判断具体哪一个或几个pod无法连通，将无法连通的目标pod所在的节点设备确定为功能异常的节点设备，并进行告警。

第二监控pod首先通过各阶段pod数量判断是否存在异常，若正常则无需与pod进行连通，提高了监控效率，节约了集群的监控资源。

步骤604e，通过目标ingress和目标service，向目标pod发送查询请求，查询请求用于指示目标pod发送节点设备标识(hostname)。

第二监控pod确定节点设备的检测结果后，继续进行ingress检测。检测依据为，ingress和service中记载有各个端点pod的地址，第二监控pod通过查询ingress和service中各个pod的地址，向对应的各个目标pod发送请求，若能得到所有目标pod的正确回应，则证明集群中的ingress功能正常，否则异常告警。

在一种可能的实施方式中，第二监控pod通过目标ingress和目标service，向目标pod发送查询请求，请求各个目标pod反馈其各自对应的hostname，即所在节点设备的主机名称。

步骤604f，响应于通过目标ingress和目标service返回的hostname内容一致，确定分布式集群中ingress的监控结果为组件功能正常。

在一种可能的实施方式中，由于ingress是随机分配集群中的pod响应请求，因此若仅转发一次第二监控pod的查询请求，可能导致部分节点设备中的目标pod未接收到请求，因此第二监控pod可以发送y次查询请求，y为正整数，例如10次，使得请求尽可能覆盖到更多的目标pod。第二监控pod获取y次查询请求后ingress和service通路的返回数据，将其组成无重复集合，若两条通路的hostname集合内容完全一致，则说明集群中的ingress功能正常，完成本轮监控流程，否则确定ingress功能异常。

上述ingress的监控策略，无需依次验证各个目标pod的返回结果是否正确，只需通过发送多次请求，并检测两个通路的返回内容是否一致，即可确定ingress是否存在异常，提高了监控效率，在保证准确性的基础上减少资源损耗。

图7示出了一种ingress和节点设备的监控流程，该流程包括如下步骤：步骤701，在每个节点设备上启动multiple-check，使用ingressAndNodeCheck模块开始检测。步骤702，判断程序处于运行状态。若是，则执行步骤703，若否，则结束流程。步骤703，到达预设的周期检查时间点，开始检查。步骤704，检测集群是否存在上轮检查异常时留下的ingress和service。步骤705，判断组件是否存在。若是，则执行步骤706，若否，则执行步骤707。步骤706，删除组件并重新配置。步骤707，检测集群是否存在上轮检查异常时留下的DaemonSet。步骤708，判断组件是否存在。若是，则执行步骤709，若否，则执行步骤710。步骤709，删除组件并重新配置。步骤710，检查各节点设备上的desireNumber、readyNumber、currentNumber和availableNumber。步骤711，判断四个数据是否相等。若是，则执行步骤715，若否，则执行步骤712。步骤712，集群存在node错误，发出告警。步骤713，遍历DaemonSet的每个pod，确定无法连通的pod。步骤714，确定无法连通的pod所在的node异常，发出告警。步骤715，完成node检查，继续检查ingress。步骤716，获取DaemonSet每个pod返回的hostname。步骤717，获取10倍数量的pod从ingress和service通路返回的hostname，组成无重复集合。步骤718，对比集合内容。步骤719，判断内容是否一致。若是，则执行步骤720，若否，则执行步骤721。步骤720，ingress正常，完成本轮监控。步骤721，ingress异常，发出告警。

此外，当本轮检查结果为ingress和node正常时，删除本轮检测所创建的目标DaemonSet、目标ingress以及目标service。

对应上述步骤603b，当监控对象为pod，监控内容为cephfs挂载情况时，步骤604包括如下步骤：

步骤604g，获取pod监控列表中第i个pod的容器初始化情况。

步骤604h，响应于容器初始化完成，获取第i个pod中各个容器对应的cephfs挂载路径。

由于pod中的容器与cephfs挂载，而获取容器的挂载路径需等待其初始化完成，因此，在一种可能的实施方式中，目标节点设备中的第二监控pod在对集群中第i个pod进行检查之前，获取其容器初始化情况。若第i个pod中所有容器初始化完成，则进行监控。可选的，若预设时长内，第i个pod中容器初始化未完成，则跳过第i个pod，继续对下一个pod进行监控。Pod的容器初始化功能异常能够在pod网络连通性监控过程中发现并告警。

步骤604i，通过第二监控pod进入各个cephfs挂载路径并进行文件查看操作(ls操作)。

ls命令将每个由目录(Directory)参数指定的目录或者每个由文件(File)参数指定的名称写到标准输出，以及所要求的和标志一起的其它信息。如果不指定File或Directory参数，ls命令显示当前目录的内容。

步骤604j，响应于第i个pod对应的各个cephfs挂载路径均正确执行ls操作，确定第i个pod的监控结果为文件挂载正常，并对第i+1个pod进行cephfs挂载路径监控。

若第i个pod对应的所有cephfs挂载路径均能够正确执行ls操作，则说明第i个pod所挂载的cephfs路径均正常，第二监控pod继续对第i+1个pod进行检测。

步骤604k，响应于第i个pod对应有cephfs挂载路径无法正确执行ls操作，确定第i个pod的监控结果为文件挂载异常，删除第i个pod并重新创建pod。

若存在至少一个cephfs挂载路径无法正确执行ls操作，则说明第i个pod存在挂载异常情况。此时第二监控pod能够进行异常处理，即将第i个pod从集群中删除，并重新创建pod，通过新建的pod与cephfs进行重新挂载。同时将此结果进行上报。

图8示出了一种cephfs挂载路径的监控流程，具体包括如下步骤：步骤801，在每个节点设备上启动multiple-check，使用cephfsCheck模块开始检测。步骤802，判断程序处于运行状态。若是，则执行步骤803，若否，则结束流程。步骤803，到达预设的周期检查时间点，使用podInformer获取所有pod放入待检查列表。步骤804，获取当前pod进行检查。步骤805，判断当前列表是否检查结束。若是，则执行步骤802，若否，则执行步骤806。步骤806，获取当前pod挂载的cephName。步骤807，统计cephName个数。步骤808，判断cephName个数是否大于0。若是，则执行步骤809，若否，则执行步骤810。步骤809，检查pod状态。步骤810，获取容器初始化情况。步骤811，判断是否全部容器初始化完成。若是，则执行步骤813，若否，则执行步骤812。步骤812，跳过当前pod，等待下一轮检查并检查下一个pod。步骤813，获取每个容器的ceph挂载路径。步骤814，进入每个挂载路径执行ls操作。步骤815，判断能否全部执行ls操作。若是，则执行不足816，若否，则执行步骤817。步骤816，当前pod挂载正常。步骤817，当前pod存在挂载错误。步骤818，删除当前pod，等待集群重新创建pod并挂载。

对应上述步骤603，当监控对象为节点设备，监控内容为节点设备的资源分配情况时，步骤604包括如下步骤：

步骤604l，通过节点调查组件(nodeInformer)对分布式集群中各个节点设备进行初始化缓存操作，初始化缓存操作用于将节点设备的pod数量初始化为0。

步骤604m，通过容器监控工具为缓存初始化完成的节点设备进行中央处理器(Central Processing Unit，CPU)负载初始化。

监控程序开始运行后，为集群中每个节点设备进行pod初始化以及CPU负载初始化。例如，目标节点设备通过nodeInformer将每个节点设备的当前pod数初始化为0，并通过普罗米修斯等监控工具为每个节点设备初始化当前的CPU负载。

步骤604n，响应于CPU负载初始化完成，通过pod调查组件(podInformer)监听pod事件，pod事件包括pod添加、pod修改以及pod删除。

由于集群中的pod并非稳定的，随时可能发生添加、修改和删除，而每个节点设备其能够管理的pod数有限，当pod数量过多时，该节点设备会存在资源分配异常、运行迟缓等情况。因此目标节点设备中的第二监控pod，创建podInformer，设置添加、修改、删除事件的监控。

步骤604o，响应于分布式集群中存在pod事件，获取pod事件对应的节点设备中所述pod的数量。

第二监控pod等待podInformer监听pod事件，同时，周期性地获取各个节点设备的CPU负载情况，例如通过普罗米修斯监控系统，每10分钟获取一次CPU负载。

当监听到pod事件时，基于pod事件对应的节点设备以及pod事件的类型，更新该节点设备中pod的数量。其中，pod修改事件可能是将一个pod从原节点设备迁移至其它节点设备，因此需要更新涉及到的所有节点设备的pod数量。

步骤604p，响应于节点设备中pod的数量未超过数量阈值，且节点设备的CPU负载比例未超过负载比例阈值，确定节点设备的监控结果为设备资源分配正常。

若pod数量更新后，节点设备中pod的数量未超过数量阈值，并且当前的CPU负载未超过负载比例阈值(例如60％)，则确定该节点设备的监控结果为设备资源分配正常。

步骤604q，响应于节点设备中pod的数量超过数量阈值，或CPU负载比例超过负载比例阈值，确定节点设备的监控结果为设备资源分配异常，并暂停运行节点设备。

若pod数量更新后，节点设备中pod的数量超过数量阈值，或者在CPU负载监控过程中确定CPU负载比例超过比例阈值，则确定该节点设备资源分配异常，并暂停运行该节点设备，等待运维人员接收到告警信息后进行设备维护。

值得注意的是，pod数量监控与CPU负载监控并无严格的先后顺序，二者可同时进行。

图9示出了一种nodeController监控流程，该流程包括如下步骤：步骤901，在每个节点设备上启动multiple-check，使用nodeController模块开始检测。步骤902，使用nodeInformer获取所有node并初始化缓存。步骤903，将每个节点设备的pod数初始化为0。步骤904，利用监控工具为每个节点设备初始化CPU负载。步骤905，创建podInformer，设置pod事件监控。步骤906，判断程序是否运行。若是，则执行不足907，若否，则结束流程。步骤907，等待podInformer监听pod事件。步骤908，周期性地从监控工具中获取节点设备的CPU负载。步骤909，判断是否存在pod创建事件。若是，则执行步骤912，若否则执行步骤910。步骤910，判断是否存在pod修改事件。若是，则执行步骤913，若否，则执行步骤911。911，判断是否存在pod删除事件。若是，则执行步骤914，若否，则执行步骤916。步骤912，为新建pod所在node的pod数加一，更新其pod数。步骤913，为原pod所在node的pod数减一，为新pod躲在node的pod数加一。步骤914，为被删除pod所在node的pod数减一，更新pod数。步骤915，判断pod是否超过预设值。若是，则执行步骤917，若否，则执行步骤918。步骤916，判断CPU负载是否超过预设比例。若是，则执行步骤917，若否，则执行步骤918。步骤917，将node状态设置为cordon。步骤918，将node状态设置为uncordon。

值得注意的是，pod数量监控与CPU负载监控并无严格的先后顺序，二者可同时进行。例如图9中步骤909、步骤910与步骤911可以按一定顺序执行，也可以同步执行，步骤907与步骤908可以按一定顺序执行，也可以同步执行。本申请实施例对此不作限定。

步骤605，响应于监控结果指示监控对象运行异常，向监控终端发送告警信息，告警信息用于指示异常组件以及异常类型。

步骤605的具体实施方式可以参考上述步骤203，本申请实施例在此不再赘述。

本申请实施例中，提供了用于统一监控的pod，能够对集群中ingress和节点设备的功能完整性、分布式文件系统挂载情况以及节点设备的资源分配情况进行自动监控，提高了异常告警的效率以及全面性。

图10是本申请一个示例性实施例提供的图像超分装置的结构框图，该装置应用于运行有Kubernetes的分布式集群中的目标节点设备，该目标节点设备中创建有监控pod，该监控pod是基于监控资源文件创建的，该分布式集群由至少两个节点设备组成，所述装置包括：

第一确定模块1001，用于基于监控内容确定所述监控pod的监控对象，所述监控内容为检测所述监控对象的网络连通性或功能完整性，所述监控对象为部署在所述分布式集群中的Kubernetes组件或设备；

第二确定模块1002，用于通过所述监控pod与所述监控对象进行网络通信，确定所述监控对象对应的监控结果，所述监控结果用于指示所述监控对象的运行状态；

发送模块1003，用于响应于所述监控结果指示所述监控对象运行异常，向监控终端发送告警信息，所述告警信息用于指示异常组件以及异常类型。

可选的，所述目标节点设备为所述分布式集群中的所有节点设备，所述监控资源文件为守护进程内置资源DeamonSet文件；

所述第二确定模块1002，包括：

第一确定单元，用于响应于达到监控周期，通过第一监控pod与所述监控对象进行网络通信，确定所述监控对象的监控结果，所述第一监控pod是通过运行所述DeamonSet文件创建得到的。

可选的，所述第一确定模块1001，包括：

第二确定单元，用于响应于所述监控内容为监控pod的网络连通性，确定所述监控对象为所述分布式集群中的pod；

所述第一确定单元，还用于：

基于因特网包探索器检测所述第一监控pod与第i个pod之间的网络连通性，i为正整数；

响应于所述第i个pod满足第一网络连通条件，确定所述第i个pod的所述监控结果为网络连通正常，对第i+1个pod进行网络连通性检测，所述第一网络连通条件为连续n次检测中至少一次网络连通成功，n为正整数；

响应于所述第i个pod不满足所述第一网络连通条件，且所述第i个pod不存在或所述pod标识改变，忽略/跳过所述第i个pod，对第i+1个pod进行网络连通性检测；

响应于所述第i个pod不满足所述第一网络连通条件，所述第i个pod存在且所述pod标识未发生变化，对所述第i个pod进行二次检测，基于二次检测结果确定所述第i个pod的所述监控结果。

可选的，所述装置还包括：

第一获取模块，用于获取所述第i个pod中容器的初始化进度；

所述第一确定单元，还用于：

响应于所述第i个pod中的所有容器初始化完成，基于所述因特网包探索器检测所述第一监控pod与所述第i个pod之间的网络连通性；

所述装置还包括：

第三确定模块，用于响应于所述第i个pod中存在未初始化的容器，确定所述第i个pod初始化异常并向所述监控终端发送所述告警信息。

可选的，所述第一确定模块1001，包括：

第三确定单元，用于响应于所述监控内容为监控服务组件service的网络连通性，确定所述监控对象为所述分布式集群中的service；

所述第一确定单元，还用于：

获取service监控列表中第i个service的端点集endpoints以及端口，所述endpoints用于指示所述service对应的pod的访问地址；

基于因特网包探索器检测所述第一监控pod与所述endpoints对应的pod之间的网络连通性；

响应于所述第i个service满足第二网络连通条件，基于远程终端协议检测所述第一监控pod与所述端口之间的网络连通性，所述第二网络连通条件为连续m次检测中与各个pod之间至少一次网络连通成功，m为正整数；

响应于所述第i个service满足第三网络连通条件，确定所述第i个service的所述监控结果为网络连通正常，对第i+1个service进行网络连通性检测，所述第三网络连通条件为连续m次检测中存在至少一次网络连通成功；

响应于所述第i个service不满足所述第二网络连通条件或所述第三网络连通条件，确定所述第i个service的所述监控结果为网络连通异常。

可选的，所述装置还包括：

第二获取模块，用于响应于所述第i个service所属的命名空间不属于指定命名空间或系统命名空间，获取所述第i个service的服务类型，所述指定命名空间为跳过service监控的命名空间；

第二获取模块，用于响应于所述第i个service的服务类型属于集群标识服务，获取所述endpoints；

第一监控模块，用于响应于所述第i个service绑定有endpoints，对所述第i个service进行网络连通性监控。

可选的，所述目标节点设备为所述分布式集群中配置有部署内置资源Deployment文件的节点设备；

所述第二确定模块1002，包括：

第四确定单元，用于响应于达到监控周期，通过第二监控pod与所述监控对象进行网络通信，确定所述监控对象的所述监控结果，所述第二监控pod是通过运行所述Deployment文件创建得到的。

可选的，所述第一确定模块1001，包括：

第五确定单元，用于响应于所述监控内容为ingress以及所述节点设备的功能完整性，确定所述监控对象为所述分布式集群中的所述节点设备以及所述ingress；

所述第二确定模块1002，包括：

创建单元，用于在所述分布式集群中创建目标ingress、目标service以及目标Deployment，所述目标Deployment用于在所述分布式集群的各个节点设备中创建目标pod；

第一获取单元，用于获取各个初始化状态下的所述目标Pod的数量，所述初始化状态包括期望创建状态、已创建状态、初始化完成状态和可用状态；

第六确定单元，用于响应于各个初始化状态下的所述目标Pod数量一致，确定所述分布式集群中所述节点设备的所述监控结果为组件功能正常；

第七确定单元，用于响应于各个初始化状态下的所述目标Pod数量不一致，确定所述分布式集群中所述节点设备的所述监控结果为组件功能异常；

发送单元，用于通过所述目标ingress和所述目标service，向所述目标pod发送查询请求，所述查询请求用于指示所述目标pod发送节点设备标识hostname；

第八确定单元，用于响应于通过所述目标ingress和所述目标service返回的所述hostname内容一致，确定所述分布式集群中ingress的所述监控结果为组件功能正常。

可选的，所述装置还包括：

检测模块，用于检测所述第二监控pod与各个目标pod之间的网络连接情况，将无法与所述第二监控pod连通的目标pod所在的节点设备确定为异常节点设备。

可选的，所述第一确定模块1001，包括：

第九确定单元，用于响应于所述监控内容为所述节点设备的分布式文件系统cephfs挂载情况，确定所述监控对象为所述pod；

所述第二确定模块1002，包括：

第二获取单元，用于获取pod监控列表中第i个pod的容器初始化情况；

第三获取单元，用于响应于容器初始化完成，获取所述第i个pod中各个容器对应的cephfs挂载路径；

操作单元，用于通过所述第二监控pod进入各个cephfs挂载路径并进行文件查看操作ls操作；

第十确定单元，用于响应于所述第i个pod对应的各个cephfs挂载路径均正确执行所述ls操作，确定所述第i个pod的所述监控结果为文件挂载正常，并对第i+1个pod进行cephfs挂载路径监控；

第十一确定单元，用于响应于所述第i个pod对应有cephfs挂载路径无法正确执行所述ls操作，确定所述第i个pod的所述监控结果为文件挂载异常，删除所述第i个pod并重新创建pod。

可选的，所述第一确定模块1001，包括：

第十二确定单元，用于响应于所述监控内容为所述节点设备的资源分配情况，确定所述监控对象为所述节点设备；

所述第二确定模块1002，包括：

第一初始化单元，用于通过节点调查组件nodeInformer对所述分布式集群中各个节点设备进行初始化缓存操作，所述初始化缓存操作用于将所述节点设备的pod数量初始化为0；

第二初始化单元，用于通过容器监控工具为缓存初始化完成的节点设备进行中央处理器CPU负载初始化；

监听单元，用于响应于CPU负载初始化完成，通过pod调查组件podInformer监听pod事件，所述pod事件包括pod添加、pod修改以及pod删除；

第四获取单元，用于响应于所述分布式集群中存在所述pod事件，获取所述pod事件对应的节点设备中所述pod的数量；

第十三确定单元，用于响应于所述节点设备中所述pod的数量未超过数量阈值，且所述节点设备的CPU负载比例未超过负载比例阈值，确定所述节点设备的所述监控结果为设备资源分配正常；

第十四确定单元，用于响应于所述节点设备中所述pod的数量超过所述数量阈值，或CPU负载比例超过所述负载比例阈值，确定所述节点设备的所述监控结果为设备资源分配异常，并暂停运行所述节点设备。

请参考图11，其示出了本申请一个示例性实施例提供的服务器的结构示意图，该服务器可以实现成为分布式集群中的节点设备。

其中，服务器1100包括中央处理单元(Central Processing Unit，CPU)1111、随机存取存储器(RandomAccessMemory，RAM)1102和只读存储器(Read-OnlyMemory，ROM)1103的系统存储器1104，以及连接系统存储器1104和中央处理单元1111的系统总线1105。服务器1100还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(Input/Output系统，I/O系统)1106，和用于存储操作系统1113、应用程序1114和其他程序模块1115的大容量存储设备1107。

基本输入/输出系统1106包括有用于显示信息的显示器1108和用于用户输入信息的诸如鼠标、键盘之类的输入设备1109。其中显示器1108和输入设备1109都通过连接到系统总线1105的输入输出控制器1110连接到中央处理单元1111。基本输入/输出系统1106还可以包括输入输出控制器1110以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器1110还提供输出到显示屏、打印机或其他类型的输出设备。

大容量存储设备1107通过连接到系统总线1105的大容量存储控制器(未示出)连接到中央处理单元1111。大容量存储设备1107及其相关联的计算机可读介质为服务器1100提供非易失性存储。也就是说，大容量存储设备1107可以包括诸如硬盘或者光盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)之类的计算机可读介质(未示出)。

不失一般性，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、计算机存储器(Erasable Programmable Read Only Memory，EPROM)、读写存储器(Electrically Erasable Programmable Read Only Memory，EEPROM)、闪存或其他固态存储其技术，CD-ROM、数字通用光盘(Digital Versatile Disc，DVD)或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知计算机存储介质不局限于上述几种。上述的系统存储器1104和大容量存储设备1107可以统称为存储器。

存储器存储有一个或多个程序，一个或多个程序被配置成由一个或多个中央处理单元1111执行，一个或多个程序包含用于实现上述服务器功能的指令，中央处理单元1111执行该一个或多个程序实现上述各个实施例中服务器的功能。

根据本申请的各种实施例，服务器1100还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器1100可以通过连接在系统总线1105上的网络接口单元1111连接到网络1112，或者说，也可以使用网络接口单元1111来连接到其他类型的网络或远程计算机系统(未示出)。

存储器还包括一个或者一个以上的程序，该一个或者一个以上程序存储于存储器中，一个或者一个以上程序包含用于进行本申请实施例提供的由服务器所执行的步骤。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有至少一条指令，所述至少一条指令由处理器加载并执行以实现如上各个实施例所述的Kubernetes组件的监控方法。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方面的各种可选实现方式中提供的Kubernetes组件的监控方法。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读存储介质中或者作为计算机可读存储介质上的一个或多个指令或代码进行传输。计算机可读存储介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种Kubernetes组件的监控方法，其特征在于，所述方法应用于运行有Kubernetes的分布式集群中的目标节点设备，所述目标节点设备中创建有监控分离舱pod，所述监控pod是基于监控资源文件创建的，所述分布式集群由至少两个节点设备组成，所述方法包括：

2.根据权利要求1所述的方法，其特征在于，所述目标节点设备为所述分布式集群中的所有节点设备，所述监控资源文件为守护进程内置资源DeamonSet文件；

所述通过所述监控pod与所述监控对象进行网络通信，确定所述监控对象对应的监控结果，包括：

响应于达到监控周期，通过第一监控pod与所述监控对象进行网络通信，确定所述监控对象的监控结果，所述第一监控pod是通过运行所述DeamonSet文件创建得到的。

3.根据权利要求2所述的方法，其特征在于，所述基于监控内容确定所述监控pod的监控对象，包括：

响应于所述监控内容为监控pod的网络连通性，确定所述监控对象为所述分布式集群中的pod；

所述通过第一监控pod与所述监控对象进行网络通信，确定所述监控对象的监控结果，包括：

4.根据权利要求3所述的方法，其特征在于，所述基于因特网包探索器检测所述第一监控pod与第i个pod之间的网络连通性之前，所述方法包括：

获取所述第i个pod中容器的初始化进度；

所述基于因特网包探索器检测所述第一监控pod与第i个pod之间的网络连通性，包括：

所述方法还包括：

响应于所述第i个pod中存在未初始化的容器，确定所述第i个pod初始化异常并向所述监控终端发送所述告警信息。

5.根据权利要求2所述的方法，其特征在于，所述基于监控内容确定所述监控pod的监控对象，包括：

响应于所述监控内容为监控服务组件service的网络连通性，确定所述监控对象为所述分布式集群中的service；

6.根据权利要求5所述的方法，其特征在于，所述基于因特网包探索器检测所述第一监控pod与所述endpoints对应的pod之间的网络连通性之前，所述方法包括：

响应于所述第i个service所属的命名空间不属于指定命名空间或系统命名空间，获取所述第i个service的服务类型，所述指定命名空间为跳过service监控的命名空间；

响应于所述第i个service的服务类型属于集群标识服务，获取所述endpoints；

响应于所述第i个service绑定有endpoints，对所述第i个service进行网络连通性监控。

7.根据权利要求1所述的方法，其特征在于，所述目标节点设备为所述分布式集群中配置有部署内置资源Deployment文件的节点设备；

响应于达到监控周期，通过第二监控pod与所述监控对象进行网络通信，确定所述监控对象的所述监控结果，所述第二监控pod是通过运行所述Deployment文件创建得到的。

8.根据权利要求7所述的方法，其特征在于，所述监控内容确定所述监控pod的监控对象，包括：

响应于所述监控内容为监控访问权限组件ingress以及所述节点设备的功能完整性，确定所述监控对象为所述分布式集群中的所述节点设备以及所述ingress；

所述通过第二监控pod与所述监控对象进行网络通信，确定所述监控对象的所述监控结果，包括：

在所述分布式集群中创建目标ingress、目标service以及目标Deployment，所述目标Deployment用于在所述分布式集群的各个节点设备中创建目标pod；

获取各个初始化状态下的所述目标Pod的数量，所述初始化状态包括期望创建状态、已创建状态、初始化完成状态和可用状态；

响应于各个初始化状态下的所述目标Pod数量一致，确定所述分布式集群中所述节点设备的所述监控结果为组件功能正常；

响应于各个初始化状态下的所述目标Pod数量不一致，确定所述分布式集群中所述节点设备的所述监控结果为组件功能异常；

通过所述目标ingress和所述目标service，向所述目标pod发送查询请求，所述查询请求用于指示所述目标pod发送节点设备标识hostname；

响应于通过所述目标ingress和所述目标service返回的所述hostname内容一致，确定所述分布式集群中ingress的所述监控结果为组件功能正常。

9.根据权利要求8所述的方法，其特征在于，所述响应于各个初始化状态下的所述目标Pod数量不一致，确定所述分布式集群中所述节点设备的所述监控结果为组件运行异常之后，所述方法还包括：

检测所述第二监控pod与各个目标pod之间的网络连接情况，将无法与所述第二监控pod连通的目标pod所在的节点设备确定为异常节点设备。

10.根据权利要求7所述的方法，其特征在于，所述监控内容确定所述监控pod的监控对象，包括：

响应于所述监控内容为所述节点设备的分布式文件系统cephfs挂载情况，确定所述监控对象为所述pod；

获取pod监控列表中第i个pod的容器初始化情况；

响应于容器初始化完成，获取所述第i个pod中各个容器对应的cephfs挂载路径；

通过所述第二监控pod进入各个cephfs挂载路径并进行文件查看操作ls操作；

响应于所述第i个pod对应的各个cephfs挂载路径均正确执行所述ls操作，确定所述第i个pod的所述监控结果为文件挂载正常，并对第i+1个pod进行cephfs挂载路径监控；

响应于所述第i个pod对应有cephfs挂载路径无法正确执行所述ls操作，确定所述第i个pod的所述监控结果为文件挂载异常，删除所述第i个pod并重新创建pod。

11.根据权利要求7所述的方法，其特征在于，所述监控内容确定所述监控pod的监控对象，包括：

响应于所述监控内容为所述节点设备的资源分配情况，确定所述监控对象为所述节点设备；

通过节点调查组件nodeInformer对所述分布式集群中各个节点设备进行初始化缓存操作，所述初始化缓存操作用于将所述节点设备的pod数量初始化为0；

通过容器监控工具为缓存初始化完成的节点设备进行中央处理器CPU负载初始化；

响应于CPU负载初始化完成，通过pod调查组件podInformer监听pod事件，所述pod事件包括pod添加、pod修改以及pod删除；

响应于所述分布式集群中存在所述pod事件，获取所述pod事件对应的节点设备中所述pod的数量；

响应于所述节点设备中所述pod的数量未超过数量阈值，且所述节点设备的CPU负载比例未超过负载比例阈值，确定所述节点设备的所述监控结果为设备资源分配正常；

响应于所述节点设备中所述pod的数量超过所述数量阈值，或CPU负载比例超过所述负载比例阈值，确定所述节点设备的所述监控结果为设备资源分配异常，并暂停运行所述节点设备。

12.一种Kubernetes组件的监控装置，其特征在于，所述装置应用于运行有Kubernetes的分布式集群中的目标节点设备，所述目标节点设备中创建有监控pod，所述监控pod是基于监控资源文件创建的，所述分布式集群由至少两个节点设备组成，所述装置包括：

13.一种服务器，其特征在于，所述服务器包括处理器和存储器；所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至11任一所述的Kubernetes组件的监控方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一条计算机程序，所述计算机程序由处理器加载并执行以实现如权利要求1至11任一所述的Kubernetes组件的监控方法。