Network connectivity test method, device, equipment and medium

Abstract

The embodiment of the invention provides a network connectivity test method and device, equipment and a medium, the method and device are applied to a Kubernetes cluster, the Kubernetes cluster comprises a plurality of execution nodes, each execution node is deployed with a test container, and the method comprises the steps that in response to an event of receiving node information of a to-be-tested node, a network tool built in the test container is called; for the to-be-tested node, determining a test result between the to-be-tested node and the execution node based on a network tool built in the test container, the address information corresponding to the to-be-tested node and the service port; and collecting a test result based on a target interface of Kubernetes, and determining a network connectivity result between the to-be-tested node and the execution node based on the test result. According to the technical scheme, the network tool built in the test container is called, the network connectivity result between the to-be-tested node and the execution node is determined, deployment, operation and maintenance are simple, expansibility and real-time performance are high, and the effect of improving the efficiency of judging accessibility and performance is achieved.

Description

Technical Field

[0001] This disclosure relates to the field of Kubernetes cluster technology, and in particular to a network connectivity testing method, apparatus, device, and medium. Background Technology

[0002] With the rapid development of container technology and cloud-native architecture, more and more business systems are running on container orchestration platforms such as Kubernetes. Network connectivity between nodes in the cluster is a crucial foundation for ensuring the stable operation of application services.

[0003] Existing methods for determining network connectivity between nodes primarily involve operations personnel logging into the host node and testing network connectivity using test commands. This approach suffers from drawbacks such as cumbersome operation, high security risks, and difficulty in execution within restricted environments. Summary of the Invention

[0004] This disclosure provides a network connectivity testing method, apparatus, device, and medium to call network tools built into a test container to determine the network connectivity results between the node under test and the execution node. It is simple to deploy and maintain, highly scalable and real-time, and achieves the effect of improving the efficiency of determining reachability and performance.

[0005] In a first aspect, embodiments of this disclosure provide a network connectivity testing method, which is applied in a Kubernetes cluster containing multiple execution nodes, each execution node deploying a test container. The method includes:

[0006] In response to receiving an event of receiving node information of at least one node to be tested, a network tool built into at least one of the test containers is invoked; wherein, the node to be tested is a node corresponding to a service or application deployed outside the Kubernetes cluster; the node information includes at least the address information and service port of the node to be tested;

[0007] For at least one of the nodes to be tested, the test result between the node to be tested and at least one of the execution nodes is determined based on the network tools built into at least one of the test containers, the address information corresponding to the node to be tested, and the service port.

[0008] The test results are collected based on the target interface of the Kubernetes system, and the network connectivity results between at least one of the test nodes and at least one of the execution nodes are determined based on the test results.

[0009] Secondly, embodiments of the present invention also provide a network connectivity testing device, the device comprising:

[0010] A network tool invocation module is used to invoke a network tool built into at least one of the test containers in response to receiving node information of at least one node to be tested; wherein, the node to be tested is a node corresponding to a service or application deployed outside the Kubernetes cluster; the node information includes at least the address information and service port of the node to be tested;

[0011] The test result determination module is used to determine the test result between the test node and at least one execution node for at least one of the test nodes based on at least one network tool built into the test container, the address information corresponding to the test node, and the service port.

[0012] The network connectivity result determination module is used to collect the test results based on the target interface of the Kubernetes, and determine the network connectivity result between at least one of the test nodes and at least one of the execution nodes based on the test results.

[0013] Thirdly, embodiments of the present invention also provide an electronic device, the electronic device comprising:

[0014] One or more processors;

[0015] Storage device for storing one or more programs.

[0016] When the one or more programs are executed by the one or more processors, the one or more processors implement the network connectivity testing method as described in any embodiment of the present invention.

[0017] Fourthly, embodiments of the present invention also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the network connectivity testing method as described in any of the embodiments of the present invention.

[0018] Fifthly, embodiments of the present invention also provide a computer program product, including a computer program, characterized in that, when executed by a processor, the computer program implements the network connectivity testing method as described in any embodiment of the present invention.

[0019] The technical solution of this disclosure is applied in a Kubernetes cluster, which contains multiple execution nodes, each of which deploys a test container. First, in response to receiving node information of at least one node to be tested, a network tool built into at least one test container is invoked. Then, for at least one node to be tested, based on the network tool built into the at least one test container, the address information corresponding to the node to be tested, and the service port, the test result between the node to be tested and at least one execution node is determined. Finally, the test results are collected based on the Kubernetes target interface, and the network connectivity result between at least one node to be tested and at least one execution node is determined based on the test results. This solves the problems of existing technologies where determining network connectivity between nodes requires operations personnel to log into the host node and test network connectivity using test commands, which is cumbersome, carries high security risks, and is difficult to execute in restricted environments. This disclosure implements the invocation of a network tool built into the test container to determine the network connectivity result between the node to be tested and the execution node, resulting in simple deployment and maintenance, strong scalability and real-time performance, and achieving the effect of improving the efficiency of determining reachability and performance. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of exemplary embodiments of the present invention, the accompanying drawings used in describing the embodiments are briefly introduced below. Obviously, the accompanying drawings described are only a portion of the drawings of the embodiments to be described in this invention, and not all of the drawings. For those skilled in the art, other drawings can be obtained from these drawings without any creative effort.

[0021] Figure 1 This is a flowchart illustrating a network connectivity testing method provided in an embodiment of this disclosure;

[0022] Figure 2 This is a flowchart illustrating a network connectivity testing method provided in an embodiment of this disclosure;

[0023] Figure 3 This is a schematic diagram of the structure of a network connectivity testing device provided in an embodiment of the present disclosure;

[0024] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0025] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0026] Before introducing the technical solutions provided in the embodiments of this disclosure, the application scenarios can be illustrated first. The technical solutions provided in the embodiments of this disclosure can be applied to scenarios where network connectivity between nodes in a Kubernetes cluster and external nodes is determined. Based on the technical solutions in the embodiments of this disclosure, the network tools built into the test container are invoked to determine the network connectivity results between the node under test and the execution node. This approach is simple to deploy and maintain, highly scalable and real-time, thus improving the efficiency of determining reachability and performance.

[0027] Example 1

[0028] Figure 1 This is a flowchart illustrating a network connectivity testing method provided in this disclosure. This disclosure is applicable to situations where network connectivity between nodes in a Kubernetes cluster and external nodes is determined. The method can be executed by a network connectivity testing device, which can be implemented in the form of software and / or hardware. The hardware can be a mobile electronic device that can execute the network connectivity testing method provided in this technical solution.

[0029] like Figure 1 As shown, the testing method is applied in a Kubernetes cluster, which contains multiple execution nodes, each of which deploys a test container. The method includes:

[0030] S110. In response to receiving an event that node information of at least one node to be tested is received, a network tool built into at least one of the test containers is invoked.

[0031] The node to be tested is the node corresponding to the service or application deployed outside the Kubernetes cluster; the node information includes at least the address information and service port of the node to be tested.

[0032] A Kubernetes cluster is a set of collaborative computing resources that orchestrate and manage containerized applications through a unified control plane. A Kubernetes cluster consists of a control plane and multiple execution nodes. The control plane is responsible for global decision-making and state management, including typical components such as external interfaces and cluster entry points, consistent storage of cluster state, scheduling Pods to execution nodes, and executing various control loops. Execution nodes are physical or virtual machines in the Kubernetes cluster used to host and run application workloads. Execution nodes report their resources and status to the control plane and create and manage Pods according to scheduling results. A Pod typically refers to a basic deployment unit in Kubernetes. A Pod can contain one or more containers that share the same network and storage resources. Kubernetes clusters operate by having users interact with the control plane via APIs. The control plane schedules workloads to appropriate execution nodes based on policies and continuously monitors and corrects deviations.

[0033] It's important to note that test containers are containers built and run for testing purposes, typically encapsulated within Kubernetes Pods, and used for tasks such as network connectivity testing. It's crucial to understand that in Kubernetes, containers are not directly scheduled; the smallest unit of scheduling is the Pod. Therefore, deploying a test container on each execution node means running a Pod containing the test container on each execution node.

[0034] It's important to note that in a Kubernetes environment, services within the cluster are typically managed and scheduled by Kubernetes. However, sometimes we need to interact with services or applications outside the Kubernetes cluster, which may be deployed on other servers, virtual machines, or cloud environments. The node under test refers to the physical or virtual host on which these external services or applications run. They are not within the Kubernetes cluster but communicate with it over the network. The address information of the node under test is a string that uniquely identifies its location on the network, typically an IP address. This address information allows other services to find and communicate with the node under test. The service port is the specific port number on which the application on the node under test listens for requests. Each service typically provides its service on one or more ports. For example, an HTTP service typically runs on ports 80 or 443. The address information and service port of the node under test, combined, form complete network connectivity information. Various network tools can be used within the test container to test network connectivity with the node under test. These tools can be used to perform various network operations, such as connection tests. For example, a network tool could be the netcat utility. Netcat can be used to debug and investigate network connections. It can create TCP or UDP connections, send data, and listen on ports.

[0035] Optionally, the test container is a BusyBox container deployed on a Kubernetes-based DaemonSet controller.

[0036] The DaemonSet controller is a type of controller in Kubernetes used to ensure that a replica of a certain type of Pod runs on each or every eligible node in the cluster. When a new node joins the Kubernetes cluster, the DaemonSet automatically creates the corresponding Pod on that node; when the node is removed, the corresponding Pod is also cleaned up. BusyBox containers are a streamlined user-space environment that integrates many commonly used Unix tools into a single executable file. Known for their small size and fast startup, BusyBox containers can be used for testing tasks in container environments.

[0037] It's important to note that when deploying a BusyBox container based on a DaemonSet controller, you first need to create a YAML file to define the DaemonSet configuration. Then, you can apply the DaemonSet configuration using the kubectl command. Further, you can use corresponding commands to view the DaemonSet status and the BusyBox container's running status. Finally, you can view the BusyBox container's output by checking the logs. By following these steps, you can deploy a BusyBox container based on a DaemonSet controller in a Kubernetes cluster.

[0038] Specifically, a Kubernetes cluster contains multiple execution nodes, each deploying a test container. When testing the network connectivity between the execution node and the node under test corresponding to a service or application deployed outside the Kubernetes cluster, after receiving the address information and service port of the node under test from the front end, the network tool built into the test container deployed on the execution node is directly invoked. The network tool in the test container can respond with the address information and service port of the node under test, helping to verify the connectivity with external services.

[0039] S120. For at least one node to be tested, based on the network tools built into at least one test container, the address information corresponding to the node to be tested, and the service port, determine the test result between the node to be tested and at least one execution node.

[0040] It should be noted that the test container runs on the execution node to test the node under test. The reachability and responsiveness of the node under test are determined based on the output of the network tools.

[0041] Optionally, based on the network tools built into the test container, network connectivity tests are performed on the address information and service port corresponding to the node under test to determine the test results between the node under test and at least one execution node.

[0042] It should be noted that when performing network connectivity tests using the network tools built into the test container, the process involves obtaining the node information of the node to be tested and using appropriate network tools for testing.

[0043] In this embodiment, the test results include at least one or more of the following: the execution node name, the test container name corresponding to the execution node, the address information of the node to be tested, the service port information of the node to be tested, the connectivity information between the execution node and the node to be tested, and the test timestamp.

[0044] The execution node name refers to the name of the worker node in the Kubernetes cluster that runs the test container. In a Kubernetes cluster, a node can be a physical server or a virtual machine, and each node has a unique name. The execution node is where the container runs; it is responsible for scheduling and managing the container's lifecycle. The test container name corresponding to the execution node is the name of the specific test container running on that node. This test container has built-in network tools used for connectivity testing with the node under test. Each test container has a unique name in the Kubernetes cluster, typically specified during creation or automatically generated by the Kubernetes cluster.

[0045] It's important to note that connectivity information between the execution node and the node under test refers to the results obtained through network testing, indicating whether the execution node can successfully connect to the node under test. This connectivity information can include connection success, connection failure, and latency information. A successful connection indicates that the execution node can access the node under test, and the service is functioning normally; a connection failure indicates that the execution node may be unable to establish a connection due to network problems, service not starting, incorrect address, or firewall restrictions. Latency information refers to the response time information returned if the connection is successful, indicating the network latency between the two nodes. The test timestamp refers to the specific time the network test was performed, usually expressed in date and time format. The test timestamp is used to record when the test occurred and is crucial for subsequent monitoring and analysis. It helps track the test history and evaluate service availability and performance changes.

[0046] Specifically, the network tools built into at least one test container are invoked. For at least one node to be tested, network connectivity tests are performed on the address information and service port corresponding to the node to be tested based on the network tools built into the test container, and the test results between the node to be tested and at least one execution node are determined.

[0047] S130. Collect test results based on the target interface of Kubernetes, and determine the network connectivity results between at least one node under test and at least one execution node based on the test results.

[0048] The target interface can refer to an API or service endpoint used to receive and process result data from the test container. It can be a custom RESTful API or an endpoint of a service in the Kubernetes cluster. After performing network connectivity tests in the test container, the test results need to be collected and sent to the target interface. Once the test results are sent to the target interface, the network connectivity status between the node under test and the execution node can be determined based on the test results. For example, if the value of the `connectivity_status` field is "success", it means that the execution node can successfully connect to the node under test, and the network connectivity is normal; if the value of the `connectivity_status` field is "failure", it means that the execution node cannot establish a connection with the node under test, possibly due to network problems, service not starting, incorrect address, or firewall restrictions.

[0049] Specifically, by collecting and analyzing test results through the target interface based on Kubernetes, the network connectivity between at least one node under test and at least one execution node can be effectively determined, providing important support for network fault diagnosis, performance monitoring, and system reliability.

[0050] The technical solution of this disclosure is applied in a Kubernetes cluster, which contains multiple execution nodes, each of which deploys a test container. First, in response to receiving node information of at least one node to be tested, a network tool built into at least one test container is invoked. Then, for at least one node to be tested, based on the network tool built into the at least one test container, the address information corresponding to the node to be tested, and the service port, the test result between the node to be tested and at least one execution node is determined. Finally, the test results are collected based on the Kubernetes target interface, and the network connectivity result between at least one node to be tested and at least one execution node is determined based on the test results. This solves the problems of existing technologies where determining network connectivity between nodes requires operations personnel to log into the host node and test network connectivity using test commands, which is cumbersome, carries high security risks, and is difficult to execute in restricted environments. This disclosure implements the invocation of a network tool built into the test container to determine the network connectivity result between the node to be tested and the execution node, resulting in simple deployment and maintenance, strong scalability and real-time performance, and achieving the effect of improving the efficiency of determining reachability and performance.

[0051] Example 2

[0052] Figure 2This is a flowchart illustrating the network connectivity testing method provided in this embodiment of the invention. Based on the foregoing embodiments, it provides a more detailed explanation of the invocation of network tools built into at least one test container. For specific implementation details, please refer to the technical solution of this embodiment. Technical terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0053] like Figure 2 As shown, the method specifically includes the following steps:

[0054] S210. After receiving node information of at least one node to be tested, construct the target instructions for execution within the test container.

[0055] The target instruction refers to the command executed within the test container, typically a network connectivity test command for the node under test. The `kubectl exec` command can be used as the target instruction to execute commands in Kubernetes.

[0056] Specifically, after receiving node information for at least one node to be tested, a command is constructed based on that information. For example, the `nc` command. This constructed command is then embedded into the `kubectl exec` instruction for execution within the specified test container.

[0057] S220. Issue target instructions to at least one target test container that meets the conditions.

[0058] Specifically, the target test container that meets the criteria refers to the test container corresponding to the execution node whose network connectivity is to be tested. Issuing the target command means sending the constructed kubectl exec command to the target test container that meets the criteria. This can be done through the Kubernetes command-line interface or API.

[0059] S230. By executing the target instruction, the network tool built into at least one target test container is invoked.

[0060] Specifically, by executing the target instructions, the network tools built into the target test container are invoked to verify the reachability and service availability of the node under test.

[0061] S240. For at least one node to be tested, based on the network tools built into at least one test container, the address information corresponding to the node to be tested, and the service port, determine the test result between the node to be tested and at least one execution node.

[0062] Optionally, after determining the test results, the test results are structured and stored according to a preset data format; the stored test results are indexed and aggregated for statistics to generate network connectivity results corresponding to the execution node and the node to be tested; and the network connectivity results are displayed in a preset display format.

[0063] It's important to note that structured processing refers to converting test results into a specific data format for easier storage and processing. Common formats include JSON, XML, or database table formats. For network connectivity test results, JSON format can be chosen for structured processing, making the results easier to read and parse. The structured test results can be stored using a database, log management system, or file system. For example, relational or non-relational databases can be used to store the structured test results in tables for easy subsequent querying and analysis.

[0064] It's also worth noting that indexing refers to creating an index for the stored data to speed up queries. Aggregate statistics involve analyzing stored test results to generate summary data. For example, aggregate functions can be used to calculate network connectivity success and failure rates, and these results can be displayed through reports.

[0065] S250, based on the Kubernetes target interface, collects test results and determines the network connectivity results between at least one node under test and at least one execution node based on the test results.

[0066] Optionally, after determining the network connectivity results corresponding to the execution node and the node to be tested, the network connectivity results that meet the preset conditions are pushed to the target operation and maintenance user, so that the target operation and maintenance user can locate the unconnected execution node and the node to be tested and troubleshoot the fault based on the network connectivity results that meet the preset conditions.

[0067] It's important to note that preset conditions refer to the circumstances under which network connectivity results should be pushed to operations and maintenance users. Preset conditions can include connection failures, meaning a node under test cannot be accessed by the execution node. Preset conditions can also include high latency, meaning the response time exceeds a preset threshold. Based on the defined preset conditions, records that meet the criteria are filtered from the stored network connectivity results. These filtered network connectivity results can be pushed to the target operations and maintenance users via API. By pushing network connectivity results, operations and maintenance users can quickly locate problems based on this information.

[0068] The technical solution of this disclosure, upon receiving node information of at least one node to be tested, constructs target instructions for execution within a test container. Target instructions are issued to at least one target test container that meets the conditions. By executing the target instructions, network tools built into the at least one target test container are invoked. Then, for at least one node to be tested, based on the network tools built into the at least one test container, the address information corresponding to the node to be tested, and the service port, the test result between the node to be tested and at least one execution node is determined. Finally, the test results are collected based on the Kubernetes target interface, and the network connectivity result between the at least one node to be tested and at least one execution node is determined based on the test results. This can improve the efficiency of fault location and provide real-time monitoring data for the operations and maintenance team, helping them to more effectively manage resource configuration and optimize network performance, ensuring service stability and availability.

[0069] Example 3

[0070] Figure 3 This is a schematic diagram of the network connectivity testing device provided in the embodiments of this disclosure, as shown below. Figure 3 As shown, the device includes: a network tool invocation module 310, a test result determination module 320, and a network connectivity result determination module 330.

[0071] A network tool invocation module is used to invoke a network tool built into at least one of the test containers in response to receiving node information of at least one node to be tested; wherein, the node to be tested is a node corresponding to a service or application deployed outside the Kubernetes cluster; the node information includes at least the address information and service port of the node to be tested; a test result determination module is used to determine the test result between the node to be tested and at least one execution node for at least one node to be tested, based on the network tool built into at least one of the test containers, the address information corresponding to the node to be tested, and the service port; a network connectivity result determination module is used to collect the test results based on the target interface of the Kubernetes cluster, and determine the network connectivity result between at least one node to be tested and at least one execution node based on the test results.

[0072] The technical solution of this disclosure is applied in a Kubernetes cluster, which contains multiple execution nodes, each of which deploys a test container. First, in response to receiving node information of at least one node to be tested, a network tool built into at least one test container is invoked. Then, for at least one node to be tested, based on the network tool built into the at least one test container, the address information corresponding to the node to be tested, and the service port, the test result between the node to be tested and at least one execution node is determined. Finally, the test results are collected based on the Kubernetes target interface, and the network connectivity result between at least one node to be tested and at least one execution node is determined based on the test results. This solves the problems of existing technologies where determining network connectivity between nodes requires operations personnel to log into the host node and test network connectivity using test commands, which is cumbersome, carries high security risks, and is difficult to execute in restricted environments. This disclosure implements the invocation of a network tool built into the test container to determine the network connectivity result between the node to be tested and the execution node, resulting in simple deployment and maintenance, strong scalability and real-time performance, and achieving the effect of improving the efficiency of determining reachability and performance.

[0073] Based on the above technical solutions, the network tool invocation module 310 is further configured to, after receiving node information of at least one node to be tested, construct a target instruction for execution within a test container; issue the target instruction to at least one target test container that meets the conditions; and invoke the network tool built into at least one of the target test containers by executing the target instruction.

[0074] Based on the above technical solutions, the test result determination module 320 is also used to perform network connectivity tests on the address information and service port corresponding to the node under test based on the network tools built into the test container, and determine the test result between the node under test and at least one of the execution nodes.

[0075] Based on the above technical solutions, the test results shall include at least one or more of the following: execution node name, test container name corresponding to the execution node, address information of the node to be tested, service port information of the node to be tested, connectivity information between the execution node and the node to be tested, and test timestamp.

[0076] Based on the above technical solutions, the test container is a BusyBox container deployed based on the Kubernetes DaemonSet controller.

[0077] Based on the above technical solutions, the device further includes: an aggregation and statistics module, used to, after determining the test results, perform structured processing on the test results according to a preset data format and store them; index the stored test results and perform aggregation and statistics to generate network connectivity results corresponding to the execution node and the node to be tested; and display the network connectivity results according to a preset display format.

[0078] Based on the above technical solutions, the device further includes: a fault diagnosis module, used to push the network connectivity results that meet preset conditions to the target operation and maintenance user after determining the network connectivity results corresponding to the execution node and the node to be tested, so that the target operation and maintenance user can locate the unconnected execution node and the node to be tested and perform fault diagnosis based on the network connectivity results that meet the preset conditions.

[0079] The network connectivity testing apparatus provided in this disclosure can execute the network connectivity testing method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects for executing the method.

[0080] It is worth noting that the various units and modules included in the above-mentioned device are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be realized; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the protection scope of the embodiments of this disclosure.

[0081] Example 4

[0082] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Refer to the following... Figure 4 It illustrates an electronic device suitable for implementing embodiments of the present disclosure (e.g., Figure 4 The diagram below shows the structure of the terminal device or server 500. The terminal device in this embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and vehicle terminals (e.g., vehicle navigation terminals). Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0083] like Figure 4As shown, electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from storage device 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. An edit / output (I / O) interface 505 is also connected to bus 504.

[0084] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0085] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by the processing device 501, it performs the functions defined in the methods of embodiments of this disclosure.

[0086] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0087] The electronic device provided in this embodiment and the network connectivity testing method provided in the above embodiments belong to the same inventive concept. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0088] Example 5

[0089] This disclosure provides a computer storage medium storing a computer program that, when executed by a processor, implements the network connectivity testing method provided in the above embodiments.

[0090] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0091] In some implementations, the server may communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and may interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0092] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0093] The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to:

[0094] In response to receiving an event of receiving node information of at least one node to be tested, a network tool built into at least one of the test containers is invoked; wherein, the node to be tested is a node corresponding to a service or application deployed outside the Kubernetes cluster; the node information includes at least the address information and service port of the node to be tested;

[0095] For at least one of the nodes to be tested, the test result between the node to be tested and at least one of the execution nodes is determined based on the network tools built into at least one of the test containers, the address information corresponding to the node to be tested, and the service port.

[0096] The test results are collected based on the target interface of the Kubernetes system, and the network connectivity results between at least one of the test nodes and at least one of the execution nodes are determined based on the test results.

[0097] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0098] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0099] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0100] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0101] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0102] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0103] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0104] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A network connectivity testing method, characterized by, The test method is applied in a Kubernetes cluster containing a plurality of execution nodes, each of which is deployed with a test container, and the method comprises: In response to receiving an event of node information of at least one to-be-tested node, calling a network tool built in at least one of the test containers; wherein the to-be-tested node is a node corresponding to a service or application deployed outside the Kubernetes cluster; the node information at least includes address information and a service port of the to-be-tested node; For at least one of the to-be-tested nodes, based on the network tool built in at least one of the test containers, the address information and the service port corresponding to the to-be-tested node, determining the test result between the to-be-tested node and at least one of the execution nodes; Based on the target interface of the Kubernetes, collecting the test result, and based on the test result, determining the network connectivity result between at least one of the to-be-tested nodes and at least one of the execution nodes.

2. The method of claim 1, wherein, The response to receiving an event of node information of at least one to-be-tested node, calling a network tool built in at least one of the test containers, comprises: After receiving the node information of at least one to-be-tested node, constructing a target instruction for execution in the test container; Downlinking the target instruction to at least one target test container that meets the condition; By executing the target instruction, calling the network tool built in at least one of the target test containers.

3. The method of claim 1, wherein, The determination of the test result between the to-be-tested node and at least one of the execution nodes based on the network tool built in at least one of the test containers, the address information and the service port corresponding to the to-be-tested node, comprises: Based on the network tool built in the test container, performing network connectivity test on the address information and the service port corresponding to the to-be-tested node to determine the test result between the to-be-tested node and at least one of the execution nodes.

4. The method of claim 1, wherein, The test result at least includes one or more of execution node name, test container name corresponding to the execution node, address information of to-be-tested node, service port information of the to-be-tested node, connectivity information between the execution node and the to-be-tested node, and test timestamp.

5. The method of claim 1, wherein, The test container is a BusyBox container deployed based on the Kubernetes DaemonSet controller.

6. The method of claim 1, wherein, After determining the test result, the method further comprises: Structuring and storing the test result in a preset data format; Indexing and aggregating the stored test result to generate a network connectivity result corresponding to the execution node and the to-be-tested node; Displaying the network connectivity result in a preset display form.

7. The method of claim 6, wherein, After determining the network connectivity result corresponding to the execution node and the to-be-tested node, the method further comprises: The network connectivity result meeting the preset condition is pushed to a target operation and maintenance user, so that the target operation and maintenance user locates an execution node and a node to be tested that cannot be connected according to the network connectivity result meeting the preset condition and performs troubleshooting.

8. A network connectivity testing apparatus, characterized by: Comprise: A network tool calling module is configured to call a network tool built in at least one test container in response to an event of receiving node information of at least one node to be tested; wherein the node to be tested is a node corresponding to a service or an application deployed outside the Kubernetes cluster; and the node information at least includes address information and a service port of the node to be tested; A test result determining module is configured to determine a test result between the node to be tested and at least one execution node based on the network tool built in the at least one test container, the address information and the service port corresponding to the node to be tested for at least one node to be tested; A network connectivity result determining module is configured to collect the test result based on a target interface of the Kubernetes, and determine a network connectivity result between at least one node to be tested and at least one execution node based on the test result.

9. An electronic device, comprising: The electronic device comprises: One or more processors; A storage device for storing one or more programs, When one or more programs are executed by one or more processors, one or more processors implement a network connectivity test method as claimed in any one of claims 1-7.

10. A storage medium containing computer-executable instructions, wherein: The computer executable instructions when executed by the computer processor are for performing the network connectivity test method as claimed in any one of claims 1-7.

Images