CN116781564A

CN116781564A - 一种容器云平台的网络检测方法和***

Info

Publication number: CN116781564A
Application number: CN202310932548.9A
Authority: CN
Inventors: 蓝维洲; 李冀; 程锐; 颜开; 郭峰; 潘远航; 张红兵
Original assignee: Shanghai Daoke Network Technology Co ltd
Current assignee: Shanghai Daoke Network Technology Co ltd
Priority date: 2023-07-26
Filing date: 2023-07-26
Publication date: 2023-09-19
Anticipated expiration: 2043-07-26
Also published as: CN116781564B

Abstract

本申请涉及云原生技术领域，提供一种容器云平台的网络检测方法和***。容器云平台上部署有网络检测控制器，容器云平台的至少一个节点中对应部署有网络检测代理组件。第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略向指定的目标组件发送检测请求；网络检测策略包括检测请求的请求参数，请求参数用于指定检测请求的发送模式；网络检测控制器基于检测请求对应的响应，生成网络检测结果。由此，通过自定义网络检测资源文件对网络检测任务的请求参数进行定义，由网络检测控制器以及至少一个节点上的网络检测代理组件执行网络检测任务，并基于响应自动生成网络检测结果，实现容器云平台的主动式、自动化、分布式的网络检测。

Description

一种容器云平台的网络检测方法和***

技术领域

本申请涉及云原生技术领域，特别涉及一种容器云平台的网络检测方法、***、计算机可读存储介质和电子设备。

背景技术

随着容器技术的不断发展，企业在生产环境中使用容器云平台来部署和管理容器化部署的应用实例已经成为一种普遍性选择。在容器云平台内部，网络是整个容器云平台正常运行的核心因素之一，一个健康的网络可以确保部署应用实例的容器组之间通信流畅，并确保服务可以高效地对访问请求作出响应。如果网络出现故障，整个容器云平台的工作效率将受到严重影响，并导致应用实例不可用或响应时间变慢。因此，确保网络健康状况良好不仅是企业运维人员的一项非常重要的任务，也是确保应用实例在生产环境中可靠运行的关键因素。

为确保网络的健康运行，需要对网络运行状况进行检测。现有的网络检测方式主要有两种，一种是通过一些辅助的诊断工具来实现周期性的被动式网络检测，该方法主要依赖于采集容器云平台或应用的指标信息来确定整个容器云平台以及各个应用的状态，无法基于不同网络检测需求对网络进行针对性主动检测。另一种是由运维人员根据网络检测需求主动在容器云平台中部署一个应用实例，然后在容器云平台内部或外部向该应用实例发起访问请求，并根据访问请求的响应结果来检验网络的连通性。然而，随着容器云平台规模的增大，不同网络检测的需求也随着增多，网络检测流程日益复杂，现有的通过运维人员手工进行主动检测的方法效率较低，难以快速、自动获得网络检测结果。此外，容器云平台的网络拓扑结构复杂，现有方法难以在短时间内定位故障，无法保证容器云平台在运行过程中的网络连通性和网络性能，导致容器云平台的可靠性受到影响。

因此，亟需一种适用于云原生场景下的有针对性、周期性、自动化、全互联式的网络检测方案，以实现对容器云平台中全方位覆盖检测。

发明内容

本申请的目的在于提供一种容器云平台的网络检测方法、***、计算机可读存储介质和电子设备，以解决或缓解上述现有技术中存在的问题。

为了实现上述目的，本申请提供如下技术方案：

本申请提供了一种容器云平台的网络检测方法，容器云平台上部署有网络检测控制器，所述容器云平台的至少一个节点中对应部署有网络检测代理组件，所述方法包括：

第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略向目标组件发送检测请求；

其中，所述目标组件为所述容器云平台中的任意组件，基于所述自定义网络检测资源文件记载的内容确定，所述网络检测策略至少包括所述检测请求的请求参数，所述请求参数用于指定所述检测请求的发送模式；

所述网络检测控制器基于所述检测请求对应的响应，生成网络检测结果。

上述技术方案中，所述网络检测策略还包括启动时间和执行轮数；

第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略向目标组件发送检测请求，具体为：

所述第一网络检测代理组件在所述启动时间按所述执行轮数重复向所述目标组件发送所述检测请求。

上述技术方案中，所述网络检测策略还包括判定标准；

所述网络检测控制器基于所述检测请求对应的响应，生成网络检测结果之后，还包括：

对所述网络检测结果进行分析，得到网络质量指标数值；

将所述网络质量指标数值与所述判定标准进行比对，以确定所述容器云平台是否处于健康状态。

上述技术方案中，所述第一网络检测代理组件部署在所述容器云平台的第一节点中，所述目标组件为第二网络检测代理组件，所述第二网络检测代理组件部署在所述容器云平台的第二节点中；所述请求参数包括至少一种通信方式，所述通信方式用于定义所述检测请求经由的网络检测路径，所述检测请求为HTTP访问请求；

所述第一网络检测代理组件通过至少一种所述网络检测路径向至少一个所述第二网络检测代理组件的预设API接口发送所述HTTP访问请求。

上述技术方案中，所述通信方式包括容器组IP地址通信、节点端口通信、平台负载均衡通信、平台入口组件通信中的任意一种。

上述技术方案中，所述目标组件为域名解析组件；

所述第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略，向所述域名解析组件发送域名解析请求；所述域名解析请求中的域名为所述第一网络检测代理组件的域名。

本申请实施例提供一种容器云平台的网络检测***，容器云平台上部署有网络检测控制器，所述容器云平台的至少一个节点中对应部署有网络检测代理组件，所述***包括：

发送单元，配置为第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略向目标组件发送检测请求；

响应单元，配置为所述网络检测控制器基于所述检测请求对应的响应，生成网络检测结果。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上任一实施例所述的容器云平台的网络检测方法。

本申请实施例还提供一种电子设备，包括：存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如上任一实施例所述的容器云平台的网络检测方法。

有益效果：

本申请实施例提供的技术方案由容器云平台中部署的网络检测控制器以及各个节点中对应部署的网络检测代理组件协同完成网络检测任务，具体通过自定义网络检测资源文件记载的内容确定需要检测的目标组件，通过网络检测策略定义检测请求的发送模式，网络检测代理组件基于网络检测策略具体执行网络检测任务，再由网络检测控制器基于检测请求的响应生成网络检测结果。由此，使用自定义网络检测资源文件对网络检测任务的目标、时效、检测范围进行定义，运维人员只需根据网络检测的需求创建自定义网络检测资源文件或者对其内容进行更新，即可主动发起网络检测任务，由网络检测代理组件和网络检测控制器按自定义网络检测资源文件记载的网络检测策略自动执行，完成检测后自动生成网络检测结果，实现容器云平台的主动式、自动化的网络检测，进而能够及时、准确地发现、定位网络故障，提高了容器云平台网络的可靠性。

附图说明

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

图1为根据本申请实施例提供的一种容器云平台的网络检测方法的逻辑示意图；

图2为根据本申请实施例提供的一种容器云平台的网络检测方法的流程示意图；

图3为根据本申请实施例提供的使用容器组IP地址通信方式的网络检测方法的逻辑示意图；

图4为根据本申请实施例提供的使用节点端口通信方式的网络检测方法的逻辑示意图；

图5为根据本申请另一实施例提供的使用节点端口通信方式的网络检测方法的逻辑示意图；

图6为根据本申请实施例提供的使用平台负载均衡通信或平台入口组件通信方式的网络检测方法的逻辑示意图；

图7为根据本申请实施例提供的对域名解析组件进行网络检测的逻辑示意图；

图8为根据本申请实施例提供的一种容器云平台的网络检测***的结构示意图；

图9为根据本申请实施例提供的电子设备的结构示意图；

图10为根据本申请实施例提供的电子设备的硬件结构图。

具体实施方式

本公开中，容器云平台是一种基于容器技术的云计算平台，它通过容器云平台的管理***进行管理，允许用户轻松地创建、部署、管理和扩展容器化应用程序，提供一种简化和自动化容器生命周期管理的方式，使开发者和运维团队可以更加专注于应用程序的开发和部署，而无需关注底层的基础设施细节。

具体来说，容器云平台通常包含以下主要组件和功能：

(1)容器运行时(Container Runtime，CR)：常见的容器运行时例如可以是Docker或Containerd，用于在各个节点上创建和管理容器。

(2)编排器(也称为调度器)：容器云平台通常包含一个编排器，用于自动化地调度容器到不同的节点，并确保容器的高可用性和资源利用率。

(3)存储管理：容器云平台支持对容器化应用程序的持久化存储需求，并提供可靠的存储解决方案，如持久卷(Persistent Volume)。

(4)自动扩缩：容器云平台可以根据应用程序的负载自动调整容器的副本数，以实现水平扩展或缩减。

此外，容器云平台还可以包括用于收集运行指标以监控平台运行状态的监控组件、以及用于保证通信安全的权限与安全组件等。

一个具体实现容器云平台的例子是Kubernetes***。Kubernetes***是目前最流行的容器编排器之一，它提供了全面的容器管理功能，支持高度自动化的容器生命周期管理，并可以在多种云服务提供商或私有数据中心中部署。本实施例以Kubernetes***作为示例对技术方案进行说明。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

(1)Kubernetes集群，是部署有Kubernetes***的节点集群，包括多个节点。

(2)CRD(Custom Resource Definition)，是一种Kubernetes API的拓展方式，允许开发人员在Kubernetes集群中创建自定义资源类型，并基于自定义资源类型创建对应的自定义资源(Custom Resource，CR)。这些自定义资源类型可以与现有的Kubernetes资源类型(如Deployments、Pods和Services)一起使用，并且可以通过Kubernetes API访问和管理。

(3)HTTP(Hypertext transfer protocol)，中文名称是超文本传输协议，通过浏览器和服务器进行数据交互，进行超文本(文本、图片、视频等)传输的规定，HTTP协议规定了超文本传输所要遵守的规则。

(4)CNI(Container Network Interface)，是一种用于在容器化环境中管理网络的开放标准。它提供了一组简单的命令行接口，可用于在容器和网络之间建立连接、分配IP地址和配置网络参数；CNI插件是实现CNI接口的软件，用于实际执行网络配置和连接容器的任务。Kubernetes可以使用各种CNI插件来支持不同的网络模型，例如网桥、Overlay网络和VLAN网络等。

(5)Kube-proxy，是Kubernetes集群中的一个组件，它运行在每个节点上，负责在集群中的节点之间转发网络流量，负责实现Kubernetes Service的服务发现和负载均衡功能；同时它提供了反向代理功能，可以将外部流量转发到集群内的服务。例如，如果在集群外部创建了一个指向集群内某个服务的域名，则可以使用Kube-proxy将流量转发到该服务。

(6)控制器(Controller)，通常由一组Go语言编写的程序组成，运行在KubernetesMaster节点上。Controller监控API-Server组件，接收来自API-Server组件的事件和数据，并根据预定义的策略和规则来控制和管理容器化部署的应用实例的运行。

(7)Pod，也称为容器组，是Kubernetes集群中最小的可以被调度的单元，并且是在Kubernetes中部署应用实例的基本单位。Pod可以包含一个或多个容器，并且可以被分配到任意的节点上运行。

(8)Pod IP，是Kubernetes***为每个Pod分配的私有IP地址，该IP地址仅在集群内部可见，用于部署在Pod中的应用实例在集群内部进行网络通信，而不能用于与公共网络或其他外部网络进行通信。

(9)Cluster IP，又称为虚拟IP/集群IP，是Kubernete***为每个服务分配的虚拟IP地址，该IP地址仅在集群内部可见，用于服务之间进行通信。

(10)NodePort，又称为节点端口，是一种特殊的服务类型(Service Type)，对于支持NodePort通信方式的服务，能够将服务的Cluster IP地址和端口号映射到集群中的每个节点上的一个端口号(即NodePort)，以实现使用节点IP地址和NodePort端口号来访问服务。对于不支持NodePort通信方式的服务，则是将服务对应的某个Pod的IP地址和端口号映射到集群中的每个节点上的一个端口号，以实现使用节点IP地址和NodePort端口号来直接访问该Pod。

(11)LoadBalancer，是Kubernetes集群为每个服务分配的一个外部负载均衡器，用于接收外部访问请求，并根据预设的负载均衡策略将外部访问请求分发到集群内服务对应的应用实例。

(12)Ingress，入口组件，是一种特殊的负载均衡器，用于将外部访问请求路由到集群内服务对应的应用实例。

(13)IPv4和IPv6，是两种不同的互联网协议版本，它们用于在计算机之间传输数据。IPv4是早期使用的互联网协议版本，它使用32位的IP地址来唯一标识网络设备。IPv6是之后推出的互联网协议版本，它使用128位的IP地址来唯一标识网络设备。

(14)Full Mesh，全互联式的网络连接，即所有网络通信节点之间都直接相连。

如背景技术所述，为实现网络检测，相关技术通常由运维人员在集群中部署一个应用实例，然后以该应用实例为目标从不同位置发起访问请求进行网络连通测试，或者通过诊断工具辅助实现周期性被动式、周期性的网络检测，然而，随着集群的规模不断扩大，使用上述方案来检验网络的连通性存在以下问题：

1、无法确定导致网络通信失败的通信方式

以Kubernetes为代表的容器云平台为例，为了满足集群内不同场景下的通信需求，Kubernetes提供了容器组IP地址通信(Pod IP)、虚拟IP地址(Custer IP)、节点端口通信(Node Port)、平台负载均衡通信(LoadBalancer)、平台入口组件通信(Ingress)五种通信方式，这五种通信方式都可能出现问题导致网络通信失败，对于使用多种通信方式的Kubernetes集群，即便发现网络通信失败也难以确定出现问题的通信方式。

Pod IP：Pod是Kubernetes集群中最小的可以被调度的单元，Pod IP是Pod被创建时Kubernetes***分配给该Pod的IP地址，部署在不同Pod中的应用实例可以通过Pod IP进行相互访问。由于Pod IP地址是动态分配的，部署在Pod中的应用实例使用Pod IP进行通信时，一旦Pod重启或者发生故障，Pod绑定的IP地址可能会发生变化，导致网络通信故障。

Cluster IP：为了便于Kubernetes集群中的应用实例之间的相互访问，Kubernetes***提供了一种服务发现机制，为每个服务(Service)分配一个虚拟IP地址(即Cluster IP)，将同一Service对应的所有应用实例所在Pod映射到Cluster IP上，能够在Service级别实现负载均衡。Kubernetes集群中的应用实例可以发出指向某一Service的Cluster IP的访问请求，以实现对该Service对应的某个应用实例进行访问。但如果Service没有正常运行或者Service的监听端口设置有误，则应用实例无法通过该Service的Cluster IP对该Service对应的某个应用实例进行访问。此外，如果发出访问请求的应用实例对应的Service的网络策略被配置为受限，则该应用实例无法使用Cluster IP对其它Service进行访问。

NodePort：为了便于外部请求方对部署在Kubernetes集群中的Service进行访问，使用Node节点的静态端口(NodePort)对Kubernetes集群外部暴露某一Service，外部请求方发出的指向NodeIP:NodePort的访问请求会被路由到对应的Service的预设端口，或者被直接路由到该Service对应的某个应用实例的Pod的预设端口，从而实现对该Service对应的某个应用实例进行访问。但如果为Service指定的NodePort已被其它进程占用，或者网络安全组配置错误，导致外部访问请求无法到达指定的NodePort，将导致Service无法对外部访问请求进行正常响应。

LoadBalancer：为了便于外部请求方对部署在Kubernetes集群中的Service进行访问，设置负载均衡器(LoadBalancer)将外部访问请求转发至对应的Service，具体需要为每个Service单独设置一个LoadBalancer和外部访问IP地址。外部请求方发出的指向Service的外部访问IP地址的访问请求会被路由到对应的Service的Cluster IP，从而实现对该Service对应的某个应用实例进行访问。如果LoadBalancer所在节点出现故障或者负载均衡策略配置不正确，将导致Service无法对外部访问请求进行正常响应。

Ingress：鉴于上述LoadBalancer的通信方式需要为每个Service单独设置一个LoadBalancer和外部访问IP地址，成本过高，可以使用Ingress将外部访问请求转发至对应的Service，具体只需为Kubernetes集群设置一个Ingress和外部访问IP地址即可，Ingress能够根据外部访问请求中的URI访问路径将外部访问请求路由至对应的Service的ClusterIP，从而实现对该Service对应的某个应用实例进行访问。此外，Ingress需要由对应的Ingress Controller进行管理才能正常运行。如果Ingress配置不正确或IngressController进程崩溃或者意外退出，将导致Service无法对外部访问请求进行正常响应。

2、无法确定导致网络通信失败的原因

基于前述说明可知，Kubernetes***提供了多种通信方式，每种通信方式的正常运行都需要对应的网络组件保持正常状态，一旦网络组件发生故障，将导致该种通信方式出现问题，而任何一种通信方式出现问题都可能导致整个Kubernetes集群的网络通信失败。具体可以将网络组件发生的故障按外在表现分为功能性故障和偶发性障碍。

其中，功能性障碍指的是网络组件本身工作异常或不能工作，具体表现为不能提供网络转发的能力，导致应用实例一直无法通信，此类故障通常比较容易发现。比如：用于管理容器网络的CNI插件配置错误，导致应用实例无法正确访问其他应用实例或外部网络，或者用于负责转发服务和Pod之间的网络流量的Kube-proxy组件配置错误，导致指向Service的访问请求无法被路由到对应的应用实例，再或者Service、Ingress配置错误，导致应用实例无法正确访问Service对应的某个应用实例。偶发性障碍指的是网络组件本身能够正常工作，但在某些特殊场景下，比如控制面组件发生大量变更、集群规模过大、通信流量过高，会出现偶发的网络转发能力故障，从而导致偶发性的网络通信失败，此类故障发生频次低，难以察觉。

3、网络拓扑复杂度增加导致故障定位困难

随着集群规模的不断增加，一旦出现网络通信失败，运维人员难以在短时间内定位故障，需要进行全互联(Full Mesh)式的网络检测，才能确定所有的故障。

基于前述说明可知，云原生场景下的网络检测方案需要满足以下需求：

(1)要同时支持IPv4、IPv6网络协议和Pod IP、Cluster IP、Node Port、LoadBalancer、Ingress等多种通信方式的网络检测。

(2)被探测的目标应用实例的Pod IP随时可能发生变化，网络检测组件需要能够实时获取目标应用实例的Pod IP。

(3)网络组件本身存在的某些问题可能会引起难以察觉的网络抖动和偶发性网络通信失败，需要及时发现网络组件本身存在的此类问题。

(4)为了能够对Kubernetes集群进行全方位覆盖的网络检测，需要从集群中的所有节点向目标应用实例发出访问请求，确保整个集群内的全量分布式检测。

为此，本申请实施例提供一种适用于云原生场景下的网络检测的容器云平台的网络检测方法、***、计算机可读存储介质和电子设备，该方案利用Kubernetes***的自定义资源定义机制，能够针对不同网络检测需求自动发起主动式、全方位覆盖、全量分布式的网络检测，快速确定网络整体的健康状态，确定导致通信失败的原因以及对故障进行定位，及时掌握容器云平台在运行过程中的网络连通性和网络性能，提升容器云平台的可靠性。

下面将参考附图并结合实施例来详细说明本申请。各个示例通过本申请的解释的方式提供而非限制本申请。实际上，本领域的技术人员将清楚，在不脱离本申请的范围或精神的情况下，可在本申请中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本申请包含归入所附权利要求及其等同物的范围内的此类修改和变型。

在以下描述中，所涉及的术语“第一/第二/第三”仅仅是区别类似的对象，不代表对对象的特定排序，可以理解地，“第一/第二/第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除另有定义，本文所使用的所有的技术和科学术语与属于本公开的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本公开实施例的目的，不是旨在限制本公开。

示例性方法

本申请实施例提供一种容器云平台的网络检测方法，如图1～图7所示，容器云平台上部署有网络检测控制器，容器云平台的至少一个节点中对应部署有网络检测代理组件(Agent，简称代理组件)，该方法包括：

步骤S101、第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略向目标组件发送检测请求。

本实施例中，为对集群的网络健康状态进行检测，在容器云平台(比如Kubernetes集群)中部署有网络检测控制器，网络检测控制器是一种自定义控制器(Controller)，用于对Kubernetes的功能进行扩展，能够根据网络检测的需求实现网络检测的逻辑。

具体来说，参考图1，按照各个节点的作用不同，Kubernetes集群中的节点可以分为控制节点和工作节点，网络检测控制器通常部署在控制节点上，应理解，网络检测控制器也可以部署在工作节点上，本实施例对网络检测控制器的部署位置不作限定。

利用Kubernetes***的自定义资源定义(Custom Resource Definition，简称CRD)机制，本实施例还在Kubernetes集群中引入新的自定义资源类型，即自定义网络检测资源，该自定义网络检测资源通过对应的自定义网络检测资源文件来定义，应理解，根据网络检测任务不同，自定义网络检测资源可以有不同的资源类型，比如自定义网络检测资源可以是用于检测特定范围内某些业务应用网络连通性的AppHttp资源，也可以是用于检测整个集群基础网络连通性的NetHttp资源，也可以是用于检测某个网络组件(比如DNS组件)连通性的NetDNS资源等。通过创建或者更新自定义网络检测资源文件，再由网络检测控制器来创建相应的资源对象(CustomResource，CR)，实现对自定义网络检测资源的管理。

其中，自定义网络检测资源文件可以是YAML(YAML Ain't Markup Language)格式或者JSON格式，这两种格式的文件均是一种人类可读的数据序列化格式文件，其上记载有网络检测策略。其中，网络检测策略是针对具体的网络检测任务需求而定义的，可以包括网络检测任务的目的、时效，检测范围等需求。

网络检测控制器能够根据自定义网络检测资源文件的内容，创建相应属性和规格的自定义网络检测资源对象，并根据网络检测任务的需求在自定义网络检测资源对象的创建、更新和删除事件中写入相应的控制逻辑，在集群运行的过程中，网络检测控制器还能够监控自定义网络检测资源对象的状态，以控制网络检测控制器、网络检测代理组件与自定义网络检测资源对象之间的关联、依赖关系。可以理解地，这些关联、依赖关系可以是相互之间的接口调用关系，也可以是参数传递的关系，本实施例对此不作限定。

本实施例中，网络检测代理组件是为实现网络检测方法而提供的应用程序，其部署在容器云平台的至少一个节点中，用于根据自定义网络检测资源文件记载的网络检测策略，具体执行网络检测任务。

可以理解，第一网络检测代理组件可以是容器云平台中任一节点上部署的网络检测代理组件，也可以是多个节点上部署的网络检测代理组件的集合，也可以是全部节点上部署的网络检测代理组件的集合。这样，当第一网络检测代理组件部署在容器云平台中任一节点上时，可以使用该第一网络检测代理组件向目标组件发送检测请求，以检测二者所在节点以及目标组件与第一网络检测代理组件二者在应用层面的网络连通性。当第一网络检测代理组件是任意多个节点上部署的网络检测代理组件的集合时，可以使用该第一网络检测代理组件检测任意多个节点与目标组件所在节点之间的网络连通性，以及目标组件与第一网络检测代理组件二者在应用层面的网络连通性。

其中，目标组件为容器云平台中的任意组件，目标组件可以基于自定义网络检测资源文件记载的内容确定。可以理解，目标组件的数量可以是一个，也可以是多个，这些组件的类型、所实现的功能可以相同，也可以不同。

由于目标组件基于自定义网络检测资源文件记载的内容确定，运维人员可以根据不同网络检测任务的需求在自定义网络检测资源文件指定不同范围、不同类型的目标组件，进而针对该目标组件的网络连通状况进行全方位检测。

本实施例中，检测请求可以是HTTP访问请求，也可以是TCP请求，还可以是UDP请求，本实施例对检测请求所使用的网络协议不作限定。

示例性地，根据网络检测的目的不同，可以分为网络连通性检测和应用连通性检测。在确定网络连通性的网络检测任务中，可以向目标组件发送基于ICMP协议的控制消息包来确定网络连通状况、节点是否可达、路由是否可用等网络本身的消息，也可以发送其他访问请求来确定应用层的网络连通性。而在应用连通性检测中，通常使用不同参数的HTTP访问请求来确定不同请求方式、不同请求协议下业务应用之间的网络是否畅通、性能是否达到要求。

本实施例中，网络检测策略记录在自定义网络检测资源文件中，其内容是针对网络检测任务需求而定义的，每一个自定义网络检测资源记载有相应的网络检测策略，网络检测策略与一个网络检测任务相对应。也就是说，每个网络检测任务所对应的网络检测策略是根据对应的自定义网络检测资源来确定，本质上是由对应的自定义网络检测资源文件的内容来定义。

为实现不同网络检测任务需求，网络检测策略至少包括检测请求的请求参数，请求参数用于指定检测请求的发送模式。

具体地，不同的发送模式实现的网络检测目标不同，比如将发送模式设定为PodIP检测模式，则第一网络检测代理组件将根据Pod IP直接向目标组件发送检测请求的方式以检测二者之间Pod IP的连通性，又比如将发送模式设定为多网卡检测模式，则第一网络检测代理组件可以使用所在节点上不同的网卡向目标组件的不同网卡发送检测请求，以确定二者之间多块网卡的网络连通性。这里，网络检测代理组件能够根据不同的请求参数，确定不同的发送模式，进而执行不同的网络检测任务。

此外，请求参数作为网络检测策略的组成部分，不同的应用场景，请求参数可能不同，比如为了确定检测请求不同的发送模式，请求参数可以包括检测请求的发送路径、请求主体(http-body)、目标组件所属的命名空间(Namespace)、请求访问的安全认证信息(tlsSecretName)等。这些请求参数以键值对(Key-Value)的方式记载在自定义网络检测资源文件，其中，请求参数的取值可以是字符串、数值、布尔型类型，也可以是存储在容器组指定路径下的文件，例如可以是配置映射文件(ConfigMap文件)。

需要说明的是，配置映射文件是用于存储配置数据的对象，也是一种向容器组中的应用传递配置参数的机制，配置映射文件的内容可以是键值对，也可以嵌套包含其他文件，将配置映射文件挂载到容器中的特定路径后，容器可以读取挂载路径中的配置数据，并将其用于应用程序的配置，供应用程序在容器中使用，实现将应用程序配置信息与容器镜像解耦，使用户可以动态地修改应用程序的配置，而无需重新构建镜像的目的。本实施例中，配置映射文件可以用于定义复杂的网络检测任务，并将复杂的配置信息传入到网络检测代理组件所在的容器组中，以供网络检测代理组件执行时使用，比如，配置映射文件可以通过定义HTTP请求主体的内容来执行以BUG复现为目标的网络检测，即通过在配置映射文件定义HTTP请求主体，网络检测代理组件可以向目标组件注入可能复现其BUG的检测请求，观察目标组件对这些检测请求的处理结果，以定位BUG发生的位置以及发生的原因。另一场景中，可以在配置映射文件中定义E2E(End to End)测试流程，利用网络检测代理组件实现E2E测试，或者，还可以定义随机测试的参数，以实现混沌测试的效果。

作为一个示例，以AppHttp资源为例，自定义网络检测资源文件的内容可以如下：

各个字段含义如下：

apiVersion：指定Kubernetes API的版本；

kind：资源类型，这里AppHttp，表示创建一个AppHttp的自定义网络检测资源；

metadata：定义了自定义网络检测资源的元数据，包括名称(name)等信息；

spec:指定自定义网络检测资源的规格和属性，即配置网络检测策略；

spec.request：规定了网络检测任务的性能要求指标；

spec.request.durationInSecond：定义了一轮网络检测任务的最长持续时间(秒)；

spec.request.perRequestTimeoutInMS：定义了请求超时阈值，单个HTTP访问请求的最长持续时间；

spec.request.qps：定义了每秒响应的最小访问请求数量；

spec.schedule：定义了网络检测任务的执行方式；

spec.schedule.roundNumber：定义了网络检测任务需要执行的轮数；

spec.schedule.roundTimeoutMinute：定义了单个网络检测请求的最长持续时间；

spec.expect：定义了期望的网络检测结果；

spec.expect.meanAccessDelayInMs：平均响应时间的合理阈值；

spec.expect.successRate：通信成功率阈值；

spec.expect.statusCode：通信成功的状态码；

spec.target：请求参数；

spec.target.bodyConfigmapName：请求主体的Configmap文件名称；

spec.target.bodyConfigmapNamespace：请求主体的Configmap文件所在的命名空间。

本实施例中，由于网络检测策略记载在自定义网络检测资源文件中，且请求参数的取值可以灵活定制，运维人员只需创建或者修改自定义网络检测资源文件的内容，即可启动或者更新一个网络检测任务，进而由网络检测代理组件根据网络检测策略自动地执行这些复杂的网络检测任务，实现主动式、自动化的网络检测。

应理解，目标组件或者实现网络通信的各个网络组件本身存在的某些问题可能会引起难以察觉的网络抖动和偶发性网络通信失败，需要及时发现各个组件本身存在的此类问题。为此，一些实施例中，网络检测策略还包括启动时间和执行轮数；第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略向目标组件发送检测请求，具体为：第一网络检测代理组件在启动时间按执行轮数重复向目标组件发送检测请求。

其中，启动时间指的是网络检测任务的启动时间，即何时发起一次网络检测任务，执行轮数则是网络检测任务需要重复执行的次数。可选地，还可以在网络检测策略中定义每一轮网络检测任务之间的执行间隔，进一步地，可以设置默认的执行间隔，比如间隔2分钟执行一轮。这样，第一网络检测代理组件就可以在启动时间开始执行第一轮网络检测，然后间隔2分钟再执行第二轮网络检测，以此类推，直至到达执行轮数的要求。

通过上述设定，一方面可以在指定的时间自动执行网络检测任务，生成网络检测结果，无需运维人员干涉，另一方面，企业生产环境中，网络检测的执行不可避免地对业务访问产生一定的影响，通过启动时间的设定，可以将网络检测任务的执行时间与业务应用的高峰时间段错开，避免对业务应用造成不利影响。通过启动时间和执行轮数来指定检测请求开始发送的时间以及重复发送的次数，还能够避免网络抖动造成的检测结果失真，使网络检测的结果更加符合实际情况。

应理解，在不同的网络健康状态下一轮网络检测任务所需执行的时间可能不同，为此，还可以在网络检测策略中设置任务超时阈值，即当第一网络检测代理组件在启动时间向目标组件发出检测请求后，记录网络检测结果和执行本轮网络检测任务所需的时间，当该时间大于设置的任务超时阈值，则判定本轮网络检测任务失败，停止执行后续网络检测任务轮数，以节约资源。

由于业务应用在应用通信的复杂性，生产实践中通常需要针对应用层进行全方位的网络检测，为此，一些实施例中，第一网络检测代理组件部署在容器云平台的第一节点中，目标组件为第二网络检测代理组件，第二网络检测代理组件部署在容器云平台的第二节点中；请求参数包括至少一种通信方式，通信方式用于定义检测请求经由的网络检测路径，检测请求为HTTP访问请求。第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略向目标组件发送检测请求，具体为：第一网络检测代理组件通过至少一种网络检测路径向至少一个第二网络检测代理组件的预设API接口发送HTTP访问请求。

本实施例中，检测请求为HTTP访问请求，即网络检测使用HTTP协议进行通信。HTTP协议是用于在客户端和服务器之间传输超文本和其他资源的协议，HTTP访问请求运行在网络通信的应用层级别，通过逐层的封装和处理，通过底层网络传输到服务器，并返回响应数据到客户端。也就是说，使用HTTP进行通信的前提是底层网络能够正常连通，任意两两节点之间的网络检测代理组件基于HTTP协议使用请求-响应模型进行通信来执行网络检测，既可以确定基础网络是否处于健康状态，也可以确定应用层的网络状态，进而实现全面检测网络的健康状态。

具体地，参见图1，第一网络检测代理组件作为发起检测请求的网络检测代理组件，其部署在第一节点上，第一节点可以是工作节点1，也可以是工作节点2，还可以是工作节点3上，或者是任意多个工作节点。目标组件是第二网络检测代理组件，作为接收检测请求的组件，其部署在集群中的第二节点上。

应当理解，当目标组件为第二网络检测代理组件时，每个网络检测代理组件会将自身的Pod IP上报给网络检测控制器，再由网络检测控制器将所有网络检测代理组件的Pod IP同步至每个网络检测代理组件，以便第一网络检测代理组件向第二网络检测代理组件发送检测请求。当网络检测代理组件的Pod IP发生变化时，立即将变化后的Pod IP上报给网络检测控制器，并同步给其他网络检测代理组件，使得第一网络检测代理组件能够实时获取第二网络检测代理组件的Pod IP。

一些具体实现中，第二节点可以是除第一节点以外的所有其他节点，这样，第一节点上的第一网络检测代理组件向所有其他节点上的第二网络检测代理组件发送检测请求，在部署网络检测代理组件的所有节点之间形成全互联式网络连接，实现所有节点的全方位覆盖检测。

其中，当目标组件是第二网络检测代理组件时，第一网络检测代理组件与第二网络检测代理组件是基于发送方与接收方的不同而定义的，可以理解，同一个节点上的网络检测代理组件既可以是检测请求的发送方，也可以是检测请求的接收方，当网络检测代理组件作为发送检测请求一方时，将其称为第一网络检测代理组件，当作为接收检测请求一方时，称为第二网络检测代理组件。检测请求的发送与接收在网络检测代理组件之间进行，第二网络检测代理组件通过预设API接口接收检测请求后，根据网络检测目的做出响应，并将响应结果返回给第一网络检测代理组件。

进一步地，由于检测请求的发送与接收是在网络检测代理组件之间进行，可以在网络检测策略中设置选择器(selector)参数，用于指定第一节点的范围，进而限定第一网络检测代理组件，此时，可以实现指定节点范围内的网络连通性检测。

基于前述说明可知，集群中网络的通信方式可能有多种，本实施例中，请求参数包括至少一种通信方式，通信方式用于定义检测请求经由的网络检测路径。执行网络检测时，由第一网络检测代理组件根据请求参数所指定的通信方式，通过至少一种网络检测路径向第二网络检测代理组件的预设API接口发出HTTP访问请求，并将网络检测结果发送至网络检测控制器，由网络检测控制器基于汇总后的网络检测结果判定网络是否处于健康状态，实现对容器云平台中不同网络路径的网络性能的检测。

一些实施例中，通信方式包括容器组IP地址(Pod IP)通信、节点端口(NodePort)通信、平台负载均衡(LoadBalancer)通信、平台入口(Ingress)组件通信中的任意一种。

下面具体说明第一网络检测代理组件使用不同通信方式发送HTTP访问请求的过程。

图3示出了使用Pod IP的通信方式发送HTTP访问请求的一个示例。如图3所示，网络检测代理组件部署在容器组中，当第一网络检测代理组件使用Pod IP向第二网络检测代理组件发送HTTP访问请求时，HTTP访问请求指向第二网络检测代理组件所在容器组的容器组端口。

需要说明的是，当使用NodePort的通信方式发送HTTP访问请求时，根据第二网络检测代理组件是否同样支持NodePort类型服务，HTTP访问请求经由的网络路径也不同。

图4示出了使用节点端口(NodePort)通信方式发送HTTP访问请求的一个示例。如图4所示，当使用NodePort向不支持NodePort类型服务的第二网络检测代理组件发送HTTP访问请求时，HTTP访问请求指向第二网络检测代理组件所属服务绑定的NodeIP(节点IP)：NodePort，进而直接路由至第二网络检测代理组件所在容器组的容器组端口。

图5示出了使用节点端口通信方式发送HTTP访问请求的另一个示例。如图5所示，当第一网络检测代理组件使用NodePort向支持NodePort类型服务的第二网络检测代理组件发送HTTP访问请求时，HTTP访问请求指向第二网络检测代理组件所属服务绑定的NodeIP：NodePort，接着被路由至第二网络检测代理组件所属服务的预设端口，最后基于服务的负载均衡机制发送至第二网络检测代理组件所在容器组的容器组端口。

图6示出了使用平台负载均衡通信或平台入口组件通信方式发送HTTP访问请求的一个示例。如图6所示，当第一网络检测代理组件使用负载均衡/Ingress向第二网络检测代理组件发送HTTP访问请求时，HTTP访问请求指向第二网络检测代理组件所属服务的外部访问IP地址和外部访问端口，接着被路由至第二网络检测代理组件所属服务的Cluster IP和预设端口，最后被路由至第二网络检测代理组件所在容器组的容器组端口。

由此可见，不同的通信方式，HTTP访问请求所经由的网络检测路径均不同，本实施例中，由于请求参数包括至少一种通信方式，第一网络检测代理组件能够基于请求参数向第二网络检测代理组件发送HTTP访问请求，使得HTTP访问请求按照所指定的网络检测路径到达第二网络检测代理组件的预设API接口，这样，通过请求参数控制HTTP访问请求经由的网络路径，并记录HTTP访问请求经由这些网络路径时的网络连通性和网络性能，实现任意网络路径全量分布式、全自动、主动的网络检测。

一些实施例中，网络检测代理组件部署在容器云平台的所有节点上，或者，网络检测代理组件部署在容器云平台的指定节点上。

具体地，本实施例中，既可以采用DeamonSet形式将网络检测代理组件部署在容器云平台的所有节点上，也可以采用Deployment形式将网络检测代理组件部署在容器云平台的指定节点上，两种部署的方式包括的节点范围不同，网络检测的范围也不同。

采用DeamonSet形式进行部署时，DeamonSet控制器会在Kubernetes集群中的每个节点中部署网络检测代理组件，进而能够对所有节点的网络进行检测。而采用Deployment形式进行部署时，只会在Kubernetes集群中的指定节点中部署网络检测代理组件，能够对指定节点的网络进行检测。

也就是说，本实施例提供的方法中，Kubernetes集群中部署了自定义网络检测资源(比如NetHttp资源)，同时在Kubernetes集群中以Deployment形式部署了对应的网络检测控制器(Controller)，还以DeamonSet形式在所有节点上(或者以Deployment形式在指定节点上)部署了对应的网络检测代理组件(Agent)，由此形成整个网络检测***的基本架构，用于实现不同的网络检测任务。

需要说明的是，要实现在整个集群内进行全互联(Full Mesh)式的网络检测，需要采用DeamonSet形式进行部署，而在某些场景下，仅需对部分可能存在问题的节点进行网络检测，只需采用Deployment形式进行部署即可，能够节省检测时间和网络资源。

作为一个示例，以NetHttp资源为例，本实施例中的自定义网络检测资源文件的内容可以如下：

/>

以上是用于创建NetHttp资源的配置文件内容，各个字段含义如下：

spec.schedule：定义了网络检测任务的执行参数，其中：

roundNumber：定义了网络检测任务需要执行的轮数；

intervalMinute：定义了每一轮网络检测任务之间的执行间隔；

startAfterMinute：定义了网络检测任务延时执行的时长(分钟)；

timeoutMinute：定义了网络检测任务的最长执行时间，如果网络检测任务执行超时，则判定此次网络检测结果为网络存在故障。

spec.request：规定了网络检测任务的性能要求指标，其中：

durationInSecond：定义了一轮网络检测任务的最长持续时间(秒)；

perRequestTimeoutInMS：定义了请求超时阈值，单个HTTP访问请求的最长持续时间；

qps：定义了第二网络检测代理组件每秒响应的最小访问请求数量。

spec.target.targetAgent：指定了探测第二网络检测代理组件使用的网络通信方式，其中：

testEndpoint：表示是否需要向集群中的第二网络检测代理组件通过Endpoint的方式发送HTTP访问请求；

testIPv4：表示是否需要探测IPv4地址；

testIPv6：表示是否需要探测IPv6地址；

testClusterIp：表示是否需要向集群中以Cluster IP方式提供服务的第二网络检测代理组件发送HTTP访问请求；

testIngress：表示是否需要向集群中以Ingress方式提供服务的第二网络检测代理组件发送HTTP访问请求；

testNodePort：表示是否需要向集群中以NodePort方式提供服务的第二网络检测代理组件发送HTTP访问请求；

testLoadBlancer：表示是否需要向集群中以testLoadBlancer方式提供服务的第二网络检测代理组件发送HTTP访问请求。

spec.success：定义了集群网络性能的判定条件，其中：

meanAccessDelayInMs：定义了平均响应时间的合理阈值，如果HTTP访问请求的实际平均响应时间超过此阈值，则判定此次网络检测结果为网络存在故障；

successRate：定义了HTTP访问请求的通信成功率阈值，如果HTTP访问请求的通信成功率小于此阈值，则判定此次网络检测结果为网络存在故障。

spec.status：记录了网络检测任务的执行状态，其中：

doneRound：表示网络检测任务执行完毕的轮数；

expectedRound：表示网络检测任务期望执行的轮数；

finish：表示网络检测任务是否已经执行完毕；

lastRoundStatus：表示上一轮网络检测任务的执行状态；

history：是一个数组，用于记录网络检测任务的历史执行结果。

将上述NetHttp资源文件部署至Kubernetes集群，当网络检测控制器(Controller)通过API-Server组件监听到上述的NetHttp资源文件被创建，会根据spec.schedule字段记载的内容获取网络检测任务的执行参数(比如上述的NetHttp资源文件中的spec.schedule字段定义了网络检测任务将于2分钟后开始，每轮执行间隔为2分钟，最长执行时间为1分钟，共需执行两轮)，并将spec.schedule字段记载的网络检测任务的执行参数同步至spec.status字段中。

而集群中所有的网络检测代理组件通过API-Server组件监听到NetHttp资源文件被创建，则会在指定的时间点(2分钟以后)开始执行网络检测任务，所有网络检测代理组件会通过Pod IP、Cluster IP、Node Port、Ingress方式向其他网络检测代理组件发出HTTP访问请求，请求的API为网络检测代理组件提供的专门用来做网络检测的API，由此实现基于HTTP协议的网络全方位检测。

应理解，集群中包括多种类型的网络组件，比如CNI组件、DNS组件等，这些网络组件本身工作异常或不能工作，将会导致网络产生故障。比如DNS组件，应用程序访问DNS组件进行域名解析对于应用程序的正常运行至关重要，但应用程序访问DNS组件的过程中，可能存在以下问题：DNS组件出现故障或者配置错误，导致DNS组件无法对域名解析请求进行响应；DNS组件性能不足或者资源配置不当，导致DNS组件在对大量域名解析请求进行响应时，出现不可用或响应延迟较高的情况；CNI组件未能为DNS组件分配IP地址，导致DNS组件无法正常工作。针对DNS组件的功能和性能检测，相关技术中采用Nslookup、Dig、DNSperf等传统DNS检测工具来实现，但这些检测工具都是单机测试，无法模拟真实的多用户、高并发的场景，并且无法对DNS组件进行安全性和可靠性测试。

为此，本申请一些实施例提供的方法中，目标组件为域名解析组件(DNS组件)；第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略向目标组件发送检测请求，具体为：第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略，向域名解析组件发送域名解析请求；域名解析请求中的域名为第一网络检测代理组件的域名。

应理解，域名解析组件可以是为容器云平台本身提供的用于整个平台域名解析服务的DNS组件，也可以是用户自定义、并部署在容器云平台上仅用于部分应用的DNS组件，本实施例对此不做限定。

在一种实施方式中，自定义网络检测资源可以是自定义域名解析网络检测资源，比如NetDNS资源。该资源用于定义域名解析网络检测任务相应的网络检测策略。相应地，网络检测控制器可以具体为域名解析网络检测控制器，用于管理和控制自定义域名解析网络检测资源的状态。

为实现对DNS组件的网络检测，本实例中，网络检测策略可以包括：DNS组件的标识；DNS组件的访问地址和端口，即发送域名解析请求的目的地址和端口；域名解析请求所采用的IP地址协议(IPv4或者IPv6)以及通信协议(TCP、UDP)。

作为一个示例，NetDNS资源文件的内容可以如下：

各个字段含义如下：

apiVersion：NetDNS资源对象的API版本。

kind：NetDNS资源对象的类型。

metadata：元数据对象，包含NetDNS资源对象的基本信息，例如名称和标签等，其中metadata.name表示了该NetDNS资源对象的名称。

spec：定义了域名解析网络检测任务的执行要求，即网络检测策略。

spec.schedule：定义了网络检测任务的执行方式，其中：

startAfterMinute：定义了域名解析网络检测任务延时执行的时长(分钟)；

roundNumber：定义了域名解析网络检测任务需要执行的轮数；

intervalMinute：定义了每一轮域名解析网络检测任务之间的执行间隔；

timeoutMinute：定义了域名解析网络检测任务的最长执行时间，如果域名解析网络检测任务执行超时，则判定此次域名解析网络检测结果为网络存在故障。

spec.request：规定了域名解析网络检测任务的性能要求指标，其中：

testIPv4：表示是否需要测试IPv4网络的连通性；

testIPv6：表示是否需要测试IPv6网络的连通性；

durationInSecond：定义了一轮域名解析网络检测任务的持续时间(秒)；

qps：定义了DNS组件每秒响应的最小访问请求数量；

perRequestTimeoutInMS：定义了单个域名解析请求的最长持续时间。

spec.protocol：定义了域名解析请求所使用的协议，可以是TCP或UDP。

spec.success：定义了域名解析网络连通性和域名解析组件性能的判定条件，其中：

successRate：定义了域名解析的请求成功率阈值，如果域名解析的请求成功率大于此阈值，则判定此次域名解析网络检测结果为网络处于健康状态；

meanAccessDelayInMs：定义了平均响应时间的合理阈值，如果域名解析请求的实际平均响应时间超过此阈值，则判定此次域名解析网络检测结果为网络性能存在问题。

本实施例中，第一网络检测代理组件基于上述网络检测策略，使用TCP或者UDP协议向域名解析组件的访问地址(IPv4或者IPv6)和端口发送域名解析请求，并将第一网络检测代理组件的域名作为请求解析的域名，这样，就能够根据域名解析的反馈确定域名解析组件是否处于健康状态。

图7示出了对域名解析组件进行网络检测的一个示例。如图7所示，在对域名解析组件进行网络检测时，集群可以包括自定义域名解析网络检测资源文件(NetDNS资源文件)，以Deployment形式部署的域名解析网络检测控制器和以DeamonSet形式在所有节点上部署的网络检测代理组件。

部署在所有节点(或指定节点)上的网络检测代理组件(第一网络检测代理组件)通过API-Server组件对Kubernetes集群中NetDNS资源的变化事件进行监听，当监听到Kubernetes集群中新增NetDNS资源或者已有的NetDNS资源被修改，也就是新的NetDNS资源文件被创建或者已有的NetDNS资源文件的内容被修改，则根据NetDNS资源文件的内容所定义的域名解析网络检测要求执行域名解析网络检测任务，即按照TCP或UDP中的至少一种协议向域名解析组件发出域名解析请求，域名解析请求所使用的域名为自身的域名，以检测域名解析组件网络是否处于健康状态。

步骤S102、网络检测控制器基于检测请求对应的响应，生成网络检测结果。

实际中，网络检测任务至少包括一轮网络检测，每轮网络检测进行时，第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略，按照一定的速率主动向目标组件发送检测请求，并根据网络检测策略中定义的检测请求的性能指标以及通信成功的状态码，实时判定本次检测请求的响应是否符合预设的性能和功能需求。

其中，检测请求的发送速率可以根据需要来设定，比如，在网络检测初期，由于未确定网络连通状况，可以使用较低的速率发生检测请求，排除网络功能性障碍后，可以使用较高的速率发送检测请求，以判断网络的承压能力以及性能。

应理解，每轮网络检测可能包括发送一次或多次检测请求，在每轮网络检测后，每个第一网络检测代理组件将会记录本轮所有的检测请求对应的响应，网络检测控制器根据所有网络检测代理组件的记录生成网络检测结果。

一些实施例中，网络检测策略还包括判定标准；网络检测控制器基于检测请求对应的响应，生成网络检测结果之后，还包括：对网络检测结果进行分析，得到网络质量指标数值；将网络质量指标数值与判定标准进行比对，以确定容器云平台是否处于健康状态。

具体地，网络质量指标数值，可以包括通信成功率和平均响应时间。

对网络检测结果进行分析，得到网络质量指标数值，可以通过如下方式实现：将网络检测结果中的每一次检测请求所返回的响应状态码与通信成功的状态码进行比对，若二者符合预设条件，则判断该次通信成功，否则通信失败，进一步进行汇总得到该轮网络检测的通信成功率；将网络检测结果中的所有检测请求所需的响应时间进行求均值运算，得到平均响应时间，由通信成功率和平均响应时间构成该轮网络检测相应的网络质量指标数值。

示例性地，当检测请求为HTTP访问请求时，可以依据HTTP响应的状态码进行计算生成HTTP访问请求的通信成功率，根据访问请求响应的平均耗时来计算HTTP访问请求的平均响应时间。

其中，HTTP协议的状态码用三位数字来表示不同的错误，共有五种类别，分别是1XX，2XX，3XX，4XX，5XX。1XX类状态码信息表示临时的响应。客户端在收到常规响应之前，应准备接收一个或多个1xx响应。2xx类状态码信息表示服务器成功地接受了客户端请求。3xx类状态码信息表示：客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求。4xx类状态码信息表示：发生错误，客户端似乎有问题。例如，客户端请求不存在的页面，客户端未提供有效的身份验证信息。5xx类状态码信息表示：服务器由于遇到错误而不能完成该请求。可见状态码为2xx类或3xx类时，服务处于健康状态，对所有HTTP响应的状态码的类型进行统计即可计算出HTTP访问请求的通信成功率。

平均响应时间指多次HTTP访问请求响应的平均耗时，其中，一次HTTP访问请求的响应时间可以包括：解析域名获取服务器的IP地址所花费的时间、与目标组件建立连接所花费的时间、将HTTP访问请求传输到目标组件所花费的时间、等待目标组件处理请求并返回响应的时间等。这样，通过HTTP访问请求的通信成功率和平均响应时间来判断网络的连通性以及网络的质量。

又比如，当目标组件为域名解析组件时，可以依据DNS的应答状态码进行计算生成域名解析的通信成功率。DNS的应答状态码包括五种，分别是0、1、2、3、4、5，分别代表查询请求成功完成(NOERROR)、查询请求格式错误(FORMERR)、服务端处理失败(SERVFAIL)、请求查询的域名不存在(NXDOMAIN)、功能未实现(NOTIMP)、服务端拒绝回复该查询(REFUSED)，可见应答状态码为0时，域名访问请求成功，对所有域名解析请求的应答状态码进行统计即可计算出域名解析的请求成功率，当域名解析的请求成功率高于合理阈值，则判定域名解析网络处于健康状态。

本实施例中，判定标准用于定义集群网络功能或性能的判定条件，比如，可以包括平均响应时间的合理阈值、通信成功率阈值、通信成功的状态码等。

将网络检测任务执行后生成的通信成功率、平均响应时间与判断标准中的平均响应时间的合理阈值、通信成功率阈值进行比对，就可以确定容器云平台是否处于健康状态。

需要说明的是，第一网络检测代理组件向目标组件发出检测请求，只有当第一网络检测代理组件与目标组件之间的网络连通，第一网络检测代理组件才能收到响应，再进一步根据响应中的状态码判定应用通信或者域名解析是否成功。而如果第一网络检测代理组件超过预设时长(比如20秒)未收到响应，则说明第一网络检测代理组件与目标组件之间的网络不通，即可判定第一网络检测代理组件所在节点的网络存在故障。

此外，若网络检测任务是对域名解析网络进行检测，由于域名解析请求所使用的域名是第一网络检测代理组件自身的域名，所以，还可以对应答码为0的响应进行进一步检验，如果响应的IP地址为第一网络检测代理组件自身的IP地址，则说明域名解析组件完全正常，如果响应的IP地址不是第一网络检测代理组件的IP地址，则说明域名解析组件功能不正常，存在被第三方入侵的可能，需要进一步排查。这样，依据第一网络检测代理组件在预设时长内是否收到响应来判定域名解析网络的连通性，依据响应的应答状态码来判定域名解析组件的功能是否正常，依据响应的IP地址来判定域名解析组件是否安全，依据平均响应时间来判定域名解析网络或者域名解析组件的性能是否存在问题，实现了对域名解析网络和DNS组件的连通性、功能、性能的全方位检测。

综上，本申请实施例中，容器云平台上部署有网络检测控制器，容器云平台的至少一个节点中对应部署有网络检测代理组件。第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略向目标组件发送检测请求；其中，目标组件为容器云平台中的任意组件，基于自定义网络检测资源文件记载的内容确定，网络检测策略至少包括检测请求的请求参数，请求参数用于指定检测请求的发送模式；网络检测控制器基于检测请求对应的响应，生成网络检测结果。由此，利用容器云平台提供的自定义资源定义机制，以CRD资源的形式在容器云平台中引入新的自定义资源类型，通过自定义网络检测资源文件对网络检测任务的目标、时效、检测范围进行定义，运维人员只需创建自定义网络检测资源文件或者对其内容进行更新，即可主动发起网络检测任务，由各个节点上的网络检测代理组件以及网络检测控制器按自定义网络检测资源文件记载的网络检测策略自动执行网络检测任务，并在检测后自动生成网络检测结果，实现容器云平台的主动式、自动化、全量分布式的网络检测。

本申请实施例提供了一种适用于云原生场景的周期性、自动化的网络检测方法，只需对自定义网络检测资源中特定字段进行修改即可对网络检测任务的相关参数进行配置，能够支持检测所有节点、所有网络路径、所有网络协议的连通性，实现网络检测的全方位覆盖。

示例性***

本申请实施例提供一种容器云平台的网络检测***，在容器云平台上部署有网络检测控制器，容器云平台的至少一个节点中对应部署有网络检测代理组件，如图8所示，该***包括：发送单元801、响应单元802。其中：

发送单元801，配置为第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略向目标组件发送检测请求。

其中，目标组件为容器云平台中的任意组件，基于自定义网络检测资源文件记载的内容确定，网络检测策略至少包括检测请求的请求参数，请求参数用于指定检测请求的发送模式。

响应单元802，配置为网络检测控制器基于检测请求对应的响应，生成网络检测结果。

本申请实施例提供的容器云平台的网络检测***能够实现上述任一实施例提供的容器云平台的网络检测方法的步骤、流程，并达到相同的技术效果，在此不再一一赘述。

示例性设备

图9为根据本申请的一些实施例提供的电子设备的结构示意图；电子设备上运行有容器云平台的管理***，该***用于管理容器云平台，容器云平台上部署有网络检测控制器，容器云平台的至少一个节点中对应部署有网络检测代理组件，如图9所示，该电子设备包括：

一个或多个处理器901；

计算机可读存储介质，可以配置为存储一个或多个程序902，一个或多个处理器901执行一个或多个程序902时，实现如下步骤：第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略向目标组件发送检测请求；其中，目标组件为容器云平台中的任意组件，基于自定义网络检测资源文件记载的内容确定，网络检测策略至少包括检测请求的请求参数，请求参数用于指定检测请求的发送模式；网络检测控制器基于检测请求对应的响应，生成网络检测结果。

图10为根据本申请的一些实施例提供的电子设备的硬件结构；如图10所示，该电子设备的硬件结构可以包括：处理器1001、通信接口1002、计算机可读存储介质(也称为存储器)1003和通信总线1004。

其中，处理器1001、通信接口1002、计算机可读存储介质1003通过通信总线1004完成相互间的通信。

该电子设备运行有容器云平台的管理***，用于管理容器云平台，容器云平台上部署有网络检测控制器，容器云平台的至少一个节点中对应部署有网络检测代理组件。

计算机可读存储介质1003，可以配置为存储一个或多个程序。

可选地，通信接口1002可以为通信模块的接口，如GSM模块的接口。

其中，处理器1001具体可以配置为：第一网络检测代理组件基于自定义网络检测资源文件记载的网络检测策略向目标组件发送检测请求；其中，目标组件为容器云平台中的任意组件，基于自定义网络检测资源文件记载的内容确定，网络检测策略至少包括检测请求的请求参数，请求参数用于指定检测请求的发送模式；网络检测控制器基于检测请求对应的响应，生成网络检测结果。

处理器1001可以是通用处理器，包括中央处理器(central processing unit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如：iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、***总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

需要指出，根据实施的需要，可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的容器云平台的网络检测方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及***实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。

以上所描述的设备及***实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元提示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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

Claims

1.一种容器云平台的网络检测方法，其特征在于，容器云平台上部署有网络检测控制器，所述容器云平台的至少一个节点中对应部署有网络检测代理组件，所述方法包括：

2.根据权利要求1所述的容器云平台的网络检测方法，其特征在于，所述网络检测策略还包括启动时间和执行轮数；

3.根据权利要求1所述的容器云平台的网络检测方法，其特征在于，所述网络检测策略还包括判定标准；

对所述网络检测结果进行分析，得到网络质量指标数值；

4.根据权利要求1至3任一项所述的容器云平台的网络检测方法，其特征在于，所述第一网络检测代理组件部署在所述容器云平台的第一节点中，所述目标组件为第二网络检测代理组件，所述第二网络检测代理组件部署在所述容器云平台的第二节点中；所述请求参数包括至少一种通信方式，所述通信方式用于定义所述检测请求经由的网络检测路径，所述检测请求为HTTP访问请求；

5.根据权利要求4所述的容器云平台的网络检测方法，其特征在于，所述通信方式包括容器组IP地址通信、节点端口通信、平台负载均衡通信、平台入口组件通信中的任意一种。

6.根据权利要求4所述的容器云平台的网络检测方法，其特征在于，所述网络检测代理组件部署在所述容器云平台的所有节点上，或者，所述网络检测代理组件部署在所述容器云平台的指定节点上。

7.根据权利要求1至3任一项所述的容器云平台的网络检测方法，其特征在于，所述目标组件为域名解析组件；

8.一种容器云平台的网络检测***，其特征在于，容器云平台上部署有网络检测控制器，所述容器云平台的至少一个节点中对应部署有网络检测代理组件，所述***包括：

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的容器云平台的网络检测方法。

10.一种电子设备，其特征在于，包括：存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如权利要求1至7任一项所述的容器云平台的网络检测方法。