A method and device for container cross-network communication based on four-layer proxy

Abstract

The application relates to a four-layer proxy-based container cross-network communication method and device, and relates to the technical field of communication. The method comprises the following steps: presetting a custom component, configuring at least two custom Pods respectively located in different networks in the custom component; when an external Pod needs to access a target network different from a network to which the external Pod belongs, identifying whether a custom Pod in the custom component is in the same network as the external Pod, and if yes, the custom Pod is recorded as a same-network Pod; identifying whether a custom Pod in the custom component is in the target network, and if yes, the custom Pod is recorded as a target Pod; and the external Pod establishes communication with the target Pod by means of the same-network Pod, so as to access the target network. The application configures the Pods in different networks in the preset custom component, communicates with other Pods in different networks, and thus realizes cross-network communication and meets different communication requirements.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a container cross-network communication method and apparatus based on a four-layer proxy. Background Technology

[0002] In Kubernetes, a Pod is the basic unit of workload. By default, a Pod will only connect to one network, meaning it cannot access services on other networks. Currently, the industry typically introduces the Multus component to allow Pods to connect to different networks simultaneously, such as the management network and the business network.

[0003] However, in actual use, due to network planning issues, there may be address conflicts between different networks that Pods access in the Multus technical solution, or for security reasons, some networks may prohibit Pods from directly accessing them. In this case, the Multus solution is no longer suitable.

[0004] Therefore, to meet the current needs of cross-network communication, a new cross-network communication technology is provided. Summary of the Invention

[0005] This application provides a container cross-network communication method and apparatus based on a four-layer proxy. Pods in different networks are configured within a preset custom component, and cross-network communication is achieved by communicating with other Pods in different networks to meet different communication needs.

[0006] In a first aspect, this application provides a container cross-network communication method based on a four-layer proxy, the method comprising the following steps:

[0007] A custom component is preset, and at least two custom Pods located on different networks are configured within the custom component;

[0008] When an external Pod needs to access a target network that is different from its own network, the system identifies whether there is a custom Pod in the custom component that is in the same network as the external Pod. If there is, it is recorded as a Pod in the same network.

[0009] Identify whether the custom Pod exists in the target network within the custom component; if it does, record it as the target Pod.

[0010] The external Pod establishes communication with the target Pod through the Pod on the same network, thereby accessing the target network.

[0011] Furthermore, the preset custom component configures at least two custom Pods located on different networks, including the following steps:

[0012] Configure the proxy source port, proxy destination port, and proxy destination IP for each custom Pod, and establish a correspondence between them and the address and proxy source port of the custom component.

[0013] Furthermore, when an external Pod needs to access a target network different from its own network, the system identifies whether there is a custom Pod in the custom component that is in the same network as the external Pod. If so, it is recorded as a Pod in the same network, including the following steps:

[0014] Identify the proxy source port, proxy destination port, and proxy destination IP of each custom Pod in the custom component;

[0015] Determine whether there is a custom Pod in the custom component that is on the same network as the external Pod. If there is, record it as a Pod on the same network.

[0016] Furthermore, identifying whether the custom component contains a custom Pod located in the target network, and if so, recording it as part of the target Pod, includes the following steps:

[0017] Identify the proxy source port, proxy destination port, and proxy destination IP of each custom Pod in the custom component;

[0018] Determine whether the custom Pod exists in the target network within the custom component; if it does, record it as the target Pod.

[0019] Furthermore, the method also includes the following steps:

[0020] Create a CRI interface that dynamically obtains the proxy source port, proxy destination port, and proxy destination IP of the custom Pod.

[0021] Secondly, this application provides a container cross-network communication device based on a four-layer proxy, the device comprising:

[0022] The component configuration module is used to preset a custom component and configure at least two custom Pods located on different networks within the custom component.

[0023] The first Pod identification module is used to identify whether there is a custom Pod in the custom component that is in the same network as the external Pod when the external Pod needs to access a target network that is different from its own network. If there is, it is recorded as a same network Pod.

[0024] The second Pod identification module is used to identify whether the custom Pod exists in the target network within the custom component; if it does, it is recorded as the target Pod.

[0025] A cross-network communication module is used to control the external Pod to establish communication with the target Pod through the same network Pod, thereby accessing the target network.

[0026] Furthermore, the component configuration module is also used to configure the proxy source port, proxy destination port, and proxy destination IP for each custom Pod, and establish a correspondence between them and the address and proxy source port of the custom component.

[0027] Furthermore, the first Pod identification module is also used to identify the proxy source port, proxy destination port, and proxy destination IP of each custom Pod in the custom component;

[0028] The first Pod identification module is also used to determine whether there is a custom Pod in the custom component that is in the same network as the external Pod. If there is, it is recorded as a Pod in the same network.

[0029] Furthermore, the second Pod identification module is also used to identify the proxy source port, proxy destination port, and proxy destination IP of each custom Pod in the custom component;

[0030] The second Pod identification module is also used to determine whether there is a custom Pod in the target network in the custom component, and if so, it is recorded as the target Pod.

[0031] Furthermore, the device also includes an information acquisition module, which is used to create a CRI interface to dynamically acquire the proxy source port, proxy destination port, and proxy destination IP of the custom Pod.

[0032] The beneficial effects of the technical solution provided in this application include:

[0033] This application configures Pods on different networks within a pre-defined custom component, enabling cross-network communication by communicating with other Pods on different networks, thus meeting diverse communication needs. Attached Figure Description

[0034] Terminology Explanation:

[0035] IP: Internet Protocol.

[0036] CRI: Container Runtime Interface.

[0037] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 This is a flowchart illustrating the steps of the container cross-network communication method based on a four-layer proxy provided in the embodiments of this application;

[0039] Figure 2 This is a timing diagram for configuring the CRI interface in the container cross-network communication method based on a four-layer proxy provided in the embodiments of this application.

[0040] Figure 3 This is a schematic diagram illustrating the working principle of the custom component forwarding in the container cross-network communication method based on a four-layer proxy provided in this application embodiment;

[0041] Figure 4 This is a structural block diagram of a container cross-network communication device based on a four-layer proxy provided in the embodiments of this application. Detailed Implementation

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

[0043] The embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0044] This application provides a container cross-network communication method and apparatus based on a four-layer proxy. Pods in different networks are configured within a preset custom component, and cross-network communication is achieved by communicating with other Pods in different networks to meet different communication needs.

[0045] To achieve the aforementioned technical effects, the overall concept of this application is as follows:

[0046] A method for container cross-network communication based on a four-layer proxy, comprising the following steps:

[0047] S1. Pre-set a custom component and configure at least two custom Pods located on different networks within the custom component;

[0048] S2. When an external Pod needs to access a target network that is different from its own network, identify whether there is a custom Pod in the custom component that is in the same network as the external Pod. If there is, record it as a Pod in the same network.

[0049] S3. Identify whether there is a custom Pod in the target network in the custom component. If there is, record it as the target Pod.

[0050] S4. External Pods establish communication with the target Pod through Pods on the same network, thereby accessing the target network.

[0051] The embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0052] Firstly, see [the following] Figures 1-3 As shown in the figure, this application provides a container cross-network communication method based on a four-layer proxy, which includes the following steps:

[0053] S1. Pre-set a custom component and configure at least two custom Pods located on different networks within the custom component;

[0054] S2. When an external Pod needs to access a target network that is different from its own network, identify whether there is a custom Pod in the custom component that is in the same network as the external Pod. If so, record it as a Pod in the same network.

[0055] S3. Identify whether there is a custom Pod in the target network in the custom component. If there is, record it as the target Pod.

[0056] S4. External Pods establish communication with the target Pod through Pods on the same network, thereby accessing the target network.

[0057] It should be noted that a Pod is the smallest deployable unit of computing and can be created and managed in Kubernetes;

[0058] A Pod is a group of one or more containers that share storage and network resources, and specifications on how to run the containers;

[0059] The content of a Pod is always co-located and co-scheduled, and runs in a shared environment;

[0060] A Pod simulates a specific application "logical host": it contains one or more relatively tightly coupled application containers.

[0061] In this embodiment, Pods from different networks are configured within a preset custom component, and cross-network communication is achieved by communicating with other Pods from different networks, thus meeting different communication needs.

[0062] Furthermore, the preset custom component configures at least two custom Pods located on different networks, including the following steps:

[0063] Configure the proxy source port, proxy destination port, and proxy destination IP for each custom Pod, and establish a correspondence between them and the address and proxy source port of the custom component.

[0064] Furthermore, when an external Pod needs to access a target network different from its own network, the system identifies whether there is a custom Pod in the custom component that is in the same network as the external Pod. If so, it is recorded as a Pod in the same network, including the following steps:

[0065] Identify the proxy source port, proxy destination port, and proxy destination IP of each custom Pod in the custom component;

[0066] Determine whether there is a custom Pod in the custom component that is on the same network as the external Pod. If there is, record it as a Pod on the same network.

[0067] Furthermore, identifying whether the custom component contains a custom Pod located in the target network, and if so, recording it as part of the target Pod, includes the following steps:

[0068] Identify the proxy source port, proxy destination port, and proxy destination IP of each custom Pod in the custom component;

[0069] Determine whether the custom Pod exists in the target network within the custom component; if it does, record it as the target Pod.

[0070] Furthermore, the method also includes the following steps:

[0071] Create a CRI interface that dynamically obtains the proxy source port, proxy destination port, and proxy destination IP of the custom Pod;

[0072] The CRI interface is used to dynamically obtain Pod network namespace information and dynamically listen to proxy ports in the namespace to provide proxy services.

[0073] In summary, the technical solution based on the embodiments of this application is as follows:

[0074] First, in Linux systems, Pods run within network namespaces represented by Net Namespaces. Each Net Namespace is isolated from the others, meaning each Pod is isolated on the network. When Pods connect to the same network, external routing ensures Layer 4 communication between them. However, when two different Pods connect to different networks, they cannot communicate at Layer 4 without external routing to establish a connection. Here, we introduce a component called dispatcher to act as a proxy for the two Pods located on different networks. They configure proxy rules, which are then distributed to the dispatcher by another component called agent. Finally, the Pods indirectly access each other by accessing the dispatcher, thus indirectly establishing Layer 4 communication.

[0075] Second, regarding proxy rules, users mainly declare (proxy source port, proxy destination port, proxy destination IP). After declaration, users access the dispatcher address and proxy source port, thus indirectly accessing the proxy destination IP and proxy destination port.

[0076] Third, the dispatcher component consists of a pair of Pods (PodA, PodB), each connected to two different networks (NetworkA, NetworkB). When PodC in NetworkA wants to access a web service on port 80 of PodD in NetworkB, the user only needs to declare the proxy rules (proxy source port 80, proxy destination port 80, proxy destination IP PodD's IP), and then access PodA's IP and proxy source port.

[0077] Fourth, when configuring proxy rules, the agent queries the CRI for the metadata (Net Namespace information) of the proxy destination Pod in the dispatcher. Finally, the rules sent to the proxy source Pod in the dispatcher contain information (proxy source port, proxy destination port, proxy destination IP, Net Namespace). The proxy source Pod in the dispatcher will listen on the Socket in the Net Namespace based on the received information.

[0078] The technical solutions of this application have at least the following technical advantages:

[0079] Users don't need to be aware of other networks; they only need to focus on which services they need to access.

[0080] Accessing the destination service via the dispatcher only requires attention to the Layer 4 port, and the Layer 3 network addresses can overlap, reducing the requirements for network planning.

[0081] Dynamic configuration, flexible deployment.

[0082] Secondly, see Figure 4 As shown, this application provides a container cross-network communication device based on a four-layer proxy.

[0083] The component configuration module is used to preset a custom component and configure at least two custom Pods located on different networks within the custom component.

[0084] The first Pod identification module is used to identify whether there is a custom Pod in the custom component that is in the same network as the external Pod when the external Pod needs to access a target network that is different from its own network. If there is, it is recorded as a same network Pod.

[0085] The second Pod identification module is used to identify whether the custom Pod exists in the target network within the custom component; if it does, it is recorded as the target Pod.

[0086] A cross-network communication module is used to control the external Pod to establish communication with the target Pod through the same network Pod, thereby accessing the target network.

[0087] In this embodiment, Pods from different networks are configured within a preset custom component, and cross-network communication is achieved by communicating with other Pods from different networks, thus meeting different communication needs.

[0088] Furthermore, the component configuration module is also used to configure the proxy source port, proxy destination port, and proxy destination IP for each custom Pod, and establish a correspondence between them and the address and proxy source port of the custom component.

[0089] Furthermore, the first Pod identification module is also used to identify the proxy source port, proxy destination port, and proxy destination IP of each custom Pod in the custom component;

[0090] The first Pod identification module is also used to determine whether there is a custom Pod in the custom component that is in the same network as the external Pod. If there is, it is recorded as a Pod in the same network.

[0091] Furthermore, the second Pod identification module is also used to identify the proxy source port, proxy destination port, and proxy destination IP of each custom Pod in the custom component;

[0092] The second Pod identification module is also used to determine whether there is a custom Pod in the target network in the custom component, and if so, it is recorded as the target Pod.

[0093] Furthermore, the device also includes an information acquisition module, which is used to create a CRI interface to dynamically acquire the proxy source port, proxy destination port, and proxy destination IP of the custom Pod.

[0094] In summary, the technical solution based on the embodiments of this application is as follows:

[0095] First, in Linux systems, Pods run within network namespaces represented by Net Namespaces. Each Net Namespace is isolated from the others, meaning each Pod is isolated on the network. When Pods connect to the same network, external routing ensures Layer 4 communication between them. However, when two different Pods connect to different networks, they cannot communicate at Layer 4 without external routing to establish a connection. Here, we introduce a component called dispatcher to act as a proxy for the two Pods located on different networks. They configure proxy rules, which are then distributed to the dispatcher by another component called agent. Finally, the Pods indirectly access each other by accessing the dispatcher, thus indirectly establishing Layer 4 communication.

[0096] Second, regarding proxy rules, users mainly declare (proxy source port, proxy destination port, proxy destination IP). After declaration, users access the dispatcher address and proxy source port, thus indirectly accessing the proxy destination IP and proxy destination port.

[0097] Third, the dispatcher component consists of a pair of Pods (PodA, PodB), each connected to two different networks (NetworkA, NetworkB). When PodC in NetworkA wants to access a web service on port 80 of PodD in NetworkB, the user only needs to declare the proxy rules (proxy source port 80, proxy destination port 80, proxy destination IP PodD's IP), and then access PodA's IP and proxy source port.

[0098] Fourth, when configuring proxy rules, the agent queries the CRI for the metadata (Net Namespace information) of the proxy destination Pod in the dispatcher. Finally, the rules sent to the proxy source Pod in the dispatcher contain information (proxy source port, proxy destination port, proxy destination IP, Net Namespace). The proxy source Pod in the dispatcher will listen on the Socket in the Net Namespace based on the received information.

[0099] The technical solutions of this application have at least the following technical advantages:

[0100] Users don't need to be aware of other networks; they only need to focus on which services they need to access.

[0101] Accessing the destination service via the dispatcher only requires attention to the Layer 4 port, and the Layer 3 network addresses can overlap, reducing the requirements for network planning.

[0102] Dynamic configuration, flexible deployment.

[0103] It should be noted that in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0104] The above are merely specific embodiments of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A container cross-network communication method based on a four-layer proxy, characterized in that, The method includes the following steps: A custom component is preset, and at least two custom Pods located on different networks are configured within the custom component; When an external Pod needs to access a target network that is different from its own network, the system identifies whether there is a custom Pod in the custom component that is in the same network as the external Pod. If there is, it is recorded as a Pod in the same network. Identify whether the custom Pod exists in the target network within the custom component; if it does, record it as the target Pod. The external Pod establishes communication with the target Pod through the Pod on the same network, thereby accessing the target network; The preset custom component configures at least two custom Pods located on different networks, including the following steps: Configure the proxy source port, proxy destination port, and proxy destination IP for each custom Pod, and establish a correspondence between them and the address and proxy source port of the custom component; When an external Pod needs to access a target network different from its own network, the system identifies whether there is a custom Pod in the custom component that is in the same network as the external Pod. If so, it is recorded as a Pod in the same network, including the following steps: Identify the proxy source port, proxy destination port, and proxy destination IP of each custom Pod in the custom component; Determine whether there is a custom Pod in the custom component that is on the same network as the external Pod. If there is, record it as a Pod on the same network.

2. The container cross-network communication method based on a four-layer proxy as described in claim 1, characterized in that, Identify whether the custom Pod exists in the target network within the custom component. If it does, mark it as being in the target Pod. This includes the following steps: Identify the proxy source port, proxy destination port, and proxy destination IP of each custom Pod in the custom component; Determine whether the custom Pod exists in the target network within the custom component; if it does, record it as the target Pod.

3. The container cross-network communication method based on a four-layer proxy as described in claim 1, characterized in that, The method further includes the following steps: Create a CRI interface that dynamically obtains the proxy source port, proxy destination port, and proxy destination IP of the custom Pod.

4. A container cross-network communication device based on a four-layer proxy, characterized in that, The device includes: The component configuration module is used to preset a custom component and configure at least two custom Pods located on different networks within the custom component. The first Pod identification module is used to identify whether there is a custom Pod in the custom component that is in the same network as the external Pod when the external Pod needs to access a target network that is different from its own network. If there is, it is recorded as a same network Pod. The second Pod identification module is used to identify whether the custom Pod exists in the target network within the custom component; if it does, it is recorded as the target Pod. A cross-network communication module is used to control the external Pod to establish communication with the target Pod through the same network Pod, thereby accessing the target network; The component configuration module is also used to configure the proxy source port, proxy destination port and proxy destination IP for each custom Pod, and establish a correspondence between them and the address and proxy source port of the custom component; The first Pod identification module is also used to identify the proxy source port, proxy destination port, and proxy destination IP of each custom Pod in the custom component; The first Pod identification module is also used to determine whether there is a custom Pod in the custom component that is in the same network as the external Pod. If there is, it is recorded as a Pod in the same network.

5. The container cross-network communication device based on a four-layer proxy as described in claim 4, characterized in that: The second Pod identification module is also used to identify the proxy source port, proxy destination port, and proxy destination IP of each custom Pod in the custom component; The second Pod identification module is also used to determine whether there is a custom Pod in the target network in the custom component, and if so, it is recorded as the target Pod.

6. The container cross-network communication device based on a four-layer proxy as described in claim 4, characterized in that, The device further includes: The information acquisition module is used to create a CRI interface, which dynamically acquires the proxy source port, proxy destination port, and proxy destination IP of the custom Pod.

Images