A method of flow control for a container and related apparatus

Abstract

This application relates to the field of container technology and provides a container flow control method and related apparatus to improve data transmission efficiency. The method includes: after acquiring target data, determining the target container corresponding to the target data, and based on the transmission direction of the target data, determining a target token bucket set for the target container and the transmission direction. The token generation rate of the target token bucket is set according to the transmission bandwidth threshold of the target container in the transmission direction. Then, based on the amount of target data, determining the number of tokens required, and when it is determined that the current number of tokens in the target token bucket is not less than the number of tokens required, performing send and receive processing on the target data.

Description

Technical Field

[0001] This application relates to the field of computer technology, and provides a method and related apparatus for controlling the flow of a container. Background Technology

[0002] With the continuous development of computer technology, containers, as an emerging lightweight virtualization technology, are widely used. Containers share the kernel with the host to reduce virtualization overhead, but they have poor isolation, which leads to resource contention among containers on the same host and affects the host's network performance. Therefore, flow control for containers is necessary.

[0003] In related technologies, container-oriented flow control is typically implemented using the Traffic Control (TC) tool. TC is a flow control tool included with Linux, which implements flow control by establishing queues for processing data packets and defining how data packets in the queues are sent or received.

[0004] However, since the queue length is fixed, queuing delays will occur when bandwidth fluctuates, affecting data transmission efficiency. Packet loss will occur when the queue is full. In addition, since the queue is set for all containers, the data transmission speed cannot be actively controlled, resulting in additional packet loss. Furthermore, the configuration process of TC is complex and difficult to use. Summary of the Invention

[0005] This application provides a method and related apparatus for controlling the flow of a container, which can improve data transmission efficiency and, to a certain extent, prevent data loss.

[0006] In a first aspect, embodiments of this application provide a method for controlling the flow of a container, comprising:

[0007] Acquire target data, and based on the container identification information carried in the target data, determine the target container corresponding to the target data from at least one preset container;

[0008] Based on the transmission direction of the target data, a target token bucket is determined for the target container and the transmission direction. The token generation rate of the target token bucket is set according to the transmission bandwidth threshold of the target container in the transmission direction.

[0009] Based on the amount of the target data, the required number of tokens is determined, and the target data is sent and received when the current number of tokens in the target token bucket is not less than the required number of tokens.

[0010] Secondly, embodiments of this application provide a flow control device for a container, comprising:

[0011] An acquisition unit is used to acquire target data and, based on the container identification information carried in the target data, determine the target container corresponding to the target data from at least one preset container.

[0012] The determining unit is configured to determine a target token bucket set for the target container and the transmission direction based on the transmission direction of the target data, wherein the token generation rate of the target token bucket is set according to the transmission bandwidth threshold of the target container in the transmission direction;

[0013] The transmission unit is used to determine the number of tokens required based on the amount of the target data, and to perform send and receive processing on the target data when it is determined that the current number of tokens in the target token bucket is not less than the number of tokens required.

[0014] As one possible implementation, when processing the transmission of the target data after determining that the current number of tokens in the target token bucket is not less than the required number of tokens, the transmission unit is specifically used for:

[0015] When it is determined that the current number of tokens contained in the target token bucket is not less than the required number of tokens, the required number of tokens are taken out from the target token bucket.

[0016] If the transmission direction of the target data is the receiving direction, then the target data is sent to the target container; otherwise, the target data is sent to the data receiving end via the target physical network card.

[0017] As one possible implementation, the transmission unit is specifically used to determine the current number of tokens contained in the target token bucket in the following way:

[0018] The token generation time difference is determined based on the first moment when a token is requested for the target container and the second moment when a token is previously retrieved from the target token bucket.

[0019] The token increment is determined based on the token generation rate and the token generation time difference;

[0020] The current token count is obtained based on the token increment and the historical token count corresponding to the second time point.

[0021] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of the above-described container flow control method.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium including a computer program that, when run on an electronic device, causes the electronic device to perform the steps of the above-described container flow control method.

[0023] Fifthly, embodiments of this application provide a computer program product, the program product including a computer program stored in a computer-readable storage medium, wherein a processor of an electronic device reads from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the steps of the above-described container flow control method.

[0024] In this embodiment of the application, after obtaining the target data, the target container corresponding to the target data is determined, and based on the transmission direction of the target data, the target token bucket set for the target container and the transmission direction is determined. The token generation rate of the target token bucket is set according to the transmission bandwidth threshold of the target container in the transmission direction. Then, based on the amount of target data, the number of tokens required is determined, and when it is determined that the current number of tokens in the target token bucket is not less than the number of tokens required, the target data is sent and received.

[0025] In this way, the token bucket mechanism enables container-level bandwidth resource isolation and allocation strategies. At the same time, by setting the corresponding token bucket based on the transmission bandwidth threshold of the target container in the transmission direction, it is ensured that the actual bandwidth used by the current container will not exceed the configured transmission bandwidth threshold. Compared with queue-based flow control methods, this avoids packet loss due to queue fullness and queuing delay due to bandwidth jitter to a certain extent. In addition, since the token generation rate of the token bucket is set according to the transmission bandwidth threshold of the target container, it can not only actively control the speed of the sending and receiving ends according to the transmission bandwidth threshold, but also reduce the configuration difficulty.

[0026] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0027] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0028] Figure 1 This is a schematic diagram of a queue-based container flow control method.

[0029] Figure 2This is a schematic diagram of an application scenario provided in the embodiments of this application;

[0030] Figure 3 This is a flowchart illustrating a flow control method for a container provided in an embodiment of this application.

[0031] Figure 4 This is a logical schematic diagram of a token bucket mechanism provided in the embodiments of this application;

[0032] Figure 5 This is a schematic diagram of a token bucket provided in an embodiment of this application;

[0033] Figure 6A This is a schematic diagram of another token bucket provided in an embodiment of this application;

[0034] Figure 6B This is a schematic diagram of yet another token bucket provided in the embodiments of this application;

[0035] Figure 7 This is a schematic diagram illustrating a logic for determining the current number of tokens provided in an embodiment of this application;

[0036] Figure 8 This is a logical diagram illustrating a traffic control process based on a physical network interface card (NIC) provided in an embodiment of this application.

[0037] Figure 9 This is a schematic diagram of a server system architecture provided in an embodiment of this application;

[0038] Figure 10 This is a schematic diagram of the structure of a flow control device for a container provided in an embodiment of this application;

[0039] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this application. Obviously, the described embodiments are only some embodiments of the technical solutions of this application, and not all embodiments. Based on the embodiments recorded in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the technical solutions of this application.

[0041] Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to achieve data computing, storage, processing, and sharing.

[0042] Cloud technology is a collective term for network technologies, information technologies, integration technologies, management platform technologies, and application technologies applied to the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.

[0043] Cloud computing is a computing model that distributes computing tasks across a large pool of computers, enabling various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, resources in the "cloud" appear infinitely scalable, readily available, on-demand, and expandable, with payment based on usage.

[0044] As a provider of fundamental cloud computing capabilities, a cloud resource pool (referred to as a cloud platform, generally called Infrastructure as a Service (IaaS)) platform) is established. Various types of virtual resources are deployed in the resource pool for external customers to choose from. The cloud resource pool mainly includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0045] Based on logical function, a Platform as a Service (PaaS) layer can be deployed on top of the IaaS layer, followed by a Software as a Service (SaaS) layer. Alternatively, SaaS can be deployed directly on top of IaaS. PaaS is the platform for running software, such as databases and web containers. SaaS refers to various types of business software, such as web portals and bulk SMS senders. Generally, SaaS and PaaS are upper layers compared to IaaS.

[0046] With the continuous development of computer technology, containers, as an emerging lightweight virtualization technology, are widely used. Containers share the kernel with the host to reduce virtualization overhead, but they have poor isolation, which leads to resource contention among containers on the same host and affects the host's network performance. Therefore, flow control for containers is necessary.

[0047] In related technologies, container-oriented flow control is typically implemented using the TC tool, a built-in flow control tool in Linux. TC achieves flow control by establishing queues for processing data packets and defining how packets in these queues are sent or received. For example, see... Figure 1 As shown, in the data transmission direction, the service data generated by the container is sent to the physical network interface card (NIC) via the container bridge. Hierarchical Token Bucket (HTB) flow control is performed on the physical NIC. In the data reception direction, the service data is sent to the target container via the physical NIC, the Intermediate Functional Block (IFB) virtual NIC, and the container bridge. HTB flow control is performed on both the physical NIC and the IFB virtual NIC. HTB is a traffic classification queuing algorithm that can effectively improve bandwidth utilization and limit various network traffic types. It can prioritize data streams based on parameters such as Internet Protocol (IP) address, protocol, and port, and then perform bandwidth control for different categories of data streams.

[0048] However, since the queue length is fixed, queuing delays will occur when bandwidth fluctuates, affecting data transmission efficiency. Packet loss will occur when the queue is full. In addition, since the queue is set for all containers, the data transmission speed cannot be actively controlled, resulting in additional packet loss. Furthermore, the virtual network interface card receives packets twice, increasing overhead. Moreover, the configuration process of TC is complex and difficult to use.

[0049] In this embodiment of the application, after obtaining the target data, the target container corresponding to the target data is determined, and based on the transmission direction of the target data, the target token bucket set for the target container and the transmission direction is determined. The token generation rate of the target token bucket is set according to the transmission bandwidth threshold of the target container in the transmission direction. Then, based on the amount of target data, the number of tokens required is determined, and when it is determined that the current number of tokens in the target token bucket is not less than the number of tokens required, the target data is sent and received.

[0050] In this way, the token bucket mechanism enables container-level bandwidth resource isolation and allocation strategies. At the same time, by setting the corresponding token bucket based on the transmission bandwidth threshold of the target container in the transmission direction, it is ensured that the actual bandwidth used by the current container will not exceed the configured transmission bandwidth threshold. Compared with queue-based flow control methods, this avoids packet loss due to queue fullness and queuing delay due to bandwidth jitter to a certain extent. In addition, since the token generation rate of the token bucket is set according to the transmission bandwidth threshold of the target container, it can not only actively control the speed of the sending and receiving ends according to the transmission bandwidth threshold, but also reduce the configuration difficulty.

[0051] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0052] See Figure 2 The diagram shown illustrates an application scenario provided in this application embodiment. This application scenario includes at least a terminal device 110 and a server 120. The number of terminal devices 110 can be one or more, and the number of servers 120 can also be one or more. This application does not specifically limit the number of terminal devices 110 and servers 120.

[0053] In this embodiment, the terminal device 110 may be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, IoT device, smart home appliance, vehicle terminal, etc., but is not limited to these.

[0054] Server 120 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminal device 110 and server 120 can be connected directly or indirectly via wired or wireless communication; this application does not impose any restrictions on this.

[0055] For example, terminal device 110 is equipped with a client for accessing various services, and server 120 runs at least one container. After acquiring target data, the target container corresponding to the target data is determined, and a target token bucket is set for the target container and the transmission direction based on the transmission direction of the target data. The token generation rate of the target token bucket is set according to the transmission bandwidth threshold of the target container in the transmission direction. Then, based on the amount of target data, the number of tokens required is determined, and the target data is sent and received when the current number of tokens in the target token bucket is not less than the number of tokens required.

[0056] See Figure 3 The diagram shown is a flowchart of a container flow control method provided in this embodiment of the application. The method is applied to a server, and the specific process is as follows:

[0057] S301. Obtain target data, and based on the container identification information carried in the target data, determine the target container corresponding to the target data from at least one preset container.

[0058] It should be noted that, in the embodiments of this application, the target data is data to be sent or data to be received.

[0059] For example, the preset containers are container 1 and container 2, where the container identifier information of container 1 is Docker0 and the container identifier information of container 2 is Docker1. Assuming that the container identifier information carried in the target data is Docker0, based on the container identifier information carried in the target data, the target container corresponding to the target data is determined to be container 1 from container 1 and container 2.

[0060] S302. Based on the transmission direction of the target data, determine the target token bucket set for the target container and the transmission direction. The token generation rate of the target token bucket is set according to the transmission bandwidth threshold of the target container in the transmission direction.

[0061] In this embodiment of the application, if the target data is data to be sent, then the transmission direction of the target data is the sending direction; if the target data is data to be received, then the data transmission direction of the target data is the receiving direction.

[0062] For at least one container, network load bandwidth can be pre-configured for each container. Network load bandwidth can also be referred to as transmission bandwidth threshold, which includes transmission bandwidth thresholds in the sending direction and transmission bandwidth thresholds in the receiving direction. Network load bandwidth can be determined based on server bandwidth resource thresholds, bandwidth requirements of applications running in each container, application service priorities, etc., but is not limited to these. For example, the bandwidth indication information in a container configuration file can be adjusted based on the network load bandwidth to configure it.

[0063] Each container holds its own token bucket for both the sending and receiving directions. For each container, the transmission bandwidth threshold in the sending direction is used as the token generation rate of the token bucket in the sending direction, and the transmission bandwidth threshold in the receiving direction is used as the token generation rate of the token bucket in the receiving direction.

[0064] See Figure 4 As shown, it is a schematic diagram of a token bucket algorithm provided in an embodiment of this application. The token bucket generates tokens according to the token generation rate and fills the token bucket. When a data packet arrives, if there are enough tokens in the bucket, the corresponding number of tokens are taken out of the token bucket and the data packet is sent or received. Otherwise, the data packet is discarded, thereby controlling the data packet processing rate and achieving the goal of traffic rate limiting.

[0065] In this embodiment of the application, as one possible implementation, each container holds its own token bucket for both the sending and receiving directions, thereby independently implementing container-level traffic rate limiting in the data receiving and sending directions. Accordingly, after obtaining the target data, the target token bucket set for the target container and the transmission direction can be directly determined based on the transmission direction of the target data.

[0066] For example, see Figure 5 As shown, for container 1, a token bucket 1 is set in the receiving direction, and a token bucket 3 is set in the data sending direction. For container 2, a token bucket 2 is set in the receiving direction, and a token bucket 4 is set in the data sending direction. If the target data is transmitted in the sending direction and the target container is container 1, then the target token bucket is determined to be token bucket 3 based on the transmission direction of the target data. If the target data is transmitted in the receiving direction and the target container is container 2, then the target token bucket is determined to be token bucket 2 based on the data transmission direction.

[0067] As another possible implementation, each container holds its own token bucket for different physical network interface cards (NICs) in both the sending and receiving directions. Accordingly, when determining the target token bucket, the target physical NIC for transmitting the target data is determined from at least one preset set of physical NICs based on the physical NIC identifier carried in the target data. Then, based on the target physical NIC and the transmission direction of the target data, the target token bucket is determined from at least one preset set of token buckets for the target container.

[0068] For example, see Figure 6A and Figure 6B As shown, the container includes container 1 and container 2, and the physical network interface card (NIC) includes physical NIC 1 and physical NIC 2. For physical NIC 1, container 1 is equipped with a token bucket 1 in the receiving direction.

[0069] Container 1 has a token bucket 3 in the data sending direction, Container 2 has a token bucket 2 in the receiving direction, Container 2 has a token bucket 4 in the data sending direction, and for physical network card 2, Container 1 has a token bucket 5 in the receiving direction, Container 1 has a token bucket 7 in the data sending direction, Container 2 has a token bucket 6 in the receiving direction, and Container 2 has a token bucket 8 in the data sending direction.

[0070] If the transmission direction of the target data is the sending direction, the target container is container 1, and the physical network card identifier carried in the target data is the physical network card identifier of physical network card 1, then, based on the physical network card identifier carried in the target data, the target physical network card is determined to be physical network card 1 from physical network card 1 and physical network card 2. Then, based on the target physical network card and the transmission direction of the target data, the target token bucket is determined to be token bucket 3 from token bucket 1 to token bucket 8.

[0071] If the transmission direction of the target data is the receiving direction, the target container is container 2, and the physical network card identifier carried in the target data is the physical network card identifier of physical network card 2, then, based on the physical network card identifier carried in the target data, the target physical network card is determined to be physical network card 2 from physical network card 1 and physical network card 2. Then, based on the target physical network card and the transmission direction of the target data, the target token bucket is determined to be token bucket 6 from token bucket 1 to token bucket 8.

[0072] By implementing the above method and individually limiting the rate of multiple network interface cards (NICs), it enables NIC-based traffic control within containers. Furthermore, by configuring separate bandwidth limiting policies for different containers and NICs, it solves the resource allocation problem when services are deployed in a mixed environment, achieving more flexible bandwidth resource isolation and allocation strategies, effectively improving bandwidth utilization while ensuring service quality. In addition, the token bucket can leverage the characteristics of lock-free atomic variables to ensure the timeliness and effectiveness of data processing.

[0073] S303. Based on the amount of target data, determine the number of tokens required, and when the current number of tokens in the target token bucket is not less than the number of tokens required, perform send and receive processing on the target data.

[0074] The data volume of the target data refers to the storage capacity of the target data. The target data can also be called the target message. The target message carries a message length description field, and the data volume of the target data can be determined based on the message length description field.

[0075] It should be noted that this embodiment only uses one token corresponding to one byte as an example for illustration. In actual applications, the number of bytes corresponding to one token can be flexibly set. Specifically, when executing S303, the following methods can be used, but are not limited to:

[0076] If the current number of tokens in the target token bucket is not less than the required number of tokens, then take the required number of tokens from the target token bucket.

[0077] If the transmission direction of the target data is the receiving direction, the target data will be sent to the target container; otherwise, the target data will be sent to the data receiving end via the target physical network card.

[0078] The current number of tokens in the target token bucket can be determined in the following way:

[0079] The token generation time difference is determined based on the first moment when a token is requested for the target container, and the second moment when a token is previously retrieved from the target token bucket.

[0080] The token increment is determined based on the token generation rate and the time difference between token generation.

[0081] The current token count is obtained based on the token increment and the historical token count at the second time step.

[0082] See Figure 7 As shown, assuming the first moment for requesting a token for the target container is t1, and the second moment for retrieving a token from the target token bucket is t2, based on the first moment t1 for requesting a token for the target container and the second moment t2 for retrieving a token from the target token bucket, the token generation time difference Δt is determined to be t2-t1. Then, based on the token generation rate dw and the token generation time difference Δt, the token increment Δcount is determined to be dw*Δt. Finally, based on the token increment Δcount and the historical token count count' corresponding to the second moment, the current token count is obtained.

[0083] For example, suppose the first time is 10:01, the second time is 10:02, the token generation rate is 500 bytes per second, the historical token count corresponding to the second time is 1000, that is, t1 is 10:01, t2 is 10:02, dw is 500 bytes per second, count' is 1000. Based on the first time t1 of requesting a token for the target container, and based on the second time t2 of the previous time of taking a token from the target token bucket, the token generation time difference Δt is determined to be 1 second. Then, based on the token generation rate dw and the token generation time difference Δt, the token increment Δcount is determined to be 500 bytes. After that, based on the token increment Δcount and the historical token count' corresponding to the second time, the current token count is 500 + 1000 = 1500 bytes, that is, 1500 tokens.

[0084] By implementing the above method, target data is sent and received only when the target token bucket contains a sufficient number of tokens. This ensures that the actual bandwidth used by the current container does not exceed the configured rate limit threshold, achieving a reasonable allocation of server bandwidth resources among containers. Furthermore, the number of tokens in the token bucket is updated by using the token generation rate and the token generation time difference, enabling incremental updates to the token bucket. This improves data processing efficiency and, consequently, traffic control efficiency.

[0085] In some embodiments, in order to ensure that the physical network card can be accurately located when receiving or sending data packets, when acquiring target data, as a possible case, if the transmission direction of the target data is the receiving direction, when receiving the data to be received through the target physical network card, the data format of the data to be received is converted to obtain initial data. Then, the physical network card identifier of the target physical network card is recorded in the initial data to obtain the target data.

[0086] As another possible scenario, if the transmission direction of the target data is the sending direction, the data to be sent generated by the target container can be obtained. When it is determined that the target physical network card is used to send the data to be sent, the physical network card identifier of the target physical network card is recorded in the data to be sent, and the data to be sent after recording the identifier is used as the target data.

[0087] It should be noted that in this embodiment of the application, the target data may not carry the physical network card identifier of the target physical network card in the transmission direction. In this case, the physical network card identifier of the target physical network card can be obtained from the socket to determine the target physical network card.

[0088] See Figure 8 The diagram illustrates a possible server network architecture provided in this embodiment. The server includes a target physical network interface card (NIC), a target container, and a container bridge. The target container and the container bridge communicate via sockets. The container's network mode is either Bridge or Host mode. In this embodiment, the target physical NIC, the target token bucket, and the required token quantity are determined based on the amount of target data by calling a local receive hook or a local send hook. When the current token quantity in the target token bucket is determined to be not less than the required token quantity, the target data is processed for sending and receiving.

[0089] For example, see Figure 8 Assuming the target physical network interface card (NIC) is NIC1 and the target container is container1, when receiving data through NIC1, the data format of the data to be received is converted to obtain initial data. The physical NIC identifier of NIC1 is recorded in the initial data to obtain the target data. The network mode is either Bridge or host mode. Then, the local receive hook is called to extract the physical NIC identifier of NIC1 from the target data and bind the physical NIC identifier of NIC1 to the socket, thereby transmitting the target data to the target container.

[0090] For example, see Figure 8 Assuming the target physical network card is physical network card 1 and the target container is container 1, when data to be sent is generated through container 1, the local send hook is called to obtain the physical network card identifier of physical network card 1 from the socket, and then the target data is transmitted to physical network card 1 through the container bridge, and then the target data is sent to the data receiving end through physical network card 1.

[0091] By implementing the above method, even if the data packet passes through one or more virtual network cards, it can be ensured that the received or sent data can quickly and accurately find the physical network card, thereby improving data transmission efficiency.

[0092] In some embodiments, the target physical network interface card and the target container are connected via a container bridge;

[0093] The received data undergoes data format conversion to obtain the target data, including:

[0094] Send the data to be received to the container bridge;

[0095] In a container bridge, the data to be received is converted based on the specified target data format to obtain the target data.

[0096] It should be noted that in this embodiment, the target data format is a socket buffer (SKB), which is the Linux kernel packet management structure. When sending the data to be received to the container bridge, the data can be forwarded to the virtual network interface card corresponding to the container bridge based on the address information contained in the data. The address information can be the IP address or port number of the container bridge, or the container identifier information of the target container.

[0097] For example, assuming the container's network mode is bridge / host mode, after physical network interface card 1 receives a data packet, it sends the data to be received to the virtual network interface card corresponding to the container bridge through physical network interface card 1. The virtual network interface card driver converts the data packet to be received into SKB format to obtain the target data in SKB format.

[0098] By implementing the above method, the data to be received is converted into the target data format, so that the Linux kernel can process the target data and thus achieve flow control for containers.

[0099] It should be noted that in this embodiment of the application, a control group (cgroup) is used to limit, control and separate the resources (such as CPU, memory, disk input / output, etc.) of a process group. Therefore, in S1004, the target container can also be determined by judging the cgroup corresponding to the target data.

[0100] The present application will now be described in conjunction with specific embodiments.

[0101] See Figure 9 As shown, it is a schematic diagram of the system architecture of a server provided in an embodiment of this application. The server includes two containers, two physical network cards, and a container bridge. The two containers are container 1 and container 2, and the two physical network cards are physical network card 1 and physical network card 2.

[0102] Docker is an open-source application container engine. When a container starts, Docker creates a pair of virtual network interface devices. These virtual network interface devices exist in pairs; data entering from one end simultaneously appears on the other. Docker attaches one end to a container bridge (docker0) and places the other end within the container's network namespace, thus enabling communication between the container and the host. Bridge mode is the default network mode. This mode sets up a network namespace, IP address, etc., for each container. When Docker starts, it creates a container bridge named docker0 on the host. This container bridge can also be called a virtual bridge. Docker containers started on this host will connect to this virtual bridge, thus communicating with other containers on the same host in bridge mode.

[0103] Figure 9 In the container bridge, there are two virtual network interfaces: veth0 and veth1. The virtual network interface of container 1 is nic0 and the virtual network interface of container 2 is nic1. veth0 corresponds to nic0 of container 1 and veth1 corresponds to nic0 of container 2.

[0104] Taking the receiving direction as an example, assuming the target physical network interface card (NIC) is NIC 1, NIC 1 receives the data to be received and, based on the address information in the data, forwards it to the virtual NIC of the container bridge. The container's network mode is bridge / host. Then, the container bridge converts the data to be received into target data in SKB format through the NIC driver. The target data in SKB format is simply called the target SKB. The entry function of the protocol stack is called to hand the target SKB over to the protocol stack for processing. In the protocol stack, the early_demux function is called to look up the target network layer descriptor block (sock) corresponding to the target SKB in advance at the network IP layer. The structure of the target sock contains a member sock_cgroup_data, which points to container 1, thus determining that the target container corresponding to the target data is container 1. Afterwards, at the local receive hook point, it is determined that the target token bucket corresponding to the target data is token bucket 1, and the number of tokens in token bucket 1 is updated based on the token generation rate and the token generation time difference. When enough tokens are obtained from token bucket 1, the target data is sent to container 1.

[0105] Taking the sending direction as an example, assume that the target physical network interface is physical network interface 1, the target container is container 1, container 1 generates data to be sent, and uses the data to be sent as the target data; then, the corresponding sending function is called to send the target data into the protocol stack, and the network layer descriptor block corresponding to the target data is sock; then, at the local sending hook point, based on sock, it is determined that the target token bucket corresponding to the target data is token bucket 3, and the number of tokens in token bucket 3 is updated based on the token generation rate and the token generation time difference. When enough tokens are obtained from token bucket 1, the target data is sent to the container bridge; then, when it is allowed to continue sending the target data, the protocol stack calls the driver to pass the target data to the container network interface, and finally the target data is sent to physical network interface 1 through the container bridge, and the target data is sent through physical network interface 1.

[0106] Based on the same inventive concept, embodiments of this application provide a flow control device for a container. For example... Figure 10 The diagram shown is a structural schematic of a flow control device 1000 for a container, which may include:

[0107] The acquisition unit 1001 is used to acquire target data and, based on the container identification information carried in the target data, determine the target container corresponding to the target data from at least one preset container.

[0108] The determining unit 1002 is used to determine a target token bucket set for the target container and the transmission direction based on the transmission direction of the target data, wherein the token generation rate of the target token bucket is set according to the transmission bandwidth threshold of the target container in the transmission direction.

[0109] The transmission unit 1003 is used to determine the number of tokens required based on the amount of data in the target data, and to perform send and receive processing on the target data when it is determined that the current number of tokens in the target token bucket is not less than the number of tokens required.

[0110] As one possible implementation, when determining the target token bucket set for the target container and the transmission direction based on the transmission direction of the target data, the determining unit 1002 is specifically used for:

[0111] Based on the physical network card identifier carried in the target data, a target physical network card for transmitting the target data is determined from at least one preset physical network card.

[0112] Based on the target physical network card and the transmission direction of the target data, the target token bucket is determined from at least one token bucket preset for the target container.

[0113] As one possible implementation, when acquiring the target data, the acquisition unit 1001 is specifically used for:

[0114] If the transmission direction of the target data is the receiving direction, then when receiving the data to be received through the target physical network card, the data to be received is converted into a data format to obtain the initial data;

[0115] The physical network card identifier of the target physical network card is recorded in the initial data to obtain the target data.

[0116] As one possible implementation, the target physical network interface card and the target container are connected via a container bridge; when converting the data format of the data to be received to obtain the target data, the acquisition unit 1001 is specifically used for:

[0117] The data to be received is sent to the container bridge;

[0118] In the container bridge, the data to be received is converted into a data format based on a specified target data format to obtain the target data.

[0119] As one possible implementation, when acquiring the target data, the acquisition unit 1001 is specifically used for:

[0120] If the transmission direction of the target data is the sending direction, then obtain the data to be sent generated by the target container;

[0121] When it is determined that the target physical network card will be used to send the data to be sent, the physical network card identifier of the target physical network card is recorded in the data to be sent, and the data to be sent after recording the identifier is used as the target data.

[0122] As one possible implementation, when processing the transmission and reception of the target data after determining that the current number of tokens in the target token bucket is not less than the required number of tokens, the transmission unit 1003 is specifically used for:

[0123] When it is determined that the current number of tokens contained in the target token bucket is not less than the required number of tokens, the required number of tokens are taken out from the target token bucket.

[0124] If the transmission direction of the target data is the receiving direction, then the target data is sent to the target container; otherwise, the target data is sent to the data receiving end via the target physical network card.

[0125] As one possible implementation, the transmission unit 1003 is specifically used to determine the current number of tokens contained in the target token bucket in the following manner:

[0126] The token generation time difference is determined based on the first moment when a token is requested for the target container and the second moment when a token is previously retrieved from the target token bucket.

[0127] The token increment is determined based on the token generation rate and the token generation time difference;

[0128] The current token count is obtained based on the token increment and the historical token count corresponding to the second time point.

[0129] For ease of description, the above sections are divided into modules (or units) according to their functions and described separately. Of course, in implementing this application, the functions of each module (or unit) can be implemented in one or more software or hardware components.

[0130] Regarding the apparatus in the above embodiments, the specific manner in which each unit executes the request has been described in detail in the embodiments related to the method, and will not be elaborated here.

[0131] In this embodiment, a token bucket mechanism is used to implement container-level bandwidth resource isolation and allocation strategies. Simultaneously, by setting a corresponding token bucket based on the target container's transmission bandwidth threshold in the transmission direction, it ensures that the actual bandwidth used by the current container will not exceed the configured transmission bandwidth threshold. Compared to queue-based flow control methods, this avoids packet loss due to queue fullness and queuing latency due to bandwidth fluctuations to a certain extent. Furthermore, since the token generation rate of the token bucket is set according to the target container's transmission bandwidth threshold, it not only actively controls the speed of the sending and receiving ends based on the transmission bandwidth threshold but also reduces configuration complexity and is more business-friendly. Moreover, since the number of tokens is related to the amount of target data, it supports traffic statistics for a single container, providing a more detailed display of bandwidth consumption within the container.

[0132] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0133] Based on the same inventive concept, this application also provides an electronic device, see reference. Figure 11 As shown, it is a schematic diagram of the structure of a possible electronic device provided in an embodiment of this application. Figure 11 In the electronic device 1100, there are: processor 1110 and memory 1120.

[0134] The memory 1120 stores a computer program that can be executed by the processor 1110. By executing the instructions stored in the memory 1120, the processor 1110 can perform the steps of the above-mentioned container flow control method.

[0135] Memory 1120 may be volatile memory, such as random-access memory (RAM); memory 1120 may also be non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 1120 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1120 may also be a combination of the above-described memories.

[0136] Processor 1110 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 1110 implements the flow control method of the container described above when executing a computer program stored in memory 1120.

[0137] In some embodiments, the processor 1110 and the memory 1120 may be implemented on the same chip, while in other embodiments they may be implemented on separate chips.

[0138] This application embodiment does not limit the specific connection medium between the processor 1110 and the memory 1120. This application embodiment takes the connection between the processor 1110 and the memory 1120 via a bus as an example. Figure 11 The diagram uses thick lines to describe the connections between other components; these are merely illustrative and not intended to be limiting. Buses can be categorized as address buses, data buses, control buses, etc. For ease of description, Figure 11 It is described using only a thick line, but does not indicate that there is only one bus or one type of bus.

[0139] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium including a computer program. When the computer program is run on an electronic device, it causes the electronic device to perform the steps of the aforementioned container flow control method. In some possible implementations, various aspects of the container flow control method provided in this application can also be implemented as a program product including a computer program. When the program product is run on an electronic device, the computer program causes the electronic device to perform the steps in the aforementioned container flow control method. For example, the electronic device can perform actions such as... Figure 3 The steps are shown in the figure.

[0140] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0141] The program product of the embodiments of this application may be a CD-ROM and include a computer program, and may run on an electronic device. However, the program product of this application is not limited thereto. In this document, the readable storage medium may be any tangible medium that contains or stores a computer program that may be used by or in conjunction with a command execution system, apparatus, or device.

[0142] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a computer program for use by or in conjunction with a command execution system, apparatus, or device.

[0143] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0144] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0145] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0146] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0147] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0148] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A flow control method of a container, characterized by, The method includes: Acquire target data, and based on the container identification information carried in the target data, determine the target container corresponding to the target data from at least one preset container; wherein, for each physical network interface card of the target container, a token bucket is held in the sending direction and the receiving direction respectively; Based on the physical network card identifier carried in the target data, a target physical network card for transmitting the target data is determined from at least one preset physical network card. Based on the target physical network interface card and the transmission direction of the target data, a target token bucket is determined from at least one token bucket preset for the target container; the token generation rate of the target token bucket is set according to the transmission bandwidth threshold of the target container in the transmission direction. Based on the amount of the target data, the required number of tokens is determined, and the target data is sent and received when the current number of tokens in the target token bucket is not less than the required number of tokens.

2. The method of claim 1, wherein, The acquisition of target data includes: If the transmission direction of the target data is the receiving direction, then when receiving the data to be received through the target physical network card, the data to be received is converted into a data format to obtain the initial data; The physical network card identifier of the target physical network card is recorded in the initial data to obtain the target data.

3. The method of claim 2, wherein, The target physical network interface card and the target container are connected via a container bridge. The process of converting the data format of the data to be received to obtain the target data includes: The data to be received is sent to the container bridge; In the container bridge, the data to be received is converted into a data format based on a specified target data format to obtain the target data.

4. The method of claim 1, wherein, The acquisition of target data includes: If the transmission direction of the target data is the sending direction, then obtain the data to be sent generated by the target container; When it is determined that the target physical network card will be used to send the data to be sent, the physical network card identifier of the target physical network card is recorded in the data to be sent, and the data to be sent after recording the identifier is used as the target data.

5. The method of any one of claims 1-4, wherein, The step of processing the target data for sending and receiving when it is determined that the current number of tokens in the target token bucket is not less than the required number of tokens includes: When it is determined that the current number of tokens contained in the target token bucket is not less than the required number of tokens, the required number of tokens are taken out from the target token bucket. If the transmission direction of the target data is the receiving direction, then the target data is sent to the target container; otherwise, the target data is sent to the data receiving end via the target physical network card.

6. The method as described in claim 5, characterized in that, The current number of tokens contained in the target token bucket is determined in the following way: The token generation time difference is determined based on the first moment when a token is requested for the target container and the second moment when a token is previously retrieved from the target token bucket. The token increment is determined based on the token generation rate and the token generation time difference; The current token count is obtained based on the token increment and the historical token count corresponding to the second time point.

7. A flow control device for a container, characterized in that, include: An acquisition unit is used to acquire target data and, based on the container identification information carried in the target data, determine the target container corresponding to the target data from at least one preset container; wherein, for each physical network interface card of the target container, a token bucket is held in the sending direction and the receiving direction respectively. The determining unit is configured to determine a target physical network interface card (NIC) for transmitting the target data from at least one preset physical NICs based on the physical NIC identifier carried in the target data; and to determine a target token bucket from at least one preset token bucket for the target container based on the target physical NIC and the transmission direction of the target data; the token generation rate of the target token bucket is set according to the transmission bandwidth threshold of the target container in the transmission direction. The transmission unit is used to determine the number of tokens required based on the amount of the target data, and to perform send and receive processing on the target data when it is determined that the current number of tokens in the target token bucket is not less than the number of tokens required.

8. The apparatus as claimed in claim 7, characterized in that, When acquiring the target data, the acquisition unit is specifically used for: If the transmission direction of the target data is the receiving direction, then when receiving the data to be received through the target physical network card, the data to be received is converted into a data format to obtain the initial data; The physical network card identifier of the target physical network card is recorded in the initial data to obtain the target data.

9. The apparatus as claimed in claim 8, characterized in that, The target physical network interface card and the target container are connected via a container bridge. When converting the data format of the data to be received to obtain the target data, the acquisition unit is specifically used for: The data to be received is sent to the container bridge; In the container bridge, the data to be received is converted into a data format based on a specified target data format to obtain the target data.

10. The apparatus as claimed in claim 7, characterized in that, When acquiring the target data, the acquisition unit is specifically used for: If the transmission direction of the target data is the sending direction, then obtain the data to be sent generated by the target container; When it is determined that the target physical network card will be used to send the data to be sent, the physical network card identifier of the target physical network card is recorded in the data to be sent, and the data to be sent after recording the identifier is used as the target data.

11. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of any of the methods described in claims 1 to 6.

12. A computer-readable storage medium, characterized in that, It includes a computer program that, when run on an electronic device, causes the electronic device to perform the steps of any of the methods described in claims 1 to 6.

13. A computer program product, characterized in that, It includes a computer program stored in a computer-readable storage medium, and a processor of an electronic device reads from and executes the computer program, causing the electronic device to perform the steps of any of the methods described in claims 1 to 6.

Images