Fault detection method and system
By combining the eBPF network acquisition module and the Ingress component with Kubernetes resource data to detect faults in the global access links of containers, the detection challenges caused by the complexity of cloud-native platform networks are solved, enabling efficient fault analysis and tracing.
Patent Information
- Application Number
- CN202511069229.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-31
- Publication Date
- 2025-10-28
AI Technical Summary
Existing network analysis tools and methods are insufficient for tracing and observing faults in the network of cloud-native platforms, making it difficult to manage the complexity and black-box nature of the network topology of cloud-native platforms.
The eBPF network acquisition module captures TCP connection events, network connection events, and connection information before and after NAT translation from the operating system kernel of the container cluster nodes. This information is then matched with Kubernetes cluster resource data and combined with application container request context information obtained from the Ingress component to perform fault detection and analysis of the container global access link.
It enables efficient fault detection and analysis of the global access link of containers on cloud-native platforms, improves detection efficiency, ensures complete traceability of network connections and application requests, and reduces system overhead and latency.
Smart Images
Figure CN120856533A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a fault detection method and system. Background Technology
[0002] With the accelerated digital transformation of data centers, traditional infrastructure and network architectures are gradually shifting towards cloud-native platforms.
[0003] However, compared with traditional infrastructure and network architecture, the network topology of cloud-native platforms is extremely complex, and the network within container clusters exhibits black-box characteristics. This makes it difficult to trace the source of network problems and detect faults on cloud-native platforms using current network analysis tools and methods.
[0004] Therefore, there is an urgent need for a solution to address the aforementioned technical problems. Summary of the Invention
[0005] Based on the above problems, this application provides a fault detection method and system.
[0006] The embodiments of this application disclose the following technical solutions:
[0007] Firstly, embodiments of this application provide a fault detection method, including:
[0008] The five-tuple information of TCP connection events, network connection events and network connection status, and connection information before and after NAT translation in the operating system kernel of the container cluster node, captured by the eBPF network acquisition module, are matched with Kubernetes cluster resource data to obtain processed container network layer access link data; the Kubernetes cluster resource data is obtained by calling the Kubernetes API interface.
[0009] The application container request context information obtained based on the Ingress component is matched with Kubernetes cluster resource data to obtain the processed application layer request call data.
[0010] Based on the processed container network layer access link data and the processed application layer request call data, fault detection and analysis are performed on the container global access link to obtain the detection results.
[0011] In one possible implementation, the steps of obtaining the five-tuple information of TCP connection events in the operating system kernel of the container cluster node based on the eBPF network acquisition module include:
[0012] TCP connection events are detected using the eBPF probe in the eBPF network acquisition module.
[0013] When the eBPF probe detects a TCP connection event on a container cluster node, it captures the 5-tuple information of the TCP connection event in the operating system kernel of the container cluster node based on the eBPF probe.
[0014] In one possible implementation, the steps for capturing connection information before and after NAT translation based on the eBPF network acquisition module include:
[0015] The eBPF network acquisition module uses the Netfilter and Conntrack modules mounted on the operating system kernel of the container cluster node to detect NAT translation events.
[0016] When a NAT translation event is detected, capture the connection information before and after the NAT translation.
[0017] In one possible implementation, the process of matching the five-tuple information of TCP connection events in the operating system kernel of the container cluster node captured by the eBPF network acquisition module, the network connection events and network connection states, and the connection information before and after NAT translation, with Kubernetes cluster resource data to obtain processed container network layer access link data includes:
[0018] The five-tuple information of TCP connection events, network connection events and network connection status in the operating system kernel of the container cluster node captured by the eBPF network acquisition module are integrated and correlated to generate the container network NAT tracing path from the source Pod to the target Pod in the container cluster.
[0019] The container network NAT tracing path is matched with Kubernetes cluster resource data to obtain the processed container network layer access link data.
[0020] In one possible implementation, the Kubernetes API interface includes a container resource API interface. The process of matching the five-tuple information of TCP connection events, network connection events and network connection states captured by the eBPF network acquisition module from the container cluster node operating system kernel, as well as connection information before and after NAT translation, with Kubernetes cluster resource data to obtain processed container network layer access link data includes:
[0021] Call the Kubernetes container resource API interface to obtain the five-tuple information, network connection events and network connection status, and the first sub-resource data corresponding to the connection information before and after NAT translation from the Kubernetes cluster resource data;
[0022] The five-tuple information of TCP connection events, network connection events and network connection status, and connection information before and after NAT translation in the operating system kernel of the container cluster node captured by the eBPF network acquisition module are matched with the first sub-resource data to obtain the processed container network layer access link data.
[0023] In one possible implementation, the Kubernetes API interface includes a network service resource API interface. The step of matching the application container request context information obtained based on the Ingress component with Kubernetes cluster resource data to obtain processed application-layer request invocation data includes:
[0024] Call the Kubernetes network service class resource API interface to obtain the second sub-resource data corresponding to the application container request context information from the Kubernetes cluster resource data;
[0025] The application container request context information obtained based on the Ingress component is matched with the second sub-resource data to obtain the processed application layer request call data.
[0026] In one possible implementation, the step of performing fault detection and analysis on the container global access link based on the processed container network layer access link data and the processed application layer request call data, and obtaining detection results, includes:
[0027] The processed container network layer access link data is associated with the processed container application layer request call data to generate a container global access link;
[0028] Fault detection and analysis are performed on the global access link of the container to obtain the detection results.
[0029] Second aspect: Embodiments of this application provide a fault detection system, including:
[0030] The system comprises a first matching module, a second matching module, and a detection module.
[0031] The first matching module is used to match the five-tuple information of TCP connection events, network connection events and network connection status, and connection information before and after NAT translation in the operating system kernel of the container cluster node captured by the eBPF network acquisition module with Kubernetes cluster resource data to obtain processed container network layer access link data; the Kubernetes cluster resource data is obtained by calling the Kubernetes API interface.
[0032] The second matching module is used to match the application container request context information obtained based on the Ingress component with Kubernetes cluster resource data to obtain the processed application layer request call data.
[0033] The detection module is used to perform fault detection and analysis on the container global access link based on the processed container network layer access link data and the processed application layer request call data, and obtain the detection results.
[0034] In one possible implementation, the system includes a first capture module;
[0035] The first capture module is specifically used for:
[0036] TCP connection events are detected using the eBPF probe in the eBPF network acquisition module.
[0037] When the eBPF probe detects a TCP connection event on a container cluster node, it captures the 5-tuple information of the TCP connection event in the operating system kernel of the container cluster node based on the eBPF probe.
[0038] In one possible implementation, the system includes a second capture module;
[0039] The second capture module is specifically used for:
[0040] The eBPF network acquisition module uses the Netfilter and Conntrack modules mounted on the operating system kernel of the container cluster node to detect NAT translation events.
[0041] When a NAT translation event is detected, capture the connection information before and after the NAT translation.
[0042] In one possible implementation, the first matching module is specifically used for:
[0043] The five-tuple information of TCP connection events, network connection events and network connection status in the operating system kernel of the container cluster node captured by the eBPF network acquisition module are integrated and correlated to generate the container network NAT tracing path from the source Pod to the target Pod in the container cluster.
[0044] The container network NAT tracing path is matched with Kubernetes cluster resource data to obtain the processed container network layer access link data.
[0045] In one possible implementation, the Kubernetes API interface includes a container resource API interface, and the first matching module is specifically used for:
[0046] Call the Kubernetes container resource API interface to obtain the five-tuple information, network connection events and network connection status, and the first sub-resource data corresponding to the connection information before and after NAT translation from the Kubernetes cluster resource data;
[0047] The five-tuple information of TCP connection events, network connection events and network connection status, and connection information before and after NAT translation in the operating system kernel of the container cluster node captured by the eBPF network acquisition module are matched with the first sub-resource data to obtain the processed container network layer access link data.
[0048] In one possible implementation, the Kubernetes API interface includes a network service resource API interface, and the second matching module is specifically used for:
[0049] Call the Kubernetes network service class resource API interface to obtain the second sub-resource data corresponding to the application container request context information from the Kubernetes cluster resource data;
[0050] The application container request context information obtained based on the Ingress component is matched with the second sub-resource data to obtain the processed application layer request call data.
[0051] In one possible implementation, the detection module is specifically used for:
[0052] The processed container network layer access link data is associated with the processed container application layer request call data to generate a container global access link;
[0053] Fault detection and analysis are performed on the global access link of the container to obtain the detection results.
[0054] Third aspect: This application provides a computer device, which includes a processor and a memory;
[0055] The memory is used to store program code and transmit the program code to the processor;
[0056] The processor is used to execute the steps of the fault detection method described in the first aspect above, according to the instructions in the program code.
[0057] Fourth aspect: Embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of a fault detection method as described in the first aspect above.
[0058] Fifth aspect: This application provides a computer program product, which, when run on a computer, executes the steps of a fault detection method as described above.
[0059] Sixth aspect: This application provides a chip including a processor coupled to a memory for executing computer programs or instructions stored in the memory, such that the chip implements a fault detection method as described in the first aspect above.
[0060] Compared with the prior art, this application has the following beneficial effects:
[0061] This application provides a fault detection method. It involves matching the five-tuple information of TCP connection events, network connection events and network connection states, and connection information before and after NAT translation captured by an eBPF network acquisition module with Kubernetes cluster resource data to obtain processed container network layer access link data. It also matches application container request context information obtained based on the Ingress component with Kubernetes cluster resource data to obtain processed application layer request call data. Based on the processed container network layer access link data and the processed application layer request call data, fault detection and analysis are performed on the container global access link to obtain detection results. In this application embodiment, based on Kubernetes cluster resource data in a cloud-native platform, the five-tuple information, network connection events and network connection states, connection information before and after NAT translation, and application container request context information can be processed to obtain processed container network layer access link data and processed application layer request call data. Based on these two types of data, fault detection and analysis of the container global access link are achieved, improving detection efficiency. Attached Figure Description
[0062] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0063] Figure 1A flowchart of a fault detection method provided in an embodiment of this application;
[0064] Figure 2 A system framework diagram for fault detection provided in an embodiment of this application;
[0065] Figure 3 This is a schematic diagram of the structure of a fault detection system provided in an embodiment of this application. Detailed Implementation
[0066] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.
[0067] As mentioned earlier, compared with traditional infrastructure and network architecture, the network topology of cloud-native platforms is extremely complex, and the network within the cluster exhibits black-box characteristics. This makes it difficult to trace the source of network problems and detect faults on cloud-native platforms using current network analysis tools and methods.
[0068] Based on this, this application provides a fault detection method that can process 5-tuple information, network connection events and network connection status, connection information before and after NAT translation, and application container request context information in a cloud-native platform based on Kubernetes cluster resource data. This results in processed container network layer access link data and processed application layer request call data. Based on these two types of data, fault detection and analysis of the container's global access link can be achieved, improving detection efficiency.
[0069] See Figure 1 The figure is a flowchart of a fault detection method provided in an embodiment of this application, including S101-S103.
[0070] S101. The five-tuple information of TCP connection events, network connection events and network connection status, and connection information before and after NAT translation in the operating system kernel of the container cluster node captured by the eBPF network acquisition module are matched with the Kubernetes cluster resource data to obtain the processed container network layer access link data.
[0071] The Kubernetes cluster resource data is obtained by calling the Kubernetes API interface.
[0072] The Transmission Control Protocol (TCP) is a four-layer network architecture used in computer networks to implement communication protocols. It defines how computers exchange data over a network and ensures reliable data transmission. The TCP / IP stack contains a series of protocols that control all aspects from data transmission to application-layer communication.
[0073] Extended Berkeley Packet Filter (eBPF) is a high-efficiency, low-overhead kernel-level packet processing technology that can dynamically load programs in the kernel to perform packet filtering, network traffic monitoring, fault detection, and other functions.
[0074] In one possible implementation, the eBPF probe in the eBPF network acquisition module can detect TCP connection events; when the eBPF probe detects a TCP connection event on a container cluster node, it can capture the 5-tuple information of the TCP connection event in the operating system kernel of the container cluster node.
[0075] The 5-tuple information may include source IP, destination IP, source port, destination port, and protocol type.
[0076] After the eBPF probe captures the 5-tuple information of TCP connection events in the kernel of the container cluster node's operating system, it can store the 5-tuple information in the eBPF Map structure in the kernel memory of the container cluster node's operating system.
[0077] In one possible implementation, the Netfilter and Conntrack modules mounted on the operating system kernel of the container cluster node in the eBPF network acquisition module can detect NAT translation events; when a NAT translation event is detected, the connection information before and after the NAT translation is captured.
[0078] Network Address Translation (NAT) is a technology used to translate private network addresses into public network addresses. It is widely used in cloud-native environments, such as Service load balancing and inter-Pod communication in Kubernetes.
[0079] Kubernetes, or K8S for short, is an open-source software cluster for large-scale deployment and management of containers. It has the capabilities of resource scheduling, application deployment and management, automatic repair, service discovery and load balancing, and elastic scaling, and has become the standard for container orchestration.
[0080] A Service is an abstract concept in Kubernetes that defines a logical collection of Pods (typically Pods performing the same task) and a policy for accessing them. A Service provides a stable IP address and port. A Pod, on the other hand, is a collection of container instances and their dependent storage and configurations.
[0081] The Netfilter module is a framework in the Linux kernel used to filter, forward, and modify network packets. It provides network packet processing capabilities and is a core component for implementing network functions such as firewalls, NAT, and flow control.
[0082] The Conntrack module is a kernel module used to track network connection status. It is part of the Linux kernel network stack and is primarily used to track and manage network connection status information. It is a crucial foundation for implementing firewalls, NAT, and other network-related functions.
[0083] For example, in this embodiment of the application, when a NAT translation event is detected, the eBPF network acquisition module can capture the changes in source IP, target IP and port number before and after the NAT translation, obtain the connection information before and after the NAT translation, and record the connection information before and after the NAT translation into the eBPF Map structure.
[0084] In one possible implementation, based on the five-tuple information of TCP connection events, network connection events and network connection states in the operating system kernel of the container cluster node captured by the eBPF network acquisition module, as well as the connection information before and after NAT translation, the five-tuple information of TCP connection events, network connection events and network connection states in the operating system kernel of the container cluster node, as well as the connection information before and after NAT translation, can be integrated and correlated to generate a container network NAT tracing path from the source Pod to the target Pod within the container cluster.
[0085] Based on this, the container network NAT tracing path is matched with Kubernetes cluster resource data to obtain the processed container network layer access link data.
[0086] For example, the Kubernetes API interface includes a container resource API interface. By calling the Kubernetes container resource API interface, the 5-tuple information, network connection events and network connection status, as well as the first sub-resource data corresponding to the connection information before and after NAT translation, can be obtained from the Kubernetes cluster resource data.
[0087] This first sub-resource data can be used to indicate the mapping relationship between Pods and Services.
[0088] By matching the 5-tuple information, network connection events and network connection states, as well as the connection information before and after NAT translation, with the first sub-resource data, the processed container network layer access link data can be obtained.
[0089] After obtaining the processed container network layer access link data, the processed container network layer access link data can be stored in an eBPF Map structure for subsequent tracing and retrieval.
[0090] S102. The application container request context information obtained based on the Ingress component is matched with the Kubernetes cluster resource data to obtain the processed application layer request call data.
[0091] The Kubernetes cluster resource data may include, but is not limited to, one or more of Pods, Services, and Ingresses.
[0092] Ingress, as an API object, can be used to manage how external access to services within a cluster is handled, typically via HTTP and HTTPS protocols. It provides HTTP routing rules that can route traffic to the appropriate service based on the requested URL.
[0093] In this embodiment, the Kubernetes API interface includes a network service resource API interface. By calling the Kubernetes network service resource API interface, the second sub-resource data corresponding to the application container request context information can be obtained from the Kubernetes cluster resource data.
[0094] Based on this, by matching the application container request context information obtained based on the Ingress component with the second sub-resource data, the processed application layer request call data can be obtained.
[0095] S103. Based on the processed container network layer access link data and the processed application layer request call data, perform fault detection and analysis on the container global access link to obtain the detection results.
[0096] In this embodiment, after obtaining the processed container network layer access link data and the processed application layer request call data, a container global access link can be generated by associating the processed container network layer access link data with the processed container application layer request call data. Detection results can be obtained by performing fault detection and analysis on the container global access link.
[0097] In summary, this application provides a method that, based on Kubernetes cluster resource data in a cloud-native platform, can process five-tuple information, network connection events and network connection status, connection information before and after NAT translation, and application container request context information to obtain processed container network layer access link data and processed application layer request call data. Based on these two types of data, fault detection and analysis of the global access link of the container can be achieved, thereby improving detection efficiency.
[0098] To facilitate understanding, the following will be combined with... Figure 2 The methods provided in the embodiments of this application will be described in general.
[0099] like Figure 2 As shown in the figure, this is a system framework diagram for fault detection provided in an embodiment of this application. The system framework includes an eBPF network acquisition module, a NAT mapping tracing module, an application context parsing and association module, and a network link association and anomaly tracing module.
[0100] The eBPF network acquisition module is used to capture the five-tuple information of TCP connection events, network connection events and network connection status in the operating system kernel of the container cluster node, as well as connection information before and after NAT translation.
[0101] For example, the eBPF network acquisition module can be deployed as a proxy pod on a K8S cluster node. This module attaches an eBPF probe to the kernel's TCP / IP stack, which can listen for TCP connection events (tcp_connect) and TCP close events (tcp_close). When a TCP connection is established, the eBPF probe captures the five-tuple information of the TCP connection event in the container cluster node's operating system kernel (e.g., source IP, destination IP, source port, destination port, and protocol type) and stores the five-tuple information in the eBPF Map structure in the operating system kernel memory of the container cluster node.
[0102] Meanwhile, the eBPF network acquisition module, based on the Netfilter and Conntrack modules mounted on the kernel, can capture connection information through NAT translation. That is, when a data packet passes through NAT translation, the eBPF module can capture the changes in source IP, destination IP and port number before and after the translation, obtain the connection information before and after NAT translation, and record it in the eBPF Map structure.
[0103] In this embodiment of the application, after the eBPF network acquisition module completes data acquisition, it can transmit the five-tuple information, network connection events and network connection status recorded and stored in the eBPFMap, as well as the connection information before and after NAT translation, to the user space through a timed task, and send it to the NAT mapping tracking module for subsequent path tracing and NAT address translation tracking.
[0104] The NAT mapping tracking module can receive the five-tuple information, network connection events, and network connection status sent by the eBPF network acquisition module, as well as the connection information before and after NAT translation. By calling the Kubernetes container resource API interface, it can obtain the first sub-resource data corresponding to the five-tuple information, network connection events, network connection status, and connection information before and after NAT translation from the Kubernetes cluster resource data.
[0105] The first sub-resource data includes the mapping relationship between Pods and Services provided by the Kubernetes kube-apiserver server. The NAT mapping tracking module can match the five-tuple information of TCP connection events in the operating system kernel of the container cluster node, network connection events and network connection status, as well as the connection information before and after NAT translation, captured by the eBPF network acquisition module, with the first sub-resource data to complete the resource interpretation of network data, obtain the processed container network layer access link data, and dynamically update and maintain the mapping of the link data.
[0106] In this embodiment, the NAT mapping tracing module can track and record network connection events, construct the real path from the source Pod to the target Pod, record the network connection status in real time, and send the processed container network layer access link data to the network link association and anomaly tracing module for subsequent container global access link fault detection and analysis.
[0107] The application context resolution and association module receives application container request context information obtained based on the Ingress component, and obtains the second sub-resource data corresponding to the application container request context information from the Kubernetes cluster resource data by calling the Kubernetes network service class resource API interface.
[0108] Based on this, the application context parsing and association module will match the application container request context information obtained from the Ingress component with the second sub-resource data, thereby achieving accurate association between the application request context information and the second sub-resource data and obtaining the processed application layer request call data.
[0109] After obtaining the processed application layer request call data, the application context parsing and association module can send the processed application layer request call data to the network link association and anomaly tracing module for subsequent container global access link fault detection and analysis.
[0110] The network link association and anomaly tracing module receives processed container network layer access link data sent by the NAT mapping tracing module and processed application layer request call data sent by the application context resolution and association module. By associating the processed container network layer access link data with the processed container application layer request call data, a global container access link can be generated.
[0111] In this embodiment of the application, by generating a global access link for the container, the complete traceability of network connections and application requests can be ensured, thereby enabling application requests in the container network to be directly associated with and dynamically tracked by the connection status and NAT translation of the underlying network layer.
[0112] Meanwhile, the network link association and anomaly tracing module can perform fault detection and analysis on the container's global access link and obtain the detection results.
[0113] For example, the network link association and anomaly tracing module can automatically identify abnormal connections and provide fault detection analysis results by analyzing connection state data (such as TCP packet loss rate and retransmission count) based on the acquired network connection and status information.
[0114] In summary, in this embodiment of the application, the processed container network layer access link data is associated with the processed container application layer request call data, thereby realizing automatic correlation analysis between the network and the application and locating the root cause of the fault, thus improving the efficiency of fault handling.
[0115] This application establishes an eBPF multi-layer tracing mechanism. By utilizing eBPF technology in a cloud-native platform, it captures the five-tuple information of TCP connection events, network connection events and network connection states, as well as connection information before and after NAT translation. Based on this, and combined with application request data, it achieves complete traceability of network connections and application requests. This allows application requests in container networks to be directly correlated with and dynamically traced against the connection states and NAT translations of the underlying network layer, greatly improving the observability of the cloud-native platform.
[0116] Meanwhile, the eBPF network acquisition module can capture address mappings before and after NAT in real time, and combined with Kubernetes control plane information, it provides accurate traceability of inter-container communication paths. eBPF technology avoids the high complexity, high invasiveness, and low real-time performance of traditional network data acquisition methods, greatly reducing system overhead and achieving low-latency, high-precision real-time data acquisition.
[0117] This application provides a fault detection system, see [link to relevant documentation] Figure 3 The figure is a schematic diagram of the structure of a fault detection system provided in an embodiment of this application. Its specific implementation method is consistent with the implementation method and the technical effect achieved in the embodiments of the above method. Some contents will not be repeated.
[0118] This application provides a fault detection system 3100, including:
[0119] The system comprises a first matching module 3101, a second matching module 3102, and a detection module 3103;
[0120] The first matching module 3101 is used to match the five-tuple information of TCP connection events, network connection events and network connection status, and connection information before and after NAT translation in the operating system kernel of the container cluster node captured by the eBPF network acquisition module with Kubernetes cluster resource data to obtain processed container network layer access link data; the Kubernetes cluster resource data is obtained by calling the Kubernetes API interface.
[0121] The second matching module 3102 is used to match the application container request context information obtained based on the Ingress component with Kubernetes cluster resource data to obtain the processed application layer request call data.
[0122] The detection module 3103 is used to perform fault detection and analysis on the container global access link based on the processed container network layer access link data and the processed application layer request call data, and obtain the detection results.
[0123] In one possible implementation, the system includes a first capture module;
[0124] The first capture module is specifically used for:
[0125] TCP connection events are detected using the eBPF probe in the eBPF network acquisition module.
[0126] When the eBPF probe detects a TCP connection event on a container cluster node, it captures the 5-tuple information of the TCP connection event in the operating system kernel of the container cluster node based on the eBPF probe.
[0127] In one possible implementation, the system includes a second capture module;
[0128] The second capture module is specifically used for:
[0129] The eBPF network acquisition module uses the Netfilter and Conntrack modules mounted on the operating system kernel of the container cluster node to detect NAT translation events.
[0130] When a NAT translation event is detected, capture the connection information before and after the NAT translation.
[0131] In one possible implementation, the first matching module is specifically used for:
[0132] The five-tuple information of TCP connection events, network connection events and network connection status in the operating system kernel of the container cluster node captured by the eBPF network acquisition module are integrated and correlated to generate the container network NAT tracing path from the source Pod to the target Pod in the container cluster.
[0133] The container network NAT tracing path is matched with Kubernetes cluster resource data to obtain the processed container network layer access link data.
[0134] In one possible implementation, the Kubernetes API interface includes a container resource API interface, and the first matching module is specifically used for:
[0135] Call the Kubernetes container resource API interface to obtain the five-tuple information, network connection events and network connection status, and the first sub-resource data corresponding to the connection information before and after NAT translation from the Kubernetes cluster resource data;
[0136] The five-tuple information of TCP connection events, network connection events and network connection status, and connection information before and after NAT translation in the operating system kernel of the container cluster node captured by the eBPF network acquisition module are matched with the first sub-resource data to obtain the processed container network layer access link data.
[0137] In one possible implementation, the Kubernetes API interface includes a network service resource API interface, and the second matching module is specifically used for:
[0138] Call the Kubernetes network service class resource API interface to obtain the second sub-resource data corresponding to the application container request context information from the Kubernetes cluster resource data;
[0139] The application container request context information obtained based on the Ingress component is matched with the second sub-resource data to obtain the processed application layer request call data.
[0140] In one possible implementation, the detection module is specifically used for:
[0141] The processed container network layer access link data is associated with the processed container application layer request call data to generate a container global access link;
[0142] Fault detection and analysis are performed on the global access link of the container to obtain the detection results.
[0143] In summary, the embodiments of this application can process 5-tuple information, network connection events and network connection status, connection information before and after NAT translation, and application container request context information based on Kubernetes cluster resource data in a cloud-native platform. This results in processed container network layer access link data and processed application layer request call data. Based on these two types of data, fault detection and analysis of the global access link of the container can be achieved, thereby improving detection efficiency.
[0144] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.
[0145] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A fault detection method, characterized in that, include: The five-tuple information of TCP connection events, network connection events and network connection status, and connection information before and after NAT translation in the operating system kernel of the container cluster node, captured by the eBPF network acquisition module, are matched with Kubernetes cluster resource data to obtain processed container network layer access link data; the Kubernetes cluster resource data is obtained by calling the Kubernetes API interface. The application container request context information obtained based on the Ingress component is matched with Kubernetes cluster resource data to obtain the processed application layer request call data. Based on the processed container network layer access link data and the processed application layer request call data, fault detection and analysis are performed on the container global access link to obtain the detection results.
2. The method according to claim 1, characterized in that, The steps for obtaining the five-tuple information of TCP connection events in the operating system kernel of a container cluster node based on the eBPF network acquisition module include: TCP connection events are detected using the eBPF probe in the eBPF network acquisition module. When the eBPF probe detects a TCP connection event on a container cluster node, it captures the 5-tuple information of the TCP connection event in the operating system kernel of the container cluster node based on the eBPF probe.
3. The method according to claim 1, characterized in that, The steps for capturing connection information before and after NAT translation using the eBPF network acquisition module include: The eBPF network acquisition module uses the Netfilter and Conntrack modules mounted on the operating system kernel of the container cluster node to detect NAT translation events. When a NAT translation event is detected, capture the connection information before and after the NAT translation.
4. The method according to claim 1, characterized in that, The process involves matching the five-tuple information of TCP connection events, network connection events and network connection states captured by the eBPF network acquisition module in the operating system kernel of the container cluster node, as well as the connection information before and after NAT translation, with Kubernetes cluster resource data to obtain processed container network layer access link data, including: The five-tuple information of TCP connection events, network connection events and network connection status in the operating system kernel of the container cluster node captured by the eBPF network acquisition module are integrated and correlated to generate the container network NAT tracing path from the source Pod to the target Pod in the container cluster. The container network NAT tracing path is matched with Kubernetes cluster resource data to obtain the processed container network layer access link data.
5. The method according to claim 1, characterized in that, The Kubernetes API interface includes a container resource API interface. The process involves matching the five-tuple information of TCP connection events, network connection events and network connection states captured by the eBPF network acquisition module from the container cluster node operating system kernel, as well as connection information before and after NAT translation, with Kubernetes cluster resource data to obtain processed container network layer access link data, including: Call the Kubernetes container resource API interface to obtain the five-tuple information, network connection events and network connection status, and the first sub-resource data corresponding to the connection information before and after NAT translation from the Kubernetes cluster resource data; The five-tuple information of TCP connection events, network connection events and network connection status, and connection information before and after NAT translation in the operating system kernel of the container cluster node captured by the eBPF network acquisition module are matched with the first sub-resource data to obtain the processed container network layer access link data.
6. The method according to claim 1, characterized in that, The Kubernetes API interfaces include network service resource API interfaces. The process of matching the application container request context information obtained based on the Ingress component with Kubernetes cluster resource data to obtain processed application layer request invocation data includes: Call the Kubernetes network service class resource API interface to obtain the second sub-resource data corresponding to the application container request context information from the Kubernetes cluster resource data; The application container request context information obtained based on the Ingress component is matched with the second sub-resource data to obtain the processed application layer request call data.
7. The method according to claim 1, characterized in that, Based on the processed container network layer access link data and the processed application layer request call data, fault detection and analysis are performed on the container global access link to obtain detection results, including: The processed container network layer access link data is associated with the processed container application layer request call data to generate a container global access link; Fault detection and analysis are performed on the global access link of the container to obtain the detection results.
8. A fault detection system, characterized in that, include: The system comprises a first matching module, a second matching module, and a detection module. The first matching module is used to match the five-tuple information of TCP connection events, network connection events and network connection status, and connection information before and after NAT translation in the operating system kernel of the container cluster node captured by the eBPF network acquisition module with Kubernetes cluster resource data to obtain processed container network layer access link data; the Kubernetes cluster resource data is obtained by calling the Kubernetes API interface. The second matching module is used to match the application container request context information obtained based on the Ingress component with Kubernetes cluster resource data to obtain the processed application layer request call data. The detection module is used to perform fault detection and analysis on the container global access link based on the processed container network layer access link data and the processed application layer request call data, and obtain the detection results.
9. A computer device, characterized in that, The computer device includes: a processor and a memory; The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the steps of a fault detection method as described in any one of claims 1-7 according to instructions in the program code.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of a fault detection method as described in any one of claims 1-7.