Rate control method and device for Docker container virtual network

Abstract

The invention relates to the technical field of computers, in particular to a rate control method and device for a Docker container virtual network. The method comprises the following steps: acquiring event data corresponding to a Docker internal event, and extracting network event characteristics in the event data; judging whether the Docker internal event is a virtual network creation event or a virtual network abnormal event based on the network event characteristics; if the Docker internal event is a virtual network creation event or a virtual network abnormal event, obtaining a network flow control parameter corresponding to the virtual network creation event or the virtual network abnormal event; and performing traffic control on the Docker internal event in a preset mode according to the network traffic control parameter. According to the invention, fairness and flow distribution of the container in the same network environment can be ensured, and an individual task container is prevented from occupying excessive bandwidth resources.

Description

Technical Field

[0001] This invention relates to the field of computers, and more particularly to a rate control method and apparatus for Docker container virtual networks. Background Technology

[0002] In a Docker cluster environment on a domestic operating system platform, developers package applications and their dependencies into lightweight, portable container images. A Docker cluster typically runs container instances based on multiple container images, with Docker deployed on a Linux host machine. Each container communicates with other containers or external systems through a virtual network provided by the Docker engine, forming an isolated but interconnected virtual network topology. When events within a container trigger sudden traffic spikes, without effective bandwidth management strategies, individual task containers may consume a large amount of host machine network bandwidth resources in a short period. Since multiple business containers in a Docker cluster typically share the same physical network interface, this traffic influx can crowd out the available bandwidth of other containers, causing congestion in the overall virtual network and leading to issues such as delayed response times, data loss, and even service anomalies. Therefore, improving network resource utilization efficiency, ensuring fairness and traffic allocation among containers in the same network environment, and preventing individual task containers from consuming excessive bandwidth resources have become problems that need to be solved.

[0003] In addition, current methods often use network traffic monitoring tools, such as the CNI (Container Network Interface) plugin or Prometheus + cAdvisor, to monitor the bandwidth usage of each Docker container in real time, thereby confirming whether a particular container is excessively consuming bandwidth resources. However, in a virtualized environment, the network of a Docker container is not directly exposed to the host machine's network stack. Instead, it is isolated through technologies such as network bridging and virtual network interfaces. This network isolation can lead to errors in the monitoring tools' capture of container traffic, especially when inter-container communication is forwarded through different network interfaces or multi-layered virtualized networks. In such cases, traffic monitoring tools are even less able to accurately identify the actual traffic between containers.

[0004] Therefore, overcoming the shortcomings of the existing technology is an urgent problem to be solved in this technical field. Summary of the Invention

[0005] In view of the above-mentioned defects or improvement needs of the existing technology, the present invention provides a rate control method and apparatus for Docker container virtual networks. The present invention can ensure the fairness and traffic allocation of containers in the same network environment and avoid individual task containers from consuming too much bandwidth resources.

[0006] The embodiments of the present invention adopt the following technical solutions: In a first aspect, the present invention provides a rate control method for Docker container virtual networks, specifically: obtaining event data corresponding to internal Docker events, and extracting network event features from the event data; Based on the network event characteristics, determine whether the Docker internal event is a virtual network creation event or a virtual network anomaly event; If the Docker internal event is a virtual network creation event or a virtual network exception event, then obtain the network traffic control parameters corresponding to the virtual network creation event or the virtual network exception event; Based on the network traffic control parameters, traffic management is performed on the internal events of Docker according to a preset method.

[0007] Preferably, the method includes: Based on the network event characteristics, traffic surge anomalies, time series anomalies, protocol anomalies, and network connection anomalies are calculated. The combined anomaly value is obtained by weighted summation of the traffic surge anomaly value, the time series anomaly value, the protocol anomaly value, and the network connection anomaly value. Based on the comprehensive anomaly value, obtain the network traffic control parameters corresponding to the virtual network anomaly event.

[0008] Preferably, the comprehensive anomaly value is obtained by weighted summation of the traffic surge anomaly, the time series anomaly, the protocol anomaly, and the network connection anomaly, and the calculation formula is as follows: ; in, The aforementioned comprehensive outlier, The aforementioned abnormal value of sudden increase in traffic. The weight value corresponding to the abnormal traffic surge. These are the outliers in the time series. The weight value corresponding to the outlier in the time series. This is an abnormal value in the protocol. The weight value corresponding to the protocol outlier. The network connection anomaly value, The weight value corresponding to the network connectivity anomaly value. The size of the observation time window is given by , where t is the t-th time point within the observation time window. This represents the traffic increase index at time point t. This represents the flow rate at time t. This represents the moving average at time t. This represents the moving standard deviation at time t. Let be the rate of change of the protocol at time t. Let be the information entropy at time t. The preset average information entropy.

[0009] Preferably, the method further includes: ; ; ; ; in, This represents the traffic increase index at time point t. This represents the flow rate at time point t. Indicates the first Average flow rate at any given time; This represents the moving average at time t. This represents the moving standard deviation at time t. This represents the size of the sliding window, where i represents each time point. This represents the flow rate at the i-th time point; Let be the rate of change of the protocol at time t. To indicate the first The frequency of the protocol used at time t represents the frequency of the t. The frequency of the protocol used at any given time; Let be the information entropy at time t, i represent each combination of source or destination IP and port, the range of which depends on the complexity of the network connection, p(i,t) be the probability of the occurrence of the i-th type of IP or port at time t, and n be the total number of IPs or ports.

[0010] Preferably, the method for controlling the traffic of Docker internal events according to the network traffic control parameters and a preset method includes: Based on the network traffic control parameters, obtain the virtual network control rate limiting rules corresponding to the network traffic control parameters from the preset management and control policy database; Traffic control is applied to the internal events of Docker based on the virtual network control rate limiting rules.

[0011] Preferably, before obtaining the virtual network control rate limiting rule corresponding to the network traffic control parameters from the preset management and control policy database based on the network traffic control parameters, the preset management and control policy database needs to be constructed, and the method further includes: Obtain multiple preset network traffic control parameters; Multiple preset virtual network control rate limiting rules are constructed based on multiple preset network traffic control parameters; Establish a preset mapping relationship between multiple preset virtual network control rate limiting rules and multiple network traffic control parameters, wherein one network traffic control parameter corresponds to one preset virtual network control rate limiting rule; The preset mapping relationship is stored in the preset management strategy database.

[0012] Preferably, the method further includes: A virtual Ethernet device pair is established between the host machine and the container, wherein one end of the virtual Ethernet device pair is located in the host machine namespace and the other end is located in the container namespace; The virtual Ethernet device is used to logically connect the network device that connects the host machine and the container, so that each container instance and the host machine have independent ingress control hooks and egress control hooks respectively; Virtual network control rate limiting rules are attached to the inlet control hook and / or outlet control hook to perform precise control on network traffic flowing into and / or out of the container based on the virtual network control rate limiting rules.

[0013] Preferably, the event data includes timestamp data, traffic information data, and protocol data, and the method further includes: Based on the timestamp data, obtain the time series characteristics corresponding to the internal events of the Docker; Based on the traffic information data, obtain the traffic data characteristics corresponding to the Docker internal events; Based on the protocol data, obtain the protocol type characteristics corresponding to the Docker internal events; By integrating the time series features, the traffic data features, and the protocol type features, the network event features corresponding to the Docker internal events are obtained.

[0014] Secondly, the present invention provides a rate control system for Docker container virtual networks. The rate control system for Docker container virtual networks includes an acquisition module and a processing module, wherein... The acquisition module is used to acquire event data corresponding to internal Docker events and extract network event features from the event data. The processing module is used to determine whether the Docker internal event is a virtual network creation event or a virtual network abnormal event based on the network event characteristics; if the Docker internal event is a virtual network creation event or a virtual network abnormal event, then obtain the network traffic control parameters corresponding to the virtual network creation event or the virtual network abnormal event; and perform traffic control on the Docker internal event according to the network traffic control parameters in a preset manner.

[0015] Thirdly, the present invention provides a rate control apparatus for a Docker container virtual network, the apparatus comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor to perform the rate control method for a Docker container virtual network as described in the first aspect.

[0016] Fourthly, the present invention also provides a non-volatile computer storage medium storing computer-executable instructions that are executed by one or more processors to perform the rate control method for Docker container virtual networks described in the first aspect.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: it listens to the internal events of Docker container runtime, and when the internal event is a virtual network creation event or a virtual network abnormal event, it extracts the network traffic control parameters of the internal event in real time, and performs traffic control on the internal event according to the network traffic control parameters, so as to improve the utilization efficiency of network resources, ensure the fairness and traffic allocation of containers in the same network environment, and avoid individual task containers occupying too much bandwidth resources, affecting the normal operation of other containers. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0019] Figure 1 This is a flowchart illustrating a rate control method for Docker container virtual networks provided in an embodiment of the present invention. Figure 2 This is a flowchart illustrating the method for obtaining network event characteristics provided in an embodiment of the present invention; Figure 3This is a flowchart illustrating the method for determining whether an internal event is a virtual network anomaly event, as provided in an embodiment of the present invention. Figure 4 This is a flowchart illustrating the method for creating a preset control strategy database provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of virtual network traffic direction provided by an embodiment of the present invention; Figure 6 This is a schematic diagram of a rate control system for a Docker container virtual network provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of a rate control device for Docker container virtual networks provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0021] Unless the context otherwise requires, throughout the specification and claims, the term "comprising" is interpreted as openly inclusive, meaning "including, but not limited to." In the description of the specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this disclosure. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics mentioned may be included in any suitable manner in any one or more embodiments or examples; that is, although they may be incorporated into embodiments or examples using the above terms for reasons such as order and position, it does not limit them to be incorporated in combination by a single embodiment or example.

[0022] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more. Furthermore, for example, the description may use the prefix "A" or "B" to describe the same type of nouns as two independent entities. In this case, the corresponding features defined with "A" and "B" are used only to distinguish between similar entities and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features.

[0023] In the description of this invention, the expression “A and / or B” (where A and B are used to formally represent specific features) will be used. The corresponding expression includes the following three combinations: only A, only B, and a combination of A and B.

[0024] As used in this invention, “about,” “approximately,” or “approximately” includes the stated value and the average value within an acceptable range of deviation from a particular value, wherein the acceptable range of deviation is determined by a person skilled in the art taking into account the measurement under discussion and the error associated with the measurement of the particular quantity (i.e., the limitations of the measurement system).

[0025] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0026] Example 1: To enable those skilled in the art to better understand the technical solution of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings.

[0027] like Figure 1 As shown, this embodiment provides a rate control method for Docker container virtual networks, which specifically includes the following steps: Step 101: Obtain the event data corresponding to the internal events of Docker, and extract the network event features from the event data.

[0028] Specifically, Docker's internal events are monitored and acquired in real time through the event streaming interface provided by Docker (usually via the Docker events command or the Docker API). These internal events include container lifecycle events (such as creation, startup, and shutdown), network-related events (such as the creation, updating, and deletion of virtual networks), and other events related to the container's running state. The event data differs depending on the type of internal event. All internal events include basic metadata (such as event type, specific action, and event timestamp). When an internal event involves container-related events, the event data also includes the container's Identity Document (ID) and container name. When an internal event involves network-related events, the event data also includes the network ID, network name, and container information associated with that network. During the process of a container connecting to or disconnecting from a virtual network, the event data also includes the Internet Protocol (IP) address assigned to the associated container, subnet information, and port mapping configuration to identify the communication patterns between containers. The event timestamp indicates the specific time the internal event occurred; it is typically a Unix timestamp and can be used for subsequent time-series analysis.

[0029] In one embodiment, event data contains a large amount of information, thus requiring filtering and parsing of the event data in the event stream. Particular attention is paid to network events (such as virtual network creation, updates, and deletions) and related container information, especially in events related to network creation and container lifecycle. Network-related events can be filtered from the event data, extracting event data (such as network name, container ID, network type, and protocol) and performing feature extraction to obtain network event features (including time-series features, traffic data features, and protocol type features). In other words, the raw information obtained from the event data is transformed into features usable for model analysis. The feature extraction process includes extracting key features from different dimensions such as timestamps, traffic, protocols, IP addresses, and ports. It should be noted that the network event features that can be extracted in this invention are not limited to those mentioned above. More types of network features can be extracted from Docker internal event data according to actual conditions and needs. For specific methods of obtaining network event features, please refer to [link to relevant documentation]. Figure 2 A flowchart.

[0030] Step 102: Determine whether the Docker internal event is a virtual network creation event or a virtual network anomaly event based on the network event characteristics.

[0031] In one embodiment, a trained virtual network event recognition model can be used to determine whether an internal Docker event is a virtual network creation event or a virtual network anomaly event.

[0032] In one embodiment, the sheer number of virtual networks, the complex internal traffic, and the increasing prevalence of encrypted traffic make comprehensive monitoring of every data stream exceptionally difficult and inefficient. Therefore, this embodiment transforms traffic control of virtual networks into traffic control of virtual network creation events and traffic management of abnormal virtual network events. On the one hand, managing virtual network creation events essentially involves forcibly binding network resource policies such as bandwidth limiting, latency control, packet loss rate constraints, and traffic scheduling at the time of network entity creation. This design is equivalent to defining the boundaries of transmission behavior before traffic is generated, avoiding network congestion, service quality loss, or resource abuse caused by unrestricted or unreasonable resource allocation, thereby establishing a predictable and manageable network operation baseline from the source. On the other hand, when abnormal events occur during virtual network operation (such as sudden bandwidth surges, abnormal scheduling paths, sudden increases in latency, etc.), the system can identify, limit, or adjust scheduling in real time according to preset performance rules. This design not only ensures network service quality but also quickly detects potential faults or abuse through abnormal traffic behavior patterns, achieving a closed loop of operation and management.

[0033] Step 103: If the Docker internal event is a virtual network creation event or a virtual network exception event, then obtain the network traffic control parameters corresponding to the virtual network creation event or the virtual network exception event.

[0034] In one embodiment, if the virtual network event identification model determines that the internal event is neither a virtual network creation event nor a virtual network anomaly event, it continues to evaluate the next internal event in Docker until all Docker internal events have been evaluated. If the virtual network event identification model determines that the internal event is a virtual network creation event, it directly obtains the network traffic control parameters corresponding to the virtual network creation event. If the virtual network event identification model determines that the internal event is a virtual network anomaly event, it obtains a comprehensive anomaly value by weighted summation of the anomaly values, and obtains the network traffic control parameters corresponding to the virtual network anomaly event through the comprehensive anomaly value. These network traffic control parameters include bandwidth parameters, latency parameters, packet loss rate parameters, and traffic shape parameters.

[0035] In one embodiment, a mapping relationship between virtual network creation events, virtual network anomaly events, and network traffic control parameters is pre-built. Specifically, a virtual network creation event is associated with a set of default or context-based network traffic control parameters. If the network traffic control parameters are default, each virtual network creation event corresponds to the same network traffic control parameters; if the network traffic control parameters are context-based, each virtual network creation event corresponds to different network traffic control parameters. Each type of anomaly event corresponds to a specific network traffic control parameter configuration for targeted traffic regulation and response. Furthermore, this mapping relationship can be stored as a policy template in a configuration library or policy engine. When a creation event or an anomaly event occurs, the mapping table in the configuration library or policy engine is queried based on the event type and context to obtain parameters such as bandwidth, latency, packet loss rate, and traffic shaping corresponding to the event.

[0036] Step 104: Based on the network traffic control parameters, manage the traffic of the Docker internal events according to a preset method.

[0037] In one embodiment, based on network traffic control parameters, the virtual network control rate limiting rules corresponding to the network traffic control parameters are obtained from a preset management policy database. If the internal event is a virtual network creation event, then according to the virtual network control rate limiting rules, during resource instantiation, the virtual network control rate limiting rules are solidified into the underlying data plane of the virtual network, thereby constraining its maximum usable bandwidth from the source and preventing over-specified resource configurations from taking effect. If the internal event is a virtual network anomaly event, then according to the virtual network control rate limiting rules, real-time observed deviations in traffic behavior are intervened and corrected. The virtual network control rate limiting rules include a series of settings and rules used to control traffic characteristics within the virtual network. Traffic control is used to limit network traffic associated with the virtual network creation event. The method for creating the preset management policy database is described in [reference needed]. Figure 4 A flowchart.

[0038] In one embodiment, traffic management can be applied to internal Docker events, thereby applying virtual network control rate limiting rules to virtual devices to limit the overall bandwidth usage of the physical network interface card (NIC), and thus precisely control the upper limit and priority of traffic for each container. Specifically, a virtual Ethernet device pair is established between the host machine and the container, where one end of the virtual Ethernet device pair is located in the host machine's namespace and the other end is located in the container's namespace. The virtual Ethernet device pair is used to logically connect the network devices of the host machine and the container, so that each container instance and the host machine have independent ingress control hooks and egress control hooks. Virtual network control rate limiting rules are attached to the ingress control hooks and / or egress control hooks to perform precise control on network traffic flowing into and / or out of the container based on the virtual network control rate limiting rules (including precise adjustment of at least one of bandwidth, latency, and packet loss rate). The virtual network control rate limiting rules correspond to network traffic control parameters. The host machine refers to the physical or virtual operating system instance running the container, providing underlying computing, storage, and network resources, and hosting the container's runtime environment. A container is a lightweight, isolated user-space instance containing an application and its dependencies. Through the Linux kernel's namespace and control group mechanisms, it can achieve resource isolation and restriction from the host machine and other containers. That is, the container's virtual network interface card is connected to the host machine's network namespace, enabling the container to communicate with the outside world. At the same time, it allows the host machine to apply traffic control policies such as rate limiting, latency, and packet loss to the interface, thereby achieving fine-grained management of the network behavior of each container.

[0039] In this embodiment, internal events during Docker container runtime are monitored. When an internal event is a virtual network creation event or a virtual network anomaly event, the network traffic control parameters of the internal event are extracted in real time, and traffic control is performed on the internal event based on the network traffic control parameters to improve the utilization efficiency of network resources, ensure fairness and traffic allocation among containers in the same network environment, and prevent individual task containers from consuming too much bandwidth resources and affecting the normal operation of other containers.

[0040] Event data includes timestamp data, traffic information data, and protocol data.

[0041] like Figure 2 As shown in the figure, this embodiment provides a method for obtaining network event characteristics, which specifically includes the following steps: Step 201: Obtain the time series features corresponding to the internal events of the Docker based on the timestamp data.

[0042] In one embodiment, timestamp data typically records the specific time points when internal events occur. Based on the timestamps of internal events, various time-series features can be extracted for in-depth analysis of event behavior patterns. Time-series features include the time intervals between internal events, the duration of events, and the frequency of events within a specific time window. For example, by analyzing the timestamps of multiple internal events (such as virtual network creation events), the time interval between two consecutive events can be calculated, thereby determining whether the events are periodic or sudden: if the time intervals are relatively uniform, it may indicate that the system is in a stable operating state; if a large number of short time intervals occur, it may reflect sudden business demands or abnormal behavior. Event frequency refers to the number of events occurring within a fixed time window. Monitoring changes in event frequency helps identify whether there are abnormal fluctuations. For example, virtual network creation events may concentrate during certain peak periods, leading to a surge in resource usage or a sharp increase in network load. This concentration is often closely related to specific business activities. Furthermore, trend analysis of time-series data can reveal the overall pattern of network event evolution over time. For example, virtual network creation events may exhibit a clustering effect at fixed times each day, reflecting concentrated changes in background task scheduling, user behavior patterns, or peak business periods. By comprehensively utilizing these time series features, we can not only help understand the normal behavior of the system, but also provide an important basis for anomaly detection and resource optimization.

[0043] Step 202: Obtain the traffic data characteristics corresponding to the Docker internal events based on the traffic information data.

[0044] In one embodiment, traffic data characteristics refer to key indicators extracted from network traffic information that reflect traffic behavior, such as bandwidth usage, traffic rate, packet size, and traffic fluctuations. These characteristics help assess the impact of virtual network creation events on overall network performance. Bandwidth usage reflects the network bandwidth resources consumed during virtual network creation or updates. Monitoring this indicator can determine whether such events consume excessive bandwidth, potentially affecting the normal operation of other services. Traffic rate refers to the amount of data transmitted in the network per unit time (such as bytes or packets transmitted per second), and can be used to identify sudden increases or decreases in traffic. For example, virtual network creation events are often accompanied by a sudden surge in data traffic; this significant change can serve as an important basis for identifying virtual network creation events. Analyzing the distribution of packet sizes during virtual network transmission can further reveal the compositional characteristics of the traffic. For example, if large packets dominate during the event, it may indicate that mirroring deployment, configuration synchronization, or other batch data operations are underway, which helps distinguish different types of network activity. Furthermore, traffic volatility characteristics can be used to assess the stability of network load. Virtual network creation events typically trigger drastic changes in traffic within a short period, leading to network load instability. By quantifying the degree of flow fluctuation (such as standard deviation, coefficient of variation, etc.), such sudden behaviors can be effectively captured, and support can be provided for anomaly detection and capacity planning.

[0045] Step 203: Obtain the protocol type characteristics corresponding to the Docker internal event based on the protocol data.

[0046] In one embodiment, by analyzing protocol information in event data, the network protocol type used by the data packets can be identified, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP). Since different protocols differ in their resource consumption methods and behavioral characteristics within the network, protocol type characteristics can effectively reflect the network communication characteristics of virtual network creation events. Protocol type-related characteristics include protocol frequency, protocol distribution, and protocol changes. Protocol frequency refers to the frequency of use of a specific protocol (such as TCP or UDP) per unit of time. By monitoring protocol frequency, it can be determined whether the virtual network creation event has triggered a sudden surge in the use of certain protocols. For example, a sudden increase in the number of TCP connections may indicate that the virtual network is conducting a large amount of reliable data transmission between containers; while a surge in UDP usage may be related to real-time control communication or lightweight messaging. Protocol distribution reflects the proportion of various protocols in the total traffic. By analyzing protocol distribution, it can be identified whether a certain protocol dominates during the virtual network creation process. For example, in certain business scenarios, Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) traffic may increase significantly due to configuration distribution, service registration, or Application Programming Interface (API) calls, thus accounting for a large proportion of the overall protocol distribution. Protocol changes are determined by comparing the differences in protocol usage before and after the event to determine whether the creation of the virtual network has introduced a new communication mode. For example, some containers may start using protocols that were not previously enabled after the event, such as switching from using only TCP to using both gRPC and Quick UDP Internet Connections (QUIC) to support new service functions or performance requirements.

[0047] Step 204: Integrate the time series features, the traffic data features, and the protocol type features to obtain the network event features corresponding to the Docker internal events.

[0048] In one embodiment, the extracted time-series features, traffic data features, and protocol type features are integrated to form a complete set of network event features, which comprehensively reflect the behavioral patterns of network events. Furthermore, since different features may have different scales and units (e.g., time intervals and bandwidth have different units), these network event features also need to be standardized to ensure that their contributions to the subsequent virtual network event recognition model are balanced.

[0049] In one embodiment, the virtual network event recognition model typically relies on machine learning (e.g., support vector machines, decision trees, etc.) and deep learning (e.g., neural networks, etc.) techniques. During training, the virtual network event recognition model extracts a feature training set from the event data corresponding to internal events in Docker. By analyzing the feature training set, it learns the regularity and patterns between internal events in Docker. After training, the virtual network event recognition model can accurately identify whether an internal event is a virtual network creation event or a virtual network anomaly event. That is, when using the virtual network event recognition model, the model outputs a judgment result to determine whether the internal event is a virtual network creation event or a virtual network anomaly event.

[0050] like Figure 3 As shown in the figure, this embodiment provides a method for obtaining network traffic control parameters corresponding to virtual network anomaly events. The method specifically includes the following steps: Step 301: Calculate the traffic surge anomaly value, time series anomaly value, protocol anomaly value, and network connection anomaly value based on the network event characteristics.

[0051] In one embodiment, network event characteristics include time series characteristics, traffic data characteristics, and protocol type characteristics obtained in steps 201-203. The time series characteristics include the event frequency within a specific time window; the traffic data characteristics include the traffic rate (i.e., bandwidth usage) and traffic fluctuations; and the protocol type characteristics include protocol frequency, protocol distribution, and their temporal changes. By calculating the network event characteristics, traffic surge anomalies, time series anomalies, protocol anomalies, and network connection anomalies can be obtained.

[0052] In one embodiment, the formula for calculating the traffic increment index at time point t is as follows: ; in, This represents the traffic increase index at time point t. This represents the flow rate at time point t. Indicates the first Average flow rate at any given time.

[0053] In one embodiment, the formulas for calculating the moving average and moving standard deviation at time t are as follows:

[0054] in, This represents the moving average at time t. Let represent the moving standard deviation at time t. This represents the size of the sliding window, where i represents each time point. This represents the traffic flow at the i-th time point.

[0055] In one embodiment, the formula for calculating the protocol change rate is as follows:

[0056] in, Let be the rate of change of the protocol at time t. To indicate the first The frequency of the protocol used at time t represents the frequency of the t. The frequency of the protocol used at any given time.

[0057] In one embodiment, the formula for calculating the information entropy at time t is as follows: ; in, Let be the information entropy at time t, i represent each combination of source or destination IP and port, the range of which depends on the complexity of the network connection, p(i,t) be the probability of the occurrence of the i-th type of IP or port at time t, and n be the total number of IPs or ports.

[0058] Step 302: Perform a weighted summation calculation on the traffic surge anomaly, the time series anomaly, the protocol anomaly, and the network connection anomaly to obtain a comprehensive anomaly value.

[0059] In one embodiment, to accurately identify different types of virtual network anomaly events, differentiated weights can be assigned based on the importance of each anomaly value in its corresponding event. This makes the weighted sum of the comprehensive anomaly values ​​class-specific, capable of characterizing a specific type of virtual network anomaly event. Furthermore, this calculation method integrates multiple anomalies, effectively avoiding misjudgments or missed judgments caused by relying on a single anomaly value while distinguishing different types of virtual network anomalies, significantly improving the accuracy and robustness of anomaly detection. The weighted summation formula is as follows: ; in, To summarize outliers, For abnormal values ​​of sudden increase in traffic, The weight value corresponding to the abnormal value of sudden increase in traffic. These are outliers in the time series. These are the weight values ​​corresponding to outliers in the time series. This is an outlier in the protocol. The weight value corresponding to the protocol outlier. This is an abnormal value for network connectivity. The weight value corresponding to the network connectivity anomaly. Let t be the size of the observation time window, and t be the t-th time point within the observation time window. This represents the traffic increase index at time point t. This represents the flow rate at time t. This represents the moving average at time t. This represents the moving standard deviation at time t. Let be the rate of change of the protocol at time t. Let be the information entropy at time t. The preset average information entropy.

[0060] Step 303: Based on the comprehensive anomaly value, obtain the network traffic control parameters corresponding to the virtual network anomaly event.

[0061] In one embodiment, the specific network traffic control parameters corresponding to the virtual network anomaly event are matched from the mapping table in the configuration library or policy engine based on the comprehensive anomaly value.

[0062] like Figure 4 As shown in the figure, this embodiment provides a method for creating a preset management and control policy database, which specifically includes the following steps: Step 401: Obtain multiple preset network traffic control parameters.

[0063] Among them, several preset network traffic control parameters include bandwidth parameters, latency parameters, packet loss rate parameters, and traffic shape parameters.

[0064] In one embodiment, the maximum bandwidth usage of a virtual network or container can be determined by bandwidth parameters, such as a preset bandwidth limit of 1Gbps or 100Mbps; latency parameters refer to the latency of simulated data packet transmission to ensure that the communication latency between containers in the virtual network meets the requirements of a specific application, such as setting a latency of 100ms or 200ms; packet loss rate parameters are the proportion of data packets lost in the network, used to simulate network instability, such as setting a packet loss rate of 0.5% or 1%; traffic shape parameters refer to the distribution pattern of network traffic, such as the range of traffic fluctuations and the limitation of burst traffic, such as limiting the data traffic within a certain period of time to not exceed a set peak value; Step 402: Construct multiple preset virtual network control rate limiting rules based on multiple preset network traffic control parameters.

[0065] Among them, several preset virtual network control rate limiting rules include bandwidth limiting rules, latency control rules, packet loss rate control rules, and traffic scheduling rules.

[0066] In one embodiment, each traffic control parameter corresponds to a specific virtual network control rate limiting rule. For example, bandwidth limiting rules, latency control rules, packet loss rate control rules, and traffic scheduling rules can define the maximum bandwidth limit for a virtual network or container. For instance, if the bandwidth control parameter is 1Gbps, the bandwidth limiting rule will limit the bandwidth to 1Gbps. Latency control rules are used to set the maximum latency for inter-container communication; for example, a latency control rule might use the `tc` command to set the latency to 200ms. Packet loss rate control rules are used to set the packet loss rate in the virtual network; for example, a packet loss rate control rule might set the packet loss rate to 0.5%. Traffic scheduling rules can prioritize traffic based on conditions such as bandwidth and traffic load. For example, traffic scheduling rules can use iptables or the `tc` tool to control traffic shape and ensure the reasonable allocation of network traffic.

[0067] Step 403: Construct a preset mapping relationship between multiple preset virtual network control rate limiting rules and multiple network traffic control parameters, wherein one network traffic control parameter corresponds to one preset virtual network control rate limiting rule.

[0068] The preset mapping relationship includes the mapping relationship between network traffic control parameters and virtual network control rate limiting rules.

[0069] In one embodiment, a preset management policy database stores virtual network control rate limiting rules corresponding to these network traffic control parameters. For example, bandwidth control parameters correspond to bandwidth limiting rules, and delay control parameters correspond to delay control rules.

[0070] Step 404: Store the preset mapping relationship in the preset management strategy database.

[0071] In one embodiment, after a virtual network creation event is confirmed, the system searches a preset management policy database for virtual network control rate limiting rules corresponding to the network traffic control parameters (such as bandwidth, latency, packet loss rate, and traffic shape) of the event. For example, if the bandwidth control parameter in the event is 100Mbps, the system will search the preset database for bandwidth limiting rules and obtain a rule that limits the virtual network bandwidth to 100Mbps; if the latency control parameter in the event is 50ms, the system will search for latency control rules and obtain a rule that sets the latency to 50ms, and so on. Once the virtual network control rate limiting rules corresponding to the network traffic control parameters are obtained, the network traffic inside Docker is managed according to these rules. Specific traffic management operations for virtual network creation events include: setting a maximum bandwidth limit using system network control tools (such as tc in Linux), for example, allocating 100 Mbps bandwidth to the test environment to prevent it from affecting production traffic; and injecting fixed or jittery latency (such as 50ms ± 10ms) using the tc tool or netem module in Linux to simulate cross-regional or high-latency networks and verify the application's performance under real network conditions. Configure random packet loss rules (e.g., 1% packet loss rate) to create an unstable network environment for chaos engineering or fault tolerance testing. Based on traffic shaping strategies (e.g., token bucket, HTB queue), smooth burst traffic and allocate high-priority queues to critical business flows to achieve load balancing and Quality of Service (QoS) assurance.

[0072] In one embodiment, if a virtual network anomaly is identified, the specific network traffic control parameters corresponding to the virtual network anomaly are obtained. The corresponding virtual network control rate limiting rules are then obtained through these parameters and applied to the virtual network anomaly to manage its traffic in real time. For example, the bandwidth of the virtual network anomaly can be drastically reduced to an extremely low level (e.g., 50Kbps) to significantly reduce the attacker's data transmission capability while preserving basic connectivity for forensics. A higher packet loss rate (e.g., 10%~30%) can be set for the virtual network anomaly to disrupt the integrity of attack traffic, which is particularly suitable for suppressing UDP flooding or concealed channels. Abnormal traffic from the virtual network anomaly can be scheduled to a low-priority queue to ensure that normal business traffic is not affected.

[0073] Furthermore, it supports updates to network traffic control parameters and virtual network rate limiting rules. This means that these control parameters and corresponding rules can be dynamically updated in real time based on changes in network traffic or adjustments to container application requirements. This mechanism ensures that network management policies can adapt to different load changes, network conditions, container needs, and other factors that may affect virtual network performance. Moreover, when a virtual network removal event occurs, the control process obtains the corresponding virtual network name and removes the virtual network's traffic control parameters, ensuring that subsequent removal operations proceed smoothly.

[0074] See Figure 5 This invention provides a schematic diagram of virtual network traffic direction. Figure 5 This invention involves multiple virtual network interfaces and traffic control queues. First, the external network in the diagram connects to the host system via a physical network interface card (NIC), ethX. This NIC is connected to two virtual network interfaces, veth1 and veth2. These virtual interfaces control traffic through two different traffic control queues (rate-limiting queue TC1 and rate-limiting queue TC2). In practice, there may be more than two queues; the number of virtual interfaces and traffic control queues is not limited in this embodiment. The virtual network interfaces are further connected to three virtual network devices, net1, net2, and net3. The number of virtual network devices is also not limited in this invention. These virtual network devices can represent Docker containers or other network services and are associated with traffic queues, controlling the network bandwidth passing through each Docker container. By configuring traffic control queues, different bandwidth limits are assigned to each container for precise management and optimization of network traffic.

[0075] See Figure 6 This invention provides a schematic diagram of a rate control system for Docker container virtual networks. The device includes an acquisition module 31 and a processing module 32. The acquisition module 31 is used to acquire event data corresponding to internal events in Docker and extract network event features from the event data.

[0076] The processing module 32 is used to determine whether the Docker internal event is a virtual network creation event or a virtual network abnormal event based on the network event characteristics; if the Docker internal event is a virtual network creation event or a virtual network abnormal event, then obtain the network traffic control parameters corresponding to the virtual network creation event or the virtual network abnormal event; and perform traffic control on the Docker internal event according to the network traffic control parameters in a preset manner.

[0077] In one possible implementation, the event data includes timestamp data, traffic information data, and protocol data. The acquisition module 31 extracts network event features from the event data, specifically including: obtaining time series features corresponding to Docker internal events through timestamp data; obtaining traffic data features corresponding to Docker internal events through traffic information data; obtaining protocol type features corresponding to Docker internal events through protocol data; and using the time series features, traffic data features, and protocol type features as network event features corresponding to Docker internal events.

[0078] In one possible implementation, the processing module 32 is used to obtain network traffic control parameters corresponding to the virtual network anomaly event, specifically including: calculating a traffic surge anomaly value, a time series anomaly value, a protocol anomaly value, and a network connection anomaly value based on the network event characteristics; performing a weighted summation calculation on the traffic surge anomaly value, the time series anomaly value, the protocol anomaly value, and the network connection anomaly value to obtain a comprehensive anomaly value; and obtaining the network traffic control parameters corresponding to the virtual network anomaly event based on the comprehensive anomaly value.

[0079] In one possible implementation, the processing module 32 is used to perform a weighted summation calculation on the traffic surge anomaly, the time series anomaly, the protocol anomaly, and the network connection anomaly to obtain a comprehensive anomaly value, specifically including: calculating the comprehensive anomaly value using the following formula: ; in, To summarize outliers, For abnormal values ​​of sudden increase in traffic, The weight value corresponding to the abnormal value of sudden increase in traffic. These are outliers in the time series. These are the weight values ​​corresponding to outliers in the time series. This is an outlier in the protocol. The weight value corresponding to the protocol outlier. This is an abnormal value for network connectivity. The weight value corresponding to the network connectivity anomaly. Let t be the size of the observation time window, and t be the t-th time point within the observation time window. This represents the traffic increase index at time point t. This represents the flow rate at time t. This represents the moving average at time t. This represents the moving standard deviation at time t. Let be the rate of change of the protocol at time t. Let be the information entropy at time t. The preset average information entropy.

[0080] In one possible implementation, the processing module 32 further includes: ; ; ; ; in, This represents the traffic increase index at time point t. This represents the flow rate at time point t. Indicates the first Average flow rate at any given time; This represents the moving average at time t. This represents the moving standard deviation at time t. This represents the size of the sliding window, where i represents each time point. This represents the flow rate at the i-th time point; Let be the rate of change of the protocol at time t. To indicate the first The frequency of the protocol used at time t represents the frequency of the t. The frequency of the protocol used at any given time; Let be the information entropy at time t, i represent each combination of source or destination IP and port, the range of which depends on the complexity of the network connection, p(i,t) be the probability of the occurrence of the i-th type of IP or port at time t, and n be the total number of IPs or ports.

[0081] In one possible implementation, the processing module 32 is used to perform traffic control on the Docker internal events according to the network traffic control parameters and in a preset manner, specifically including: obtaining the virtual network control rate limiting rule corresponding to the network traffic control parameters from the preset control policy database according to the network traffic control parameters; and performing traffic control on the Docker internal events according to the virtual network control rate limiting rule.

[0082] In one possible implementation, the processing module 32 is configured to construct the preset management policy database before obtaining the virtual network control rate limiting rule corresponding to the network traffic control parameter from the preset management policy database based on the network traffic control parameter. Specifically, this includes: obtaining multiple preset network traffic control parameters; constructing multiple preset virtual network control rate limiting rules based on the multiple preset network traffic control parameters; constructing a preset mapping relationship between the multiple preset virtual network control rate limiting rules and the multiple network traffic control parameters, wherein one network traffic control parameter corresponds to one preset virtual network control rate limiting rule; and storing the preset mapping relationship in the preset management policy database.

[0083] In one possible implementation, the processing module 32 further includes: establishing a virtual Ethernet device pair between the host machine and the container, wherein one end of the virtual Ethernet device pair is located in the host machine namespace and the other end is located in the container namespace; The virtual Ethernet device is used to logically connect the network device that connects the host machine and the container, so that each container instance and the host machine have independent ingress control hooks and egress control hooks respectively; Virtual network control rate limiting rules are attached to the inlet control hook and / or outlet control hook to perform precise control on network traffic flowing into and / or out of the container based on the virtual network control rate limiting rules.

[0084] It should be noted that the above embodiments of the apparatus are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0085] Example 2: The present invention also provides an electronic device. (See reference...) Figure 7 , Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. The electronic device may include: at least one processor 401, at least one communication bus 402, a user interface 403, at least one network interface 404, and a memory 405.

[0086] The communication bus 402 is used to enable communication between these components.

[0087] The user interface 403 may include a display screen and a camera. Optionally, the user interface 403 may also include a standard wired interface and a wireless interface.

[0088] The network interface 404 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0089] The processor 401 may include one or more processing cores. The processor 401 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 405, and by calling data stored in memory 405. Optionally, the processor 401 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 401 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the processor 401.

[0090] The memory 405 may include random access memory (RAM) or read-only memory. Optionally, the memory 405 may include non-transitory computer-readable storage medium. The memory 405 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 405 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data involved in the various method embodiments described above, etc. Optionally, the memory 405 may also be at least one storage device located remotely from the aforementioned processor 401. (Refer to...) Figure 7 The memory 405, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a rate control application for Docker container virtual networks.

[0091] exist Figure 7In the illustrated electronic device, the user interface 403 is primarily used to provide an input interface for the user and acquire user input data; while the processor 401 can be used to call the rate control application for the Docker container virtual network stored in the memory 405. When executed by one or more processors 401, the electronic device performs one or more of the methods described in the above embodiments. It should be noted that, for the foregoing method embodiments, for the sake of simplicity, they are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0092] The present invention also provides a computer-readable storage medium storing instructions. When executed by one or more processors, these instructions cause an electronic device to perform one or more of the methods described in the above embodiments.

[0093] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0094] In the various embodiments provided by this invention, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0095] The units described as separate components may or may not be physically separate. The components shown 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 units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0096] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0097] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0098] The above description is merely an exemplary embodiment of the present invention and should not be construed as limiting the scope of the invention. Any equivalent changes and modifications made in accordance with the teachings of this invention are still within the scope of this invention. Those skilled in the art will readily conceive of other embodiments of the present invention upon considering the specification and practical truths disclosed herein.

[0099] This invention is intended to cover any variations, uses, or adaptations disclosed herein that follow the general principles disclosed herein and include common knowledge or customary techniques in the art not described in this invention.

Claims

1. A rate control method for Docker container virtual network, characterized in that, The method includes: Obtain event data corresponding to internal Docker events, and extract network event features from the event data; Based on the network event characteristics, determine whether the Docker internal event is a virtual network creation event or a virtual network anomaly event; If the Docker internal event is a virtual network creation event or a virtual network exception event, then obtain the network traffic control parameters corresponding to the virtual network creation event or the virtual network exception event; Based on the network traffic control parameters, traffic management is performed on the internal events of Docker according to a preset method. 2.The method for rate control for Docker container virtual network of claim 1, wherein, The method includes: Based on the network event characteristics, traffic surge anomalies, time series anomalies, protocol anomalies, and network connection anomalies are calculated. The combined anomaly value is obtained by weighted summation of the traffic surge anomaly value, the time series anomaly value, the protocol anomaly value, and the network connection anomaly value. Based on the comprehensive anomaly value, obtain the network traffic control parameters corresponding to the virtual network anomaly event. 3.The rate control method for a Docker container virtual network according to claim 2, characterized in that, The weighted summation of the traffic surge anomaly, the time series anomaly, the protocol anomaly, and the network connection anomaly is used to calculate the comprehensive anomaly value. The calculation formula is as follows: ； in, The aforementioned comprehensive outlier, The aforementioned abnormal value of sudden increase in traffic. The weight value corresponding to the abnormal traffic surge. These are the outliers in the time series. The weight value corresponding to the outlier in the time series. This is an abnormal value in the protocol. The weight value corresponding to the protocol outlier. The network connection anomaly value, The weight value corresponding to the network connectivity anomaly value. The size of the observation time window is given by , where t is the t-th time point within the observation time window. This represents the traffic increase index at time point t. This represents the flow rate at time t. This represents the moving average at time t. This represents the moving standard deviation at time t. Let be the rate of change of the protocol at time t. Let be the information entropy at time t. The preset average information entropy.

4. The rate control method for Docker container virtual network according to claim 1, characterized in that, The method further includes: ； ； ； ； in, This represents the traffic increase index at time point t. This represents the flow rate at time point t. Indicates the first Average flow rate at any given time; This represents the moving average at time t. This represents the moving standard deviation at time t. This represents the size of the sliding window, where i represents each time point. This represents the flow rate at the i-th time point; Let be the rate of change of the protocol at time t. To indicate the first The frequency of the protocol used at time t represents the frequency of the t. The frequency of the protocol used at any given time; Let be the information entropy at time t, i represent each combination of source or destination IP and port, the range of which depends on the complexity of the network connection, p(i,t) be the probability of the occurrence of the i-th type of IP or port at time t, and n be the total number of IPs or ports.

5. The rate control method for Docker container virtual network according to claim 1, characterized in that, The step of managing the traffic of internal Docker events according to the network traffic control parameters and a preset method includes: Based on the network traffic control parameters, obtain the virtual network control rate limiting rules corresponding to the network traffic control parameters from the preset management and control policy database; Traffic control is applied to the internal events of Docker based on the virtual network control rate limiting rules.

6. The rate control method for Docker container virtual network according to claim 4, characterized in that, Before obtaining the virtual network control rate limiting rule corresponding to the network traffic control parameters from the preset management policy database based on the network traffic control parameters, the preset management policy database needs to be constructed. The method further includes: Obtain multiple preset network traffic control parameters; Multiple preset virtual network control rate limiting rules are constructed based on multiple preset network traffic control parameters; Establish a preset mapping relationship between multiple preset virtual network control rate limiting rules and multiple network traffic control parameters, wherein one network traffic control parameter corresponds to one preset virtual network control rate limiting rule; The preset mapping relationship is stored in the preset management strategy database.

7. The rate control method for Docker container virtual networks according to claim 1, characterized in that, The method further includes: A virtual Ethernet device pair is established between the host machine and the container, wherein one end of the virtual Ethernet device pair is located in the host machine namespace and the other end is located in the container namespace; The virtual Ethernet device is used to logically connect the network device that connects the host machine and the container, so that each container instance and the host machine have independent ingress control hooks and egress control hooks respectively; Virtual network control rate limiting rules are attached to the inlet control hook and / or outlet control hook to perform precise control on network traffic flowing into and / or out of the container based on the virtual network control rate limiting rules.

8. The rate control method for Docker container virtual network according to claim 1, characterized in that, The event data includes timestamp data, traffic information data, and protocol data; the method further includes: Based on the timestamp data, obtain the time series characteristics corresponding to the internal events of the Docker; Based on the traffic information data, obtain the traffic data characteristics corresponding to the Docker internal events; Based on the protocol data, obtain the protocol type characteristics corresponding to the Docker internal events; By integrating the time series features, the traffic data features, and the protocol type features, the network event features corresponding to the Docker internal events are obtained.

9. A rate control apparatus for a Docker container virtual network, characterized by, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor for performing the rate control method for a Docker container virtual network as described in any one of claims 1-8.

10. A non-transitory computer storage medium, comprising, The computer storage medium stores computer-executable instructions that are executed by one or more processors to perform the rate control method for a Docker container virtual network as described in any one of claims 1-8.

Images