Kubernetes-based container network implementation method
By creating distributed logical routers and switches in Kubernetes and dividing logical subnets, the problem of low network access efficiency in existing technologies is solved, enabling efficient internal and external access to Pods.
Patent Information
- Application Number
- CN202311348480.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-10-17
- Publication Date
- 2025-11-04
- Estimated Expiration
- 2043-10-17
AI Technical Summary
In existing Kubernetes container networking implementations, Pod communication involves both Layer 2 and Layer 3 networks, resulting in long access links, low network access performance, and increased network pressure when Pods communicate with external networks.
Create distributed logical routers and switches based on VPC, divide logical subnets, add Node nodes and Pods to the distributed logical switches, enable internal and external access of Pods, and use physical network cards for external access of Pods, simplifying network access paths.
By shortening the network access link, network access efficiency is improved, cluster network access pressure is reduced, and management process is simplified.
Smart Images

Figure CN119854130B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of Internet, and in particular to a container network implementation method based on Kubernetes, device and storage medium. BACKGROUND
[0002] The rise of container technology makes the deployment and management of application more flexible and efficient. However, the communication between containers is a challenge because containers can run on different hosts and their network addresses may change dynamically. In order to solve this problem, a container network solution is needed to provide communication and network isolation between containers and automatically adapt to the dynamic changes of containers. Kubernetes, as a container orchestration and management platform, provides abstraction and management functions for container networking, making communication between containers more simple and reliable.
[0003] In the existing container network implementation method of Kubernetes, the access and communication of Pods include: the communication between different Pods on the same node can be carried out through the layer 2 network, when the communication between Pods occurs on the same node, Kubernetes uses the network device on the node to communicate, without leaving the node; when the communication between Pods occurs on different nodes, Kubernetes uses layer 3 network to communicate, each Pod has a unique IP address, and cross-node communication can be carried out through the IP address, Kubernetes realizes cross-node communication between Pods through routing and network configuration; Pods can communicate with external networks through Service and Ingress; Service can load balance requests to multiple Pods on the back end and return responses to the requester through the network device on the node, and Ingress can route external HTTP and HTTPS requests to the Service inside the cluster.
[0004] In the prior art, the communication of Pods covers layer 2 network and layer 3 network, and the way that one host corresponds to one subnet leads to long access link, and the network access performance is reduced due to too many entries on the host; the communication between Pods and external networks increases the network access pressure, therefore, the prior art has the technical problem of low network access efficiency. SUMMARY
[0005] The present application provides a container network implementation method based on Kubernetes, device and storage medium to solve the technical problem of low network access efficiency in the prior art.
[0006] In a first aspect, the present application provides a container network implementation method based on Kubernetes, comprising:
[0007] create a corresponding distributed logical switch based on the distributed logical router;
[0008] obtain the Node and the Pod in the cluster, add the Node and the Pod to the distributed logical switch, and determine the logical subnet corresponding to the Node and the Pod;
[0009] implement internal access and external access of the Pod based on the distributed logical switch.
[0010] Optionally, obtaining the Node and the Pod in the cluster, adding the Node and the Pod to the distributed logical switch, and determining the logical subnet corresponding to the Node and the Pod, comprise:
[0011] obtain the number of Node in the preset cluster, and create the logical subnet corresponding to the Node and a preset subnet based on the distributed logical switch;
[0012] add the Node to the preset subnet, create the network card corresponding to the Node, and mount the network card to the logical port of the preset subnet;
[0013] create the Pod based on the Node, and mount the network card of the container in the Pod to the logical subnet corresponding to the Node to which the Pod belongs.
[0014] Optionally, before implementing the internal access and the external access of the Pod based on the distributed logical switch, further comprising:
[0015] start the Pod based on the Node, obtain the configuration information based on the configuration file of the Pod, obtain the logical subnet of the Node corresponding to the Pod based on the configuration information, and add the Pod to the logical subnet.
[0016] Optionally, implementing the internal access and the external access of the Pod based on the distributed logical switch, comprises:
[0017] when the Pod accesses other Pods, the access Pod and the accessed Pod belong to the same distributed logical switch, and the access Pod accesses the accessed Pod based on the distributed logical switch;
[0018] wherein the access Pod and the accessed Pod belong to the same Node or do not belong to the same Node.
[0019] Optionally, implementing the internal access and the external access of the Pod based on the distributed logical switch, further comprises:
[0020] When the Pod accesses the Node, the Pod accesses the Node based on a same distributed logical router to which the Node and the Pod belong.
[0021] Optionally, the internal access and the external access of the Pod are implemented based on the distributed logical switch, and the method further includes:
[0022] When the Pod accesses the Svc, the access traffic of the Pod is forwarded to the Node to which the Pod belongs based on a first preset rule, and a destination address accessed by the Pod is determined as a network address of the Pod based on a second preset rule.
[0023] The source address accessed by the Pod is determined as an address of a network card of the Node based on a third preset rule in the network card of the Node, and the access of the Pod and the Svc in the same distributed logical switch is implemented based on the address of the network card and the network address of the Pod.
[0024] Optionally, the internal access and the external access of the Pod are implemented based on the distributed logical switch, and the method further includes:
[0025] When the Pod accesses an external network address, the access traffic of the Pod is directed to the network card of the Node to which the Pod belongs based on the distributed logical router, and the external network address is accessed based on the physical network card of the Node.
[0026] In a second aspect, the present application provides a container network implementation device based on Kubernetes, including:
[0027] A first processing module is configured to create a distributed logical router based on a VPC, and create a corresponding distributed logical switch based on the distributed logical router.
[0028] A second processing module is configured to acquire Node and Pod in a cluster, add the Node and the Pod to the distributed logical switch, and determine a logical subnet corresponding to the Node and the Pod.
[0029] A third processing module is configured to implement internal access and external access of the Pod based on the distributed logical switch.
[0030] Optionally, the device is further configured to:
[0031] Acquire a preset number of Node in a cluster, and create a logical subnet corresponding to the Node and a preset subnet based on the distributed logical switch;
[0032] Add the Node to the preset subnet, create a network card corresponding to the Node, and mount the network card to a logical port of the preset subnet;
[0033] The Pod is created based on the Node, and a network card of a container in the Pod is mounted to a logical subnet corresponding to a Node to which the Pod belongs.
[0034] Optionally, the device is further configured to:
[0035] The Pod is started based on the Node, configuration information is obtained based on a configuration file of the Pod, a logical subnet of the Node corresponding to the Pod is obtained based on the configuration information, and the Pod is added to the logical subnet.
[0036] Optionally, the device is further configured to:
[0037] When the Pod accesses another Pod, the accessed Pod and the accessed Pod belong to a same distributed logical switch, and the accessed Pod accesses the accessed Pod based on the distributed logical switch.
[0038] The accessed Pod and the accessed Pod belong to a same Node or do not belong to a same Node.
[0039] Optionally, the device is further configured to:
[0040] When the Pod accesses the Node, the Pod accesses the Node based on a same distributed logical router to which the Node and the Pod belong.
[0041] Optionally, the device is further configured to:
[0042] When the Pod accesses the Svc, the access traffic of the Pod is forwarded to a Node to which the Pod belongs based on a first preset rule, and a destination address accessed by the Pod is determined as a network address of the Pod based on a second preset rule.
[0043] The source address accessed by the Pod is determined as an address of a network card based on a third preset rule in the network card of the Node, and the access of the Pod and the Svc is implemented in a same distributed logical switch based on the address of the network card and the network address of the Pod.
[0044] Optionally, the device is further configured to:
[0045] When the Pod accesses an external network address, the access traffic of the Pod is directed to a network card of a Node to which the Pod belongs based on the distributed logical router, and the external network address is accessed based on the physical network card of the Node.
[0046] In a third aspect, the application provides a container network implementation device based on Kubernetes, comprising:
[0047] a processor and a memory;
[0048] The memory stores computer-executable instructions;
[0049] The processor executes the computer-executable instructions stored in the memory, so that the Kubernetes-based container network implementation device executes the Kubernetes-based container network implementation method of any one of the first aspect.
[0050] In a fourth aspect, the present application provides a computer-readable storage medium, the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are executed by a processor to implement the Kubernetes-based container network implementation method of any one of the first aspect.
[0051] The present application provides a Kubernetes-based container network implementation method, device and storage medium. The method comprises: creating a distributed logical router based on a VPC, and creating a corresponding distributed logical switch based on the distributed logical router; obtaining Node nodes and Pods in a cluster, adding the Node nodes and the Pods to the distributed logical switch, and determining logical subnets corresponding to the Node nodes and the Pods; and implementing internal access and external access of the Pods based on the distributed logical switch. By dividing logical subnets and preset subnets based on the number of Node nodes in the cluster under the same distributed logical switch, and adding the Node nodes to the preset subnets, the network access link is shortened, and the internal access and the external access of the Pods are both within the same distributed logical switch, which improves the access efficiency while shortening the access link. The logical subnet division method enables the Pods in the Node to be added to the same network segment, and the external access of the Pods is implemented by using the physical network card of the Node node, which facilitates management and reduces the network access pressure of the cluster, thereby achieving the technical effect of improving the network access efficiency. BRIEF DESCRIPTION OF DRAWINGS
[0052] The accompanying drawings, which are incorporated herein and constitute part of the specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0053] Figure 1 The flow of the Kubernetes-based container network implementation method provided by the embodiments of the present application Figure One ;
[0054] Figure 2 The flow of the Kubernetes-based container network implementation method provided by the embodiments of the present application Figure Two ;
[0055] Figure 3An application architecture diagram of the Kubernetes-based container network implementation method provided by the embodiment of the present application is shown in FIG. 1.
[0056] Figure 4 A network access link of the Kubernetes-based container network provided by the embodiment of the present application is shown in FIG. 2. Figure One ;
[0057] Figure 5 A network access link of the Kubernetes-based container network provided by the embodiment of the present application is shown in FIG. 3. Figure Two ;
[0058] Figure 6 A network access link of the Kubernetes-based container network provided by the embodiment of the present application is shown in FIG. 4. Figure Three ;
[0059] Figure 7 A structure diagram of the Kubernetes-based container network implementation device provided by the embodiment of the present application is shown in FIG. 5.
[0060] Figure 8 A hardware structure diagram of the Kubernetes-based container network implementation device provided by the embodiment of the present application is shown in FIG. 6.
[0061] The specific embodiments of the present application have been shown in the above-described drawings, and will be described in more detail hereinafter. These drawings and written descriptions are not intended to limit the scope of the concept of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION
[0062] The exemplary embodiments will be described in detail herein with reference to the accompanying drawings. The same reference numbers in different drawings represent the same or similar elements unless otherwise represented. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of apparatuses and methods consistent with some aspects of the present application as detailed in the appended claims.
[0063] First, the terms involved in the present application are explained:
[0064] Kubernetes: an open-source container orchestration platform for automating deployment, scaling, and managing containerized applications; it was initially developed by Google and released in 2014; Kubernetes provides a reliable and scalable platform for managing the life cycle of containerized applications, including deployment, scaling, automation, and fault tolerance.
[0065] Open Virtual Network (OVN): An open-source virtual network solution based on Open vSwitch (OVS) and OpenFlow technology, used to build and manage virtual networks. OVN provides a distributed and scalable network architecture suitable for cloud computing and container environments.
[0066] Node: A worker node in a Kubernetes cluster, also known as an actual host, responsible for running and managing container applications. They communicate with Master nodes and execute instructions from Master nodes to ensure the normal operation of applications.
[0067] Pod: The smallest deployable unit in Kubernetes, a collection of related containers that share network and storage resources. Pods run on Node nodes and are the basic unit of Kubernetes scheduling and management.
[0068] Virtual Private Cloud (VPC): Also known as private network or private network. When subscribing to cloud hosts, VPC is configured to allow the subscribed cloud hosts to be divided into a private network and isolated from other users.
[0069] Distributed Logical Switch (DLS): A technology used in virtualized networks to provide logical layer-2 network switching functions. It is implemented in a Software-Defined Networking (SDN) environment by separating network switching functions from physical switches and implementing them in a virtualized environment using software.
[0070] Distributed Logical Routing: A layer network routing function used in virtualized networks. It is implemented in a Software-Defined Networking (SDN) environment by separating network routing functions from physical routers and implementing them in a virtualized environment using software.
[0071] Source Network Address Translation (snat): A network address translation technology used to modify the source IP address of data packets in the network. It is commonly used to solve the conversion problem between private network IP addresses and public network IP addresses.
[0072] Service (SVC): In the nodes of a cluster, SVC is a resource object in Kubernetes that defines the access method and network policy for a group of Pods.
[0073] Classless Inter-Domain Routing (CIDR): A method for allocating and managing IP addresses; in CIDR, IP addresses are represented as a block of addresses with a prefix length, such as 192.168.0.0 / 24; the prefix length represents the number of bits for the network part of the address, while the remaining bits are used for the host part of the address; traditional IP address classification divides IP addresses into A, B, and C classes, each with a fixed network part and host part; however, this classification method leads to waste of address space, as each network has a fixed number of host addresses, while the actual number of hosts used is generally much less than this number; the advantage of CIDR is that it allows more flexible allocation of IP addresses; by using variable-length prefixes, CIDR can allocate address blocks according to actual needs, thereby reducing the waste of address space; in addition, CIDR simplifies the management of routing tables, as it can combine multiple address blocks into a larger address block, thereby reducing the number of entries in the routing table.
[0074] IP Virtual Server (ipvs): A module in the Linux kernel that provides a high-performance load balancing solution; in Kubernetes, ipvs can be used as a load balancing solution to distribute traffic to multiple Pods. The kube-proxy component of Kubernetes can use the ipvs mode to implement load balancing and provide high-performance service proxy functions.
[0075] iptables: A firewall tool that works on Linux operating systems, which can be used to configure, manage and monitor the rules of network connections; it is based on the kernel's firewall system and can protect computers and networks from malicious attacks and unauthorized access by filtering, forwarding and modifying network packets.
[0076] kube-proxy: A core component in the Kubernetes cluster that is responsible for implementing the proxy and load balancing functions of Kubernetes services, kube-proxy runs on each Node node and communicates with the Kubernetes API server to obtain service and endpoint information.
[0077] Kubelet: refers to an important component in the Kubernetes cluster, which runs on each node and is responsible for managing and maintaining the containers on the node. The main responsibility of Kubelet is to communicate with the Kubernetes master control plane, receive orders, and ensure that the containers run correctly on the node.
[0078] In the existing container network implementation method of Kubernetes, the access and communication of Pods include: communication between different Pods on the same node can be carried out through a layer 2 network, when the communication between Pods occurs on the same node, Kubernetes uses the network device on the node to communicate, without leaving the node; when the communication between Pods occurs on different nodes, Kubernetes uses a layer 3 network to communicate, each Pod has a unique IP address, and cross-node communication can be carried out through the IP address, Kubernetes realizes cross-node communication between Pods through routing and network configuration; Pods can communicate with external networks through Service and Ingress; Service can balance the request load to multiple Pods on the back end and return the response to the requester through the network device on the node, and Ingress can route external HTTP and HTTPS requests to the Service inside the cluster. In the prior art, the communication of Pods covers layer 2 network and layer 3 network, and the mode of one host corresponding to one subnet leads to long access link, and due to too many entries on the host, the access performance of the network is reduced; the communication between Pods and external networks increases the access pressure of the network, therefore, there is a technical problem of low network access efficiency in the prior art.
[0079] The application provides a Kubernetes-based container network implementation method, device and storage medium. The method comprises the following steps: creating a distributed logical router based on a VPC, creating a corresponding distributed logical switch based on the distributed logical router; acquiring Node nodes and Pods in a cluster, adding the Node nodes and the Pods to the distributed logical switch, and determining logical subnets corresponding to the Node nodes and the Pods; and implementing internal access and external access of the Pods based on the distributed logical switch. By dividing logical subnets and preset subnets based on the number of Node nodes in the cluster under the same distributed logical switch, and adding the Node nodes to the preset subnets, the network access link is shortened, and the internal access of the Pods and the external access of the Pods belong to the same distributed logical switch, so that the access efficiency is improved while the access link is shortened; the logical subnet division manner enables the Pods in the Node nodes to be added to the same network segment, and the external access of the Pods is implemented by using the physical network card of the Node nodes, so that the network access pressure of the cluster is reduced while the management is facilitated, thereby solving the technical problem of low network access efficiency in the prior art.
[0080] The technical solutions of the application and how the technical solutions solve the above technical problems will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes can not be described again in some embodiments. The embodiments of the application will be described below with reference to the drawings.
[0081] Figure 1 The Kubernetes-based container network implementation method provided for the embodiments of the application Figure One . As shown in Figure 1 , the method comprises the following steps:
[0082] S101, creating a distributed logical router based on a VPC, and creating a corresponding distributed logical switch based on the distributed logical router;
[0083] In the first exemplary embodiment, a VPC is created based on a cluster, a distributed logical router is created based on the VPC, and a distributed logical switch is created based on the distributed logical router. The distributed logical switch and the distributed logical router in the embodiment have a one-to-one correspondence.
[0084] S102, acquiring Node nodes and Pods in a cluster, adding the Node nodes and the Pods to the distributed logical switch, and determining logical subnets corresponding to the Node nodes and the Pods;
[0085] In this embodiment, Nodes and Pods are added to the same distributed logical switch. Within the same distributed logical switch, Pods can directly access each other. All communication between Nodes is also forwarded through the distributed logical switch.
[0086] S103. Implement internal and external access for Pods based on distributed logical switches.
[0087] In the second example, the Pod accesses the outside world through a distributed logical switch, and through the physical network card of the Node host where the Pod resides.
[0088] This application provides a Kubernetes-based container network implementation method. The method includes: creating a distributed logical router based on a VPC, and creating a corresponding distributed logical switch based on the distributed logical router; obtaining Node nodes and Pods in the cluster, adding the Node nodes and Pods to the distributed logical switch, and determining the logical subnets corresponding to the Node nodes and Pods; and implementing internal and external access for Pods based on the distributed logical switch. By dividing the cluster into logical subnets and preset subnets based on the number of Node nodes under the same distributed logical switch, and adding Node nodes to the preset subnets, the network access link is shortened. Both internal and external access for Pods belong to the same distributed logical switch, improving access efficiency while shortening the access link. The logical subnetting method allows Pods within a Node to be added to the same network segment, and utilizes the Node's physical network interface card to enable external access for Pods. This facilitates management, reduces the network access pressure on the cluster, and solves the technical problem of low network access efficiency in existing technologies.
[0089] Figure 2 The flow of the Kubernetes-based container network implementation method provided in the embodiments of this application Figure Two . Figure 3 The application architecture diagram of the Kubernetes-based container network implementation method provided in the embodiments of this application is as follows: Figure 3 As shown, the cluster has N Node nodes, and is divided into N+1 logical subnets based on a distributed logical switch, including a preset subnet and the subnets of the N Node nodes. Each Node node creates a corresponding network card and attaches it to the logical port of the preset subnet. The container network card of the Pod in the Node node is attached to the subnet of the corresponding Node node. Figure 4 , Figure 5 and Figure 6 The network access links for Kubernetes-based container networks provided in the embodiments of this application are respectively.Figure One 、 Two and three, network access links respectively include: Pod access between Pods, which can be directly accessed through a distributed logical switch; Pod to Node access, which is accessed through a logical port of a preset subnet to achieve access under the same distributed logical routing; Pod to Svc access, which is achieved by converting the source address and the destination address, converting the source address into the address of the network card of the Node node, and converting the destination address into the address of the Pod, to realize Pod to Svc access in the same VPC network. As shown in Figure 2 the method comprises:
[0090] S201, creating a distributed logical router based on a VPC, and creating a corresponding distributed logical switch based on the distributed logical router;
[0091] S202, obtaining the number of Node nodes in a preset cluster, and creating a logical subnet corresponding to the Node nodes and a preset subnet based on the distributed logical switch; adding the Node nodes to the preset subnet, creating a network card corresponding to the Node nodes, and mounting the network card to a logical port of the preset subnet; creating a Pod based on the Node nodes, and mounting a network card of a container in the Pod to a logical subnet corresponding to a Node node to which the Pod belongs;
[0092] In this embodiment, the number of Node nodes in the preset cluster is N, where N is a positive integer, and N+1 subnets are divided based on the distributed logical switch, where N subnets are used as Node node subnets and one is a preset subnet; N Node nodes are added to the preset subnet, and a network card of the Node node is created and mounted to a logical port of the preset subnet.
[0093] In this embodiment, the logical subnet is divided by CIDR, and the preset subnet and the logical subnet of the Node node belong to the same distributed logical switch, and the difference lies in that the network segments of the two are different.
[0094] In this embodiment, when the Pod in the Node node is created, the network card of the container in the Pod is mounted to the logical subnet of the corresponding Node node to realize the connection of the container network and the Node node network; in the third exemplary embodiment, a virtual network card is created for the container in the bridge mode, and the virtual network card is connected to the host bridge, and the host bridge will be responsible for forwarding the network traffic of the container to the physical network card of the host, thereby realizing the connection of the container and the host network.
[0095] In this embodiment, to mount the network card of the container in the Pod in the cluster to the logical subnet of the node, the network plug-in of Kubernetes can be used to achieve this, and Kubernetes provides multiple network plug-ins (CNI, Container Network Interface), which can be Flannel, Calico, Weave, etc., which can assign IP addresses to the Pods in the cluster and connect the network card of the Pod to the logical subnet of the node.
[0096] S203, starting the Pod based on the Node node, obtaining configuration information based on the configuration file of the Pod, obtaining the logical subnet of the Node node corresponding to the Pod based on the configuration information, and adding the Pod to the logical subnet;
[0097] In the fourth example, when the Node node starts the Pod, the kubelet will issue a request to the CNI plug-in; the CNI plug-in will read the configuration file from the / etc / cni / net.d / path, and these configuration files contain the network configuration information of the current node; through these configuration files, the CNI plug-in can directly add the Pod to the logical subnet of the corresponding Node node, so that the Pod can communicate with the Pods on other nodes; in this way, the Pod can perform network communication within the cluster.
[0098] S204, when the Pod accesses other Pods, the accessed Pod and the accessed Pod belong to the same distributed logical switch, and the accessed Pod accesses the accessed Pod based on the distributed logical switch;
[0099] In this embodiment, the accessed Pod and the accessed Pod belong to the same Node node or do not belong to the same Node node; at the OVN level, the access between the Pods is all in the same distributed logical switch, that is, the access under the same layer 2.
[0100] In the fifth example, the access between the Pods is the access between the Pod with network address A and the Pod with network address B, both of which belong to the network segment of the distributed logical switch and can directly access the distributed logical switch.
[0101] S205, when the Pod accesses the Node node, the access of the Pod to the Node node is implemented based on the same distributed logical router to which the Node node and the Pod belong;
[0102] In this embodiment, on the OVN, the traffic passes through the distributed logical switch and reaches the distributed logical router, the traffic from the subnet corresponding to the CIDR network segment of the Node node is forwarded to the logical port mounted on the network card of the Node node by adding the source address route on the VPC, access to the Node node is realized, and the access link is under the same logical router of the OVN.
[0103] In S206, when the Pod accesses the SVC, the access traffic of the Pod is forwarded to the Node node to which the Pod belongs based on the first preset rule, the destination address accessed by the Pod is determined as the network address of the Pod based on the second preset rule, the source address accessed by the Pod is determined as the address of the network card based on the third preset rule in the network card of the Node node, and the access of the Pod and the SVC in the same distributed logical switch is realized based on the address of the network card and the network address of the Pod.
[0104] In this embodiment, the access traffic of the Pod is forwarded to the Node node on which the load Pod is located by configuring the routing rule of the VPC, the traffic reaches the Node node, the ipvs or iptables rule written by the Kubernetes to the Node node is used to parse the network address of the Pod in the backend load, the destination address is changed into the network address of the Pod, the source address is converted into the address of the network card by the snat rule of the network card on the Node, and the address of the network card and the network address of the Pod are in the same VPC network, thereby realizing the access of the Pod to the SVC address.
[0105] In S207, when the Pod accesses the external network address, the access traffic of the Pod is directed to the network card of the Node node to which the Pod belongs based on the distributed logical router, and the external network address is accessed based on the physical network card of the Node node.
[0106] In this embodiment, when the Pod accesses the external network address, the physical network card of the host machine can be used for access, and the network access pressure in the cluster is balanced.
[0107] The application provides a Kubernetes-based container network implementation method. The method comprises the following steps: creating a distributed logical router based on a VPC, creating a corresponding distributed logical switch based on the distributed logical router, wherein one distributed logical router corresponds to one distributed logical switch; acquiring Node nodes and Pods in a cluster, adding the Node nodes and the Pods to the distributed logical switch, and determining logical subnets corresponding to the Node nodes and the Pods; implementing internal access and external access of the Pods based on the distributed logical switch; determining a same VPC and a corresponding distributed logical router and a distributed logical switch for all nodes in a cluster, adding all nodes in the cluster to the same distributed logical switch, and using the same distributed logical switch for communication of the Node nodes and communication of the Pods, that is, access control of the network is in the same Layer 2 network, and external communication of the Pods is implemented by using physical network cards of host computers, so as to reduce network access levels, support a distributed NAT gateway, shorten access links, and reduce network access pressure in the cluster, thereby solving the technical problem of low network access efficiency.
[0108] Figure 7 A structure diagram of a Kubernetes-based container network implementation device provided by an embodiment of the application is provided. The device of the embodiment can be in the form of software and / or hardware. As shown in the figure, the Kubernetes-based container network implementation device 700 provided by the embodiment of the application comprises a first processing module 701, a second processing module 702, and a third processing module 703. Figure 7
[0109] The first processing module 701 is configured to create a distributed logical router based on a VPC, and create a corresponding distributed logical switch based on the distributed logical router.
[0110] The second processing module 702 is configured to acquire Node nodes and Pods in a cluster, add the Node nodes and the Pods to the distributed logical switch, and determine logical subnets corresponding to the Node nodes and the Pods.
[0111] The third processing module 703 is configured to implement internal access and external access of the Pods based on the distributed logical switch.
[0112] In a possible implementation manner, the device is further configured to:
[0113] acquire a preset number of Node nodes in a cluster, and create a logical subnet corresponding to the Node nodes and a preset subnet based on the distributed logical switch.
[0114] Add the Node to the preset subnet, create the network interface card (NIC) corresponding to the Node, and attach the NIC to the logical port of the preset subnet;
[0115] Create a Pod based on a Node node, and attach the network interface card of the container inside the Pod to the logical subnet corresponding to the Node node to which the Pod belongs.
[0116] In one possible implementation, the device is also used for:
[0117] The Pod is started based on the Node node, the configuration information is obtained from the Pod's configuration file, the logical subnet of the Node node corresponding to the Pod is obtained based on the configuration information, and the Pod is added to the logical subnet.
[0118] In one possible implementation, the device is also used for:
[0119] When a Pod accesses other Pods, the accessing Pod and the accessed Pod belong to the same distributed logical switch, and the accessing Pod accesses the accessed Pod based on the distributed logical switch.
[0120] The pod that is accessing and the pod that is being accessed may belong to the same node or may not belong to the same node.
[0121] In one possible implementation, the device is also used for:
[0122] When a Pod accesses a Node, the Pod accesses the Node based on the same distributed logical router to which both the Node and the Pod belong.
[0123] In one possible implementation, the device is also used for:
[0124] When a Pod accesses an SVC, the Pod's access traffic is forwarded to the Node to which the Pod belongs based on the first preset rule, and the destination address accessed by the Pod is determined to be the Pod's network address based on the second preset rule.
[0125] The third preset rule in the Node's network interface card (NIC) determines the source address accessed by the Pod as the NIC address. Based on the NIC address and the Pod's network address, Pod and SVC access can be achieved within the same distributed logical switch.
[0126] In one possible implementation, the device is also used for:
[0127] When a Pod accesses an external network address, the Pod's access traffic is directed to the network interface card (NIC) of the Node to which the Pod belongs, based on a distributed logical router, and the external network address is accessed based on the Node's physical NIC.
[0128] The application provides a Kubernetes-based container network implementation device. The device comprises: a first processing module configured to create a distributed logical router based on a VPC, and create a corresponding distributed logical switch based on the distributed logical router, wherein one distributed logical router corresponds to one distributed logical switch; a second processing module configured to obtain Node and Pod in a cluster, add the Node and the Pod to the distributed logical switch, and determine a logical subnet corresponding to the Node and the Pod; and a third processing module configured to implement internal access and external access of the Pod based on the distributed logical switch. By determining a same VPC for all nodes in a cluster, determining a corresponding distributed logical router and a distributed logical switch, and adding all nodes in the cluster to the same distributed logical switch, the communication of the Node and the communication of the Pod use the same distributed logical switch, that is, the access control of the network is in the same Layer 2 network, and the external communication of the Pod is implemented by using the physical network card of the host, thereby reducing the network access level, supporting the distributed NAT gateway, shortening the access link, reducing the network access pressure in the cluster, and solving the technical problem of low network access efficiency.
[0129] Figure 8 A hardware structure diagram of the Kubernetes-based container network implementation device provided by the embodiments of the application is provided. As shown in the figure, the Kubernetes-based container network implementation device 800 comprises: Figure 8
[0130] a processor 801 and a memory 802;
[0131] The memory stores computer execution instructions;
[0132] The processor executes the computer execution instructions stored in the memory 802, so that the Kubernetes-based container network implementation device executes the Kubernetes-based container network implementation method as described above.
[0133] It should be appreciated that the processor 801 described above can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), or the like. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in combination with the application can be directly embodied as hardware processor execution, or executed by a combination of hardware and software modules in the processor. The memory 802 can include a high-speed random access memory (RAM), and can also include a non-volatile memory (NVM), such as at least one disk memory, and can also be a U disk, a mobile hard disk, a read-only memory, a magnetic disk or an optical disk, etc.
[0134] The embodiments of the application also provide a computer readable storage medium, the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the container network implementation method based on Kubernetes.
[0135] It should be noted that for the foregoing method embodiments, in order to simply describe, they are all expressed as a series of action combinations, but those skilled in the art should know that the application is not limited by the action order described, because according to the application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the application.
[0136] Further, it should be noted that although each step in the flowchart is displayed in sequence according to the arrow, these steps are not necessarily executed in sequence according to the arrow. Unless otherwise stated in this article, the execution of these steps has no strict order limit, and these steps can be executed in other order. Moreover, at least part of the steps in the flowchart can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily sequential, but can be executed with at least part of other steps or other steps, sub-steps or stages of the stage, or alternately.
[0137] It should be understood that the above-described apparatus embodiments are merely illustrative, and the apparatus of the present application can also be implemented in other manners. For example, the division of units / modules in the above-described embodiments is merely a logical function division, and the actual implementation can be in another manner. For example, a plurality of units / modules or components can be combined, or can be integrated into another system, or some features can be omitted or not executed.
[0138] In addition, unless specifically stated otherwise, each functional unit / module in each embodiment of the present application can be integrated in one unit / module, or can be physically present separately, or two or more units / modules can be integrated together. The integrated unit / module can be implemented in the form of hardware or in the form of a software program module.
[0139] If the integrated unit / module is implemented in the form of hardware, the hardware can be a digital circuit, an analog circuit, etc. The physical implementation of the hardware structure includes but is not limited to transistors, memristors, etc. Unless specifically stated otherwise, the processor can be any suitable hardware processor, such as a CPU, a GPU, an FPGA, a DSP, an ASIC, etc. Unless specifically stated otherwise, the storage unit can be any suitable magnetic storage medium or magneto-optical storage medium, such as a resistive random access memory (RRAM), a dynamic random access memory (DRAM), a static random access memory (SRAM), an enhanced dynamic random access memory (EDRAM), a high-bandwidth memory (HBM), a hybrid memory cube (HMC), etc.
[0140] If the integrated units / modules are implemented in the form of software program modules and sold or used as independent products, they can be stored in a computer readable memory. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a memory and includes a number of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the embodiments of the method of the present application. The aforementioned memory includes: a U disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.
[0141] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments. The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described, however, as long as the combinations of the technical features do not exist contradictory, they should be considered as the scope of the present application.
[0142] Other embodiments of the application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. The application is intended to cover any variations, uses or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice in the art to which the application pertains or can relate. The specification and examples are to be regarded as exemplary only, and the true scope and spirit of the application are indicated by the following claims.
[0143] It should be understood that the application is not limited to the precise construction that has been described above and shown in the accompanying drawings, and that various modifications and changes can be made by those skilled in the art without departing from the scope of the application. The scope of the application is limited only by the appended claims.
Claims
1. A method for implementing container networking based on Kubernetes, characterized in that, include: A distributed logical router is created based on the VPC, and a corresponding distributed logical switch is created based on the distributed logical router. Obtain the Node nodes and Pods in the cluster, add the Node nodes and Pods to the distributed logical switch, and determine the logical subnets corresponding to the Node nodes and Pods; The distributed logical switch enables internal and external access to the Pod.
2. The method according to claim 1, characterized in that, The steps of obtaining the Node nodes and Pods in the cluster, adding the Node nodes and Pods to the distributed logical switch, and determining the logical subnets corresponding to the Node nodes and Pods include: Obtain the number of Node nodes in the preset cluster, and create the logical subnet corresponding to the Node node and a preset subnet based on the distributed logical switch; Add the Node to the preset subnet, create a network interface card (NIC) corresponding to the Node, and attach the NIC to the logical port of the preset subnet; A Pod is created based on the Node, and the network interface card of the container in the Pod is attached to the logical subnet corresponding to the Node to which the Pod belongs.
3. The method according to claim 2, characterized in that, Before implementing internal and external access to Pods based on the distributed logical switch, the following is also included: The Pod is started based on the Node, configuration information is obtained based on the Pod's configuration file, the logical subnet of the Node corresponding to the Pod is obtained based on the configuration information, and the Pod is added to the logical subnet.
4. The method according to claim 3, characterized in that, The implementation of internal and external access for Pods based on the distributed logical switch includes: When the Pod accesses other Pods, the accessing Pod and the accessed Pod belong to the same distributed logical switch, and the accessing Pod accesses the accessed Pod based on the distributed logical switch. The accessing Pod and the accessed Pod may belong to the same Node or not.
5. The method according to claim 4, characterized in that, The implementation of internal and external access for Pods based on the distributed logical switch also includes: When the Pod accesses the Node, the access from the Pod to the Node is achieved based on the same distributed logical router to which the Node and the Pod belong.
6. The method according to claim 5, characterized in that, The implementation of internal and external access for Pods based on the distributed logical switch also includes: When the Pod accesses the SVC, the access traffic of the Pod is forwarded to the Node to which the Pod belongs based on the first preset rule, and the destination address accessed by the Pod is determined as the network address of the Pod based on the second preset rule; Based on the third preset rule in the network interface card of the Node, the source address accessed by the Pod is determined to be the address of the network interface card. Based on the address of the network interface card and the network address of the Pod, the Pod and the SVC can access each other within the same distributed logical switch.
7. The method according to claim 6, characterized in that, The implementation of internal and external access for Pods based on the distributed logical switch also includes: When the Pod accesses an external network address, the access traffic of the Pod is directed to the network interface card (NIC) of the Node to which the Pod belongs, based on the distributed logical router, and the external network address is accessed based on the physical NIC of the Node.
8. A container network implementation device based on Kubernetes, characterized in that, include: The first processing module is used to create a distributed logical router based on the VPC and to create a corresponding distributed logical switch based on the distributed logical router. The second processing module is used to obtain the Node nodes and Pods in the cluster, add the Node nodes and Pods to the distributed logical switch, and determine the logical subnets corresponding to the Node nodes and Pods. The third processing module is used to enable internal and external access to the Pod based on the distributed logical switch.
9. A container network implementation device based on Kubernetes, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the Kubernetes-based container network implementation method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the Kubernetes-based container network implementation method as described in any one of claims 1 to 7.
Citation Information
Patent Citations
Method and system of kubernetes container cloud platform VLAN
CN111796905A
Network access method and device based on Kubernetes, equipment and medium
CN113572838A