CN114363170A - Container service network configuration method and related product - Google Patents
Container service network configuration method and related product Download PDFInfo
- Publication number
- CN114363170A CN114363170A CN202111643239.7A CN202111643239A CN114363170A CN 114363170 A CN114363170 A CN 114363170A CN 202111643239 A CN202111643239 A CN 202111643239A CN 114363170 A CN114363170 A CN 114363170A
- Authority
- CN
- China
- Prior art keywords
- container
- network
- host
- network card
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 52
- 238000012545 processing Methods 0.000 claims abstract description 23
- 230000006870 function Effects 0.000 claims description 67
- 238000004590 computer program Methods 0.000 claims description 14
- 230000003993 interaction Effects 0.000 claims description 4
- 230000005540 biological transmission Effects 0.000 abstract description 12
- 238000010586 diagram Methods 0.000 description 17
- 238000003860 storage Methods 0.000 description 17
- 238000005516 engineering process Methods 0.000 description 14
- 230000007246 mechanism Effects 0.000 description 8
- 238000004891 communication Methods 0.000 description 7
- 230000008569 process Effects 0.000 description 7
- 238000006243 chemical reaction Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 238000001914 filtration Methods 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 230000003071 parasitic effect Effects 0.000 description 3
- 101100513046 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) eth-1 gene Proteins 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 238000007493 shaping process Methods 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The application belongs to the technical field of cloud computing, and particularly relates to a container service network configuration method and a related product. The method comprises the following steps: when it is monitored that a new container is created on a host, configuring a container network stack for the container; configuring a virtual network card corresponding to a physical network card of the host, wherein the virtual network card is a network interface with an independent physical address; recording the physical address of the virtual network card in the physical network card of the host; and registering a hook function for carrying out load balancing processing on the service access flow of the container according to the physical address of the virtual network card. The method and the device can shorten the data transmission path, reduce cross-layer transmission and reduce the network delay of data transmission.
Description
Technical Field
The application belongs to the technical field of cloud computing, and particularly relates to a container service network configuration method, a container service network configuration device, a computer readable medium, an electronic device and a computer program product.
Background
A container service network is one of three core network capabilities of a container cluster (kuberntes cluster), which provides containers with forwarding and load balancing capabilities from container to container service on the premise of container network connectivity. When the container and the host carry out data communication, multiple network layers need to be spanned, so that technical problems of long data propagation link, large network delay and the like generally exist, and further obvious performance loss exists in a container cluster.
Disclosure of Invention
The present application aims to provide a container service network configuration method, a container service network configuration apparatus, a computer readable medium, an electronic device, and a computer program product, which at least overcome technical problems of long data propagation link, large network delay, and the like in the related art to some extent.
Other features and advantages of the present application will be apparent from the following detailed description, or may be learned by practice of the application.
According to an aspect of an embodiment of the present application, there is provided a container service network configuration method, including:
when it is monitored that a new container is created on a host, configuring a container network stack for the container;
configuring a virtual network card corresponding to a physical network card of the host, wherein the virtual network card is a network interface with an independent physical address;
recording the physical address of the virtual network card in the physical network card of the host;
and registering a hook function for carrying out load balancing processing on the service access flow of the container according to the physical address of the virtual network card.
According to an aspect of an embodiment of the present application, there is provided a container service network configuration apparatus, including:
the network stack configuration module is configured to configure a container network stack for a container when it is monitored that a new container is created on a host;
a virtual network card configuration module configured to configure a virtual network card corresponding to a physical network card of the host, the virtual network card being a network interface having an independent physical address;
an address recording module configured to record a physical address of the virtual network card in a physical network card of the host;
and the function registration module is configured to register a hook function for performing load balancing processing on the service access flow of the container according to the physical address of the virtual network card.
In an embodiment of the application, based on the above technical solution, the function registration module may further include:
the information acquisition module is configured to acquire service configuration information of the container network stack according to the physical address of the virtual network card;
a function conversion module configured to convert the service configuration information into a hook function for load balancing service access traffic of the container through a traffic controller installed in the host.
In an embodiment of the present application, based on the above technical solution, the function transformation module may further include:
a code writing module configured to write the service configuration information as a programming language code through a flow controller installed in the host;
a code conversion module configured to convert the programming language code into a hook function for load balancing service access traffic of the container.
In an embodiment of the present application, based on the above technical solution, the code conversion module may further include:
a code compilation module configured to invoke an underlying virtual machine configured within the host to compile the programming language code into Berkeley packet filter instructions;
a bytecode compilation module configured to compile the berkeley packet filter instructions into bytecodes through an extended berkeley packet filter installed within the host;
a bytecode registration module configured to register the bytecode as a hook function for load balancing service access traffic of the container.
In an embodiment of the present application, based on the above technical solution, the bytecode compiling module may be further configured to: calling a kernel just-in-time compiler through an extended Berkeley packet filter configured in the host, so as to compile the Berkeley packet filter instruction into byte codes through the kernel just-in-time compiler.
In an embodiment of the present application, based on the above technical solution, the network stack configuration module may be further configured to: and calling a container network interface plug-in through a proxy node of a container arranging engine installed on the host, so as to configure a container network stack for the container through the container network interface plug-in.
In an embodiment of the present application, based on the above technical solution, the container network interface plug-in performs data interaction with the proxy node of the container orchestration engine based on a container network interface standard to implement an add network function and a remove network function in the container network interface standard.
According to an aspect of the embodiments of the present application, there is provided a computer-readable medium, on which a computer program is stored, which when executed by a processor, implements a container service network configuration method as in the above technical solution.
According to an aspect of an embodiment of the present application, there is provided an electronic apparatus including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the container service network configuration method as in the above technical solution via executing the executable instructions.
According to an aspect of embodiments herein, there is provided a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the computer device executes the container service network configuration method as in the above technical solution.
In the technical scheme provided by the embodiment of the application, the virtual network card is configured in the container network stack, and the hook function for load balancing the service access flow of the container is registered, so that the data packet can be directly transmitted to the physical network card of the host through the L2 layer without crossing a name space, a data transmission path can be shortened, cross-layer transmission is reduced, the network delay of data transmission is reduced, the problem of load balancing at an L2 data link layer can be solved, and the method is more suitable for large-scale service scenes.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.
Fig. 1 is a diagram illustrating a network architecture for implementing a container service network in the related art.
Fig. 2 is a flow chart illustrating steps of a container service network configuration method in one embodiment of the present application.
Fig. 3 shows a block diagram of a container service network configuration over kubernets according to an embodiment of the present application.
Fig. 4 shows a block diagram of a module for implementing a data forwarding path based on macvlan in an embodiment of the present application.
Fig. 5 shows a block diagram of modules for implementing packet load balancing in an embodiment of the present application.
Fig. 6 schematically shows a block diagram of a configuration apparatus of a container service network according to an embodiment of the present application.
FIG. 7 schematically illustrates a block diagram of a computer system suitable for use in implementing an electronic device of an embodiment of the present application.
Detailed Description
Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art.
Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the subject matter of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.
The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.
The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.
The embodiment of the application relates to a technical scheme for constructing a high-performance container service network based on cloud technology.
Cloud technology refers to a hosting technology for unifying serial resources such as hardware, software, network and the like in a wide area network or a local area network to realize calculation, storage, processing and sharing of data. Cloud technology (Cloud technology) is based on a general term of network technology, information technology, integration technology, management platform technology, application technology and the like applied in a Cloud computing business model, can form a resource pool, is used as required, and is flexible and convenient. Cloud computing technology will become an important support. Background services of the technical network system require a large amount of computing and storage resources, such as video websites, picture-like websites and more web portals. With the high development and application of the internet industry, each article may have its own identification mark and needs to be transmitted to a background system for logic processing, data in different levels are processed separately, and various industrial data need strong system background support and can only be realized through cloud computing.
Cloud computing (cloud computing) is a computing model that distributes computing tasks over a pool of resources formed by a large number of computers, enabling various application systems to obtain computing power, storage space, and information services as needed. The network that provides the resources is referred to as the "cloud". Resources in the "cloud" appear to the user as being infinitely expandable and available at any time, available on demand, expandable at any time, and paid for on-demand. As a basic capability provider of cloud computing, a cloud computing resource pool (called as an ifas (Infrastructure as a Service) platform for short is established, and multiple types of virtual resources are deployed in the resource pool and are selectively used by external clients.
Kubernetes, K8s for short, is an abbreviation for 8 replacing the 8 characters "ubernet" in the middle of the name. Kubernets is an open source for managing containerized applications on multiple hosts in a cloud platform, the goal of kubernets is to make deploying containerized applications simple and efficient, and it provides mechanisms for application deployment, planning, updating, maintenance, etc.
A traditional deployment of applications is to install the applications through plug-ins or scripts. The disadvantage of this is that the running, configuration, management, and all life cycles of the application will be bound to the current operating system, which is not beneficial to the upgrade update/rollback and other operations of the application, and certainly, some functions can be implemented by creating a virtual machine, but the virtual machine is very heavy and not beneficial to portability.
Kubernetes realizes application deployment on a cloud platform in a container creating mode, containers are isolated from one another, each container has a file system of the container, processes among the containers cannot affect one another, and computing resources can be distinguished. Compared with a virtual machine, the container can be deployed rapidly, and the container can be migrated among different clouds and different versions of operating systems because the container is decoupled from underlying facilities and a machine file system.
The container occupies less resources and is fast to deploy, each application can be packaged into a container mirror image, the container has greater advantages due to the one-to-one relationship between each application and the container, and the container mirror image can be created for the application at the stage of build or release by using the container, because each application does not need to be combined with the rest of application stacks and does not depend on the production environment infrastructure, and a consistent environment can be provided from research and development to test and production. Similarly, containers are lighter weight, more "transparent" than virtual machines, which is more convenient to monitor and manage.
Kubernetes supports automated deployment, large-scale scalable, application containerization management. When an application is deployed in a production environment, multiple instances of the application are typically deployed to load balance application requests. In kubernets, a plurality of containers can be created, each container runs an application instance, and then management, discovery and access of the group of application instances are realized through a built-in load balancing strategy, and the details do not need operation and maintenance personnel to perform complicated manual configuration and processing.
The container service network is one of three core network capabilities of a Kubernetes container cluster, and provides a container with forwarding and load balancing capabilities from the container to a container service on the premise of container network connectivity.
Fig. 1 is a diagram illustrating a network architecture for implementing a container service network in the related art.
As shown in fig. 1, a critical datapath of the container service network is that a data packet is first sent from a network stack of a container to a host network stack via a veth pair (across namespace), and then load balancing forwarding to a container service instance is realized based on an iptables/ipv rule (out of host network card) of the host.
The implementation scheme of the key datapath of the container service network has obvious performance loss and cannot meet the requirement of high-performance service access (such as ultra-low delay).
The scheme mainly has the following problems:
1) the data packet receiving and sending from the container to the host is carried out through a path pair, the path pair is a virtual network interface, the receiving and sending data packet is similar to a real network device, and the processing delay caused by obvious (soft) interruption is realized;
2) an L3 protocol stack is needed from a veth interface of a host end to a physical network card, so that the link is long and the time delay is large;
3) the load balancing modules such as the ipv/iptables and the like are realized based on a Netfilter packet filtering mechanism, and an obvious performance problem exists in a high-concurrency scene.
In view of the above problems in the related art, the embodiments of the present application provide a method and a system for constructing a high performance container service network based on macvlan and eBPF. Specifically, the embodiment of the application designs a new mechanism for realizing a container service network, the mechanism uses an L2 link layer scheme macvlan to replace a veth pair and a host L3 scheme to realize an efficient data forwarding path, and designs a 'tc-ebpf' scheme to solve the problem that the macvlan cannot adapt to iptables/ipv of an L3 layer at an L2 layer, thereby realizing efficient load balancing capability; based on the mechanism, a system implementation process in the kubernets environment is designed. By the method and the system, the transmission and processing time delay of the container service network can be greatly reduced, and the high-performance container service network is realized.
The following detailed description is provided to technical solutions of a container service network configuration method, a container service network configuration apparatus, a computer readable medium, an electronic device, and a computer program product, which are provided by the present application, in conjunction with specific embodiments.
Fig. 2 is a flow chart illustrating steps of a container service network configuration method in one embodiment of the present application. As shown in fig. 2, the method for configuring a container service network may mainly include the following steps S210 to S240.
Step S210: when it is monitored that a new container is created on a host, a container network stack is configured for the container;
step S220: configuring a virtual network card corresponding to a physical network card of a host in a container network stack, wherein the virtual network card is a network interface with an independent physical address;
step S230: recording the physical address of the virtual network card in the physical network card of the host;
step S240: and registering a hook function for carrying out load balancing processing on the service access flow of the container in the container network stack according to the physical address of the virtual network card.
In the container service network configuration method provided in the embodiment of the present application, by configuring a virtual network card in a container network stack and registering a hook function for load balancing a service access traffic of a container, a data packet can be directly transmitted to a physical network card of a host through an L2 layer without crossing a namespace, so that a data transmission path can be shortened, cross-layer transmission can be reduced, a network delay of data transmission can be reduced, a problem of load balancing at an L2 data link layer can be solved, and the method is more suitable for a large-scale service scenario.
The following describes each method step of the container service network configuration method in the present application in detail.
In step S210, when it is monitored that a new container is created on the host, a container network stack is configured for the container.
The network stack comprises a network card, a loop back device, a routing table, an Iptables rule and other various elements. For a process, these elements form the basic environment for initiating and responding to network requests. For a container, the Network stack of the host can be directly used, i.e. the Network Namespace is not opened, however, the problem of sharing Network resources, such as port conflict, is inevitably introduced. Therefore, in the embodiment of the application, a container network stack is configured for the container in the network Namespace, so that the container has an IP address and a port of the container.
Fig. 3 shows a block diagram of a container service network configuration over kubernets according to an embodiment of the present application. As shown in fig. 3, the implementation scheme of the embodiment of the present application mainly includes two parts, on one hand, a network stack is configured for a container based on a macvlan mechanism, including an IP and a MAC address; specifically, the implementation includes a network plug-in cni _ macvlan, which is responsible for integrating with kubernets and configuring the container network stack; another aspect is to configure a load balancing policy based on the eBPF mechanism; the method specifically comprises writing a tc _ controller plug-in which is responsible for listening to the creation of the container service and converting the container service into a hook function for load balancing.
In one embodiment of the present application, the container network interface plug-in cni _ macvlan may be invoked by a proxy node kubel of a container orchestration engine Kubernetes installed on the host to configure the container network stack for the container via the container network interface plug-in cni _ macvlan.
In an embodiment of the present application, the container network interface plug-in performs data interaction with a proxy node of the container orchestration engine based on a container network interface standard, so as to implement an add network function addNetwork and a remove network function delNetwork in the container network interface standard.
In step S220, a virtual network card corresponding to the physical network card of the host is configured in the container network stack, and the virtual network card is a network interface having an independent physical address.
Fig. 4 shows a block diagram of a module for implementing a data forwarding path based on macvlan in an embodiment of the present application. As shown in fig. 4, the physical network card on the host is eth _0, and the corresponding virtual network card eth _1 and virtual network card eth _2 may be respectively configured for the two containers based on the macvlan mechanism.
The macvlan is a network card virtualization technology, a physical network card can be virtualized into a plurality of network interfaces with independent mac addresses and IP addresses, and the network interfaces can be directly configured in a network stack of a container namespace.
The data packet directly reaches the physical network card at a link layer through a virtual network interface (such as eth _1) of the macvlan, and does not pass through a Netfilter module of a kernel, so that the data does not pass through an L3 protocol stack, and cross-layer transmission of the data packet is avoided.
In step S230, the physical address of the virtual network card is recorded in the physical network card of the host.
The physical network card of the host can forward the data packet by recording the physical address of the virtual network card in the physical network card of the host.
The Macvlan can configure a plurality of virtual network interfaces on one network interface of the host, and the network interfaces have independent MAC addresses, and can also configure IP addresses for communication. The virtual machine or container network under the Macvlan and the host are in the same network segment and share the same broadcast domain. Macvlan and Bridge are relatively similar, but because it omits the presence of Bridge, configuration and commissioning is relatively simple and efficient. In addition, Macvlan itself also perfectly supports VLANs.
Data transmission between the same VLAN is realized by two-layer mutual access, namely MAC address, and routing is not needed. By default, users of different VLANs cannot communicate directly, and if communication is desired, three layers of equipment are required for routing, as is the case with Macvlan. The virtual network card virtualized by the Macvlan technology is logically equivalent to the physical network card. The physical network card also acts as an exchanger, records the corresponding virtual network card and MAC address, and judges which virtual network card the packet belongs to according to the destination MAC address after the physical network card receives the data packet. This means that the physical network card receives only the packet and does not process the packet as long as the packet is transmitted from the Macvlan subinterface (or the packet is transmitted to the Macvlan subinterface).
Briefly, the Macvlan virtual network card device is parasitic on the physical network card device. And calling the packet sending function of the user when sending the packet, searching the parasitic physical equipment, and then sending the packet through the physical equipment. And when the packet is received, processing the data packet by registering the rx _ handler callback function of the parasitic physical device.
In step S240, a hook function for performing load balancing processing on the service access traffic of the container is registered in the container network stack according to the physical address of the virtual network card.
In an embodiment of the present application, a method for registering a hook function for load balancing service access traffic of a container in a container network stack according to a physical address of a virtual network card may include: acquiring service configuration information of a container network stack according to the physical address of the virtual network card; and converting the service configuration information into a hook function for load balancing the service access flow of the container through a flow controller installed in the host.
The Hook technology is also called Hook function, before the system does not call the function, the Hook program captures the message, the Hook function obtains control right first, and the Hook function can process (change) the execution behavior of the function and can also forcibly end the transfer of the message.
Fig. 5 shows a block diagram of modules for implementing packet load balancing in an embodiment of the present application. As shown in fig. 5, the TC module takes over the incoming and outgoing traffic directly hook at the network card device. The traffic controller tc _ controller module of the kernel can work directly in the link layer to pipe the traffic to and from the container, while providing a hook interface for the eBPF framework. The load balancing function can be realized by writing a hook function of eBPF: the eBPF is a set of kernel framework, and customized execution logic can be added to each key processing node of a kernel through hooks (hooks). According to the embodiment of the application, the load balancing processing is realized by writing eBPF hook codes in the egr node of the tc module.
In an embodiment of the present application, converting, by a traffic controller installed in a host, service configuration information into a hook function for load balancing service access traffic of a container includes: writing service configuration information into a programming language code through a flow controller installed in a host; and converting the programming language code into a hook function for carrying out load balancing processing on the service access flow of the container.
The flow controller tc (traffic control) in the Linux operating system is used for flow control of the Linux kernel, and establishes a queue for processing a data packet by using a queue rule, and defines a manner in which the data packet in the queue is transmitted, thereby implementing flow control. The queue specification used by the TC module to implement the flow control function is divided into two categories, one is a non-class queue specification and the other is a class queue specification. The non-class queue specification is relatively simple, and the classification queue specification introduces concepts such as classification and filters, so that the flow control function of the non-class queue specification is enhanced.
The non-class queue specification is a queue specification which does not distinguish and treat data streams entering a network device (network card) uniformly. The use of classless queues provides that the formed queue can receive packets and re-order, delay or drop packets. Such queues provide that the formed queue can shape the traffic of the entire network device (network card), but cannot subdivide the traffic into various cases. The common classless queue specification mainly includes pffo _ fast (first in first out), TBF (token bucket filter), SFQ (random fair queue), ID (forward random packet loss), and the like. The traffic shaping means specified for use by such queues are mainly ordering, rate limiting and packet dropping.
The classification queue specification is a queue specification in which data packets entering the network device are treated differently in a classification manner according to different requirements. After a packet enters a sorted queue, it needs to be sent to a certain sort, that is, the packet needs to be sorted. The means for classifying the packets is a filter which returns a decision upon which to queue the packets into the corresponding class. Each subclass can be further classified again using their filter. Until no further classification is required, the packet is queued into the queue contained in that class. Most sorted queue specifications are capable of shaping traffic, in addition to being able to contain other queue specifications. This is useful where simultaneous scheduling (e.g., using SFQ) and flow control is required.
In one embodiment of the present application, a method of converting programming language code into a hook function for load balancing service access traffic of a container may include: calling a bottom virtual machine configured in a host machine to compile programming language codes into Berkeley packet filter instructions; compiling the Berkeley packet filter instruction into byte codes through an extended Berkeley packet filter installed in the host; the bytecode is registered as a hook function for load balancing the service access traffic of the container.
In one embodiment of the present application, tc _ controller first writes the configuration information of the container service as c language program code, and then calls the underlying virtual machine LLVM to compile the c language program code as BPF instructions.
The Berkeley Packet Filter (abbreviated as BPF) is a primitive interface of the data link layer in a Unix-like system, providing the receiving and sending of primitive link layer packets, and in addition, if the network card driver supports the flooding mode, it can make the network card in this mode, so that all packets on the network can be received, regardless of whether their destination is the host or not. The BPF supports the 'filtering' packet, so that the BPF only transmits the 'interested' packet to upper-layer software, other packets can be prevented from being copied from an operating system kernel to a user mode, the load of a CPU (central processing unit) for capturing the packet and the required buffer space are reduced, and the packet loss rate is reduced. The filtering function of the BPF is realized in the form of an interpreter of a BPF virtual machine language, a program of the language can capture packet data, take arithmetic operation on the data in the packet, compare the result with a constant or the data in the packet or a test bit in the result, and decide whether to accept or reject the packet according to the comparison result. On some platforms, including FreeBSD and WinPcap, just-in-time compilation techniques are used to convert virtual machine instructions into native code to further reduce overhead.
An extended burley Packet Filter (eBPF), which is a set of generic execution engines, provides a generic capability for efficiently and safely executing specific code based on system or program events, and users of the generic capability are no longer limited to kernel developers; the eBPF can be composed of an execution bytecode instruction, a storage object and a Helper help function, the bytecode instruction must be verified by a BPF verifier Verfier before the kernel executes, and meanwhile, in the kernel which enables the BPF JIT mode, the bytecode instruction is directly converted into a local instruction which can be executed by the kernel to run.
In one embodiment of the present application, a method for compiling berkeley packet filter instructions into bytecode through an extended berkeley packet filter configured in a host may include: and calling a kernel just-in-time compiler through an extended Berkeley packet filter configured in the host so as to compile the Berkeley packet filter instruction into byte codes through the kernel just-in-time compiler.
In the Java programming language and environment, a just-in-time compiler (JIT compiler) is a program that converts Java bytecodes (a program that includes instructions that need to be interpreted) into instructions that can be sent directly to a processor (processor). When a Java program is written, the source language statements are compiled into bytecodes by a Java front-end compiler (incremental compiler in Java or Eclipse JDT), rather than into native instruction code corresponding to a particular processor hardware platform (e.g., Intel's Pentium microprocessor or IBM's System/390 processor). Bytecode is platform independent code that can be sent to any platform and can run on that platform. A just-in-time compiler (JIT compiler) is provisioned with the virtual machine and is optionally used. It compiles the bytecode into an executable code of a specified platform that can be executed immediately.
In one embodiment of the present application, tc _ controller first writes the configuration information of the container service into c language code, and then calls LLVM to compile c program into BPF instruction; the eBPF module calls a kernel just-in-time compiler JIT to compile the BPF instruction into opcode byte codes; the eBPF module registers the byte codes as a hook function of the TC module Egress flow, and the hook function is responsible for carrying out load balancing processing on the service access of the container.
It should be noted that although the various steps of the methods in this application are depicted in the drawings in a particular order, this does not require or imply that these steps must be performed in this particular order, or that all of the shown steps must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions, etc.
The following describes an embodiment of an apparatus of the present application, which may be used to perform the container service network configuration method in the foregoing embodiment of the present application. Fig. 6 schematically shows a block diagram of a configuration apparatus of a container service network according to an embodiment of the present application. As shown in fig. 6, the container service network configuration apparatus 600 may include:
a network stack configuration module 610 configured to configure a container network stack for a container when it is monitored that a new container is created on a host;
a virtual network card configuration module 620 configured to configure a virtual network card corresponding to a physical network card of the host, where the virtual network card is a network interface having an independent physical address;
an address recording module 630 configured to record a physical address of the virtual network card in a physical network card of the host;
a function registration module 640 configured to register a hook function for load balancing service access traffic of the container according to the physical address of the virtual network card.
In an embodiment of the present application, based on the above embodiment, the function registration module 640 may further include:
the information acquisition module is configured to acquire service configuration information of the container network stack according to the physical address of the virtual network card;
a function conversion module configured to convert the service configuration information into a hook function for load balancing service access traffic of the container through a traffic controller installed in the host.
In an embodiment of the present application, based on the above embodiment, the function transformation module may further include:
a code writing module configured to write the service configuration information as a programming language code through a flow controller installed in the host;
a code conversion module configured to convert the programming language code into a hook function for load balancing service access traffic of the container.
In an embodiment of the present application, based on the above embodiment, the code conversion module may further include:
a code compilation module configured to invoke an underlying virtual machine configured within the host to compile the programming language code into Berkeley packet filter instructions;
a bytecode compilation module configured to compile the berkeley packet filter instructions into bytecodes through an extended berkeley packet filter installed within the host;
a bytecode registration module configured to register the bytecode as a hook function for load balancing service access traffic of the container.
In an embodiment of the present application, based on the above embodiment, the bytecode compilation module may be further configured to: calling a kernel just-in-time compiler through an extended Berkeley packet filter configured in the host, so as to compile the Berkeley packet filter instruction into byte codes through the kernel just-in-time compiler.
In an embodiment of the present application, based on the above embodiment, the network stack configuration module 610 may be further configured to: and calling a container network interface plug-in through a proxy node of a container arranging engine installed on the host, so as to configure a container network stack for the container through the container network interface plug-in.
In an embodiment of the present application, based on the above embodiment, the container network interface plug-in performs data interaction with the proxy node of the container orchestration engine based on a container network interface standard to implement an add network function and a remove network function in the container network interface standard.
The specific details of the container service network configuration apparatus provided in each embodiment of the present application have been described in detail in the corresponding method embodiment, and are not described herein again.
Fig. 7 schematically shows a block diagram of a computer system of an electronic device for implementing an embodiment of the present application.
It should be noted that the computer system 700 of the electronic device shown in fig. 7 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.
As shown in fig. 7, the computer system 700 includes a Central Processing Unit (CPU) 701 that can perform various appropriate actions and processes according to a program stored in a Read-Only Memory (ROM) 702 or a program loaded from a storage section 708 into a Random Access Memory (RAM) 703. In the random access memory 703, various programs and data necessary for system operation are also stored. The cpu 701, the rom 702, and the ram 703 are connected to each other via a bus 704. An Input/Output interface 705(Input/Output interface, i.e., I/O interface) is also connected to the bus 704.
The following components are connected to the input/output interface 705: an input portion 706 including a keyboard, a mouse, and the like; an output section 707 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 708 including a hard disk and the like; and a communication section 709 including a network interface card such as a local area network card, a modem, and the like. The communication section 709 performs communication processing via a network such as the internet. A driver 710 is also connected to the input/output interface 705 as necessary. A removable medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 710 as necessary, so that a computer program read out therefrom is mounted into the storage section 708 as necessary.
In particular, according to embodiments of the present application, the processes described in the various method flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 709, and/or installed from the removable medium 711. The computer program, when executed by the central processor 701, performs various functions defined in the system of the present application.
It should be noted that the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM), a flash Memory, an optical fiber, a portable Compact Disc Read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the application. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.
Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains.
It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.
Claims (10)
1. A method for configuring a container service network, comprising:
when it is monitored that a new container is created on a host, configuring a container network stack for the container;
configuring a virtual network card corresponding to a physical network card of the host, wherein the virtual network card is a network interface with an independent physical address;
recording the physical address of the virtual network card in the physical network card of the host;
and registering a hook function for carrying out load balancing processing on the service access flow of the container according to the physical address of the virtual network card.
2. The method according to claim 1, wherein registering a hook function for load balancing service access traffic of the container according to the physical address of the virtual network card comprises:
acquiring service configuration information of the container network stack according to the physical address of the virtual network card;
and converting the service configuration information into a hook function for load balancing the service access flow of the container through a flow controller installed in the host.
3. The method according to claim 2, wherein converting the service configuration information into a hook function for load balancing service access traffic of the container through a traffic controller installed in the host includes:
writing the service configuration information into programming language codes through a flow controller installed in the host;
and converting the programming language code into a hook function for carrying out load balancing processing on the service access flow of the container.
4. The container service network configuration method according to claim 3, wherein converting the programming language code into a hook function for load balancing service access traffic of the container comprises:
calling a bottom virtual machine configured in the host machine to compile the programming language code into Berkeley packet filter instructions;
compiling the berkeley packet filter instructions into bytecodes through an extended berkeley packet filter installed in the host;
and registering the bytecode as a hook function for carrying out load balancing processing on the service access flow of the container.
5. The method of claim 4, wherein compiling the berkeley packet filter instructions into bytecodes via an extended berkeley packet filter configured in the host comprises:
calling a kernel just-in-time compiler through an extended Berkeley packet filter configured in the host, so as to compile the Berkeley packet filter instruction into byte codes through the kernel just-in-time compiler.
6. The container service network configuration method of claim 1, wherein configuring a container network stack for the container comprises:
and calling a container network interface plug-in through a proxy node of a container arranging engine installed on the host, so as to configure a container network stack for the container through the container network interface plug-in.
7. The container service network configuration method of claim 6, wherein the container network interface plug-in performs data interaction with the agent node of the container orchestration engine based on a container network interface standard to implement an add network function and a remove network function in the container network interface standard.
8. A container service network configuration apparatus, comprising:
the network stack configuration module is configured to configure a container network stack for a container when it is monitored that a new container is created on a host;
a virtual network card configuration module configured to configure a virtual network card corresponding to a physical network card of the host, the virtual network card being a network interface having an independent physical address;
an address recording module configured to record a physical address of the virtual network card in a physical network card of the host;
and the function registration module is configured to register a hook function for performing load balancing processing on the service access flow of the container according to the physical address of the virtual network card.
9. A computer-readable medium, characterized in that the computer-readable medium has stored thereon a computer program which, when being executed by a processor, carries out the container service network configuration method of any one of claims 1 to 7.
10. An electronic device, comprising:
a processor; and
a memory for storing executable instructions of the processor;
wherein the processor is configured to cause the electronic device to perform the container service network configuration method of any one of claims 1 to 7 via execution of the executable instructions.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111643239.7A CN114363170A (en) | 2021-12-29 | 2021-12-29 | Container service network configuration method and related product |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111643239.7A CN114363170A (en) | 2021-12-29 | 2021-12-29 | Container service network configuration method and related product |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114363170A true CN114363170A (en) | 2022-04-15 |
Family
ID=81104187
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111643239.7A Pending CN114363170A (en) | 2021-12-29 | 2021-12-29 | Container service network configuration method and related product |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114363170A (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114928490A (en) * | 2022-05-20 | 2022-08-19 | 国网江苏省电力有限公司 | Multi-terminal network management and control method and device in container scene, storage medium and electronic equipment |
| CN114938331A (en) * | 2022-05-20 | 2022-08-23 | 国网江苏省电力有限公司 | Single-physical-port multi-network access method and device in container scene, storage medium and electronic equipment |
| CN114979076A (en) * | 2022-05-23 | 2022-08-30 | 杭州仟金顶信息科技有限公司 | Flat communication network oriented to cross-host container |
| CN115189948A (en) * | 2022-07-11 | 2022-10-14 | 北京志凌海纳科技有限公司 | Method and system for realizing container network plug-in CaaS platform |
| CN115529272A (en) * | 2022-11-03 | 2022-12-27 | 苏州浪潮智能科技有限公司 | Data processing method and device based on policy routing, equipment and storage medium |
| CN115766858A (en) * | 2022-11-11 | 2023-03-07 | 中国工商银行股份有限公司 | Traffic processing method and device, computer readable storage medium and electronic equipment |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111404753A (en) * | 2020-03-23 | 2020-07-10 | 星环信息科技（上海）有限公司 | Flat network configuration method, computer equipment and storage medium |
| US20200314015A1 (en) * | 2019-03-29 | 2020-10-01 | Juniper Networks, Inc. | Configuring service load balancers with specified backend virtual networks |
| CN111885075A (en) * | 2020-07-30 | 2020-11-03 | 广州华多网络科技有限公司 | Container communication method, device, network equipment and storage medium |
| CN112911008A (en) * | 2021-02-04 | 2021-06-04 | 中国工商银行股份有限公司 | Cloud computing container online and offline method and device |
| CN113535370A (en) * | 2020-04-09 | 2021-10-22 | 深圳致星科技有限公司 | Method and equipment for realizing multiple RDMA network card virtualization of load balancing |
-
2021
- 2021-12-29 CN CN202111643239.7A patent/CN114363170A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200314015A1 (en) * | 2019-03-29 | 2020-10-01 | Juniper Networks, Inc. | Configuring service load balancers with specified backend virtual networks |
| CN111404753A (en) * | 2020-03-23 | 2020-07-10 | 星环信息科技（上海）有限公司 | Flat network configuration method, computer equipment and storage medium |
| CN113535370A (en) * | 2020-04-09 | 2021-10-22 | 深圳致星科技有限公司 | Method and equipment for realizing multiple RDMA network card virtualization of load balancing |
| CN111885075A (en) * | 2020-07-30 | 2020-11-03 | 广州华多网络科技有限公司 | Container communication method, device, network equipment and storage medium |
| CN112911008A (en) * | 2021-02-04 | 2021-06-04 | 中国工商银行股份有限公司 | Cloud computing container online and offline method and device |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114928490A (en) * | 2022-05-20 | 2022-08-19 | 国网江苏省电力有限公司 | Multi-terminal network management and control method and device in container scene, storage medium and electronic equipment |
| CN114938331A (en) * | 2022-05-20 | 2022-08-23 | 国网江苏省电力有限公司 | Single-physical-port multi-network access method and device in container scene, storage medium and electronic equipment |
| CN114938331B (en) * | 2022-05-20 | 2023-07-21 | 国网江苏省电力有限公司 | Single-physical-port multi-network access method and device under container scene, storage medium and electronic equipment |
| CN114928490B (en) * | 2022-05-20 | 2023-08-15 | 国网江苏省电力有限公司 | Multi-terminal network management and control method and device in container scene, storage medium and electronic equipment |
| CN114979076A (en) * | 2022-05-23 | 2022-08-30 | 杭州仟金顶信息科技有限公司 | Flat communication network oriented to cross-host container |
| CN114979076B (en) * | 2022-05-23 | 2024-03-29 | 杭州仟金顶信息科技有限公司 | Flattened communication method oriented to cross-host container |
| CN115189948A (en) * | 2022-07-11 | 2022-10-14 | 北京志凌海纳科技有限公司 | Method and system for realizing container network plug-in CaaS platform |
| CN115189948B (en) * | 2022-07-11 | 2023-05-12 | 北京志凌海纳科技有限公司 | Method and system for realizing container network plug-in CaaS platform |
| CN115529272A (en) * | 2022-11-03 | 2022-12-27 | 苏州浪潮智能科技有限公司 | Data processing method and device based on policy routing, equipment and storage medium |
| CN115529272B (en) * | 2022-11-03 | 2023-03-14 | 苏州浪潮智能科技有限公司 | Data processing method and device based on policy routing, equipment and storage medium |
| CN115766858A (en) * | 2022-11-11 | 2023-03-07 | 中国工商银行股份有限公司 | Traffic processing method and device, computer readable storage medium and electronic equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114363170A (en) | Container service network configuration method and related product | |
| US20230104129A1 (en) | Network policy generation for continuous deployment | |
| Bremler-Barr et al. | OpenBox: A software-defined framework for developing, deploying, and managing network functions | |
| CN111049796B (en) | Method for realizing Overlay multi-tenant CNI (CNI) container network based on Open vSwitch | |
| US9672071B2 (en) | Method and system for distributed processing of HTTP requests | |
| TWI408934B (en) | Network interface techniques | |
| CN110392999A (en) | Virtual filter platform in distributed computing system | |
| Huang et al. | Evaluating open-source cloud computing solutions for geosciences | |
| CN104113574B (en) | Safe transfer method and system of wide area network trusted virtual machine | |
| Qi et al. | SPRIGHT: extracting the server from serverless computing! high-performance eBPF-based event-driven, shared-memory processing | |
| US9135050B2 (en) | Extensible network configuration management | |
| CN106489251A (en) | The methods, devices and systems that applied topology relation finds | |
| US11709716B2 (en) | Hardware offload support for an operating system offload interface using operation code verification | |
| Lettieri et al. | A survey of fast packet I/O technologies for network function virtualization | |
| EP4160409A1 (en) | Cloud native software-defined network architecture for multiple clusters | |
| US20230104368A1 (en) | Role-based access control autogeneration in a cloud native software-defined network architecture | |
| US20230107891A1 (en) | User interface for cloud native software-defined network architectures | |
| US7428730B2 (en) | Software development environment | |
| Gazis et al. | A survey of dynamically adaptable protocol stacks | |
| JP2023538938A (en) | Compilation strategies for shareable application snapshots | |
| US9465601B2 (en) | Pluggable activation engine extensions via virtual disks | |
| CN117941330A (en) | Describing network-level behavior using domain-specific language | |
| Mbongue et al. | Deploying multi-tenant FPGAs within Linux-based cloud infrastructure | |
| Elahi et al. | Toward scalable cloud data center simulation using high‐level architecture | |
| US20230336414A1 (en) | Network policy generation for continuous deployment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |