A service network access method, device, equipment and storage medium

By querying the routing table and adjacency table in the macvlan network, adding MAC addresses to the data packet, and sending them directly to the backend container, it solves the problem of service network access that cannot be met by the Netfilter framework, avoids waste of IP resources and improves network performance .

CN116016448BActive Publication Date: 2024-12-17SHANGHAI PUDONG DEVELOPMENT BANK
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202211543529.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-11-30
Publication Date
2024-12-17
Estimated Expiration
2042-11-30

AI Technical Summary

Technical Problem

The Netfilter framework of L3 packet filtering technology based on the kernel protocol stack cannot meet the service network access needs of macvlan network, resulting in waste of underlying network IP resources.

Method used

By querying the routing table and adjacency table, add the MAC address of the host and container to the data packet, determine the IP address of the backend container, and send the data packet to the backend container, realizing direct communication between the container and the host, avoiding the passage of the container and the user through the kernel protocol stack.

Benefits of technology

It effectively solves the problem of service network access in macvlan network, avoids the waste of underlying network IP resources, and improves network performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116016448B_ABST
    Figure CN116016448B_ABST
Patent Text Reader

Abstract

The present invention discloses a service network access method, device, equipment and storage medium. The method comprises: querying a routing table according to the destination address of a first data packet flow to obtain a next hop address; if the next hop address is not a local address, querying an adjacency table to obtain a MAC address of a network device deployed in a host machine corresponding to the IP address of the network device; adding the MAC address of the network device deployed in the host machine and the MAC address of the network device deployed in the container to the first data packet flow to obtain a second data packet flow; determining the IP address of a backend container corresponding to the second data packet flow according to the source address and destination address of the second data packet flow; sending the second data packet flow to the backend container according to the IP address of the backend container, and through the technical solution of the present invention, it is possible to avoid the waste of underlying network IP resources.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of computer technology, and in particular to a service network access method, device, equipment and storage medium. Background Art

[0002] The service network refers to the access between pods and services. In order to solve the problem of automatic expansion and contraction of pods and to provide a unified service access method to the outside world when the pod IP changes dynamically, Kubernetes proposed the concept of service, which is an abstract concept. The main implementation method is to map a specified port through a virtual IP, and forward the request sent by the proxy client to one of the pods (endpoints) in the backend. It is a way to implement load balancing within the cluster.

[0003] Currently, communication between service networks is mostly implemented based on the Netfilter framework, an L3 packet filtering technology of the kernel protocol stack. In k8s, service communication is completed through the kube-proxy component. There are two main modes of kube-proxy: iptables mode before version 1.8, and ipvs mode was introduced starting from version 1.8. Both ipvs and iptables are essentially based on the Netfilter framework.

[0004] The solution implemented by the Netfilter framework, an L3 packet filtering technology based on the kernel protocol stack, requires that the pod network needs to pass through the host's L3 protocol stack when communicating. The Macvlan network uses the Linux kernel technology, which is closer to the bare metal in terms of network performance, and is suitable for some business scenarios that require high performance. However, in the macvlan container network, the traffic in the container does not pass through the L3 layer of the kernel protocol stack, and the container and the host cannot communicate. There is no way to use ipvs / iptables technology to achieve communication between pod and service. Therefore, the industry uses the characteristics of macvlan: macvlan sub-interfaces can communicate with each other, create a macvlan sub-interface on the parent network card of the host as the container network card, and add the traffic to access the service inside the container, and its next-hop gateway address is the address of the macvlan sub-interface on the host to achieve communication between the container and the host.

[0005] The solution of using macvlan sub-interfaces to implement service communication can meet the access problem of the service network using macvlan as the pod network. However, the above solution requires that a macvlan sub-interface be created on each vlan sub-interface and an IP address be assigned to each sub-interface. As a large layer 2 network, if the Macvlan network is combined with IPAM in a centralized allocation method, that is, all nodes in the cluster are in the same large layer 2 network, the container IP address is not strongly bound to the host machine, and each node has the same vlan. The number of cluster nodes is N, and the number of vlans is M. For each additional vlan, N more IP addresses will be assigned to the macvlan sub-interface, and for each additional node, M more IP addresses will be assigned to the macvlan sub-interface, which consumes a large amount of service traffic and underlying network IP resources, thereby resulting in a waste of service traffic and underlying network IP resources. Summary of the invention

[0006] The embodiments of the present invention provide a service network access method, device, equipment and storage medium to solve the problem that the Netfilter framework of L3 packet filtering technology based on the kernel protocol stack cannot meet the service network access of the macvlan network, and can avoid the waste of underlying network IP resources.

[0007] According to one aspect of the present invention, a service network access method is provided, comprising:

[0008] According to the destination address of the first data packet flow, the routing table is searched to obtain the next hop address;

[0009] If the next hop address is not a local address, query the adjacency table to obtain the MAC address of the network device deployed in the host machine corresponding to the IP address of the network device;

[0010] Adding the MAC address of the network device deployed in the host machine and the MAC address of the network device deployed in the container to the first data packet flow to obtain a second data packet flow;

[0011] Determine the IP address of the backend container corresponding to the second data packet flow according to the source address and the destination address of the second data packet flow;

[0012] The second data packet traffic is sent to the backend container according to the IP address of the backend container.

[0013] According to another aspect of the present invention, a service network access device is provided, the service network access device comprising:

[0014] A first query module, used to query the routing table according to the destination address of the first data packet flow to obtain a next hop address;

[0015] A second query module is used to query the adjacency table if the next hop address is not a local address, and obtain the MAC address of the network device deployed in the host machine corresponding to the IP address of the network device;

[0016] An adding module, used for adding the MAC address of the network device deployed in the host machine and the MAC address of the network device deployed in the container to the first data packet flow to obtain a second data packet flow;

[0017] A determination module, configured to determine an IP address of a backend container corresponding to the second data packet flow according to a source address and a destination address of the second data packet flow;

[0018] The sending module is used to send the second data packet flow to the backend container according to the IP address of the backend container.

[0019] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0020] at least one processor; and

[0021] a memory communicatively connected to the at least one processor; wherein,

[0022] The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the service network access method described in any embodiment of the present invention.

[0023] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the service network access method described in any embodiment of the present invention when executed.

[0024] The embodiment of the present invention obtains the next hop address by querying the routing table according to the destination address of the first data packet flow; if the next hop address is not a local address, the adjacency table is queried to obtain the MAC address of the network device deployed in the host machine corresponding to the IP address of the network device; the MAC address of the network device deployed in the host machine and the MAC address of the network device deployed in the container are added to the first data packet flow to obtain the second data packet flow; the IP address of the backend container corresponding to the second data packet flow is determined according to the source address and the destination address of the second data packet flow; the second data packet flow is sent to the backend container according to the IP address of the backend container, which solves the problem that the Netfilter framework of the L3 packet filtering technology based on the kernel protocol stack cannot meet the service network access of the macvlan network, and can avoid the waste of the underlying network IP resources.

[0025] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0027] Figure 1 is a flow chart of a service network access method in an embodiment of the present invention;

[0028] Figure 2 This is an architecture diagram of a K8S cluster in an embodiment of the present invention;

[0029] Figure 3 is a structural diagram of a service network access device in an embodiment of the present invention;

[0030] Figure 4 It is a structural schematic diagram of an electronic device in an embodiment of the present invention. DETAILED DESCRIPTION

[0031] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0033] It is understandable that before using the technical solutions disclosed in the embodiments of the present disclosure, the types, scope of use, usage scenarios, etc. of the personal information involved in the present disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0034] Embodiment 1

[0035] Figure 1 A flowchart of a service network access method provided by an embodiment of the present invention. This embodiment is applicable to the case of service network access. The method can be executed by a service network access device in an embodiment of the present invention. The device can be implemented in software and / or hardware. Figure 1 As shown, the method specifically comprises the following steps:

[0036] S110, query the routing table according to the destination address of the first data packet flow to obtain the next hop address.

[0037] The routing table is an internal routing table of the container, for example, the routing table may include: a destination address, a gateway / lladdr, and a device.

[0038] In a specific example, the routing table is shown in Table 1:

[0039] Table 1

[0040]

[0041] Specifically, the container sends the first data packet flow to the service, queries the container's internal routing table according to the destination address of the first data packet flow, and obtains the next hop address and the next hop device. For example, the next hop address is 169.254.1.1 and the next hop device is veth1 device according to the container's internal routing table.

[0042] S120: If the next hop address is not a local address, query the adjacency table to obtain the MAC address of the network device deployed in the host machine corresponding to the IP address of the network device.

[0043] The adjacency table is a static adjacency table, which includes: a destination address, a gateway / lladdr, and a device.

[0044] In a specific example, the routing table is shown in Table 2:

[0045] Table 2

[0046] type Destination Address Gateway / lladdr equipment Adjacency List 169.254.1.1 $veth1_peer_mac veth1

[0047] In a specific example, since the next hop address is 169.254.1.1, which is not a local address, the MAC address of the address is queried. According to the static adjacency table, it can be found that the MAC address of this address is the mac address of veth** and is returned to the container.

[0048] S130, adding the MAC address of the network device deployed in the host machine and the MAC address of the network device deployed in the container to the first data packet flow to obtain a second data packet flow.

[0049] Among them, the IP address of the second data packet flow has not changed, the source address is the container IP address, the destination address is the cluster_IP address, the source MAC address is the MAC address of the veth1 device, and the destination MAC address is the MAC address of veth**.

[0050] S140: Determine an IP address of a backend container corresponding to the second data packet flow according to a source address and a destination address of the second data packet flow.

[0051] The source address of the second data packet flow is the container IP address, and the destination address is the cluster_IP address.

[0052] Specifically, the method for determining the IP address of the backend container corresponding to the second data packet flow according to the source address and destination address of the second data packet flow can be: if the source address and destination address of the second data packet flow match the KUBE-MARK_MASQ chain, then mark the second data packet flow; if the marked second data packet flow matches the INPUT chain, then obtain the IP address of the backend container corresponding to the second data packet flow.

[0053] S150: Send the second data packet flow to the backend container according to the IP address of the backend container.

[0054] In a specific example, add network device veth1, the gateway IP address is the private IP address 169.254.1.1, and add an adjacency table for the veth end in the container. The next hop of the IP address 169.254.1.1 is veth1, and the MAC address is the MAC address of the veth1 peer in the network namespace of the host. At this time, the second data packet flow with the source address being the container IP address and the destination address being the cluster IP can be received from the peer of veth1.

[0055] Optionally, determining the IP address of the backend container corresponding to the second data packet flow according to the source address and the destination address of the second data packet flow includes:

[0056] If the source address and the destination address of the second data packet flow match the KUBE-MARK_MASQ chain, mark the second data packet flow;

[0057] If the second data packet flow marked by the mark matches the INPUT chain, the IP address of the backend container corresponding to the second data packet flow is obtained.

[0058] The KUBE-MARK_MASQ chain is pre-created by the kube-proxy component. The KUBE-MARK_MASQ chain is used to mark data packet traffic.

[0059] Specifically, after the second data packet traffic enters the network namespace of the host, it enters the RREROUTING chain. In the PREROUTING chain, it matches the KUBE-MARK_MASQ chain in KUBE_SERVICES, which has a mark function and matches the KUBE-CLISTER-IP table of ipset.

[0060] It should be noted that, because the ipvs mode will create a kube-ipvs0 device on each kubernetes node, and the kube-ipvs0 device will bind all cluster IPs, the second data packet traffic after the mark will enter the INPUT chain. After the second data packet traffic after the mark enters the INPUT chain, IPVS will modify the rules, mainly based on the load balancing algorithm and the endpoints information maintained in the cluster, and select a service backend multi-DNAT conversion. At this time, the source IP address in the link is the container IP address, and the destination address is the IP address of the backend container selected according to the load balancing algorithm.

[0061] Optionally, also include:

[0062] If the second data packet flow matches the POSTROUTING chain, the IP address of the network device that the second data packet flow passes through to the next hop is obtained.

[0063] It should be noted that if the IP in the container is a virtual IP, the second data packet traffic cannot be sent to the backend container according to the IP address of the backend container. Therefore, it is necessary to perform SNAT conversion on the IP in the container.

[0064] In a specific example, a data packet flow is received, wherein the data packet flow carries a container IP address and a service IP address; the data packet flow is sent to a network namespace of a host machine; if the container IP address and the service IP address meet the requirements of a KUBE-MARK_MASQ chain, the data packet flow is marked with a mark of the KUBE-MARK_MASQ chain; the data packet flow is sent to an INPUT chain to obtain an IP address of a backend container corresponding to the data packet flow; the destination address of the data packet flow is changed to the IP address of the backend container; the data packet flow is sent to a POSTROUTING chain to obtain an IP address of a network device corresponding to the data packet flow that the data packet flow passes through on the next hop; and the data packet flow is sent to a backend container according to the IP address of the backend container.

[0065] It should be noted that the second data packet traffic marked with the mark is directly forwarded to the POSTRUTING chain. After the second data packet traffic marked with the mark enters the POSTROUTIONG chain, it will match the MASQUERADE rule in the KUBE-POSTROUTING chain and perform SNAT conversion. The source IP address is the IP address of the network device that jumps to the next hop.

[0066] Optionally, before searching the routing table according to the destination address of the first data packet flow to obtain the IP address of the network device corresponding to the data packet flow, the method further includes:

[0067] Create a veth pair;

[0068] Deploy the veth pair in the container and the host respectively.

[0069] The most important feature of veth pair is that it can cross Linux network namespaces. This feature can be used to connect container ns and host ns. Create a veth pair and insert its two ends into the network namespace of the host and container respectively.

[0070] It should be noted that by creating a veth pair, creating a private address route inside the container, and creating a static adjacency table for the private address, a mapping relationship between an IP and a MAC address is established with the veth pair peer on the host, so as to realize communication between the macvlan network container and the host, thereby realizing service network communication of the macvlan that bypasses the L3 kernel protocol stack.

[0071] In a specific example, a veth pair is created; the veth pair is deployed in a container and a host respectively; the routing table is searched according to the destination address carried by the data packet flow to obtain the IP address of the network device corresponding to the data packet flow; if the IP address of the network device is not a local address, the adjacency table is queried to obtain the MAC address of the network device deployed in the host corresponding to the IP address of the network device; the MAC address of the network device deployed in the host is added to the data packet flow; the data packet flow is sent to the backend container according to the MAC address of the network device deployed in the host, the MAC address of the network device deployed in the container, the source IP and the destination IP.

[0072] Optionally, before searching the routing table according to the destination address of the first data packet flow to obtain the IP address of the network device corresponding to the data packet flow, the method further includes:

[0073] Receive vmac address request;

[0074] Create a vmac device based on the CM configuration file carried by the vmac address request;

[0075] Writing the creation information of the vmac device into the vmac configuration file;

[0076] Create a pod based on the CNI configuration file and vmac configuration file;

[0077] Perform IP address conflict detection according to the creation information of the vmac device;

[0078] If there is no conflict in the IP address, the routing table and adjacency table are added to the pod's network space.

[0079] In the embodiment of the present invention, the creation of the original macvlan sub-interface (referred to as vmac device) is retained. The device does not need to be configured with an IP address. This device can be used to perform IP address conflict detection. When the CNI network plug-in is bound to the IP address assigned by IPAM, a second-layer IP conflict detection is performed. Considering the best practices of these two solutions, the embodiment of the present invention combines the existing solution and the service network access solution with a second-layer IP conflict detection mechanism to propose a method for global access to the service network. The overall architecture diagram is as follows: Figure 2 The K8S cluster provided by the embodiment of the present invention includes: a control module and an agent module;

[0080] The control module includes two controllers. One is the macvlan subinterface (vmac for short) network device controller, which is mainly responsible for providing an entry for creating a network device for each K8S node. The other is the CNI config controller, which is mainly responsible for the configuration management of the CNI plug-in of the entire K8S cluster. It utilizes the configmap resources in K8S, and the object is mounted to the agent module in the form of daemonset.

[0081] The proxy module has two functions. The first is to receive the request from the controller layer to create a vmac and create the corresponding network device on the node. The other is to dynamically update the configuration file read from the configmap and save it in the / etc / cni / net.d / *.conf file.

[0082] like Figure 2 The architecture shown can combine the macvlan sub-interface method with the veth pair solution to create a global management control center. By modifying the configuration file and creating vmacs with different modes, the two modes can be switched, providing a device that allows users to choose to use different modes based on network resources and network performance.

[0083] Two scheme switching processes:

[0084] Take the macvlan solution switching to the veth-pair solution as an example:

[0085] 1. The application configures the args.service_mod parameter in the CNI configmap to "veth-pair".

[0086] 2. The CNI configmap will be mounted to the agent in the form of daemonset. The agent has an application process that monitors the files inside the container. When this process detects that the file mounted with the CNI configmap inside the container is updated, it will copy the file to another file. This file and the / etc / cni / net.d / *.conf file on the host are mounted in the form of hostpah to dynamically update the CNI configuration file on each node.

[0087] 3. Send a request to create a vmac address through the Vmac controller, and the agent on the corresponding node calls the Linux kernel command to create a vmac device, and writes the creation information of the vmac device into the vmac configuration file.

[0088] 4. When K8S creates a pod, kubelet senses that the pod is scheduled to its own node and calls the CNI plug-in to create network resources for the pod.

[0089] 5. The CNI plug-in reads the CNI configuration file through standard input and creates a vmac configuration file to create a pod, obtains the name of the vmac device, and executes arping-c 2-I$vmac-Dq$pod_address on the host to detect IP conflicts. If there is a response packet, an error is reported, and the K8S request to create a pod is exited, waiting for an available IP address to bind.

[0090] 6. After the IP address is confirmed to be correct, add the routing table and adjacency table to the pod's network space.

[0091] Specifically, the method of creating a vmac device according to the CM configuration file carried by the vmac address request can be: if it is macvlan mode, a vmac device with IP is created; if it is veth pair mode, a vmac device without IP is created.

[0092] It should be noted that the embodiment of the present invention combines the macvlan sub-interface method on the basis of the veth pair method, and implements the layer 2 IP conflict detection of the veth pair method by creating a macvlan sub-interface on the host machine.

[0093] The technical solution of this embodiment obtains the next hop address by querying the routing table according to the destination address of the first data packet flow; if the next hop address is not a local address, querying the adjacency table to obtain the MAC address of the network device deployed in the host machine corresponding to the IP address of the network device; adding the MAC address of the network device deployed in the host machine and the MAC address of the network device deployed in the container to the first data packet flow to obtain the second data packet flow; determining the IP address of the backend container corresponding to the second data packet flow according to the source address and destination address of the second data packet flow; sending the second data packet flow to the backend container according to the IP address of the backend container, which solves the problem that the Netfilter framework of L3 packet filtering technology based on the kernel protocol stack cannot meet the service network access of the macvlan network, and can avoid the waste of underlying network IP resources.

[0094] Embodiment 2

[0095] Figure 3 This is a schematic diagram of the structure of a service network access device provided by an embodiment of the present invention. This embodiment is applicable to the case of service network access. The device can be implemented in software and / or hardware. The device can be integrated in any device that provides a service network access function, such as Figure 3 As shown, the service network access device specifically includes: a first query module 210 , a second query module 220 , an adding module 230 , a determining module 240 and a sending module 250 .

[0096] Wherein, the first query module is used to query the routing table according to the destination address of the first data packet flow to obtain the next hop address;

[0097] A second query module is used to query the adjacency table if the next hop address is not a local address, and obtain the MAC address of the network device deployed in the host machine corresponding to the IP address of the network device;

[0098] An adding module, used for adding the MAC address of the network device deployed in the host machine and the MAC address of the network device deployed in the container to the first data packet flow to obtain a second data packet flow;

[0099] A determination module, configured to determine an IP address of a backend container corresponding to the second data packet flow according to a source address and a destination address of the second data packet flow;

[0100] The sending module is used to send the second data packet flow to the backend container according to the IP address of the backend container.

[0101] Optionally, the determining module is specifically used to:

[0102] If the source address and the destination address of the second data packet flow match the KUBE-MARK_MASQ chain, mark the second data packet flow;

[0103] If the second data packet flow marked by the mark matches the INPUT chain, the IP address of the backend container corresponding to the second data packet flow is obtained.

[0104] Optionally, the determining module is specifically used to:

[0105] If the second data packet flow matches the POSTROUTING chain, the IP address of the network device that the second data packet flow passes through to the next hop is obtained.

[0106] The above-mentioned product can execute the method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0107] The technical solution of this embodiment obtains the next hop address by querying the routing table according to the destination address of the first data packet flow; if the next hop address is not a local address, querying the adjacency table to obtain the MAC address of the network device deployed in the host machine corresponding to the IP address of the network device; adding the MAC address of the network device deployed in the host machine and the MAC address of the network device deployed in the container to the first data packet flow to obtain the second data packet flow; determining the IP address of the backend container corresponding to the second data packet flow according to the source address and destination address of the second data packet flow; sending the second data packet flow to the backend container according to the IP address of the backend container, which solves the problem that the Netfilter framework of L3 packet filtering technology based on the kernel protocol stack cannot meet the service network access of the macvlan network, and can avoid the waste of underlying network IP resources.

[0108] Embodiment 3

[0109] Figure 4 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.

[0110] like Figure 4 As shown, the electronic device 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0111] A number of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0112] The processor 11 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as a service network access method.

[0113] In some embodiments, the service network access method may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the service network access method described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to execute the service network access method in any other appropriate manner (e.g., by means of firmware).

[0114] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0115] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0116] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, 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), an 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.

[0117] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0118] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0119] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.

[0120] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.

[0121] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A service network access method, characterized in that: include: According to the destination address of the first data packet flow, the routing table is searched to obtain the next hop address; If the next hop address is not a local address, query the adjacency table to obtain the MAC address of the network device deployed in the host machine corresponding to the IP address of the network device; Add the MAC address of the network device deployed in the host machine and the MAC address of the network device deployed in the container to the first data packet flow to obtain a second data packet flow; wherein the IP address of the second data packet flow is not changed, the source address is the container IP address, and the destination address is the cluster_IP address; Determine the IP address of the backend container corresponding to the second data packet flow according to the source address and the destination address of the second data packet flow; Sending the second data packet traffic to the backend container according to the IP address of the backend container; The step of determining the IP address of the backend container corresponding to the second data packet flow according to the source address and the destination address of the second data packet flow includes: If the source address and the destination address of the second data packet flow match the KUBE-MARK_MASQ chain, mark the second data packet flow; If the second data packet flow after the mark matches the INPUT chain, and the INPUT chain is matched by the network load balancing IPVS (IP virtual Server) in the Linux kernel, the IP address of the backend container corresponding to the destination address cluster_IP of the second data packet flow is obtained; If the second data packet flow matches the POSTROUTING chain, the IP address of the network device that the second data packet flow passes through to the next hop is obtained.

2. The method according to claim 1, characterized in that Before searching the routing table according to the destination address of the first data packet flow to obtain the IP address of the network device corresponding to the second data packet flow, the method further includes: Create a veth pair; Deploy the veth pair in the container and the host respectively.

3. The method according to claim 1, characterized in that: Before searching the routing table according to the destination address of the first data packet flow to obtain the IP address of the network device corresponding to the second data packet flow, the method further includes: Receive vmac address request; Create a vmac device based on the CM configuration file carried by the vmac address request; Writing the creation information of the vmac device into the vmac configuration file; Create a pod based on the CNI configuration file and vmac configuration file; Perform IP address conflict detection according to the creation information of the vmac device; If there is no IP address conflict, the routing table and adjacency table are added to the pod's network space.

4. A service network access device, characterized in that: include: A first query module, used to query the routing table according to the destination address of the first data packet flow to obtain a next hop address; A second query module is used to query the adjacency table if the next hop address is not a local address, and obtain the MAC address of the network device deployed in the host machine corresponding to the IP address of the network device; An adding module, used to add the MAC address of the network device deployed in the host machine and the MAC address of the network device deployed in the container to the first data packet flow, to obtain a second data packet flow; wherein the IP address of the second data packet flow is not changed, the source address is the container IP address, and the destination address is the cluster_IP address; A determination module, configured to determine an IP address of a backend container corresponding to the second data packet flow according to a source address and a destination address of the second data packet flow; A sending module, used to send the second data packet flow to the backend container according to the IP address of the backend container; The determination module is specifically used for: If the source address and the destination address of the second data packet flow match the KUBE-MARK_MASQ chain, mark the second data packet flow; If the second data packet flow after the mark matches the INPUT chain, and the INPUT chain is matched by the network load balancing IPVS (IP virtual Server) in the Linux kernel, the IP address of the backend container corresponding to the destination address cluster_IP of the second data packet flow is obtained; If the second data packet flow matches the POSTROUTING chain, the IP address of the network device that the second data packet flow passes through to the next hop is obtained.

5. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the service network access method according to any one of claims 1 to 3.

6. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the service network access method according to any one of claims 1 to 3 when executed.