Request transmission method and device, related node, medium and program product
By introducing SDN controllers and virtual switches into the Kubernetes system, the containers are given virtual private cloud attributes, which solves the problem of the need for resource connectivity between containers and virtual private clouds in public cloud container scenarios, and efficient communication between containers and Overlay networks is achieved.
Patent Information
- Application Number
- CN202411860404.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-17
- Publication Date
- 2025-04-22
AI Technical Summary
In public cloud container scenarios, the Kubernetes system cannot assign virtual private cloud attributes to the container, resulting in the inability to meet the communication needs between the container and the Overlay network where the resources in the tenant's virtual private cloud are located.
By introducing a software-defined network (SDN) controller into the container network, the K8s resources are mapped into the corresponding resources of the Overlay network, multi-tenant isolation at the hardware level is achieved, the container is given virtual private cloud attributes, and the barrier-free and efficient data transmission between the container and the virtual private cloud is achieved through virtual switches and target network cards.
It realizes stable, barrier-free and efficient communication between the container in the Kubernetes system and the Overlay network where the virtual private cloud resources are located, meeting the needs of the interconnection between the container and the virtual private cloud resources.
Smart Images
Figure CN119865472A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of data transmission, and in particular to a request transmission method, device, related nodes, medium and program product. Background Art
[0002] In the Kubernetes system, container networks can achieve network transmission between different containers in the same or different node devices through their logically isolated network environment. In actual applications, the Kubernetes system configures container networks through open source container network plug-ins including Calico and MacVlan, but the above method cannot give virtual private cloud attributes to containers in public cloud container scenarios, and thus cannot meet the connectivity requirements between containers and the Overlay network where resources in the tenant's virtual private cloud are located. Summary of the invention
[0003] Based on the above technical problems, the embodiments of the present application provide a request transmission method, device, related nodes, medium and program product.
[0004] The technical solution provided by the embodiment of the present application is as follows:
[0005] The present application embodiment first provides a request transmission method, the method comprising:
[0006] If a first container in a first node of the Kubernetes system detects a data transmission request, determine a transmission route corresponding to the data transmission request;
[0007] If the transmission route is associated with a virtual private cloud, the data transmission request is sent to the virtual switch through the first target network card associated with the first container; wherein the virtual switch is set at the first node; and the first target network card is used to realize data transmission between containers and / or nodes in the virtual private cloud;
[0008] The data transmission request is routed to the second node associated with the second container based on the flow table data through the virtual switch, so that the second node transmits the data transmission request to the second container via the second target network card; wherein the second container includes the target container of the data transmission request; the second node is associated with the virtual private cloud; the flow table data is at least associated with the virtual private cloud; the second target network card is associated with the second node and is used to realize data transmission between containers and / or nodes in the virtual private cloud.
[0009] The embodiment of the present application further provides a data transmission device, wherein the request transmission device comprises:
[0010] A determination module, configured to determine a transmission route corresponding to the data transmission request if a first container in a first node of the Kubernetes system detects a data transmission request;
[0011] A transmission module, configured to send the data transmission request to a virtual switch through a first target network card associated with the first container if the transmission route is associated with a virtual private cloud; wherein the virtual switch is provided at the first node; and the first target network card is configured to implement data transmission between containers and / or nodes in the virtual private cloud;
[0012] The transmission module is also used to route the data transmission request to the second node associated with the second container based on the flow table data through the virtual switch, so that the second node transmits the data transmission request to the second container via the second target network card; wherein the second container includes the target container of the data transmission request; the second node is associated with the virtual private cloud; the flow table data is at least associated with the virtual private cloud; the second target network card is associated with the second node, and is used to realize data transmission between containers and / or nodes in the virtual private cloud.
[0013] An embodiment of the present application also provides a Kubernetes node, which includes a processor and a memory; wherein a computer program is stored in the memory; when the computer program is executed by the processor, it can implement any of the request transmission methods described above.
[0014] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored; when the computer program is executed by a processor of an electronic device, it can implement any of the request transmission methods described above.
[0015] An embodiment of the present application also provides a computer program product, which includes a computer program; when the computer program is executed by a processor of an electronic device, it can implement any of the request transmission methods described above.
[0016] The request transmission method provided in the embodiment of the present application, if the first container in the first node of the Kubernetes system detects a data transmission request, then determines the transmission route corresponding to the data transmission request, and if the transmission route is associated with a virtual private cloud, then sends the data transmission request to the virtual switch through the first target network card associated with the first container, and the first target network card is used to realize data transmission between containers and / or nodes in the virtual private cloud. In this way, through the first target network card, the first container can be able to transmit data with containers and / or nodes in the virtual private cloud without obstacles. Efficient; and, in the case that the first container is any container of the Kubernetes system, through the above operation, the virtual private cloud attributes can be set for any container in the Kubernetes system, so that the container can meet the connection requirements between the Overlay network where the virtual private cloud resources are located; at the same time, through the virtual switch set at the first node, the data transmission request is routed to the second node associated with the second container based on the flow table data, so that the first The two nodes transmit data requests to the second container via the second target network card, and the second container is associated with the virtual private cloud and is the target container of the data transmission request. The flow table data is also at least associated with the virtual private cloud, and the second target network card is associated with the second node, which is used to realize data transmission between containers and / or nodes in the virtual private cloud. In this way, through the above operations, the second container in the Kubernetes system can also stably receive data transmission requests; on this basis, when the first container and the second container are both any containers in the Kubernetes system, through the above steps, any container in the Kubernetes system can realize two-way, stable and efficient transmission of data in the virtual private cloud through the target network card set by it. In this way, through the target network cards set respectively in each container, each container can communicate with the Overlay network in the virtual private cloud without obstacles and efficiently, thereby fully meeting the connectivity requirements between the container and the Overlay network in the virtual private cloud. BRIEF DESCRIPTION OF THE DRAWINGS
[0017] Figure 1 A flowchart of a request transmission method provided in an embodiment of the present application;
[0018] Figure 2 A schematic diagram of a routing of a data transmission request provided in an embodiment of the present application;
[0019] Figure 3 A schematic diagram of the process of creating a Pod provided in an embodiment of the present application;
[0020] Figure 4 A schematic diagram of the structure of the orchestration container network provided in an embodiment of the present application;
[0021] Figure 5A schematic diagram of a process for configuring a network for a container provided in an embodiment of the present application;
[0022] Figure 6 A schematic diagram of a process flow of a request transmission device provided in an embodiment of the present application;
[0023] Figure 7 A schematic diagram of the structure of the K8s node provided in an embodiment of the present application. DETAILED DESCRIPTION
[0024] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.
[0025] It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0026] Kubernetes, abbreviated as K8s, is a distributed architecture based on container technology. It provides a series of functions such as deployment and operation, resource scheduling, service discovery, and dynamic scaling for containerized applications, improving the convenience and high availability of large-scale container cluster management. In actual applications, Kubernetes follows the rule of single Pod and single network card. However, in the public cloud container scenario, in order to meet the network connectivity between the container and the Overlay where the resources in the tenant (Virtual Private Cloud, VPC) are located, to ensure the traffic interconnection between the container and the Underlay of the node where it is located, and to enable the K8s node Service load balancing capability provided by Kube-proxy to continue to serve cloud native containers.
[0027] In the Kubernetes system, container networks can achieve network transmission between different containers in the same or different node devices through their logically isolated network environment. In actual applications, the Kubernetes system configures container networks through open source container network plug-ins including Calico and MacVlan, but the above method cannot give VPC attributes to containers in public cloud container scenarios, and thus cannot meet the connectivity requirements between containers and the Overlay network where resources in the tenant's VPC are located.
[0028] In order to solve the above technical problems, the relevant technology provides the introduction of software defined network (SDN) controller in the container network, and maps K8s resources to the corresponding resources of the Overlay network through the SDN controller to achieve multi-tenant isolation at the hardware level, so as to give VPC attributes to the container. However, this method makes the creation of the K8s cluster and the Overlay network too coupled. When creating non-Overlay network type public services in the K8s cluster, including Webhook verification service and CertManager service, they will still be abstracted into Overlay network resources, resulting in tenant isolation of public service containers on hardware, which cannot meet the network configurability in the use of the K8s cluster.
[0029] Based on the above technical problems, the embodiments of the present application provide a request transmission method, device, related nodes, medium and program product.
[0030] Figure 1 A flowchart of a request transmission method provided in an embodiment of the present application is shown in FIG. Figure 1 As shown, the process may include the following steps:
[0031] Step 101: If a first container in a first node of a Kubernetes system detects a data transmission request, a transmission route corresponding to the data transmission request is determined.
[0032] Accordingly, if the first container does not detect the data transmission request, the transmission route may not be determined.
[0033] In one implementation, a plurality of containers may be arranged in the first node, and the first container may be any container among the plurality of containers arranged in the first node.
[0034] In one implementation, the data transmission request may carry transmission data; wherein the transmission data may include at least one of text, image, and video.
[0035] In one implementation, the transmission route may include a target identifier of a target container or a target node corresponding to the data transmission request; illustratively, the target identifier may include a network address and / or name of the target container or the target node.
[0036] Step 102: If the transmission route is associated with the VPC, the data transmission request is sent to the virtual switch (Open vSwitch, OVS) through the first target network card associated with the first container.
[0037] Among them, OVS is set on the first node, and the first target network card is used to realize data transmission between containers and / or nodes in the VPC.
[0038] Accordingly, if the transmission route is not associated with the VPC, the data transmission request may not be routed to the OVS through the first target network card.
[0039] Exemplarily, if the transmission route is not associated with the VPC but with the public cloud, the data transmission request can be sent to OVS through the net0 network card in the first container; wherein the net0 network card can be configured through the cilium-cni component configured in the first node, and through the net0 network card, the first container can communicate with the Underlay network in which it is located.
[0040] Among them, OVS is a high-quality and multi-layer virtual switching software, which aims to support large-scale network automation through programming extensions, while also supporting standard management interfaces and protocols; while VPC is a customized logically isolated network space on the public cloud, where tenants can customize network segmentation, Internet Protocol (IP) addresses and routing policies, and implement multi-layer security protection through security groups and network access control lists (ACLs).
[0041] The cilium-cni component is an open source component that is used to configure or release the net0 network card and routing of any container. In specific implementation, it is called by the multus-cni component to start the configuration operation of the container's net0 network card and routing; the multus-cni component is also an open source component. As a network component proxy, it can be used to call different CNI components to implement different network configuration methods.
[0042] In one implementation, associating the transmission route with the VPC may include that a target container corresponding to the data transmission request is located in the VPC.
[0043] In one implementation, the first target network card may include a network card in the first container other than the net0 network card, which is separately set and specifically used to implement data transmission between the first container and containers and / or nodes in the VPC; illustratively, the first target network card may be recorded as net1.
[0044] In one implementation, the first target network card may call the target component through the multus-cni component to trigger the creation and configuration of the target component; wherein the target component may be specifically set and added to the first node for creating and configuring the first target network card.
[0045] In one embodiment, for any container, a first target network card can be set and configured for it through a target plug-in to achieve data transmission between it and containers and / or nodes in the VPC.
[0046] Step 103: Routing the data transmission request to the second node associated with the second container through OVS based on the flow table data, so that the second node transmits the data transmission request to the second container via the second target network card.
[0047] Among them, the second container includes a target container for the data transmission request; the second container is associated with the VPC; the second target network card is associated with the second node and is used to realize data transmission between containers and / or nodes in the VPC; the flow table data is at least associated with the VPC.
[0048] In one implementation, the flow table data may be pre-set in the OVS so that the OVS can route and transmit the data transmission request received by it based on the flow table data.
[0049] In one implementation, the flow table data may include an openflow flow table entry.
[0050] In one implementation, the function and configuration of the second target network card may be the same as the function and configuration of the first target network card.
[0051] In one implementation, the first node and the second node may be the same or different, and therefore, the transmission type of the data transmission request may include transmission between the same node and transmission between different nodes.
[0052] In one implementation, the first node and the second node may be a first host device and a second host device corresponding to the first container and the second container, respectively.
[0053] In one embodiment, the data transfer request may be routed to the second container in the following manner:
[0054] If it is determined according to the flow table data that the first node and the second node are the same node, the data transmission request can be transmitted to OVS through the interface of net1 associated with the first target network card, so that OVS can transmit the data transmission request to the interface of net2 associated with the second container based on the flow table data, so as to transmit the data transmission request to the second container through the second target network card associated with the interface.
[0055] If it is determined according to the flow table data that the first node and the second node are not the same node, the data transmission request can be sent to the vxlan port for vxlan encapsulation, and then the encapsulated data transmission request is sent to the second node through the vxlan tunnel. After the second node decapsulates the encapsulated data transmission request by vxlan, the OVS in the second node sends the data transmission request to the net3 port corresponding to the second container based on the flow table data it saves, and then sends the data transmission request to the second container through the net3 port, wherein the net3 port can be associated with the second target network card of the second container.
[0056] Figure 2 A schematic diagram of a routing of a data transmission request provided in an embodiment of the present application, such as Figure 2 As shown, in Kubernetes system 2, the first node may include two containers, pod1-vpc1 and pod2-vpc1, and the second node may include pod3-vpc1 and pod4-vpc2, wherein pod1-vpc1 and pod2-vpc1 as well as pod3-vpc1 are associated with vpc1, and pod4-vpc2 may be associated with vpc2.
[0057] Exemplarily, when the first container is pod1-vpc1 and the second container is pod2-vpc1, the data transmission request can be transmitted to the OVS of the first node through the net1 network card with an address of 10.12.2.193 via veth1, so that it can transmit the data transmission request to the second target network card associated with pod2-vpc1 via veth2 based on the pre-configured flow table data, and send the data transmission request to net1 with an address of 10.12.2.23, and then transmit it to pod2-vpc1.
[0058] Exemplarily, when the first container is pod1-vpc1 and the second container is pod3-vpc1, the data transmission request can be transmitted to the OVS of the first node through the net1 network card with an address of 10.12.2.193 via veth1, so that it can send the data transmission request to the vxlan port for vxlan encapsulation based on the pre-configured flow table data, and then transmit the data transmission request to veth3 associated with pod3-vpc1 through the vxlan tunnel, and send the data transmission request to net1 with an address of 10.12.2.194, and then transmit it to pod3-vpc1.
[0059] For example, in Kubernetes system 2, a data transmission request that is not associated with a VPC can be transmitted through eth0 of any container, which will not be described in detail here.
[0060] From the above, it can be seen that the request transmission method provided by the embodiment of the present application, if the first container in the first node of the Kubernetes system detects a data transmission request, then determines the transmission route corresponding to the data transmission request, and if the transmission route is associated with the VPC, then sends the data transmission request to OVS through the first target network card associated with the first container, and the first target network card is used to realize data transmission between containers and / or nodes in the VPC. In this way, through the first target network card, the first container can transmit data with containers and / or nodes in the VPC without obstacles. Efficient; and, in the case where the first container is any container of the Kubernetes system, through the above operation, VPC attributes can be set for any container in the Kubernetes system, so that the container can meet the connection requirements between the Overlay network where the VPC resources are located; at the same time, the OVS set at the first node routes the data transmission request to the second node associated with the second container based on the flow table data, so as to meet the connection requirements between the container and the Overlay network where the VPC resources are located. The second node transmits a data request to the second container via the second target network card, and the second container is associated with the VPC and is the target container for the data transmission request. The flow table data is also at least associated with the VPC, and the second target network card is associated with the second node, which is used to realize data transmission between containers and / or nodes in the VPC. In this way, through the above operation, the second container in the Kubernetes system can also stably receive data transmission requests; on this basis, when the first container and the second container are both any containers in the Kubernetes system, through the above steps, any container in the Kubernetes system can realize two-way, stable and efficient transmission of data in the VPC through the target network card set by it. In this way, through the target network cards set respectively in each container, each container can communicate with the Overlay network in the VPC without obstacles and efficiently, thereby fully meeting the connectivity requirements between the container and the Overlay network in the VPC.
[0061] Based on the foregoing embodiment, in the request transmission method provided in the embodiment of the present application, sending the data transmission request to OVS through the first target network card associated with the first container can be implemented by the following steps:
[0062] Step A1: Obtain a first interface corresponding to a first target network card.
[0063] The first interface includes an interface of a veth-pair corresponding to a first target network card in a first namespace of a first container.
[0064] In one implementation, the first namespace may be a network namespace (NetworkNamespace) of the first container.
[0065] In one implementation, the first interface may be a data transmission interface of the first target network card in the first container.
[0066] In one implementation, the first interface may be pre-set when the first target network card is created.
[0067] Step A2: sending a data transmission request to the second interface through the first interface.
[0068] The second interface includes an interface in which the veth-pair is located in the second namespace of the first node; and the second interface is associated with OVS.
[0069] In one implementation, the second namespace may include a network namespace of the first node.
[0070] In one implementation, the first interface and the second interface may be two interfaces of a veth-pair associated with the first target network card.
[0071] In one implementation, after the veth-pair is created, the first interface may be associated with the first container, and the second interface may be associated with OVS, so that when the first container sends a data transmission request to the first interface, OVS can stably receive the data transmission request through the second interface.
[0072] As can be seen from the above, in the request transmission method provided in the embodiment of the present application, after obtaining the first interface corresponding to the first target network card, a data transmission request is sent to the second interface through the first interface, and the first interface includes the interface of the veth-pair corresponding to the first target network card in the first namespace of the first container, and the second interface includes the interface of the veth-pair located in the second namespace of the first node, and the second interface is associated with OVS. In this way, through the first interface and the second interface, not only the mutual isolation between the first namespace of the first container and the second namespace of the first node is achieved, but also, through the first interface and the second interface, the first container can stably transmit any data transmission request to OVS through the first interface, thereby providing interface support for the stable transmission of data transmission requests.
[0073] Based on the foregoing embodiment, in the request transmission method provided in the embodiment of the present application, before determining the transmission route corresponding to the data transmission request, the following operations may also be performed:
[0074] If the Access-Agent component detects that the SDN controller performs an operation to apply for SDN resources, the Access-Agent component configures flow table data for OVS.
[0075] Accordingly, if the Access-Agent component does not detect that the SDN controller performs an operation of applying for SDN resources, flow table data may not be configured for the OVS.
[0076] In one implementation, the SDN resources may include network resources such as the networkId, subnetId, and security group of the first node or the first container.
[0077] In one implementation, when a request to create a Pod is received, the SDN controller may apply for corresponding SDN resources during the process of creating the Pod. At this time, the Access-Agent component may detect the operation of the SDN controller to apply for SDN resources. The Access-Agent component may also obtain VPC information associated with the Pod, or obtain configuration information associated with the VPC, and then determine and configure flow table data for OVS based on the above VPC information or configuration information. Pod is a virtual management unit of K8s, which may include one or more containers, and the containers in the Pod share storage space and network resources.
[0078] In one implementation, the flow table data may be specifically used to implement forwarding and routing operations of data transmission requests or data packets within a VPC.
[0079] As can be seen from the above, in the request transmission method provided by the embodiment of the present application, if the Access-Agent component detects that the SDN controller performs an operation to apply for SDN resources, the Access-Agent component configures flow table data for OVS. In this way, in the above process, with the advantages of the Access-Agent component in dynamic service discovery, high availability and security, it is possible to configure flow table data for OVS in real time, stably and efficiently.
[0080] Based on the foregoing embodiment, the request transmission method provided in the embodiment of the present application may also perform the following operations:
[0081] If a request to create a Pod is detected, the network parameters of the VPC are obtained; the SDN controller is controlled by the target component associated with the VPC to apply for SDN resources based on the network parameters.
[0082] Accordingly, if no creation request is detected, the network parameters may not be acquired, and the SDN controller may be controlled to apply for SDN resources based on the network parameters.
[0083] In one implementation, a creation request may be initiated by a user or a professional technician to the Kubernetes system; illustratively, the Pod requested to be created by the creation request may include one or more containers.
[0084] In one implementation, the network parameters may include information such as the networkId, subnetId, and security group of the VPC.
[0085] In one implementation, the network parameters may be included in the creation request, or may be included in a configuration file pre-set on the first node, and the configuration file may be acquired and parsed by a target component for creating or configuring the Pod, thereby acquiring the network parameters.
[0086] Figure 3 A schematic diagram of the process of creating a Pod provided in an embodiment of the present application is as follows: Figure 3 As shown, process 3 can be implemented through api-server, kubelet, multus-cni, cilium-cni, vpc-cni, SDN control plane, Access-Agent and OVS; the details are as follows:
[0087] The user can send a creation request through the api-server. At this time, the kubelet can receive the creation request and monitor the creation operation. At the same time, it can also call the proxy network plug-in to trigger the multus-cin component to call the corresponding component to perform the network card creation operation.
[0088] For example, the multus-cin component may call the cilium-cni component to create the net0 network card.
[0089] Exemplarily, the multus-cin component may also call the vpc-cni component to create the net1 network card; exemplary, the net1 network card may be the first target network card, and the vpc-cni component may be the target component.
[0090] Exemplarily, after the vpc-cni component is called, it can send a request to create a VPC network resource to the SND control plane to trigger the SDN controller to create the VPC network resource, and can also add a port on the OVS, where the port can be the second port.
[0091] Exemplarily, the Access-Agent component monitors the creation of VPC network resources. If it monitors the SDN resources applied for by the vpc-cni component through the SDN controller, it can send a flow table to OVS; exemplary, the flow table can be the flow table data in the aforementioned embodiment.
[0092] For example, after the net0 and net1 network cards are created, the multus-cin component can return the container network information to the kubelet, so that it can trigger the api-server to update the container IP and other information. At this point, the Pod containing the net0 and net1 network cards is created.
[0093] In the above process, the multus-cni component is used to call different components to implement different network configurations; the cilium-cni component is used to configure or release the net0 network card and routing, and the vpc-cni component is specifically used to implement the application and release of VPC resources, as well as to configure or release the container net1 network card and routing according to the VPC resources; the SDN controller is specifically used to create and manage resources such as VPC, subnets and ports, divide network segments, IP and Media Access Control Address (MAC) addresses and routing policies for the corresponding resources, and can also configure security groups and ACLs for ports, and configure firewall rules for VPC, thereby achieving multi-layer security protection for VPC resources; OVS is used to import the traffic of the underlying data port into the upper-layer openflow switch for routing and forwarding based on the openflow flow table; the Access-Agent component is used to listen to the SDN resources applied by the container through the vpc-cni component in the SDN controller, and send the openflow flow table used for routing, forwarding and transmission of data packets in the tenant VPC to OVS.
[0094] Through the cooperation between the above components, not only the Pod can be quickly created, but also two network cards, net0 and net1, are allocated to the Pod, thus providing a network foundation for data transmission of the containers contained in the Pod in the public cloud and VPC.
[0095] From the above, it can be seen that the request transmission method provided in the embodiment of the present application, if a creation request for creating a Pod is detected, obtains the network parameters of the VPC, and controls the SDN controller to apply for SDN resources based on the network parameters through the target component associated with the VPC. In this way, through the above operation, not only the precise control of obtaining the network parameters of the VPC and applying for SDN resources is achieved, but also the matching degree between the SDN resources and the network parameters of the VPC can be improved.
[0096] Based on the foregoing embodiment, in the request transmission method provided in the embodiment of the present application, before determining the transmission route corresponding to the data transmission request, the following operations may also be performed:
[0097] If the target component is installed in the first node and a creation request for creating a Pod is detected, a veth-pair is created through the target component, and a first end of the veth-pair is set in a first namespace of the first container.
[0098] The target component is associated with the VPC, the veth-pair is associated with the first target network card, and the first interface represented by the first end of the veth-pair is used for the first container to send a data transmission request.
[0099] Accordingly, if the target component is not installed in the first node, or the creation request is not detected, the veth-pair may not be created.
[0100] In one implementation, the target component may be called via the multus-cin component.
[0101] In one embodiment, the target component is associated with the VPC, and may include a component in which the target component is a specific setting in the K8S system and is used to create and configure a first target network card.
[0102] Figure 4 A schematic diagram of the structure of the orchestration container network provided in the embodiment of the present application is shown in Figure 4 In the , cilium-cni and vpc-cni are network components that implement the Container Network Interface (CNI) standard. The cilium-cni component is used to configure the first network card, net0, for the container, so that the container can support communication with the Underlay network where the node is located, and the vpc-cni component is used to configure the second network card, net1, in the container, so that the container has the tenant attributes of the VPC and can transmit traffic between the services deployed in the vpc network. Among them, CNI is a standard and universal network interface for containers, and the component that implements this interface is the CNI component; in K8s, kubelet implements different network configuration methods by calling different CNI plug-ins; the CNI component is a binary executable file.
[0103] Exemplarily, after the cilium-cni component and the vpc-cni component are installed in the host device or node, the CNI executable file will be distributed in the / opt / cni / bin directory of the host device or node, which is used to call the cilium-cni component and the vpc-cni component through the standard application programming interface (API) to implement different network configuration methods when a creation request for creating a Pod is received.
[0104] Exemplarily, based on the description of the foregoing embodiments, it can be known that in the embodiments of the present application, a single container may have at least two network cards including net0 and net1. Therefore, the container in the embodiments of the present application may be a single container with multiple network cards.
[0105] Exemplarily, multiple network cards in a single container can be implemented through a network plug-in proxy mechanism; exemplary, the configuration of multiple network cards in a single container can be implemented by using the multus-cni component as a network proxy plug-in; wherein the multus-cni component can implement sequential calls to other networks, thereby generating multiple network cards for a container.
[0106] For example, after the node is installed, multus-cni can generate the following configuration:
[0107] Distribute the 00-multus.conf configuration file in the / etc / cni / net.d directory of each node;
[0108] Distribute multus-cni in the / opt / cni / bin directory on each node;
[0109] Install the Network AttachmentDefinition custom resource definition (CRD), which stores the configuration information of the cilium-cni component and the vpc-cni component.
[0110] Exemplarily, in response to a creation request, K8S can specify the CRD name in the annotations when creating a container or Pod, so that the container can complete the network configuration through the cilium-cni component and the vpc-cni component contained in the CRD.
[0111] Exemplarily, v1.multus-cni.io / default-network in CRD can be used to specify the CNI executable file for configuring the default network card net0 of the container, and K8s.v1.cni.cncf.io / networks can be used to specify the CNI executable file for configuring the second network card net1 of the container; in this embodiment of the application, the net0 network card is uniformly managed and allocated by the cilium-cni component, and the net1 network card is uniformly managed and allocated by the vpc-cni component.
[0112] For example, the resource configuration code for K8S to create a Pod can be as follows:
[0113] apiVersion:v1
[0114] kind:Pod
[0115] metadata:
[0116] name:ubuntu-pod-mul-vnic
[0117] annotations:
[0118] v1.multus-cni.io / default-network:cilium-cni-route-override-conf
[0119] k8s.v1.cni.cncf.io / networks:default / tianchi-cni-conf
[0120] Through the above operations, one or more network cards including net0 and net1 can be configured for the container. In this way, through the above network cards, the container can realize data transmission or processing operations on the network plane associated with the network card through a single network card, thereby dividing different network planes for the container.
[0121] Exemplarily, through the first network plane associated with net0, the container can transmit and communicate data with the Underlay network of the node where it is located, as well as other public services deployed in the Underlay network and K8s components and resource objects.
[0122] For example, through the second network plane associated with net1, data transmission and communication can be achieved between the container and the services deployed in the Overlay network where the VPC is located, and mutual communication between the container and other products in the VPC, including cloud hosts and bare metal, can be achieved; and the second network plane can uniformly perform data transmission and communication through net1, and the network address of the net1 network card and the corresponding gateway routing configuration and other information can be uniformly allocated by the SDN control plane component, so that it can fully adapt to the network connectivity of the Overlay network where the VPC is located; wherein the network address can include an IP address and a MAC address.
[0123] Through the above process, a container data transmission system including the first network plane, the second network plane and their respectively associated network cards is constructed, thereby realizing the expansion and refinement of the container network in K8S, and then being able to meet the data transmission and communication needs of the containers in K8S on any network plane.
[0124] In one implementation, after the SDN port resources are created, the vpc-cni component may create a veth-pair in the first container, configure the first end of the veth-pair in the network namespace of the first container, and name the veth-pair as the net1 network card.
[0125] In one implementation, the veth-pair is associated with the VPC, which may indicate that the veth-pair is specifically used to transmit data in the network space corresponding to the VPC.
[0126] In one implementation, the veth-pair is associated with the first target network card, and may include a data transmission interface of the first target network card for representing the veth-pair.
[0127] From the above, it can be seen that in the request transmission method provided in the embodiment of the present application, if the target component is installed in the first node and a creation request for creating a Pod is detected, a veth-pair is created through the target component, and the target component is associated with the VPC, and the veth-pair is associated with the first target network card. In this way, through the above operations, precise control over the creation of veth-pair is achieved, and targeted creation of veth-pair is also achieved; and the first end of the veth-pair is set in the first namespace of the first container, and the first interface represented by the first end of the veth-pair is used for the first container to send a data transmission request. In this way, when the first container needs to send a data transmission request, it can accurately and efficiently obtain the first interface from the first namespace, thereby providing interface support for efficient and accurate transmission of data transmission requests.
[0128] Based on the foregoing embodiment, the request transmission method provided in the embodiment of the present application may also perform the following operations:
[0129] Acquire port information of the SDN resource; and configure a network address for the first target network card based on the port information.
[0130] Among them, SDN resources are obtained by applying for target components through the SDN controller.
[0131] In one implementation, the port information may be the port resources in the aforementioned embodiment.
[0132] In one implementation, Pod resources can be created through a declarative API, and all VPC network parameters are passed through the Pod's annotations. The vpc-cni component can automatically parse network parameters including networkId, subnetId, and security group information, and call the Resful interface of the SDN control plane to complete the creation of SDN port resources; wherein the port resources may include information such as IP addresses including IPv4 and IPv6 and MAC addresses.
[0133] In one implementation, after the SDN port resources are created, an IP address and a MAC address may be configured for the first target network card according to the SDN port resources.
[0134] As can be seen from the above, in the request transmission method provided by the embodiment of the present application, after obtaining the port information of the SDN resource, the network address is configured for the first target network card based on the port information, and the SDN resource is obtained by applying for the target component through the SDN controller. In this way, through the above operation, not only the reuse of the SDN controller is realized, but also, by virtue of the advantages of the SDN controller in the dimension of applying for network resources, the stability and efficiency of the successful application of the port information of the SDN resource can be improved, thereby improving the stability of configuring the network address for the first target network card.
[0135] Based on the foregoing embodiment, the request transmission method provided in the embodiment of the present application may also perform the following operations:
[0136] The gateway information of the VPC is obtained; and routing data is configured for the first container based on the gateway information through the target component.
[0137] The routing data is used to determine whether the data transmission request generated by the first container is associated with the VPC.
[0138] In one implementation, the gateway information may be predetermined, or may be configured and transmitted through annotations, which is not limited in this embodiment of the present application.
[0139] In one implementation, based on the gateway information of the VPC subnet, the vpc-cni component may also add a route for the first container, thereby configuring routing data for the first container.
[0140] In one implementation, routing data may be used to determine whether the data transmission request generated by the first container is transmitted between containers or nodes included in the VPC or in a public network.
[0141] In one implementation, if the target address corresponding to the data transmission request is within the subnet segment corresponding to the above gateway information, the data transmission request can be forwarded from the net1 network card, i.e., the first target network card, while the traffic outside the subnet segment can be forwarded from the net0 network card out of the first container.
[0142] From the above, it can be seen that the request transmission method provided in the embodiment of the present application, after obtaining the gateway information of the VPC, configures routing data for the first container based on the gateway information through the target component, and the routing data is used to determine whether the data transmission request generated by the first container is associated with the VPC. In this way, through the above operation, not only the pertinence of configuring routing data for the first container is improved, but also, through the routing data, the transmission mode of the data transmission request generated by the first container can be accurately determined and screened.
[0143] Based on the foregoing embodiment, the request transmission method provided in the embodiment of the present application may further perform the following operations after setting the first end of the veth-pair in the first namespace of the first container:
[0144] Obtain a first identifier of the first container and obtain a second identifier of the veth-pair; and associate a second end of the veth-pair with a second namespace of the first node based on the first identifier and the second identifier.
[0145] In one implementation, the first identifier may include at least one of a name, a number, and an address of the first container; illustratively, the address may include an IP address and / or a MAC address.
[0146] In one implementation, the second identifier may include a name or number of the veth-pair, and the name or number is unique.
[0147] In one implementation, associating the second end of the veth-pair to the second namespace of the first node may be accomplished by:
[0148] Concatenate at least some fields in the first identifier and the second identifier to obtain a concatenation result, and associate the concatenation result to the second namespace; illustratively, at least some resources in the first identifier may include the first 8 bits of the first identifier, for example, the concatenation result may include: veth+the first 8 bits of containerID; wherein containerID is the first identifier of the first container, and veth may be the second identifier.
[0149] From the above, it can be seen that in the request transmission method provided in the embodiment of the present application, after obtaining the first identifier of the first container and the second identifier of the veth-pair, the second end of the veth-pair is associated with the second namespace of the first node based on the first identifier and the second identifier. In this way, through the above operation, not only can the second end of the veth-pair be associated with the second namespace of the first node, but also, through the first identifier and the second identifier, the uniqueness of the second end of the veth-pair in the second namespace is improved, thereby improving the stability of the data transmission request transmission associated with the VPC generated by the first container.
[0150] Based on the foregoing embodiment, the request transmission method provided in the embodiment of the present application may also perform the following operations:
[0151] Based on the first identifier and the second identifier, associate the second end of the veth-pair with OVS.
[0152] In one implementation, the second end of the veth-pair may be associated to OVS via a target component.
[0153] In one implementation, the target component may associate the second end of the veth-pair to OVS through a port add command supported in K8s; illustratively, the port add command may be:
[0154] ovs-vsctl add port "veth" + the first 8 digits of containerID.
[0155] Figure 5 A schematic diagram of a process for configuring a network for a container provided in an embodiment of the present application is shown in FIG. Figure 5 As shown, the process may include the following steps:
[0156] Step 501: Distribute cilium-cni components and vpc-cni components to each Node node in the K8S cluster.
[0157] Step 502: Distribute the multus-cni component to the nodes in the K8S cluster.
[0158] Step 503: Create a container, specify the container network card by annotation, and configure the network for the container.
[0159] For example, the multus-cni component can create the network card net0 by calling the cilium-cni component, and can also create the network card net1 by calling the vpc-cni component.
[0160] Step 504: Container VPC network configuration is delivered.
[0161] Exemplarily, the above steps may include the following steps:
[0162] Step 5041: Create SDN resources.
[0163] Exemplarily, the vpc-cni component may apply for SDN resources through the SDN controller.
[0164] Step 5042: Configure the container network.
[0165] Exemplarily, the vpc-cni component may create a veth-pair and set its first end in the network namespace of the container; exemplarily, the network namespace of the container may be the first namespace in the aforementioned embodiment.
[0166] Step 5043: Configure the host network.
[0167] Exemplarily, the vpc-cni component may set the second end of the veth-pair in the network namespace of the host device where the container is located; exemplarily, the network namespace of the host device may be the second namespace in the aforementioned embodiment.
[0168] Step 5044: Add a port to OVS.
[0169] Exemplarily, the second end of the veth-pair can be associated with the OVS through the method provided in the aforementioned embodiment, thereby achieving the addition of the second end of the veth-pair to the OVS.
[0170] Through the above process, during the container creation process, multiple network cards can be created for the container. At the same time, the network cards associated with the VPC can be fully configured in the container network, host network, and OVS dimensions, thereby improving the stability of data transmission in the VPC.
[0171] From the above, it can be seen that the request transmission method provided in the embodiment of the present application realizes the association of veth-pair in the OVS dimension by associating the second end of the veth-pair to OVS based on the first identifier and the second identifier, thereby providing a port basis for transmitting the data transmission request generated by the first container from the first container to OVS.
[0172] To sum up, the technical solution provided by the embodiment of the present application can create multiple network cards for a container during the container creation process, and each network card processes data traffic on different network planes, so that the container can communicate with the Underlay network of the node where it is located and K8s components including kubelet and api-server, and the K8s business traffic can be load balanced to the inside of the container, and at the same time, an Overlay network can be built for the container to handle data transmission between services in the same VPC; and, the present solution also provides a VPC network configuration method for a container, by creating SDN resources, configuring the container network, configuring the host network, and adding ports in the OVS component, it is possible to configure the Overlay network for the container through a standardized container network interface, so that the container can communicate stably with other services in the same VPC; on the other hand, the embodiment of the present application also provides a VPC traffic model, and the traffic associated with the VPC in the container is sent to OVS through the net1 network card in the container, so that OVS can realize the transmission of VPC traffic in the container network based on the Openflow flow table.
[0173] Based on the above embodiments, the present application also provides a request transmission device. Figure 6 A schematic diagram of a process flow of a request transmission device provided in an embodiment of the present application, such as Figure 6As shown, the request transmission device 6 may include:
[0174] A determination module 601 is configured to determine a transmission route corresponding to the data transmission request if a first container in a first node of the Kubernetes system detects a data transmission request;
[0175] A transmission module 602 is used to send a data transmission request to OVS through a first target network card associated with the first container if the transmission route is associated with the VPC; wherein the OVS is set at the first node; and the first target network card is used to implement data transmission between containers and / or nodes in the VPC;
[0176] The transmission module 602 is also used to route the data transmission request to the second node associated with the second container based on the flow table data through OVS, so that the second node can transmit the data transmission request to the second container via the second target network card; wherein the second container includes the target container of the data transmission request; the second node is associated with the VPC; the flow table data is at least associated with the VPC; the second target network card is associated with the second node, and is used to realize data transmission between containers and / or nodes in the VPC.
[0177] In some embodiments, the determination module 601 is used to obtain a first interface corresponding to the first target network card; wherein the first interface includes an interface of a veth-pair corresponding to the first target network card in the first namespace of the first container;
[0178] The transmission module 602 is used to send a data transmission request to a second interface through a first interface; wherein the second interface includes an interface in which a veth-pair is located in a second namespace of the first node; and the second interface is associated with OVS.
[0179] In some embodiments, the determination module 601 is used to configure flow table data for the OVS through the Access-Agent component if the Access-Agent component detects that the software defined network SDN controller performs an operation of applying for SDN resources.
[0180] In some embodiments, the determination module 601 is used to obtain network parameters of the VPC if a creation request for creating a Pod is detected; and control the SDN controller to apply for SDN resources based on the network parameters through the target component associated with the VPC.
[0181] In some embodiments, the determination module 601 is used to create a veth-pair through the target component if a target component is installed in the first node and a creation request for creating a Pod is detected; wherein the target component is associated with the VPC; and the veth-pair is associated with the first target network card;
[0182] The determination module 601 is further configured to set the first end of the veth-pair in the first namespace of the first container; wherein the first interface represented by the first end of the veth-pair is used for the first container to send a data transmission request.
[0183] In some embodiments, the determination module 601 is used to obtain port information of SDN resources; wherein the SDN resources are obtained by applying for the target component through the SDN controller;
[0184] The determination module 601 is further configured to configure a network address for the first target network card based on the port information.
[0185] In some embodiments, the determination module 601 is used to obtain the gateway information of the VPC; configure routing data for the first container based on the gateway information through the target component; wherein the routing data is used to determine whether the data transmission request generated by the first container is associated with the VPC.
[0186] In some embodiments, the determination module 601 is used to obtain a first identifier of the first container; obtain a second identifier of the veth-pair; and associate the second end of the veth-pair with the second namespace of the first node based on the first identifier and the second identifier.
[0187] In some embodiments, the determination module 601 is configured to associate the second end of the veth-pair with the OVS based on the first identifier and the second identifier.
[0188] Figure 7 A schematic diagram of the structure of the K8s node provided in the embodiment of the present application is shown in FIG. Figure 7 As shown, the K8s node may include a processor 701 and a memory 702; wherein the memory 702 stores a computer program; when the computer program is executed by the processor 701, it can implement the request transmission method provided in any of the previous embodiments.
[0189] For example, Figure 7 The K8s node shown may be the first node in the aforementioned embodiment.
[0190] An embodiment of the present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor of an electronic device, it can implement the request transmission method provided in any of the previous embodiments.
[0191] An embodiment of the present application also provides a computer program product, which includes a computer program; when the computer program is executed by a processor of an electronic device, it can implement the request transmission method provided in any of the previous embodiments.
[0192] The above description of various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced to each other, and for the sake of brevity, they will not be repeated herein.
[0193] The methods disclosed in the various method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.
[0194] The features disclosed in the various product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.
[0195] The features disclosed in the various method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.
[0196] It should be noted that the above-mentioned computer-readable storage medium can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory (Flash Memory), a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM) and other memories; it can also be various electronic devices including one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.
[0197] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.
[0198] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.
[0199] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus necessary general hardware nodes, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in each embodiment of the present application.
[0200] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0201] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.
[0202] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.
[0203] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.
Claims
1. A request transmission method, characterized in that: The method comprises: If a first container in a first node of the Kubernetes system detects a data transmission request, determine a transmission route corresponding to the data transmission request; If the transmission route is associated with a virtual private cloud, the data transmission request is sent to the virtual switch through the first target network card associated with the first container; wherein the virtual switch is set at the first node; and the first target network card is used to realize data transmission between containers and / or nodes in the virtual private cloud; The data transmission request is routed to the second node associated with the second container based on the flow table data through the virtual switch, so that the second node transmits the data transmission request to the second container via the second target network card; wherein the second container includes the target container of the data transmission request; the second node is associated with the virtual private cloud; the flow table data is at least associated with the virtual private cloud; the second target network card is associated with the second node and is used to realize data transmission between containers and / or nodes in the virtual private cloud.
2. The method according to claim 1, characterized in that The sending the data transmission request to the virtual switch through the first target network card associated with the first container includes: Obtain a first interface corresponding to the first target network card; wherein the first interface includes an interface of a veth-pair corresponding to the first target network card in a first namespace of the first container; The data transmission request is sent to the second interface through the first interface; wherein the second interface includes an interface in which the veth-pair is located in a second namespace of the first node; and the second interface is associated with the virtual switch.
3. The method according to claim 1 or 2, characterized in that: Before determining the transmission route corresponding to the data transmission request, the method further includes: If the Access-Agent component detects that the software defined network SDN controller performs an operation of applying for SDN resources, the flow table data is configured for the virtual switch through the Access-Agent component.
4. The method according to claim 3, characterized in that The method further comprises: If a request to create a Pod is detected, obtain network parameters of the virtual private cloud; The target component associated with the virtual private cloud controls the SDN controller to apply for the SDN resources based on the network parameters.
5. The method according to claim 1 or 2, characterized in that: Before determining the transmission route corresponding to the data transmission request, the method further includes: If a target component is installed in the first node and a creation request for creating a Pod is detected, a veth-pair is created through the target component; wherein the target component is associated with the virtual private cloud; and the veth-pair is associated with the first target network card; The first end of the veth-pair is set in the first namespace of the first container; wherein the first interface represented by the first end of the veth-pair is used for the first container to send the data transmission request.
6. The method according to claim 5, characterized in that The method further comprises: Acquire port information of SDN resources; wherein the SDN resources are obtained by the target component through an SDN controller; A network address is configured for the first target network card based on the port information.
7. The method according to claim 5, characterized in that The method further comprises: Obtaining gateway information of the virtual private cloud; The target component configures routing data for the first container based on the gateway information; wherein the routing data is used to determine whether the data transmission request generated by the first container is associated with the virtual private cloud.
8. The method according to claim 5, characterized in that The setting the first end of the veth-pair after the first namespace of the first container, the method further includes: Obtaining a first identifier of the first container; Obtain a second identifier of the veth-pair; Based on the first identifier and the second identifier, associate the second end of the veth-pair with the second namespace of the first node.
9. The method according to claim 8, characterized in that The method further comprises: Based on the first identifier and the second identifier, associate the second end of the veth-pair with the virtual switch.
10. A request transmission device, characterized in that: The request transmission device comprises: A determination module, configured to determine a transmission route corresponding to the data transmission request if a first container in a first node of the Kubernetes system detects a data transmission request; A transmission module, configured to send the data transmission request to a virtual switch through a first target network card associated with the first container if the transmission route is associated with a virtual private cloud; wherein the virtual switch is provided at the first node; and the first target network card is configured to implement data transmission between containers and / or nodes in the virtual private cloud; The transmission module is also used to route the data transmission request to the second node associated with the second container based on the flow table data through the virtual switch, so that the second node transmits the data transmission request to the second container via the second target network card; wherein the second container includes the target container of the data transmission request; the second node is associated with the virtual private cloud; the flow table data is at least associated with the virtual private cloud; the second target network card is associated with the second node, and is used to realize data transmission between containers and / or nodes in the virtual private cloud.
11. A Kubernetes node, characterized in that: The Kubernetes node includes a processor and a memory; wherein a computer program is stored in the memory; when the computer program is executed by the processor, the request transmission method as described in any one of claims 1 to 9 can be implemented.
12. A computer-readable storage medium, characterized in that: The storage medium stores a computer program; when the computer program is executed by a processor of an electronic device, the request transmission method as described in any one of claims 1 to 9 can be implemented.
13. A computer program product, characterized in that The program product includes a computer program; when the computer program is executed by a processor of an electronic device, it can implement the request transmission method as described in any one of claims 1 to 9.