Traffic mirroring method and device and electronic equipment

Abstract

The invention discloses a traffic mirroring method, a traffic mirroring device and electronic equipment. The method comprises the steps that network information of a plurality of container groups in a container arrangement platform is acquired, the container groups are minimum calculation units in the container arrangement platform, and each container group comprises at least one container; determining a target container group needing traffic mirroring according to the network information; target equipment corresponding to the target container group on the host machine is determined, and the target equipment comprises network equipment directly associated with the target container group; and loading a target program on the target device, and performing traffic mirroring on the target container group by using the target program, the target program being used for determining an execution logic of the traffic mirroring. According to the method and the device, the technical problem that specific Pod traffic cannot be accurately mirrored due to the fact that Pod in Kubernetes has high dynamic nature and a traditional traffic mirroring technology depends on static network equipment information during configuration and cannot sense Pod changes in time is solved.

Description

Technical Field

[0001] This application relates to the field of computer network technologies, and in particular, to a method, apparatus, and electronic device for traffic mirroring. Background Art

[0002] With the wide application of cloud computing and container technologies, the security risks faced by K8s clusters are increasing day by day. The traffic mirroring technology can monitor the communication status between Pods and between Pods and the external network in real time, detect abnormal connections and malicious attack behaviors in a timely manner, provide strong data support for security audit work, and ensure the security and compliance of the cluster. In terms of performance analysis, traffic mirroring helps developers and operators comprehensively analyze important metrics such as the network bandwidth usage, packet transmission delay, and packet loss rate of Pods, accurately discover performance bottlenecks, and then optimize network configurations and application codes in a targeted manner, significantly improving the performance of application programs and the user experience.

[0003] However, implementing traffic mirroring for Pods in a K8s environment faces many challenges. Traditional traffic mirroring methods are usually carried out at the network device or virtual machine level. For Pods that are dynamically created and destroyed in K8s, it is difficult to achieve fine-grained traffic mirroring. Because Pods in K8s are highly dynamic and can be created, destroyed, and migrated at any time, traditional methods cannot perceive Pod changes in a timely manner, resulting in the mirror configuration being out of sync with the actual state of the Pods and unable to accurately mirror the traffic of specific Pods.

[0004] In response to the above problems, no effective solution has been proposed yet. Summary of the Invention

[0005] Embodiments of this application provide a method, apparatus, and electronic device for traffic mirroring to at least solve the technical problem that due to the high dynamics of Pods in Kubernetes, traditional traffic mirroring technologies rely on static network device information during configuration and cannot perceive Pod changes in a timely manner, resulting in the inability to accurately mirror the traffic of specific Pods.

[0006] According to one aspect of the embodiments of this application, a method for traffic mirroring is provided, including: obtaining network information of multiple container groups in a container orchestration platform, where a container group is the smallest computing unit in the container orchestration platform, and one container group includes at least one container; determining a target container group that needs to perform traffic mirroring based on the network information; determining a target device corresponding to the target container group on a host machine, where the target device includes a network device directly associated with the target container group; loading a target program on the target device, and using the target program to perform traffic mirroring on the target container group, where the target program is used to determine the execution logic of traffic mirroring.

[0007] In some embodiments of the present application, loading a target program on a target device includes: determining an egress path corresponding to a target container group, where the egress path is the path through which a first data packet flows from the target container group to an external network or other container groups, and the target device is included on the egress path; determining a target location on the egress path, where the target location includes the location where the first data packet leaves the target device; mounting the target program at the target location, and executing the target program when the first data packet passes through the target location.

[0008] In some embodiments of the present application, using a target program to perform traffic mirroring on a target container group includes: obtaining target information of a second data packet of the target container group, where the target information includes header information of the second data packet; comparing the target information with network information of the target container group to obtain a comparison result; and performing traffic mirroring on the second data packet according to a mirroring policy of the target program when the comparison result indicates that the second data packet belongs to the traffic of the target container group.

[0009] In some embodiments of the present application, the mirroring policy includes full traffic mirroring and selective traffic mirroring. Performing traffic mirroring on the second data packet according to the mirroring policy of the target program includes: determining to perform traffic mirroring on all second data packets when the mirroring policy is full traffic mirroring; and performing traffic mirroring on the second data packets that meet a preset condition when the mirroring policy is selective traffic mirroring.

[0010] In some embodiments of the present application, after determining the target device corresponding to the target container group on the host, the method further includes: obtaining mirror configuration information of the target container group, where the mirror configuration information includes a mirror destination, and the mirror destination includes an address for receiving network traffic from the target container group; and determining the target program according to the mirror configuration information and information corresponding to the target device.

[0011] In some embodiments of the present application, the mirror configuration information includes multiple mirror destinations. After using the target program to perform traffic mirroring on the target container group, the method further includes: obtaining the type of the mirror destination, where the type includes a local network interface and a remote server, and the local network interface is an interface other than the outbound interface of the data packet of the target container group; writing a third data packet to the local network interface when the type of the mirror destination belongs to the local network interface; and sending the third data packet to the remote server through a network protocol when the type of the mirror destination belongs to the remote server.

[0012] In some embodiments of the present application, determining a target container group that needs to perform traffic mirroring based on network information includes: obtaining target parameters in the network information, and determining the target container group based on the target parameters, where the target parameters include descriptive parameters additionally configured in the annotation field of the target container group, and the target parameters are used to indicate whether the container group meets the conditions for traffic mirroring.

[0013] According to another aspect of the embodiments of the present application, there is also provided a traffic mirroring device, including: an obtaining module, configured to obtain network information of multiple container groups in a container orchestration platform; a first determining module, configured to determine a target container group that needs to perform traffic mirroring based on the network information; a second determining module, configured to determine a target device corresponding to the target container group on a host; and a mirroring module, configured to load a target program on the target device and use the target program to perform traffic mirroring on the target container group.

[0014] According to yet another aspect of the embodiments of the present application, there is also provided an electronic device, including: a memory and a processor, where the memory is used to store program instructions; the processor is connected to the memory and is configured to execute to implement the above-mentioned traffic mirroring method.

[0015] According to yet another aspect of the embodiments of the present application, there is also provided a non-volatile storage medium, where the non-volatile storage medium includes a stored computer program, and the device where the non-volatile storage medium is located executes the above-mentioned traffic mirroring method by running the computer program.

[0016] According to yet another aspect of the embodiments of the present application, there is also provided a computer program product, including computer instructions, and when the computer instructions are executed by a processor, the above-mentioned traffic mirroring method is implemented.

[0017] In the embodiments of the present application, by adopting a method of real-time monitoring and dynamic matching, through analyzing the network information of multiple container groups in the container orchestration platform, a target container group that needs to perform traffic mirroring is determined, and the traffic of the target container group is efficiently mirrored, achieving the purpose of accurately mirroring the traffic of specific container groups in the container orchestration platform, thereby realizing the technical effect of fine-grained and accurate monitoring of traffic, and further solving the technical problem that due to the high dynamics of Pods in Kubernetes, traditional traffic mirroring technologies rely on static network device information during configuration and cannot timely perceive the changes of Pods, resulting in the inability to accurately mirror the traffic of specific Pods. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation to the present application. In the drawings:

[0019] Figure 1 It is a hardware structure block diagram of a computer terminal for a traffic mirroring method according to an embodiment of the present application;

[0020] Figure 2 It is a flowchart of a traffic mirroring method according to an embodiment of the present application;

[0021] Figure 3 It is an overall flowchart of a traffic mirroring method according to an embodiment of the present application;

[0022] Figure 4 It is a schematic structural diagram of a traffic mirroring device according to an embodiment of the present application. Detailed implementation manners

[0023] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0024] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units does not necessarily need to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0025] In order to better understand the embodiments of the present application, the technical terms involved in the embodiments of the present application are explained as follows:

[0026] Traffic Mirroring: A network monitoring technology used to copy data packets on a network interface to another interface or destination for in-depth analysis by network engineers, security analysts, and performance monitoring teams.

[0027] Container Orchestration Platform: A software platform for automating the deployment, scaling, and management of containerized applications, such as Kubernetes (abbreviated as K8s) or Docker Swarm. Such platforms can coordinate multiple container instances to ensure their correct operation, interaction, and service among multiple host machines.

[0028] Container Group: In a container orchestration platform, a container group refers to the smallest computing unit within a container orchestration platform. For example, a Pod in Kubernetes, where a Pod is the smallest deployable and manageable computing unit in K8s. Each container group can contain one or more container instances, and these containers share storage, network resources, etc., and are scheduled and managed as a whole.

[0029] eBPF (Extended Berkeley Packet Filter): A programmable framework in the Linux kernel that allows users to implement real-time filtering, analysis, and processing of network packets and system events by loading custom programs into the kernel without modifying the kernel source code. In this application, eBPF programs can run in bytecode form, providing a powerful and flexible tool for system monitoring and network optimization.

[0030] Traffic Control (abbreviated as TC): In the Linux network stack, the traffic control mechanism allows users to manage and schedule the packets entering and leaving a network interface. Egress refers to the outbound direction, that is, the path that packets take when flowing out of the system to the external network. The tc / egress hook point is a location set on the outbound path where users can mount eBPF programs or apply various traffic control rules to process the outbound packets.

[0031] In a Kubernetes (K8s) environment, implementing traffic mirroring at the Pod level has a series of challenges, mainly due to the limitations of traditional traffic mirroring techniques and their incompatibility with modern containerized infrastructures. Traditional methods often focus on implementing traffic mirroring at the network device level or on virtual machines, which may be feasible in a static environment but are inadequate in the dynamic ecosystem of K8s. Pods, as the core computing units of K8s, have extremely high mobility. They can not only be quickly created and destroyed but also migrate seamlessly within the cluster. Therefore, traditional means are difficult to capture the rapid changes in Pod status, resulting in traffic mirroring configurations lagging behind the actual running situation of Pods, and thus unable to accurately track and mirror the network communications of individual Pods.

[0032] This phenomenon of configuration asynchrony is even more severe in the face of the scale expansion of K8s. In large-scale clusters, thousands of Pods communicate frequently, generating a huge amount of network traffic. When traditional traffic mirroring technologies handle such a large amount of data, they inevitably increase the network load, consume precious CPU and memory resources, and ultimately drag down the running efficiency of the entire cluster, affecting the response time of application programs and the user experience.

[0033] In addition, the complexity of the K8s environment and the dynamics of Pods require that traffic mirroring rules be precise and highly personalized. However, traditional methods rely on manual configuration of each rule one by one. In the face of the rapid increase and continuous changes in the number of Pods, this approach is not only time-consuming and laborious, but also prone to errors at critical moments of cluster maintenance (such as upgrades, expansions, or fault recovery), resulting in confusion and inconsistency in mirroring rules, further increasing the management difficulty and reducing the reliability and stability of the system.

[0034] To solve the above technical problems, the embodiments of the present application provide corresponding solutions, which will be described in detail below.

[0035] The method embodiments of traffic mirroring provided by the embodiments of the present application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Figure 1 The hardware structure block diagram of a computer terminal for implementing a method of traffic mirroring is shown. As Figure 1 shown, the computer terminal 10 may include one or more processors (processors may include, but are not limited to, processing devices such as a microprocessor MCU or a programmable logic device FPGA, shown as 102a, 102b,..., 102n in the figure), a memory 104 for storing data, and a transmission module 106 for communication functions connected by wired and / or wireless networks. In addition, it may further include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those of ordinary skill in the art can understand that Figure 1 the structure shown is only schematic and does not limit the structure of the above-mentioned electronic device. For example, the computer terminal 10 may further include more or fewer components than Figure 1 shown, or have a different configuration from Figure 1 shown.

[0036] It should be noted that the one or more processors and / or other data processing circuits described above can generally be referred to as "data processing circuits" herein. The data processing circuit can be embodied in whole or in part as software, hardware, firmware, or any combination thereof. In addition, the data processing circuit can be a single independent processing module, or be incorporated in whole or in part into any one of the other elements in the computer terminal 10. As involved in the embodiments of the present application, the data processing circuit is a kind of processor control (such as the selection of a variable resistance terminal path connected to an interface).

[0037] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage devices corresponding to the traffic mirroring method in the embodiments of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, implements the above-mentioned traffic mirroring method. The memory 104 can include high-speed random access memory, and can also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memories. In some instances, the memory 104 can further include memories remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 through a network. Examples of the above network include but are not limited to the Internet, intranet, local area network, mobile communication network, and combinations thereof.

[0038] The transmission module 106 is used to receive or send data via a network. Specific examples of the above network can include the wireless network provided by the communication provider of the computer terminal 10. In one instance, the transmission module 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station and thus can communicate with the Internet. In one instance, the transmission module 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0039] The display can be, for example, a touch-screen liquid crystal display (LCD), which enables the user to interact with the user interface of the computer terminal 10.

[0040] It should be noted here that in some alternative embodiments, the above Figure 1 shown computer terminal can include hardware elements (including circuits), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware elements and software elements. It should be pointed out that Figure 1 is only an example of a specific specific instance, and is intended to show the types of components that can exist in the above computer terminal.

[0041] Under the above operating environment, an embodiment of a traffic mirroring method is provided in an embodiment of the present application. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0042] Figure 2 is a flowchart of a traffic mirroring method according to an embodiment of the present application, as Figure 2 shown, the method includes the following steps:

[0043] Step S202, obtain network information of multiple container groups in the container orchestration platform, where a container group is the smallest computing unit in the container orchestration platform, and a container group includes at least one container.

[0044] In the above step S202, the container orchestration platform refers to a platform for automating the deployment, scaling, and management of containerized applications, such as Kubernetes (K8s), etc. In the present application, the container orchestration platform is responsible for providing life cycle management and network services of container groups, and is the basic environment for the traffic mirroring function to be realized.

[0045] A container group is the basic scheduling and management unit in the container orchestration platform, such as a Pod in Kubernetes. A container group can contain one or more tightly coupled containers, which share the same storage volume, network namespace, and life cycle management, which means that all containers in the container group are regarded as a whole in operations such as start, stop, and restart. Network information includes all relevant data generated in network communication of the container group, such as IP address, port number, packet size and direction, protocol type, etc.

[0046] It should be noted that this method can also run in container orchestration platforms such as Docker Swarm or Mesos. In these container orchestration platforms, there are also similar "Pod" concepts like "service", "task", or "stack" (i.e., container group), which are essentially the smallest computing units composed of a group of closely related containers. By adapting to the APIs and management interfaces of each container orchestration platform, dynamic acquisition of network information of these container groups can be achieved. For example, in Docker Swarm, network configuration information of services and their corresponding containers can be obtained through the Docker API; in Mesos, network attributes of tasks can be obtained through its framework API.

[0047] In some embodiments of the present application, a stable connection can be established with the K8s API server to periodically query or monitor the status changes of all container groups (Pods) in the cluster in real time, such as using its watch mechanism to monitor the creation, deletion, migration and other events of the container group in real time. Whenever the container status changes, the system can immediately capture these changes and update its internal container group network information database. This real-time synchronization mechanism can ensure that the container image system always has the latest network topology information of the cluster, including key data such as the IP address and network port configuration of the container group. Through the K8s watch mechanism, the system can respond to the life cycle events of the Pod in a timely manner.

[0048] Step S204: determining a target container group for which traffic mirroring is required according to the network information.

[0049] In the above step S204, in the container orchestration platform (such as Kubernetes), the target container group refers to a container group (such as Pod) whose network traffic needs to be monitored and mirrored according to specific traffic mirroring requirements.

[0050] In some embodiments of the present application, it is possible to check whether the network information (i.e., metadata) of the container group contains an Annotation (label) for identifying the traffic mirroring requirement. For example, if mirror.io=true exists in the Annotation of the container group, it indicates that the container group needs to perform traffic mirroring. This method solves the problem that dynamically created and destroyed container groups are difficult to track, because the Annotation can be dynamically added when the container group is created or when traffic mirroring is required. The system can monitor in real time and adjust the mirroring target accordingly to ensure that the mirroring configuration is synchronized with the actual status of the container group.

[0051] It should be noted that the network information collected from the container group can also be analyzed according to the preset strategy. The strategy can include traffic type, communication mode, security rules, etc. For example, the system can decide whether to mirror based on the network traffic size and / or direction and / or communication protocol of the container group. This method solves the performance bottleneck of the traditional traffic mirroring method when processing large-scale clusters, because the policy judgment can effectively filter out the traffic that needs to be mirrored, avoiding the indiscriminate replication of all traffic, thereby reducing the consumption of resources such as network bandwidth, CPU and memory.

[0052] Since the system may encounter performance bottlenecks when the number of container groups is extremely large and changes frequently, resulting in delays or missed identification of traffic mirroring requirements. To solve this problem, the system can be designed as a distributed architecture, where the judgment and execution logic of traffic mirroring are distributed on each host. Components on the host (such as the Pod management controller module) independently process the traffic mirroring requirements of the container groups running on it, which can relieve the pressure of single-point processing; a caching mechanism can also be introduced to store the recent container group status and traffic mirroring requirement information, avoiding frequent requests for container group information from the K8s API server and reducing communication delays between systems; the rule matching algorithm can also be optimized to reduce unnecessary calculations and data processing, significantly improving the response speed and accuracy of the system when processing large-scale container groups. For example, obtain detection information; when the delays and / or resource usage rates that occur when processing the traffic mirroring requirements of container groups indicated by the detection information meet preset conditions, start the distributed processing architecture to ensure that the traffic mirroring requirements of the container groups running on each host can be processed locally, and / or cache the (recent) container group status and traffic mirroring requirement information within a preset duration on each host to reduce the dependence on the K8s API server.

[0053] To be able to intelligently select the target of traffic mirroring, avoid indiscriminate traffic monitoring of all container groups, and save computing resources, the target container group can be determined in the following way: obtain the target parameters in the network information, and determine the target container group based on the target parameters, where the target parameters include descriptive parameters additionally configured in the annotation field of the target container group, and the target parameters are used to indicate whether the container group meets the conditions for traffic mirroring.

[0054] Specifically, this application provides a method for determining the container groups that need to perform traffic mirroring based on target parameters. The target parameters can be descriptive parameters additionally configured in the annotation field of the container group, and can include, but are not limited to, information such as the service type, security level, and traffic characteristics of the container group, and are used to indicate whether the container group should be selected as the target for traffic mirroring. For example, a parameter can be configured in the annotation of the container group to indicate that the container group is a high-risk service and full traffic mirroring is required to enhance security monitoring.

[0055] In some embodiments of the present application, the services of the container orchestration platform (such as Kubernetes API Server) can be polled regularly or subscribed to in real time to obtain the latest status and metadata of container groups (Pods), especially the information in the annotation fields. When a specific descriptive parameter (such as mirror.io = true) is recognized, the system marks the container group as a traffic mirroring target, thus achieving selective mirroring of container groups. In addition, the system can not only check the existence of the mirror.io = true annotation, but also parse the additional parameters included in the annotation, such as the conditions for traffic mirroring (e.g., by traffic type or specific time period), the destination, etc., and accurately determine which container group traffic needs to be mirrored based on these policies. In this way, the system can flexibly adjust the scope and details of traffic mirroring for different scenarios and requirements, avoiding the resource waste and performance loss caused by full traffic mirroring, and thus solving the efficiency and cost problems of traffic mirroring in large-scale clusters.

[0056] Step S206: Determine the target device corresponding to the target container group on the host, where the target device includes the network device directly associated with the target container group.

[0057] In the above step S206, the host refers to the physical machine or virtual machine in which the containerized application (such as Pod) runs. In the Kubernetes environment, each container group (Pod) runs on the host, and the host provides the underlying hardware resources and operating system environment required for the container to run.

[0058] The target device refers to the network device directly associated with the target container group. For example, the virtual network interface that provides network connection for the container group on the host, such as the veth pair (virtual Ethernet interface pair) of the Pod. In the containerized environment, each Pod has its own network namespace, and the traffic within this network namespace needs to pass through a specific network device to enter and exit the Pod.

[0059] In the case of running a large number of container groups on the host, to improve the search efficiency and accuracy, the device mapping table can be queried according to the container group ID. Specifically, in Kubernetes, each container group (Pod) has a unique ID, and the container image system running on the host can use this ID to query the pre-built device mapping table to find the network device directly associated with the container group, where the device mapping table stores the correspondence between the container group ID and the network device index.

[0060] Since container groups are dynamic, their network devices may also change with the creation, destruction, and migration of container groups. Therefore, the container image system can set up a dynamic detection mechanism for the host network devices. Once a device change is detected, the device mapping table is immediately updated to ensure that the network device corresponding to the target container group can always be correctly found. For example, the system continuously performs dynamic detection of network devices. If a change in the network device index is detected, the device mapping table is immediately updated, and the eBPF program is reloaded to ensure that the traffic mirroring operation is always bound to the correct network device.

[0061] After determining the target device corresponding to the target container group on the host, the following steps can also be executed: Obtain the mirror configuration information of the target container group, where the mirror configuration information includes a mirror destination, and the mirror destination includes the address for receiving network traffic from the target container group; Determine the target program based on the mirror configuration information and the information corresponding to the target device.

[0062] The mirror configuration information is a set of parameters used to guide the traffic mirroring operation. It can be stored in the annotations or configuration files of the container group and can include the mirror destination, mirror conditions (such as traffic type), and specific details of the mirror operation. Among them, the mirror destination refers to the target address of the traffic mirroring operation, which can be a network interface of another host, the IP address of a remote server, or a specific service within the cluster.

[0063] To avoid the rigidity and poor manageability brought by hard coding and fixed configurations and dynamically adapt to changes in the mirroring requirements of container groups, the mirror configuration information can be extracted by reading the metadata of the container group, especially its annotations. In specific implementation, the traffic mirroring system can design a parser to automatically interpret the annotation fields of the target container group and identify the parameters related to mirroring.

[0064] The target program can be an eBPF program, which will be loaded into the host kernel to capture and process the network traffic of the target container group. To be able to quickly generate or load the optimal eBPF program according to different mirroring requirements and network environments and reduce the latency and resource consumption of the mirroring operation, in some embodiments of the present application, an appropriate eBPF program can be generated or selected based on the obtained mirror configuration information and the target device index. In specific implementation, an eBPF program library can be designed, which contains a variety of pre-compiled template programs. The traffic mirroring system selects a suitable template from the library according to the mirror destination and configuration details and makes necessary parameter adjustments to finally generate an eBPF program that can meet specific mirroring requirements.

[0065] It should be noted that since the eBPF technology is based on the Linux kernel, and most container orchestration platforms (whether Kubernetes, Docker Swarm or Mesos) rely on the Linux kernel to implement container networking, eBPF programs can be applied cross-platformly to the hook points of container network devices (such as tc / egress) to achieve real-time traffic capture and mirroring.

[0066] Since the mirror configuration information of a container group may change frequently, the eBPF program needs to be updated frequently, which causes instability in mirror operations and additional performance losses. To solve this problem, a real-time update mechanism can be designed. When the mirror configuration information of a container group changes, the system immediately detects and updates the target program. For example, the watch mechanism of Kubernetes can be used to monitor the metadata changes of the container group. Once an update to the mirror configuration information is detected, the regeneration and loading of the target program are immediately triggered. To avoid frequent reloading of the entire eBPF program, an incremental update strategy can also be adopted. Specifically, the system can be designed to only update the part of the eBPF program related to the change in the mirror configuration information, while keeping other parts unchanged. By adopting this strategy, the number of times and time overhead of reloading the eBPF program can be significantly reduced, and the stability of traffic mirroring can be improved.

[0067] Specifically, when initializing the system, load the mirror configuration information of all target container groups, and generate the corresponding eBPF program according to this information and load it into the host kernel; start the watch mechanism of Kubernetes to monitor the metadata changes of the container group in real time, especially pay attention to the changes in the mirror configuration information; once it is detected that the mirror configuration information of the target container group has changed, immediately extract other key parameters such as the mirror destination for updating the target program from the new configuration information; generate or update the eBPF program based on the new mirror configuration information and the network device index of the target container group. Among them, if the change in the mirror configuration information only affects part of the mirror logic, adopt the incremental update strategy and only update the relevant part of the eBPF program; unload the old eBPF program, load the new eBPF program into the kernel, and mount it on the network device corresponding to the target container group. Among them, if the incremental update strategy is adopted, the system will only update the parts that need to change, and keep the running status of other parts unchanged.

[0068] Step S208, load the target program on the target device, and use the target program to perform traffic mirroring on the target container group, where the target program is used to determine the execution logic of traffic mirroring.

[0069] In the above step S208, the target program can be an eBPF program for implementing the traffic mirroring function, which contains a set of predefined logics for determining which network traffic needs to be mirrored and how to perform the mirroring operation, and converting the traffic mirroring requirements into specific network behaviors. Traffic mirroring is the process of copying network traffic to one or more specified mirror destinations.

[0070] To reduce the performance overhead brought by traditional network monitoring technologies and allow the traffic mirroring function to intercept and mirror network traffic at the kernel level without modifying the kernel source code, the target program (eBPF bytecode) can be loaded onto a specified network device of the Linux kernel through the eBPF interface. Specifically in implementation, the traffic mirroring system needs to call the system call related to bpf program load, passing the bytecode and parameters of the target program to the kernel, and the kernel mounts the program at the hook point of the target device (such as tc / egress).

[0071] In some embodiments of the present application, the eBPF program can run in the kernel to capture the network traffic of the target container group, and according to the mirror destination parameter in the mirror configuration information, copy the captured traffic to the specified destination. Specifically in implementation, the eBPF program can use the bpf_clone_redirect function to redirect the data packet to the network device of the mirror destination to achieve traffic mirroring. This method can ensure the precise control and high throughput of traffic mirroring. At the same time, since the eBPF program runs in the kernel, it avoids the frequent switching of data packets between the user space and the kernel space, reduces network latency, and improves the overall performance of the system.

[0072] To adapt to the changes in the network configuration of the container group in real time and ensure that the eBPF program is always executed on the correct network path and position, the target program can be loaded on the target device in the following way: determine the egress path corresponding to the target container group, where the egress path is the path through which the first data packet flows from the target container group to the external network or other container groups, and the egress path includes the target device; determine the target position on the egress path, where the target position includes the position where the first data packet leaves the target device; mount the target program at the target position, and when the first data packet passes through the target position, execute the target program.

[0073] In a containerized environment, the egress path refers to the path that the data packets of a Pod (container group) flow out from the network namespace where it runs, reach the host network stack, and finally are sent to the external network or other Pods. Determining the egress path is used to ensure that the traffic mirroring operation can accurately intercept the outbound traffic of the Pod, because traffic mirroring needs to intervene when the data packet leaves the Pod and has not yet reached the final destination. In some embodiments of the present application, by analyzing the network configuration of the Pod, the connection relationship between its internal network interface (one end of the veth pair) and the host network device can be determined, and then the path for the data packet to flow out of the Pod can be identified. This method ensures that the eBPF program can intercept the traffic of the Pod on the correct path, avoiding misoperations on non-target Pods or non-target traffic.

[0074] The target location is the specific location on the egress path of the Pod where the eBPF program will be attached, such as the location corresponding to the moment when the data packet leaves the target device. The role of the target location is to provide an interception point so that the eBPF program can mirror the traffic when the data packet passes by. In some embodiments of the present application, the hook points where the eBPF program can be attached in the egress path can be identified, such as tc / egress. Specifically, when implementing, the system can query the kernel network stack to find the traffic control (tc) hook points associated with the target device, and these points are located before the data packet leaves the target device and is ready to enter the external network. By accurately determining the target location, it can be ensured that the eBPF program can execute at the key nodes of network traffic transmission, reducing unnecessary data packet processing and improving the efficiency and speed of traffic mirroring.

[0075] Attaching refers to the process of binding the eBPF program to the kernel network stack at the target location on the egress path of the Pod. Through attachment, the eBPF program can be automatically triggered to execute when the data packet reaches the target location, realizing real-time interception and processing of the traffic. For example, using the eBPF interface provided by the kernel, the eBPF program is attached to the target location so that whenever a data packet passes through this location, the execution of the eBPF program will be triggered.

[0076] Through precise traffic mirroring, the present application can achieve in-depth monitoring of the network activities of specific Pods. Specifically: obtaining the target information of the second data packet of the target Pod, where the target information includes the header information of the second data packet; comparing the target information with the network information of the target Pod to obtain a comparison result; and in the case where the comparison result indicates that the second data packet belongs to the traffic of the target Pod, performing traffic mirroring on the second data packet according to the mirroring policy of the target program.

[0077] In some embodiments of the present application, the target information refers to the header information of the second data packet, including source IP, destination IP, source port, destination port, protocol type, etc. This information is used by the eBPF program to determine whether the data packet belongs to the traffic of the target container group. To ensure that the traffic mirroring system can directly obtain the data packet information at the kernel level and avoid the switching of data packets between the user space and the kernel space, when the eBPF program is executed at the hook point of the target device, it can directly access the header information of the data packet.

[0078] The network information refers to the network configuration information related to the target container group, including its IP address, port number, namespace where it is located, etc. The network information can be used as a reference standard for the target information. The eBPF program decides whether to perform traffic mirroring by comparing the target information of the second data packet with the network information of the target container group. For example, the eBPF program uses a comparison algorithm to compare the header information of the second data packet with the network information of the target container group to determine whether the data packet belongs to the outbound traffic of the target container group.

[0079] Through accurate comparison and judgment, it can be ensured that the traffic mirroring system only mirrors the traffic of the target container group, avoiding misprocessing of non-target traffic and improving the accuracy and pertinence of traffic mirroring.

[0080] To meet the requirements in different scenarios and improve the efficiency and pertinence of traffic monitoring, the mirroring policy can be flexibly configured. Specifically: The mirroring policy includes full traffic mirroring and selective traffic mirroring. The second data packet is subjected to traffic mirroring according to the mirroring policy of the target program: In the case of full traffic mirroring, it is determined that all second data packets will be subjected to traffic mirroring; in the case of selective traffic mirroring, the second data packets that meet the preset conditions are subjected to traffic mirroring.

[0081] Full traffic mirroring means copying and mirroring all network traffic related to the container group, regardless of its type, source, and destination, to the specified destination. Full traffic mirroring can provide the most comprehensive network communication records and is applicable to scenarios that require in-depth understanding of all network activities of the container group, such as security audits, troubleshooting, and performance monitoring.

[0082] Selective traffic mirroring is based on preset conditions or policies and only copies and mirrors network traffic that meets specific conditions. Selective traffic mirroring can reduce unnecessary network load and storage requirements, only focus on the traffic of interest, and improve the efficiency and pertinence of data processing.

[0083] A preset condition refers to a rule or condition used to filter packets to be mirrored in selective traffic mirroring, such as source IP / destination IP addresses, port numbers, protocol types, etc. The preset condition, as a filter, can help the eBPF program determine which packets should be mirrored and which packets can be ignored.

[0084] When there are multiple mirror destinations in the mirror configuration information, after performing traffic mirroring on the target container group using the target program, the following steps can also be executed: Obtain the type of the mirror destination, where the type includes a local network interface and a remote server, and the local network interface is an interface other than the outbound interface of the packets of the target container group; When the type of the mirror destination belongs to the local network interface, write the third packet to the local network interface; When the type of the mirror destination belongs to the remote server, send the third packet to the remote server through a network protocol.

[0085] During the process of traffic mirroring, the mirror destination refers to the network location that receives the mirror traffic, which can be a local network interface on the host or the IP address of a remote server. The local network interface refers to a network interface on the host other than the outbound interface of the network traffic of the target container group, which is used to receive the mirror traffic and is an internal receiving point for traffic mirroring, facilitating traffic analysis or security monitoring within the host or cluster and reducing the overhead of network transmission. The remote server refers to a server located outside the host that receives the mirror traffic, which can be a security audit system, a troubleshooting tool, or a performance analysis platform.

[0086] In some embodiments of the present application, based on the description of the destination in the mirror configuration information, it can be determined whether it belongs to a local network interface or a remote server. When the type of the mirror destination belongs to the local network interface, the eBPF program directly writes the copied packet (the third packet) to the specified local network interface through a system call; When the type of the mirror destination belongs to the remote server, the eBPF program or an auxiliary process on the host encapsulates the mirror traffic into a packet using a network protocol (such as TCP / IP or UDP), and then sends it to the remote server.

[0087] When the mirror destination is a remote server, there may be risks of network latency and packet loss, affecting the integrity and real-time nature of the mirror traffic. To solve this problem, in the eBPF program, a traffic compression module can be designed to compress the packets before sending, or the user space process can compress the packets before sending, so as to reduce the size of the mirror packets and thus reduce the overhead of network transmission.

[0088] Through the above steps S202 to S208, by adopting the method of real-time monitoring and dynamic matching, through analyzing the network information of multiple container groups in the container orchestration platform, the target container group that needs to perform traffic mirroring is determined, and the traffic of the target container group is efficiently mirrored, achieving the purpose of accurately mirroring the traffic of specific container groups in the container orchestration platform, thereby realizing the technical effect of fine-grained and accurate monitoring of traffic, and further solving the technical problem that due to the high dynamicity of Pods in Kubernetes, traditional traffic mirroring technologies rely on static network device information during configuration and cannot perceive Pod changes in a timely manner, resulting in the inability to accurately mirror the traffic of specific Pods.

[0089] In some embodiments of the present application, the traffic mirroring system may include an eBPF program module, a Pod management controller module, and a traffic mirroring management module. Taking the K8s cluster as an example, the system architecture is as follows:

[0090] (1) eBPF program module: Write an eBPF program and load it into the Linux kernel. Through the Pod information and destination information passed by the traffic mirroring management module, capture and process the network traffic of the Pod. The eBPF program is triggered to execute when the data packet leaves the network device by being mounted to the hook point (tc / egress) of the Pod network device.

[0091] (2) Pod management controller module: Interact with the K8s API server, watch the information of Pods in the cluster in real time, and determine whether this pod enables the traffic mirroring function by judging whether there is a <mirror.io = true> field in the annotation. Obtain the information of Pods that enable the traffic mirroring function in the K8s cluster, including but not limited to the name, namespace, veth information (network card index), etc. of the Pod, and pass the qualified Pod information to the traffic mirroring management module.

[0092] (3) Traffic mirroring management module: Responsible for obtaining the Pod information (mainly the network card index) that needs traffic mirroring from the k8s management module, and configuring the parameters of traffic mirroring, such as the mirror destination (which can be another network interface), and then passing the network card index that needs to be mirrored and the destination information to the eBPF program.

[0093] Figure 3 It is the overall flowchart of another traffic mirroring method according to the embodiments of the present application. As Figure 3 shown, this process includes the following steps:

[0094] Step S302: Start.

[0095] This step is automatically triggered when the system starts up, or the user can manually start the traffic mirroring function through the command line or graphical interface. In the specific implementation, the system initializes and loads the necessary configuration information to ensure that all modules are ready to execute the traffic mirroring task.

[0096] Step S304: The Pod management controller module obtains the cluster Pod information.

[0097] The Pod management controller interacts with the Kubernetes API server and uses the watch mechanism to continuously monitor all Pod creation, deletion, and update events in real time, thereby obtaining the latest information of all Pods in the cluster. Specifically, the Pod management controller module needs to call the Kubernetes API to obtain the metadata of the Pod, including the name, namespace, IP address, and network interface information of the Pod. To improve efficiency, the Pod management controller can cache the recently obtained Pod information to reduce frequent requests to the API server.

[0098] Step S306: Determine whether the traffic mirroring function is enabled.

[0099] The Pod management controller checks the labels or annotations of each Pod to find whether there is a specific label or annotation indicating the enabling of traffic mirroring (such as mirror.io = true). If it exists, it is considered that this Pod requires traffic mirroring and jumps to step S308; if it does not exist, it jumps to step S304 to continue listening for Pod events or processing the information of other Pods.

[0100] Step S308: The Pod management controller module obtains the host device index number corresponding to this Pod.

[0101] Once it is determined that a Pod requires traffic mirroring, the Pod management controller module will query the Kubernetes network plugin or use Linux network namespace operations to obtain the kernel index number of the Pod network interface (such as one end of veth) where this Pod is located. This index number is crucial for loading the eBPF program on the correct network device later.

[0102] Step S310: Load the eBPF program onto this device.

[0103] The traffic mirroring management module uses the eBPF-related kernel API to load the pre-compiled eBPF program bytecode onto the specified network device of the host. To ensure compatibility and security, the eBPF bytecode can be verified and optimized before loading, such as using the bpf_prog_load function to load the program.

[0104] Step S312: Load the eBPF program into the kernel and attach it to the hook point.

[0105] After the eBPF program is loaded into the kernel, the traffic mirroring management module needs to further call the bpf programattach related functions to attach the eBPF program to the hook point of the network device, such as tc / egress. In this way, whenever a data packet passes through the outbound path of this device, the eBPF program will be triggered to execute.

[0106] Step S314: Traffic mirroring.

[0107] In the eBPF program, the bpf_clone_redirect function is used to capture the network traffic of the Pod and copy it to the mirror destination. The eBPF program can also contain traffic filtering logic to ensure that only data packets that meet the mirroring policy are mirrored, such as checking the source IP, destination IP, port, and protocol type of the data packet.

[0108] Step S316: Send to the mirror destination.

[0109] According to the type of the mirror destination (local network interface or remote server), the eBPF program or the auxiliary user space process will send the mirrored traffic to the corresponding destination. For the local network interface, the eBPF program can directly call the kernel interface to write the data packet to the specified interface; for the remote server, the user space process can encapsulate the data packet using a network protocol (such as TCP or UDP) and send it.

[0110] Step S318: Monitor and analyze the traffic.

[0111] The traffic mirroring system can also include a monitoring and analysis module, which is responsible for collecting the running data of the eBPF program, such as the number of mirrored data packets, traffic size, latency, etc., and then analyzing this data to generate statistical reports or real-time alerts. The monitoring data can be collected through eBPF maps or other kernel data structures, and the analysis results can be displayed in real time in the graphical interface or log file to help users quickly identify network anomalies or performance bottlenecks.

[0112] To facilitate the understanding of the implementation process of the above traffic mirroring method, a specific embodiment will be described below.

[0113] S1. Environment preparation: Install and configure the Kubernetes cluster to ensure that the cluster is running properly and contains the Pods that need to perform traffic mirroring. Install the Linux kernel that supports eBPF on the cluster nodes, and ensure that the relevant development tools and libraries (such as clang, llvm, libbpf, etc.) are installed.

[0114] S2. System Deployment: Compile and install the eBPF-based Pod traffic mirroring system provided by the present invention, including the eBPF program module, the K8s management module, and the traffic mirroring management module. Configure the connection information between the system and the K8s API server to ensure that the information of Pods can be obtained normally.

[0115] S3. Configure the Pod management controller and traffic mirroring: Through the interface or command-line tool, add the annotation field <mirror.io = true> to the target Pod that needs traffic mirroring, and configure the mirror destination, such as selecting a virtual network interface.

[0116] S4. Start traffic mirroring: Start the eBPF-based Pod traffic mirroring system. The system will automatically load the eBPF program into the kernel and start capturing and mirroring the traffic of the target Pod. Users can view the statistical information of the traffic mirroring in real time through the command-line tool (such as tcpdump the traffic of the target network card).

[0117] S5. Configure parameters: During the operation of the system, users can dynamically adjust the mirror configuration according to actual needs, such as modifying the mirror destination, stopping the traffic mirroring function of this Pod, etc. The system will automatically update the eBPF program and mirror operations according to the new configuration to ensure the accuracy and flexibility of traffic mirroring.

[0118] This application efficiently processes network packets through the kernel-level eBPF technology, significantly improving the performance of Pod traffic mirroring in the Kubernetes environment and reducing system resource consumption; at the same time, it has high flexibility, and users can freely select target Pods according to their needs, customize mirroring policies and destinations to adapt to diverse scenarios; furthermore, through fine-grained control, it realizes the precise mirroring of the traffic of a single Pod, enhancing the ability to solve network problems, security auditing, and performance optimization. This application is deeply integrated with the Kubernetes platform and automatically synchronizes Pod information, and has the following advantages:

[0119] (1) Deep integration of eBPF and K8s.

[0120] Through the real-time interaction between the K8s management module of this application and the K8s API server, it can dynamically obtain the detailed information of all Pods in the Kubernetes cluster, including but not limited to the name, namespace, IP address, etc. of the Pod. When the user specifies the target Pod that needs traffic mirroring, the system can quickly and accurately match the corresponding Pod information in the Pod information list, realizing the precise positioning of the traffic of the specific Pod. This dynamic acquisition and matching mechanism ensures that the system can adapt to the dynamic creation, destruction, and migration of Pods in the K8s environment and always maintain effective monitoring of the target Pod.

[0121] Moreover, according to the mirror parameters configured by the user, the mirror management module can flexibly generate or select appropriate eBPF program codes. These eBPF programs can adapt to different network environments and mirror requirements, be loaded into the Linux kernel through system calls, and be attached to specified network device hook points. This adaptive loading mechanism enables the system to customize the traffic mirroring logic according to actual needs without modifying the kernel source code, improving the versatility and flexibility of the system.

[0122] (2) Efficient traffic capture and processing mechanism.

[0123] This application can perform kernel-level packet parsing. The eBPF program directly parses network packets in the Linux kernel, avoiding frequent switching of packets between user space and kernel space and improving the efficiency of packet processing. By parsing the header information of the packets, the eBPF program can quickly obtain key information such as source IP address, destination IP address, port number, etc., providing a basis for subsequent traffic judgment and mirroring operations.

[0124] In addition, using the obtained packet information, the eBPF program can accurately determine whether a packet belongs to the traffic of the target Pod. By matching with the information of the target Pod and combining the mirroring policy configured by the user (such as full traffic mirroring or selective mirroring according to specific conditions), the system can precisely decide which packets need to be mirrored and which packets can be ignored, thus achieving fine-grained traffic control and mirroring operations.

[0125] (3) Flexible traffic mirroring transmission strategy.

[0126] This application supports mirroring the captured Pod traffic to multiple different destinations, including but not limited to another local network interface, remote server, etc. This diverse support enables users to select appropriate mirroring destinations according to actual needs, facilitating operations such as network fault troubleshooting, security auditing, and performance analysis.

[0127] Meanwhile, according to the type of mirroring destination, the data transmission module of the traffic mirroring system can adaptively select an appropriate transmission method. For example, when the mirroring destination is a local network interface, the data transmission module can directly write the copied packets to the network interface; when the mirroring destination is a remote server, the data transmission module can send the packets to the remote server through network protocols (such as TCP, UDP, etc.). This adaptive transmission method ensures that the mirrored data can be accurately and efficiently transmitted to the specified destination.

[0128] (4) Real-time monitoring and dynamic adjustment function.

[0129] This application can monitor the running status of eBPF programs and the situation of traffic mirroring in real time, including but not limited to the number of mirrored data packets, transmission rate, execution efficiency of eBPF programs, etc. By collecting and analyzing these monitoring data, users can timely understand the running situation of the system and discover potential problems and anomalies.

[0130] Moreover, users can dynamically adjust the mirror configuration according to actual needs through the interface or command-line tool, such as modifying the mirror destination, adjusting the mirror policy, etc. After receiving the new configuration information, the system can automatically update the eBPF program and mirror operations to ensure that traffic mirroring is always carried out according to the latest configuration, improving the flexibility and adaptability of the system.

[0131] Figure 4 It is a structural diagram of a traffic mirroring device according to an embodiment of the present application, as Figure 4 shown. The device includes:

[0132] An acquisition module 402, configured to acquire network information of multiple container groups in the container orchestration platform, where a container group is the smallest computing unit in the container orchestration platform, and one container group includes at least one container;

[0133] A first determination module 404, configured to determine a target container group that needs to perform traffic mirroring based on the network information;

[0134] A second determination module 406, configured to determine a target device corresponding to the target container group on the host, where the target device includes a network device directly associated with the target container group;

[0135] A mirroring module 408, configured to load a target program on the target device and use the target program to perform traffic mirroring on the target container group, where the target program is used to determine the execution logic of traffic mirroring.

[0136] It should be noted that Figure 4 the shown traffic mirroring device is used to execute Figure 2 the shown traffic mirroring method. Therefore Figure 2 the relevant explanations in the traffic mirroring method in Figure 4 also apply to the shown traffic mirroring device, and will not be elaborated here.

[0137] The embodiment of the present application also provides an electronic device, which includes a memory and a processor. The memory is used to store program instructions; the processor is connected to the memory and is configured to execute the steps of implementing the traffic mirroring method in each embodiment of the present application.

[0138] For example, the processor performs the following functions by executing program instructions stored in the memory: obtaining network information of multiple container groups within a container orchestration platform, where a container group is the smallest computing unit within the container orchestration platform, and a container group includes at least one container; determining a target container group that needs traffic mirroring based on the network information; determining a target device corresponding to the target container group on the host, where the target device includes a network device directly associated with the target container group; loading a target program on the target device and using the target program to perform traffic mirroring on the target container group, where the target program is used to determine the execution logic of traffic mirroring.

[0139] An embodiment of the present application also provides a non-volatile storage medium, which includes a stored computer program. The device where the non-volatile storage medium is located executes the steps of the traffic mirroring method in various embodiments of the present application by running the computer program.

[0140] An embodiment of the present application also provides a computer program product, including computer instructions, which implement the steps of the traffic mirroring method in various embodiments of the present application when executed by a processor.

[0141] An embodiment of the present application also provides a computer program, which implements the steps of the traffic mirroring method in various embodiments of the present application when executed by a processor.

[0142] The serial numbers of the above embodiments of the present application are only for description and do not represent the superiority or inferiority of the embodiments.

[0143] In the above embodiments of the present application, the descriptions of the various embodiments have their own emphases. For parts not detailed in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0144] In several embodiments provided by the present application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only illustrative. For example, the division of the units can be a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of units or modules can be in an electrical or other form.

[0145] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0146] In addition, in each embodiment of the present application, each functional unit may be integrated into a processing unit, may exist separately as individual physical units, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of a software functional unit.

[0147] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it may be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, may be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present application. The foregoing storage medium includes: various media such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), mobile hard disks, magnetic disks, or optical discs that can store program codes.

[0148] The above are only the preferred embodiments of the present application. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present application.

Claims

1. A method for traffic mirroring, characterized in that, Including: Obtain network information of multiple container groups within a container orchestration platform, where a container group is the smallest computing unit within the container orchestration platform, and one container group includes at least one container; Determine a target container group that needs to perform traffic mirroring based on the network information; Determine a target device corresponding to the target container group on a host machine, where the target device includes a network device directly associated with the target container group; Load a target program on the target device, and use the target program to perform traffic mirroring on the target container group, where the target program is used to determine the execution logic of the traffic mirroring.

2. The method according to claim 1, characterized in that, Loading the target program on the target device includes: Determine an egress path corresponding to the target container group, where the egress path is the path through which a first data packet flows from the target container group to an external network or another container group, and the egress path includes the target device; Determine a target location on the egress path, where the target location includes the location where the first data packet leaves the target device; Mount the target program at the target location, and execute the target program when the first data packet passes through the target location.

3. The method according to claim 1, characterized in that Using the target program to perform traffic mirroring on the target container group includes: Obtain target information of a second data packet of the target container group, where the target information includes the header information of the second data packet; Compare the target information with the network information of the target container group to obtain a comparison result; When the comparison result indicates that the second data packet belongs to the traffic of the target container group, perform traffic mirroring on the second data packet according to the mirroring policy of the target program.

4. The method according to claim 3, characterized in that The mirroring policy includes full traffic mirroring and selective traffic mirroring. Performing traffic mirroring on the second data packet according to the mirroring policy of the target program includes: When the mirroring policy is full traffic mirroring, determine that all the second data packets are to be subjected to traffic mirroring; When the mirroring policy is selective traffic mirroring, perform traffic mirroring on the second data packets that meet the preset conditions.

5. The method according to claim 1, characterized in that, After determining the target device corresponding to the target container group on the host machine, the method further includes: Obtain mirror configuration information of the target container group, where the mirror configuration information includes a mirror destination, and the mirror destination includes an address for receiving network traffic from the target container group; Determine the target program based on the mirror configuration information and the information corresponding to the target device.

6. The method according to claim 5, wherein The mirror configuration information includes multiple mirror destinations. After using the target program to perform traffic mirroring on the target container group, the method further includes: Obtain the type of the mirror destination, where the type includes a local network interface and a remote server, and the local network interface is an interface other than the outbound interface of the data packets of the target container group; When the type of the mirror destination belongs to the local network interface, write a third data packet to the local network interface. When the type of the mirror destination belongs to the remote server, the third data packet is sent to the remote server through a network protocol.

7. The method according to claim 1, wherein Determining a target container group that needs traffic mirroring according to the network information, including: obtaining target parameters in the network information, and determining the target container group according to the target parameters, where the target parameters include descriptive parameters additionally configured in the annotation field of the target container group, and the target parameters are used to indicate whether the container group meets the conditions for traffic mirroring.

8. An apparatus for traffic mirroring, characterized in that, Including: An obtaining module, configured to obtain network information of multiple container groups in a container orchestration platform, where the container group is the smallest computing unit in the container orchestration platform, and one container group includes at least one container; A first determination module, configured to determine a target container group that needs traffic mirroring according to the network information; A second determination module, configured to determine a target device corresponding to the target container group on a host machine, where the target device includes a network device directly associated with the target container group; A mirroring module, configured to load a target program on the target device, and use the target program to perform traffic mirroring on the target container group, where the target program is used to determine the execution logic of the traffic mirroring.

9. An electronic device, characterized in that, Including: A memory and a processor, where the memory is used to store program instructions; the processor is connected to the memory and is configured to execute the method for traffic mirroring according to any one of claims 1 to 7.

10. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored computer program, where the device where the non-volatile storage medium is located executes the method for traffic mirroring according to any one of claims 1 to 7 by running the computer program.

11. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by a processor, the method for traffic mirroring according to any one of claims 1 to 7 is implemented.

Images