Method and system for realizing multi-vpc container network based on eBPF

Abstract

The invention provides an eBPF-based multi-vpc container network implementation method and system, and the method comprises the steps: carrying out the basic deployment of a container cluster: carrying out the unified management and control of the network flow of each node in the cluster through the deployment of a perimeter-agent pod, a perimeter-cni plug-in and a perimeter-controller pod, and carrying out the unified management and control of the network flow of each node in the cluster through the deployment of a perimeter-agent pod, a perimeter-cni plug-in and a perimeter-controller pod; and forwarding traffic in the same node, the same VPC and the same Subnet: analyzing quintuple information through an eBPF program and searching a bpf map, so as to ensure that Pods in the same subnet of the same VPC in the same node can efficiently communicate with one another in a low-delay manner. The eBPF-based multi-vpc container network implementation method has the beneficial effects that the container cloud network model and functions are perfected from multiple dimensions aiming at the situation that a current container cloud network model is single and cannot realize a multi-vpc network, on one hand, container network configuration and container cluster initialization decoupling are realized, and on the other hand, the container network configuration and the container cluster initialization decoupling are realized; when a tenant deploys an application, the tenant can flexibly configure a required VPC network as required, such as configuring an address field host number, an address field network number, a gateway address and the like.

Description

Technical Field

[0001] The present invention belongs to the field of cloud computing, and in particular relates to a method for implementing a multi-vpc container network based on eBPF. Background Art

[0002] As cloud-native technologies become more and more popular, various types of businesses are gradually migrating to cloud deployment. Container cloud is known as the underlying cloud technology that replaces traditional cloud. Container cloud with open source Kubernetes as the core has gradually become the standard for container cloud. While providing the standard container network interface CNI (Container Network Interface), open source Kubernetes also recommends several open source container network CNI plug-ins such as Flannel / Calico / Cilium, etc. However, due to the limitations of the standard container network interface model provided by Kubernetes, multi-VPC (Virtual Private Cloud) networks cannot be implemented. A single container network model cannot meet the scenarios of multi-tenant application isolation, multi-tenant data security, and multi-tenant specific resource sharing on the container cloud.

[0003] Virtual Private Cloud (VPC) is widely used in traditional cloud platforms. It provides basic virtualized network capabilities while providing network resource isolation for different tenants on the cloud or different applications within the same tenant. Tenants can independently configure and manage the virtual network environment on the cloud platform according to actual conditions, and effectively isolate resource access between tenants or within tenants without relying on security rules, thereby improving the security of tenants' cloud resources.

[0004] The current container cloud network model based on open source Kubernetes is single. When creating a cluster, you need to configure an IPv4 address segment and an IPv6 address segment for initial allocation of container network application addresses. Applications of different tenants actually use the same address segment, and tenant isolation can only be achieved through complex NetworkPolicy fine-grained, but it cannot meet the needs of multi-tenant scenarios in large-scale scenarios. Summary of the invention

[0005] In view of this, the present invention aims to propose an implementation method of a multi-vpc container network based on eBPF to at least solve one problem in the background technology.

[0006] To achieve the above object, the technical solution of the present invention is achieved as follows:

[0007] In a first aspect, this solution discloses a method for implementing a multi-vpc container network based on eBPF, including:

[0008] Basic deployment of container cluster: deploy peregrine-agent pod, peregrine-cni plug-in and peregrine-controller pod to ensure unified management and control of network traffic of each node in the cluster;

[0009] Traffic forwarding in the same node, VPC and subnet: The eBPF program is used to parse the five-tuple information and search the bpf map to ensure that Pods in the same node, VPC and subnet can communicate efficiently and with low latency.

[0010] Traffic forwarding across subnets in the same VPC on the same node: The eBPF program is used to check the bpf map and multi-VPC peering connections to ensure VPC isolation and connectivity during cross-subnet communication within the same node;

[0011] Traffic forwarding across VPCs on the same node: eBPF programs are used to check multi-VPC peer connections to ensure that Pod communication across VPCs on the same node is carried out in the presence of peer connections, thereby enhancing isolation and security.

[0012] Cross-node and cross-VPC traffic forwarding: Traffic is forwarded through the eBPF program combined with the underlying network, and the VPC peer connection is verified on the destination node to ensure the secure and correct forwarding of cross-node and cross-VPC traffic.

[0013] Furthermore, the basic deployment of the container cluster includes:

[0014] Deploy the peregrine-agent pod and peregrine-cni plugin in the container cluster to ensure that each node can manage and monitor network traffic;

[0015] At the same time, by deploying the peregrine-controller pod to centrally manage network policies on the control node, a basic network environment and control mechanism are provided for traffic forwarding in the container cluster, ensuring that network communication between nodes in the cluster can be managed through a unified network plane.

[0016] The specific steps are:

[0017] Run the peregrine-agent pod on each node in the container cluster to manage and monitor the node's network traffic;

[0018] Store the peregrine-cni binary executable file in the / opt / cni / bin / directory of each node to ensure that the network plug-in can work properly;

[0019] Deploy the peregrine-controller pod on the cluster controller node to centrally manage network traffic rules and policies within the cluster.

[0020] Furthermore, in the same-node, same-VPC, and same-Subnet traffic forwarding, it includes:

[0021] When Pods in the same node, VPC, and subnet communicate with each other, the eBPF program parses the five-tuple information of the traffic message, quickly finds the corresponding entry in the bpf map, and directly forwards the traffic to the destination Pod;

[0022] The specific steps are:

[0023] The access traffic of the source Pod first reaches the eBPF program on the associated network card;

[0024] The eBPF program parses the message header to obtain five-tuple information, which includes: source IP, destination IP, protocol, source port, and destination port;

[0025] The eBPF program uses the source IP and destination IP as keys to find the corresponding entry in the bpf map;

[0026] If the bpf map entries for both the source IP and the destination IP exist and their vpcid information is the same, the eBPF program forwards the traffic directly to the network card corresponding to the destination Pod.

[0027] Furthermore, in the cross-Subnet traffic forwarding in the same node and the same VPC, it includes:

[0028] When Pods in the same node need to communicate across subnets, the eBPF program determines whether to check multi-VPC peer connections by looking up the bpf map and verifying the VPC information, thereby controlling cross-subnet communication.

[0029] The specific steps are:

[0030] The source Pod first initiates a gateway MAC request to obtain the gateway MAC address;

[0031] The traffic from the source Pod reaches the eBPF program, which parses the message header to obtain the five-tuple information. The eBPF program uses the source IP and destination IP as keys to find the corresponding entry in the bpf map.

[0032] If the bpf map entries for both the source and destination IPs exist but their vpcid information is different, the eBPF program checks whether a multi-VPC peering connection is created, where:

[0033] If no peer connection is established, the traffic is directly discarded;

[0034] If a peer connection has been established, the traffic is forwarded to the network card corresponding to the destination Pod.

[0035] Furthermore, in the same-node cross-VPC traffic forwarding, the following steps are included:

[0036] For Pod communication across VPCs within the same node, the eBPF program checks multi-VPC peering connections to ensure that traffic forwarding between different VPCs is only performed when peering connections exist, to prevent unauthorized cross-VPC communication;

[0037] The specific steps are:

[0038] The source Pod first initiates a gateway MAC request to obtain the gateway MAC address;

[0039] The traffic from the source Pod reaches the eBPF program, which parses the message header to obtain the five-tuple information. The eBPF program uses the source IP and destination IP as keys to find the corresponding entry in the bpf map.

[0040] If the bpf map entries for both the source and destination IPs exist but their vpcid information is different, the eBPF program checks whether a multi-VPC peering connection is created, where:

[0041] If no peer connection is established, the traffic is directly discarded;

[0042] If a peer connection has been established, the traffic is forwarded to the network card corresponding to the destination Pod.

[0043] Furthermore, the cross-node and cross-VPC traffic forwarding includes:

[0044] When traffic needs to communicate across nodes and VPCs, the eBPF program forwards the traffic through the underlying network and verifies the existence of the VPC peer connection and the destination Pod again on the destination node to ensure that the traffic can reach the destination Pod safely and correctly.

[0045] The specific steps are:

[0046] The source Pod first initiates a gateway MAC request to obtain the gateway MAC address;

[0047] The traffic from the source Pod reaches the eBPF program, which parses the message header to obtain the five-tuple information.

[0048] The eBPF program uses the source IP and destination IP as keys to find the corresponding entry in the bpf map. If the bpf map entry corresponding to the destination IP does not exist, the traffic will be forwarded to the physical network card corresponding to the parentindex id in the bpf map entry corresponding to the source IP.

[0049] Traffic passes through the underlying underlay network or SDN overlay network;

[0050] If a VPC peering connection is not created, the traffic is directly discarded in the underlying network;

[0051] If a VPC peering connection has been created, traffic continues to be forwarded to the eBPF program on the destination node network card;

[0052] The eBPF program of the destination node checks whether the Pod network card corresponding to the destination IP exists. If so, the traffic is forwarded directly to the corresponding Pod network card.

[0053] In a second aspect, the present solution discloses a system for a multi-vpc container network based on eBPF. According to the implementation method of the multi-vpc container network based on eBPF in the first aspect, the method includes:

[0054] peregrine-cni, as the CNI network configuration interface in the container cloud network, is responsible for the initialization configuration of the Pod network in the container cloud, including network card initialization configuration, IP address configuration, and routing configuration;

[0055] Peregrine-controller, as the core component in implementing container cloud network, is responsible for overall resource monitoring and control of cluster-level resources, such as global peregrine-endpoint CRD resource processing and Pod-related resource processing;

[0056] peregrine-agent, as a core component in implementing container cloud networks, is responsible for maintaining VPC eBPF maps information and mounting eBPF programs for multi-VPC IPv4 / IPv6 dual-stack forwarding on Pod network cards.

[0057] In the third aspect, the present solution discloses an electronic device, comprising a processor and a memory that is communicatively connected to the processor and is used to store executable instructions of the processor, wherein the processor is used to execute the implementation method of a multi-vpc container network based on eBPF as described in the first aspect.

[0058] In the fourth aspect, the present solution discloses a server, comprising at least one processor and a memory communicatively connected to the processor, wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor so that the at least one processor executes the implementation method of a multi-vpc container network based on eBPF as described in the first aspect.

[0059] In the fifth aspect, the present solution discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method for implementing a multi-vpc container network based on eBPF as described in the first aspect.

[0060] Compared with the prior art, the implementation method of the multi-vpc container network based on eBPF described in the present invention has the following beneficial effects:

[0061] (1) The method for implementing a multi-VPC container network based on eBPF described in the present invention improves the container cloud network model and functions from multiple dimensions, aiming at the fact that the current container cloud network model is single and cannot implement a multi-VPC network. On the one hand, the container network configuration and the container cluster initialization are decoupled, and the tenant can flexibly configure the required VPC network on demand when deploying applications, such as configuring the address segment host number, address segment network number, gateway address, etc.;

[0062] (2) The implementation method of the multi-vpc container network based on eBPF described in the present invention, on the other hand, the container network model can be integrated with the traditional cloud network model to unify the container cloud network, the traditional cloud network and the bare metal node network plane. At the same time, IP addresses are no longer allocated according to the node allocation CIDR method, which completes the large second layer function of the container network and solves the problem of address waste when allocating CIDR according to the node. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] The accompanying drawings constituting a part of the present invention are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the accompanying drawings:

[0064] Figure 1 This is a schematic diagram of a container multi-VPC network architecture based on eBPF according to an embodiment of the present invention;

[0065] Figure 2 This is a schematic diagram of the access traffic diagram of the same node, same vpc and same subnet of the container cloud cluster according to an embodiment of the present invention;

[0066] Figure 3 This is a schematic diagram of a traffic diagram for accessing the same node and the same vpc across subnets in a container cloud cluster according to an embodiment of the present invention;

[0067] Figure 4This is a schematic diagram of a traffic diagram for accessing the same node across VPCs in a container cloud cluster according to an embodiment of the present invention;

[0068] Figure 5 This is a schematic diagram of the cross-node and cross-VPC access traffic diagram of the container cloud cluster according to an embodiment of the present invention. DETAILED DESCRIPTION

[0069] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments may be combined with each other.

[0070] The present invention will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments.

[0071] In view of the fact that the current single container cloud network model cannot realize multiple VPC networks, the present invention proposes a method for realizing multiple VPC networks on a container cloud platform. The container cloud network model and functions are improved from multiple dimensions. On the one hand, the container network configuration and the container cluster initialization are decoupled, and the tenants can flexibly configure the required VPC network on demand when deploying applications, such as configuring the address segment host number, address segment network number, gateway address, etc. On the other hand, the container network model can be integrated with the traditional cloud network model to unify the container cloud network, traditional cloud network and bare metal node network plane. At the same time, IP addresses are no longer allocated in the way of allocating CIDR to nodes, and the large second-layer function of the container network is completed, solving the problem of address waste when allocating CIDR to nodes.

[0072] In summary, the present invention aims to achieve the following objectives:

[0073] Improve the container cloud network model. The container cloud network can be integrated with the traditional cloud network model according to the deployment scenario, unifying the container cloud network, traditional cloud network and bare metal node network plane.

[0074] Optimize the container cloud network configuration logic. Container network configuration and container cluster initialization are decoupled, and tenants can create and configure container cloud VPC networks on demand.

[0075] Realize multi-VPC network isolation and on-demand intercommunication in container cloud. Different tenant applications use different VPC networks, and the same tenant can also use multiple VPC networks to isolate applications on demand. At the same time, combined with the VPC peer connection in the SDN network, communication between different VPC networks can be opened up on demand.

[0076] IP addresses are no longer allocated according to the CIDR allocation method for nodes. Applications across cluster nodes can also use the same large Layer 2 network, completing the large Layer 2 function of the container network and solving the problem of address waste when allocating CIDR according to nodes.

[0077] The present invention proposes a method for implementing a multi-VPC network on a container cloud platform based on eBPF, which includes the following components:

[0078] (1) peregrine-cni: implements the CNI network configuration interface in the container cloud network, responsible for the initialization configuration of the Pod network in the container cloud, including network card initialization configuration, IP address configuration, routing configuration, etc. The specific functions and processes are as follows:

[0079] When the container cloud platform is deployed, the peregrine-cni binary executable file will be copied to the / opt / cni / bin / directory of each node in the cluster for docking with the Pod network configuration creation / deletion process in the container cloud.

[0080] When creating an application on the container cloud platform, you can choose a pre-configured VPC network or configure a VPC network on demand. If you use a new VPC network, the SDN network interface will be called first to configure the new VPC network. After the network configuration is completed, the VPC network information will be configured in the Pod template with annotation information.

[0081] After the Pod on the container cloud platform is scheduled, it will fall on a specific cluster node. At this time, the kubelet on the node will call the configuration Pod network interface in the peregrine-cni binary file.

[0082] peregrine-cni parses the annotation fields of the Pod to obtain the VPC network information configured for the Pod, such as the VPC network UUID and whether dual stack is enabled.

[0083] peregrine-cni packages the request to obtain the IP address. The request parameters include Pod name, Pod Namespace, PodContainer ID, and VPC UUID.

[0084] peregrine-cni uses the obtained IP address to configure the Pod network, including: migrating the created network card to the Pod network namespace, configuring the IP address, setting the network card status to UP, and configuring routing.

[0085] peregrine-cni initiates a request to peregrine-agent to save the configured Pod network parameters to the peregrine-networking CRD.

[0086] (2) peregrine-controller: implements the core component of the container cloud network, responsible for the overall resource monitoring and control of cluster-level resources, such as global peregrine-endpoint CRD resource processing, and the robust processing of Pod-related resources. The specific functions and processes are as follows:

[0087] Listening Pod and peregrine-endpoint maintain global Pod ip cache information.

[0088] (3) peregrine-agent: implements the core component of the container cloud network, responsible for VPC eBPF map information maintenance and Pod network card multi-VPC IPv4 / IPv6 dual stack forwarding eBPF program mounting. The specific functions and processes are as follows:

[0089] After peregrine-agent is started, it will provide a REST API interface for adding and deleting peregrine-endpoint resources. At the same time, it will mount a multi-VPC IPv4 / IPv6 dual-stack forwarding eBPF program on the physical network card to process the traffic from outside the node to the Pod inside the node.

[0090] When the peregrine-agent interface receives a new peregrine-networking resource request from peregrine-cni, it will first perform a preliminary verification of the peregrine-endpoint resource. The relevant peregrine-endpoint information is stored in the peregrine_ipcache forwarding table. The type of the peregrine_ipcache map is a bpf hash map. The map key is an IPv4 or IPv6 address, and the value is a defined structure that contains data such as epid, vpcid, mac, vlanid, interfaceindex, and parentindex.

[0091] At the same time, the compiled multi-VPC IPv4 / IPv6 dual-stack forwarding eBPF program will be mounted on the network card associated with the Pod. When the Pod accesses other pods on the node, the message will pass through the mounted eBPF program, first parse the header of the message to obtain the source IP address and destination IP address, and then use the source IP address and destination IP address as the key to find the data in peregrine_ipcache. If it can be found, compare the data information corresponding to the source IP address and the destination IP address, such as vpcid, to see if they are the same. If they are the same, forward them directly. If they are different, forward the traffic to the associated physical network card. When a multi-VPC docking connection is created externally, the traffic will be forwarded back. If not, it will be discarded directly. When a Pod accesses a Pod on another node, the message will pass through the mounted eBPF program. First, the message header will be parsed to obtain the source IP address and the destination IP address. The source IP address and the destination IP address will be used as the key to search for data in peregrine_ipcache. Since the Pod corresponding to the destination IP is not on this node, the corresponding data cannot be found. It will be forwarded directly from the associated physical network card. When forwarding through the underlying Underlay network or the SDN Overlay network, it will check whether a vpc peer connection has been created. If not, it will be discarded directly. If so, it will continue. When the traffic reaches the physical network card of the destination node, the eBPF program mounted on the physical network card will search for data in peregrine_ipcache to determine whether the node has a Pod corresponding to the destination IP. If so, the traffic will be forwarded to the network card corresponding to the destination Pod.

[0092] Reference Figure 1 Based on the eBPF container multi-VPC network architecture diagram, the container cluster can be deployed in a virtual machine or on a bare metal node, and the deployment location does not affect the unified network plane of the container cloud network, traditional cloud network, and bare metal node network. The specific deployment details are as follows:

[0093] 1. The peregrine-agent pod runs on each node of the cluster;

[0094] 2. The peregrine-cni binary executable file is stored in the / opt / cni / bin / directory on each node of the cluster.

[0095] 3. The peregrine-controller pod will be deployed on the cluster control node;

[0096] There are many scenarios involved in the forwarding of container cloud traffic, including: forwarding traffic in the same node, same vpc and same subnet of a cluster, forwarding traffic in the same node, same vpc but different subnets of a cluster, forwarding traffic in the same node across vpcs of a cluster, and forwarding traffic in the same node across vpcs of a cluster. Here we explain the traffic forwarding paths in the above scenarios respectively.

[0097] Reference Figure 2 Access traffic diagram of the same node, same vpc and same subnet in the container cloud cluster. The traffic forwarding process of the same node, same vpc and same subnet in the container cloud cluster is as follows:

[0098] 1. The access traffic of the source Pod reaches the eBPF program on the associated network card;

[0099] 2. The eBPF program parses the message header to obtain the five-tuple information;

[0100] 3. The eBPF program uses the source IP and destination IP as keys to search the bpf map;

[0101] 4. Confirm the map entry data corresponding to the source IP and the destination IP. If the data exists, compare the vpcid information of the two. If yes, forward it directly to the network card corresponding to the destination Pod.

[0102] Reference Figure 3 Traffic diagram of cross-subnet access in the same node and vpc of a container cloud cluster. The traffic forwarding process of cross-subnet traffic in the same node and vpc of a container cloud cluster is as follows:

[0103] 1. The source Pod first initiates a gateway mac request to obtain the gateway mac address.

[0104] 2. The traffic from the source Pod to the destination Pod reaches the eBPF program on the associated network card;

[0105] 3. The eBPF program parses the message header to obtain the five-tuple information;

[0106] 4. The eBPF program uses the source IP and destination IP as keys to search the bpf map;

[0107] 5. Confirm the map entry data corresponding to the source IP and the destination IP. If the data exists, compare the vpcid information of the two. If they are different, check whether a multi-vpc peer connection has been created. If not, discard it directly. If a multi-vpc peer connection has been created, forward the traffic to the network card corresponding to the destination Pod.

[0108] Reference Figure 4 Traffic diagram of cross-VPC access on the same node in a container cloud cluster. The traffic forwarding process of cross-VPC traffic on the same node in a container cloud cluster is as follows:

[0109] 1. The source Pod first initiates a gateway mac request to obtain the gateway mac address.

[0110] 2. The traffic from the source Pod to the destination Pod reaches the eBPF program on the associated network card;

[0111] 3. The eBPF program parses the message header to obtain the five-tuple information;

[0112] 4. The eBPF program uses the source IP and destination IP as keys to search the bpf map;

[0113] 6. Confirm the map entry data corresponding to the source IP and the destination IP. If the data exists, compare the vpcid information of the two. If they are different, check whether a multi-vpc peer connection has been created. If not, discard it directly. If a multi-vpc peer connection has been created, forward the traffic to the network card corresponding to the destination Pod.

[0114] Reference Figure 5 Container cloud cluster cross-node cross-VPC access traffic diagram. The container cloud cluster cross-node cross-VPC traffic forwarding process is as follows:

[0115] 1. The source Pod first initiates a gateway mac request to obtain the gateway mac address.

[0116] 2. The traffic from the source Pod to the destination Pod reaches the eBPF program on the associated network card;

[0117] 3. The eBPF program parses the message header to obtain the five-tuple information;

[0118] 4. The eBPF program uses the source IP and destination IP as keys to search the bpf map.

[0119] 7. Confirm the map entry data corresponding to the source IP and destination IP. If the map entry data corresponding to the destination IP does not exist, forward the traffic to the physical network card corresponding to the parentindex id in the map entry corresponding to the source IP.

[0120] 8. If the underlying Underlay network or SDN Overlay network has not created a vpc peer connection, the underlying Underlay network or SDN Overlay network will directly discard the traffic. If a vpc peer connection exists, continue;

[0121] 9. When the traffic reaches the eBPF program of the destination node network card, the ebPF program node checks whether there is a Pod network card corresponding to the destination IP. If so, it is directly forwarded to the corresponding Pod network card.

[0122] Those of ordinary skill in the art will appreciate that the units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0123] In the several embodiments provided in the present application, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the division of the units described above is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. The above-mentioned units may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of the present invention.

[0124] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein by equivalents. These modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be included in the scope of the claims and specification of the present invention.

[0125] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. The implementation method of multi-vpc container network based on eBPF is characterized in that: include: Basic deployment of container cluster: deploy peregrine-agent pod, peregrine-cni plug-in and peregrine-controller pod to ensure unified management and control of network traffic of each node in the cluster; Traffic forwarding in the same node, VPC and subnet: The eBPF program is used to parse the five-tuple information and search the bpf map to ensure that Pods in the same node, VPC and subnet can communicate efficiently and with low latency. Traffic forwarding across subnets in the same VPC on the same node: The eBPF program is used to check the bpf map and multi-VPC peering connections to ensure VPC isolation and connectivity during cross-subnet communication within the same node; Traffic forwarding across VPCs on the same node: eBPF programs are used to check multi-VPC peer connections to ensure that Pod communication across VPCs on the same node is carried out in the presence of peer connections, thereby enhancing isolation and security. Cross-node and cross-VPC traffic forwarding: Traffic is forwarded through the eBPF program combined with the underlying network, and the VPC peer connection is verified on the destination node to ensure the secure and correct forwarding of cross-node and cross-VPC traffic.

2. The method for implementing a multi-vpc container network based on eBPF according to claim 1, characterized in that: The basic deployment of the container cluster includes: Deploy the peregrine-agent pod and peregrine-cni plugin in the container cluster to ensure that each node can manage and monitor network traffic; At the same time, by deploying the peregrine-controller pod to centrally manage network policies on the control node, a basic network environment and control mechanism are provided for traffic forwarding in the container cluster, ensuring that network communication between nodes in the cluster can be managed through a unified network plane. The specific steps are: Run the peregrine-agent pod on each node in the container cluster to manage and monitor the node's network traffic; Store the peregrine-cni binary executable file in the / opt / cni / bin / directory of each node to ensure that the network plug-in can work properly; Deploy the peregrine-controller pod on the cluster controller node to centrally manage network traffic rules and policies within the cluster.

3. The method for implementing a multi-vpc container network based on eBPF according to claim 1, characterized in that: In the same-node, same-VPC, and same-Subnet traffic forwarding, the following are included: When Pods in the same node, VPC, and subnet communicate with each other, the eBPF program parses the five-tuple information of the traffic message, quickly finds the corresponding entry in the bpf map, and directly forwards the traffic to the destination Pod; The specific steps are: The access traffic of the source Pod first reaches the eBPF program on the associated network card; The eBPF program parses the message header to obtain five-tuple information, which includes: source IP, destination IP, protocol, source port, and destination port; The eBPF program uses the source IP and destination IP as keys to find the corresponding entry in the bpf map; If the bpf map entries for both the source IP and the destination IP exist and their vpcid information is the same, the eBPF program forwards the traffic directly to the network card corresponding to the destination Pod.

4. The method for implementing a multi-vpc container network based on eBPF according to claim 1, characterized in that: In the cross-subnet traffic forwarding in the same node and the same VPC, the following is included: When Pods in the same node need to communicate across subnets, the eBPF program determines whether to check multi-VPC peer connections by looking up the bpf map and verifying the VPC information, thereby controlling cross-subnet communication. The specific steps are: The source Pod first initiates a gateway MAC request to obtain the gateway MAC address; The traffic from the source Pod reaches the eBPF program, which parses the message header to obtain the five-tuple information. The eBPF program uses the source IP and destination IP as keys to find the corresponding entry in the bpf map; If the bpf map entries for both the source and destination IPs exist but their vpcid information is different, the eBPF program checks whether a multi-VPC peering connection is created, where: If no peer connection is established, the traffic is directly discarded; If a peer connection has been established, the traffic is forwarded to the network card corresponding to the destination Pod.

5. The method for implementing a multi-vpc container network based on eBPF according to claim 1, characterized in that: In the same-node cross-VPC traffic forwarding, the following steps are included: For Pod communication across VPCs within the same node, the eBPF program checks multi-VPC peering connections to ensure that traffic forwarding between different VPCs is only performed when peering connections exist, to prevent unauthorized cross-VPC communication; The specific steps are: The source Pod first initiates a gateway MAC request to obtain the gateway MAC address; The traffic from the source Pod reaches the eBPF program, which parses the message header to obtain the five-tuple information. The eBPF program uses the source IP and destination IP as keys to find the corresponding entry in the bpf map; If the bpf map entries for both the source and destination IPs exist but their vpcid information is different, the eBPF program checks whether a multi-VPC peering connection is created, where: If no peer connection is established, the traffic is directly discarded; If a peer connection has been established, the traffic is forwarded to the network card corresponding to the destination Pod.

6. The method for implementing a multi-vpc container network based on eBPF according to claim 1, characterized in that: The cross-node and cross-VPC traffic forwarding includes: When traffic needs to communicate across nodes and VPCs, the eBPF program forwards the traffic through the underlying network and verifies the existence of the VPC peer connection and the destination Pod again on the destination node to ensure that the traffic can reach the destination Pod safely and correctly. The specific steps are: The source Pod first initiates a gateway MAC request to obtain the gateway MAC address; The traffic from the source Pod reaches the eBPF program, which parses the message header to obtain the five-tuple information. The eBPF program uses the source IP and destination IP as keys to find the corresponding entry in the bpf map. If the bpf map entry corresponding to the destination IP does not exist, the traffic will be forwarded to the physical network card corresponding to the parentindex id in the bpf map entry corresponding to the source IP. Traffic passes through the underlying underlay network or SDN overlay network; If a VPC peering connection is not created, the traffic is directly discarded in the underlying network; If a VPC peering connection has been created, traffic continues to be forwarded to the eBPF program on the destination node network card; The eBPF program of the destination node checks whether the Pod network card corresponding to the destination IP exists. If so, the traffic is forwarded directly to the corresponding Pod network card.

7. A system for a multi-vpc container network based on eBPF, according to the implementation method of a multi-vpc container network based on eBPF according to any one of claims 1-6, characterized in that: include: peregrine-cni, as the CNI network configuration interface in the container cloud network, is responsible for the initialization configuration of the Pod network in the container cloud, including network card initialization configuration, IP address configuration, and routing configuration; Peregrine-controller, as the core component in implementing container cloud network, is responsible for overall resource monitoring and control of cluster-level resources, such as global peregrine-endpoint CRD resource processing and Pod-related resource processing; peregrine-agent, as a core component in implementing container cloud networks, is responsible for maintaining VPC eBPF maps information and mounting eBPF programs for multi-VPC IPv4 / IPv6 dual-stack forwarding on Pod network cards.

8. An electronic device, comprising a processor and a memory connected to the processor for storing instructions executable by the processor, characterized in that: The processor is used to execute the implementation method of the eBPF-based multi-vpc container network described in any one of claims 1-6 above.

9. A server, characterized in that: It includes at least one processor and a memory communicatively connected to the processor, wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor so that the at least one processor executes the implementation method of a multi-vpc container network based on eBPF as described in any one of claims 1-6.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for implementing a multi-vpc container network based on eBPF as described in any one of claims 1 to 6 is implemented.

Images