VRF-based container cross-network communication method and device

Abstract

The invention relates to a container cross-network communication method and device based on VRF. The method comprises the following steps: creating an agent component dispatcher for a network 1 and a network 2 which are isolated from each other; the method comprises the following steps of: calling CNI by Multi to respectively carry out initialized dispatcher network configuration on a network 1 and a network 2; respectively creating a routing table 1, a routing table 2 and corresponding VRF1 equipment and VRF2 equipment for the network 1 and the network 2, and associating the routing tables with the corresponding VRF1 equipment; and the agent component dispatcher is bound with a VRF interface, and queries different routing tables associated with the VRF equipment during flow forwarding, so that data forwarding between the network 1 and the network 2 is realized. According to the method, different networks are isolated through the VRF equipment, the proxy component is bound with the VRF interface, and different routing tables associated with the VRF equipment are queried when the traffic is forwarded, so that the requirement on network planning is reduced, and interference is effectively avoided.

Description

Technical Field

[0001] The present application belongs to the field of cross-network communication technology, and in particular, relates to a VRF-based container cross-network communication method, device, computer-readable storage medium, and electronic device. Background Art

[0002] In Kubernetes, Pod, as the basic workload unit, will only be connected to one network by default. Different networks are generally isolated from each other, which means that Pod cannot access services in other networks by default.

[0003] At present, the industry generally introduces the component Multus to call different CNIs to create two different network cards in the Pod to access different networks, such as access to the management network and the business network. At this time, these CNIs are all operated in the default routing table. However, this network access method has high requirements for network address and route planning, and is prone to address conflicts, resulting in network disconnection or security issues. Summary of the invention

[0004] In order to address the above problems, this application proposes a new VRF-based container cross-network communication method.

[0005] Specifically, this application provides the following technical solutions: A first aspect of the present application provides a VRF-based container cross-network communication method, the method comprising: For the isolated networks 1 and 2, create a proxy component dispatcher; Multus calls CNI to initialize the dispatcher network configuration for network 1 and network 2 respectively; Create routing table 1, routing table 2 and corresponding VRF1 devices, VRF2 devices for network 1 and network 2 respectively, and associate the routing table with the corresponding VRF devices; The dispatcher component binds to the VRF interface and queries different routing tables associated with the VRF device when forwarding traffic to achieve data forwarding between network 1 and network 2.

[0006] Optionally, in the method of the present application, the proxy component dispatcher spans network 1 and network 2 and is presented as a Pod in Kubernetes.

[0007] Optionally, in the method of the present application, Multus calls CNI to initialize the dispatcher network configuration for network 1 and network 2 respectively, including: (1) Multus calls network 1 CNI to initialize network 1 configuration Multus calls network 1 CNI to obtain the network configuration of network 1; Network 1 CNI creates NIC 1 in the Pod and configures IP address 1 on NIC 1; (2) Multus calls network 2 CNI to initialize network 2 configuration Multus calls network 2 CNI to obtain the network configuration of network 2; The network 2 CNI creates NIC 2 in the Pod and configures IP address 2 on NIC 2.

[0008] Optionally, in the method of the present application, the network configuration of the network 1 includes but is not limited to: IP address 1, default gateway 1; The network configuration of the network 2 includes but is not limited to: IP address 2 and default gateway 2.

[0009] Optionally, the method of the present application also includes: calling network 1 CNI and network 2 CNI respectively to create a default route in routing table 1 and routing table 2, and the gateways are set to default gateway 1 and default gateway 2 respectively.

[0010] Optionally, in the method of the present application, the proxy component dispatcher implements data forwarding between network 1 and network 2, including: The dispatcher actively creates socket1, listens to the port, and calls the system call setsockopt to configure the parameter SO_BINDTODEVICE to bind socket1 to the VRF1 device interface. The client on network 1 accesses the listening port and sends a request; After receiving the request, the dispatcher passively initiates access to the server on network 2, creates socket 2, and then calls the system call setsockopt to configure the parameter SO_BINDTODEVICE to bind socket 2 to the VRF2 device interface. The dispatcher forwards the request to the server, and the server sends a response; The dispatcher forwards the response to the client.

[0011] A second aspect of the present application provides a VRF-based container cross-network communication device, the device comprising: Dispatcher creation module: used to create a proxy component dispatcher for the isolated networks 1 and 2; Network configuration module: used to call CNI to initialize the dispatcher network configuration for network 1 and network 2 respectively; Routing association module: used to create routing table 1, routing table 2 and corresponding VRF1 device, VRF2 device for network 1 and network 2 respectively, and associate the routing table with the corresponding VRF device; Data forwarding module: used to bind the proxy component dispatcher to the VRF interface, query different routing tables associated with the VRF device when forwarding traffic, and realize data forwarding between network 1 and network 2.

[0012] The device implements the steps of the aforementioned VRF-based container cross-network communication method when running.

[0013] A third aspect of the present application provides an electronic device, comprising: a memory and a processor; Memory: used to store computer programs; Processor: used to execute the computer program to implement the steps of the aforementioned VRF-based container cross-network communication method.

[0014] A fourth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the aforementioned VRF-based container cross-network communication method are implemented.

[0015] In summary, this application proposes a new VRF-based container cross-network communication method, which has the following advantages: (1) This method isolates different networks through VRF devices. The proxy component queries the associated different routing tables when binding the VRF interface to forward traffic, effectively avoiding interference.

[0016] (2) The three-layer network addresses in the architecture of this method can overlap, reducing the requirements for network planning.

[0017] Other features and advantages of the present application will be described in the following description, or understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the techniques indicated in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions of the embodiments of the present application, a brief introduction will be given below to the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0019] Figure 1 An overall implementation flow chart of the VRF-based container cross-network communication method provided in an embodiment of the present application.

[0020] Figure 2 A flowchart for initializing the dispatcher network configuration in the VRF-based container cross-network communication method provided in an embodiment of the present application.

[0021] Figure 3 A flow chart of the dispatcher forwarding data between network 1 and network 2 in the VRF-based container cross-network communication method provided in an embodiment of the present application.

[0022] Figure 4 A composition structure diagram of a VRF-based container cross-network communication device provided in an embodiment of the present application.

[0023] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of this application.

[0025] As used herein, the term “including” and its variations are open inclusions, ie, “including but not limited to”; the term “based on” means “based at least in part on”; and the term “one embodiment” means “at least one embodiment”.

[0026] It should be noted that the modifications of "one" and "plurality" mentioned in the present application are illustrative rather than restrictive, and those skilled in the art should understand that unless the context clearly indicates otherwise, it should be understood as "one or more".

[0027] Explanation of terms CNI: Container Network Interface is a specification and library defined by the Cloud Native Computing Foundation (CNCF) project for configuring network interfaces in Linux containers. CNI aims to provide a common interface between the container runtime and the network plug-in, which is used to configure IP addresses, routing tables, etc. for Pods, and to achieve standardization of container network configuration.

[0028] Multus: is an open source CNI plug-in used to initialize the network configuration of the Pod, provide multi-network support for the Pod, and allow the Pod to have multiple network interfaces to connect to multiple networks, thus achieving more flexible and complex network topology.

[0029] Dispatcher: The proxy component used in this application to forward layer 4 traffic.

[0030] Kubelet: A Kubernetes component used to manage the lifecycle of a Pod. When a Pod is created, Multus is called to initialize the Pod network.

[0031] setsockopt: A system call commonly used in network programming to set socket options.

[0032] SO_BINDTODEVICE: A socket option used to bind a socket to a specific network device.

[0033] Figure 1 The overall implementation process of the VRF-based container cross-network communication method provided by this application is shown, including the following steps: For the isolated networks 1 and 2, create a proxy component dispatcher; Multus calls CNI to initialize the dispatcher network configuration for network 1 and network 2 respectively; Create routing table 1, routing table 2 and corresponding VRF1 devices, VRF2 devices for network 1 and network 2 respectively, and associate the routing table with the corresponding VRF devices; The dispatcher component binds to the VRF interface and queries different routing tables associated with the VRF device when forwarding traffic to achieve data forwarding between network 1 and network 2.

[0034] In order to better understand the technical solution of the present application, it is further described with reference to the following embodiments.

[0035] Assume that there are two isolated networks, Network 1 and Network 2. The client is located in Network 1 and the server is located in Network 2. At this time, if the client directly accesses the server, the access is unsuccessful because Network 1 and Network 2 are isolated from each other. In order for the client to access the server, a proxy component dispatcher needs to be created. The dispatcher spans Network 1 and Network 2 and is presented as a Pod in Kubernetes.

[0036] This embodiment is divided into two stages, which respectively describe the initial network configuration of the dispatcher by CNI and the parameters that the dispatcher program needs to set. CNI is the standard specification for Pod access to the network in Kubernetes. Different CNI programs are required to access different networks. The focus of this embodiment is not to describe how to implement CNI, but only to explain the related operations involving CNI.

[0037] 1. Initialize the dispatcher network configuration, such as Figure 2 As shown, including: (1) Multus calls network 1 CNI to initialize network 1 configuration The network 1 CNI obtains the network configuration of the network 1 (the network configuration may be stored in a database or any other medium capable of storing data), such as IP address 1, default gateway 1, etc.; Network 1 CNI creates NIC 1 in the Pod and configures IP address 1 on NIC 1; Network 1 CNI creates routing table 1, creates VRF1 device at the same time, and associates VRF1 device with this routing table 1; Network 1 CNI creates a default route in routing table 1, and the gateway is the default gateway 1 obtained earlier; (2) Multus calls network 2 CNI to initialize network 2 configuration The network 2 CNI obtains the network configuration of the network 2 (the network configuration may be stored in a database or any other medium capable of storing data), such as IP address 2, default gateway 2, etc.; Network 2 CNI creates network card 2 in the Pod and configures IP address 2 on network card 2; Network 2 CNI creates routing table 2, creates VRF2 device, and associates VRF2 device with routing table 2; Network 2 CNI creates a default route in routing table 2, and the gateway is the default gateway 2 obtained earlier.

[0038] 2. The proxy component dispatcher forwards data between network 1 and network 2, such as Figure 3 As shown, including: The dispatcher actively creates socket1, listens to the port, and calls the system call (setsockopt) to configure the parameter (SO_BINDTODEVICE) to bind socket1 to the VRF1 device interface. The client accesses the listening port and sends a request; After receiving the request, the dispatcher passively initiates access to the server, creates socket2, and then calls the system call (setsockopt) to configure the parameter (SO_BINDTODEVICE) to bind socket2 to the VRF2 device interface. The dispatcher forwards the request to the server, and the server sends a response; The dispatcher forwards the response to the client.

[0039] Figure 4 The figure shows a VRF-based container cross-network communication device proposed in the present application, including: Dispatcher creation module: used to create a proxy component dispatcher for the isolated networks 1 and 2; Network configuration module: used to call CNI to initialize the dispatcher network configuration for network 1 and network 2 respectively; Routing association module: used to create routing table 1, routing table 2 and corresponding VRF1 device, VRF2 device for network 1 and network 2 respectively, and associate the routing table with the corresponding VRF device; Data forwarding module: used to bind the proxy component dispatcher to the VRF interface, query different routing tables associated with the VRF device when forwarding traffic, and realize data forwarding between network 1 and network 2.

[0040] When the above device is running, the steps of the VRF-based container cross-network communication method disclosed in this application are implemented.

[0041] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the device, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be realized by a special hardware-based system that performs the specified function or operation, or can be realized by a combination of special hardware and computer instructions.

[0042] like Figure 5As shown, the embodiment of the present application also discloses an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing a processor executable computer program, and a communication bus 340. The processor 310, the communication interface 320, and the memory 330 communicate with each other through the communication bus 340. The processor 310 runs the executable computer program to implement the steps of the above-mentioned VRF-based container cross-network communication method.

[0043] It is understandable that, in addition to the memory and the processor, the electronic device may also include an input device such as a keyboard, an output device such as a display, and other communication modules. The input device, the output device, and other communication modules communicate with the processor via an I / O interface (i.e., an input / output interface).

[0044] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including, but not limited to, object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0045] Furthermore, the present application also discloses a computer-readable storage medium. When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the various steps of the VRF-based container cross-network communication method disclosed in the present application.

[0046] In the context of the present application, a computer-readable storage medium may be a tangible medium, more specific examples of which would include a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0047] In particular, according to an embodiment of the present application, the process described in the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program code for executing the VRF-based container cross-network communication method disclosed in the present application. When the computer program is executed by a processing device, the above functions defined in the method of the embodiment of the present application are executed.

[0048] Although several specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present application. The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present application is not limited to the technical solutions formed by a specific combination of the above technical features, but also should cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above public concept.

[0049] Those skilled in the art should also understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A container cross-network communication method based on VRF, characterized in that: The method comprises: For the isolated networks 1 and 2, create a proxy component dispatcher; Multus calls CNI to initialize the dispatcher network configuration for network 1 and network 2 respectively; Create routing table 1, routing table 2 and corresponding VRF1 devices, VRF2 devices for network 1 and network 2 respectively, and associate the routing table with the corresponding VRF devices; The dispatcher component binds to the VRF interface and queries different routing tables associated with the VRF device when forwarding traffic to achieve data forwarding between network 1 and network 2.

2. The communication method according to claim 1, characterized in that: The dispatcher proxy component spans network 1 and network 2 and is presented as a Pod in Kubernetes.

3. The communication method according to claim 1, characterized in that: The Multus calls CNI to initialize the dispatcher network configuration for network 1 and network 2 respectively, including: (1) Multus calls network 1 CNI to initialize network 1 configuration Multus calls network 1 CNI to obtain the network configuration of network 1; Network 1 CNI creates NIC 1 in the Pod and configures IP address 1 on NIC 1; (2) Multus calls network 2 CNI to initialize network 2 configuration Multus calls network 2 CNI to obtain the network configuration of network 2; The network 2 CNI creates NIC 2 in the Pod and configures IP address 2 on NIC 2.

4. The communication method according to claim 3, characterized in that: The network configuration of the network 1 includes: IP address 1, default gateway 1; The network configuration of the network 2 includes: IP address 2 and default gateway 2.

5. The communication method according to claim 4, characterized in that: The method further includes: respectively calling the network 1 CNI and the network 2 CNI to create a default route in the routing table 1 and the routing table 2, and the gateways are respectively set as the default gateway 1 and the default gateway 2.

6. The communication method according to claim 1, characterized in that: The proxy component dispatcher implements data forwarding between network 1 and network 2, including: The dispatcher actively creates socket1, listens to the port, and calls the system call setsockopt to configure the parameter SO_BINDTODEVICE to bind socket1 to the VRF1 device interface. The client on network 1 accesses the listening port and sends a request; After receiving the request, the dispatcher passively initiates access to the server on network 2, creates socket 2, and then calls the system call setsockopt to configure the parameter SO_BINDTODEVICE to bind socket 2 to the VRF2 device interface. The dispatcher forwards the request to the server, and the server sends a response; The dispatcher forwards the response to the client.

7. A container cross-network communication device based on VRF, characterized in that: The device comprises: Dispatcher creation module: used to create a proxy component dispatcher for the isolated networks 1 and 2; Network configuration module: used to call CNI to initialize the dispatcher network configuration for network 1 and network 2 respectively; Routing association module: used to create routing table 1, routing table 2 and corresponding VRF1 device, VRF2 device for network 1 and network 2 respectively, and associate the routing table with the corresponding VRF device; Data forwarding module: used to bind the proxy component dispatcher to the VRF interface, query different routing tables associated with the VRF device when forwarding traffic, and realize data forwarding between network 1 and network 2.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the VRF-based container cross-network communication method as described in any one of claims 1 to 6 are implemented.

9. An electronic device, characterized in that: include: Memory and processor; Memory: used to store computer programs; Processor: used to execute the computer program to implement the steps of the VRF-based container cross-network communication method as described in any one of claims 1-6.

Images