A network policy implementation apparatus, method, storage medium, and electronic device

Abstract

The present application belongs to the technical field of cloud native Kubernetes container platform, and particularly relates to a network policy implementation device, method, storage medium and electronic equipment. The network policy implementation device comprises connected identification module and control module; the identification module comprises CNI component compatible library and network mode compatible library; the control module comprises sequentially connected storage unit, processing unit, execution unit and issuing unit; the CNI component compatible library pre-collects CNI information, is equipped with corresponding network mode, and identifies virtual network card information corresponding to a Pod; the network mode compatible library identifies the network mode of a user self-developed CNI plug-in, and identifies virtual network card information corresponding to a Pod; the storage unit performs persistent storage on the virtual network card information, and establishes a network device label; the processing unit compiles eBPF program code for the virtual network card type into an adaptive binary file; the execution unit calls the file to be loaded into a corresponding virtual network card; and the issuing unit converts a network policy created by a user and issues it to an operating system kernel.

Description

Technical Field

[0001] This invention belongs to the field of cloud-native Kubernetes container platform technology, specifically relating to a network policy implementation device, method, storage medium, and electronic device. Background Technology

[0002] Throughout the history of computer development, computing, storage, and networking remain three enduring topics. Whether computer applications have evolved from monolithic architectures to SOA architectures, then to microservice architectures, and finally to the current cloud-native architectures, computing, storage, and networking have always been integral parts of the process.

[0003] As a mature and mainstream container orchestration platform in the industry, Kubernetes still provides computing, storage, and networking resources for the various applications running on it. With the aim of decoupling the platform, the Kubernetes development team abstracted three standards: CRI, CSI, and CNI, to facilitate integration with various runtime, storage, and networking solutions in the open-source community.

[0004] In terms of networking, CNI's basic mission is to weave a container network for Pods, assign IP addresses to Pods, and facilitate communication between Pods on the same host and across nodes. Advanced features include Pod traffic control and network policies.

[0005] The Kubernetes control plane component kube-proxy implements Service resources through the Netfilter subsystem. Similarly, some CNI components also implement network policy functionality through the Netfilter subsystem, with Calico being a prime example from the open-source community, thanks to its network architecture pattern. However, CNI components using a different network architecture pattern cannot interfere with access between their Pods through the Netfilter subsystem and therefore cannot implement network policy functionality; Flannel is a representative example of this.

[0006] eBPF is an extension of classic BPF that exposes a series of hooks in the computer kernel. This allows non-kernel developers to inject code into these hooks using programs written in various languages, thereby gaining control of the kernel. Networking is one use case for eBPF. The CNI component Cilium has implemented Kubernetes Service functionality using eBPF programs. Furthermore, because eBPF intervenes earlier than the Netfilter subsystem, its performance is significantly improved. Summary of the Invention

[0007] The purpose of this invention is to provide a network policy implementation device, method, storage medium, and electronic device. By injecting network policy-related programs into the kernel through eBPF, the problem of the Netfilter subsystem being ineffective due to differences in the network architecture mode of some CNI components is solved. This allows CNI components that originally could not implement network policies to achieve the same network policy function by adding a non-intrusive network policy implementation device based on eBPF.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: The first aspect of this invention provides a network policy implementation device, including an identification module and a control module connected together; the identification module includes a CNI component compatibility library and a network mode compatibility library; the control module includes a storage unit, a processing unit, an execution unit, and a distribution unit connected in sequence; the CNI component compatibility library and the network mode compatibility library are respectively connected to the storage unit; The CNI component compatibility library is used to pre-collect and record information on major CNI vendors in the open-source community, and is equipped with corresponding network modes to identify the virtual network interface information corresponding to the Pod. A network mode compatibility library is used to identify the network mode used by user-developed CNI plugins in order to identify the virtual network interface information corresponding to the Pod. The storage unit is used to persistently store virtual network interface card information and establish network device tags to provide an entry point for loading eBPF programs. The processing unit is used to compile eBPF program code for virtual network interface card types into adapted binary files; An execution unit is used to call the binary file and load it into the corresponding virtual network interface card; The distribution unit is used to convert user-created network policies into parameter entries that can be recognized by the eBPF program, and then distribute them to the operating system kernel via a map method.

[0009] As a preferred option, the processing unit compiles the eBPF program code for the virtual network interface card type into an adapted binary file according to the host machine's operating system version and CPU architecture type.

[0010] A second aspect of this invention provides a method for implementing a network policy, based on a network policy implementation apparatus provided in the first aspect of this invention, comprising the following steps: S1. Deploy the network policy implementation device in a Kubernetes cluster; S2. Select and install the CNI network plugin in the Kubernetes cluster based on the received information; S3. Add the network policy implementation device to the CNI processing chain; S4. Create a Pod in the cluster and create a virtual network interface card for the Pod. After creating the virtual network interface card required by the Pod, call the created virtual network interface card to the network policy implementation device. S5. The network policy implementation device identifies the virtual network card information corresponding to the Pod; S6. The network policy implementation device persistently stores the virtual network card information and establishes network device tags to provide an entry point for loading the eBPF program. S7. The network policy implementation device compiles the eBPF program code for the virtual network card type into an adapted binary file. S8. The network policy implementation device calls the eBPF program binary file and loads it into the corresponding virtual network card; S9. Based on the received network policy information created in the Kubernetes cluster, the network policy implementation device converts the network policy into parameter entries that the eBPF program can recognize, and sends them to the operating system kernel via a map method. S10. When Pods in the cluster initiate network communication, the data packets flow through the network card in the operating system kernel, triggering the hooks registered by the eBPF program. eBPF filters whether there are any matching network data packets through the parameter entries recorded in the map, and then allows or discards the data packets according to the behavior in the entries.

[0011] As a preferred option, in step S2, the network mode is specified when installing the CNI plugin.

[0012] As a preferred option, in step S3, the name of the network policy implementation device is added to the plugin list of the CNI configuration file of each node, so that the device can be added to the CNI processing chain.

[0013] As a preferred option, in step S4, the step of creating a virtual network interface for the Pod is as follows: the Kubernetes control plane executes according to the original Pod lifecycle process, and the Kubelet calls the original CNI component to create a virtual network interface for the Pod.

[0014] As a preferred option, in step S4, Kubelet calls the existing CNI components to create virtual network interfaces for the Pod in a chained sequence.

[0015] As a preferred option, in step S4, the created virtual network card is invoked to the network policy implementation device by the CNI's chained call mechanism.

[0016] As a preferred option, in step S7, the network policy implementation device compiles the eBPF program code for the virtual network card type into an adapted binary file according to the host machine's operating system version and CPU architecture type.

[0017] As a preferred embodiment, step S8 is followed by the following steps: Based on the received information about deleting network policies in the Kubernetes cluster, the network policy implementation device converts the network policy into parameter entries that the eBPF program can recognize, and searches for the original related parameter entries in the map. If they are found, they are deleted to restore the original packet flow behavior.

[0018] A third aspect of the present invention provides a computer-readable storage medium storing computer instructions for causing the computer to perform a network policy implementation method as described in the second aspect and any one of the second aspects of the present invention.

[0019] A fourth aspect of the present invention provides an electronic device, including: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform a network strategy implementation method as described in the second aspect and any one of the second aspects of the present invention.

[0020] The beneficial effects of this invention are: 1. CNI components that originally could not implement network policies can also implement network policy functions by adding a network policy implementation device. Moreover, the device operates in a hot-swappable manner without modifying the original CNI component's code. It can be used without replacing the existing Kubernetes cluster CNI components, and there is no need to worry about the impact of network mode on the running effect.

[0021] 2. The network policy implementation device is compatible with a variety of CNI components, including mainstream open-source CNI components and self-developed CNI components, and can be used to achieve the desired effect.

[0022] 3. By adding network policy, the device can achieve the purpose of network policy function without relying on the Netfilter subsystem. This avoids the inefficiency of the Netfilter subsystem caused by too many Iptables rules, and also avoids the Netfilter subsystem from failing due to certain network modes, thus making the network policy ineffective. Attached Figure Description

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

[0024] Figure 1 This is a schematic diagram of the internal modules of a network strategy implementation device.

[0025] Figure 2 This is an internal workflow diagram of a network strategy implementation device.

[0026] Figure 3 This is a flowchart of a network strategy implementation method according to the present invention.

[0027] Figure 4 This is a schematic diagram illustrating the interactions between the components of a Kubernetes cluster equipped with network policy implementation devices.

[0028] Figure 5 This is a schematic diagram of the structure of a computer-readable storage medium provided according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present invention. Detailed Implementation

[0029] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0030] Example 1: Reference Figure 1 As shown, a network strategy implementation device includes an identification module and a control module connected together; the identification module includes a CNI component compatibility library and a network mode compatibility library; the control module includes a storage unit, a processing unit, an execution unit, and a distribution unit connected in sequence; the CNI component compatibility library and the network mode compatibility library are respectively connected to the storage unit; The CNI component compatibility library is used to pre-collect and record information on major CNI vendors in the open-source community, and is equipped with corresponding network modes to identify the virtual network interface information corresponding to the Pod. A network mode compatibility library is used to identify the network mode used by user-developed CNI plugins in order to identify the virtual network interface information corresponding to the Pod. The storage unit is used to persistently store virtual network interface card information and establish network device tags to provide an entry point for loading eBPF programs. The processing unit is used to compile eBPF program code for virtual network interface card types into adapted binary files; An execution unit is used to call the binary file and load it into the corresponding virtual network interface card; The distribution unit is used to convert user-created network policies into parameter entries that can be recognized by the eBPF program, and then distribute them to the operating system kernel via a map method.

[0031] Furthermore, in the processing unit, the eBPF program code for the virtual network interface card type is compiled into an adapted binary file according to the host machine's operating system version and CPU architecture type.

[0032] Reference Figure 2 As shown, when this device is invoked to implement the network policy function of the CNI component, the matching network mode is obtained from the corresponding data adapter library in the identification module according to the type of CNI plugin, so as to identify the virtual network card information corresponding to the Pod and transmit the virtual network card information to the control module.

[0033] The control module's storage unit persistently stores virtual network interface card (NIC) information and establishes network device tags to provide an entry point for loading the eBPF program; the processing unit compiles the eBPF program code for the virtual NIC type into an adapted binary file; the execution unit calls the eBPF program binary file and loads it into the corresponding virtual NIC; the distribution unit converts the user-created network policy into parameter entries that the eBPF program can recognize and distributes them to the operating system kernel via a map method to achieve network policy conversion.

[0034] In this embodiment, the network policy implementation device is compatible with a variety of CNI components. Whether it is a mainstream CNI component from the open-source community or a self-developed CNI component, it can be used to achieve the desired effect.

[0035] Because this device extracts individual functions into separate modules, there is no need to redesign and implement network strategies when developing CNI components; the device can be used directly. If a CNI plugin was originally selected for some reason but did not implement the network strategy function, and this function is still required, this device can be used to achieve it.

[0036] Example 2: Reference Figure 3 As shown, this embodiment provides a network policy implementation method, including the following steps: S1. Deploy the network policy implementation device in a Kubernetes cluster; S2. Select and install the CNI network plugin in the Kubernetes cluster based on the received information; S3. Add the network policy implementation device to the CNI processing chain; S4. Create a Pod in the cluster and create a virtual network interface card for the Pod. After creating the virtual network interface card required by the Pod, call the created virtual network interface card to the network policy implementation device. S5. The network policy implementation device identifies the virtual network card information corresponding to the Pod; S6. The network policy implementation device persistently stores the virtual network card information and establishes network device tags to provide an entry point for loading the eBPF program. S7. The network policy implementation device compiles the eBPF program code for the virtual network card type into an adapted binary file. S8. The network policy implementation device calls the eBPF program binary file and loads it into the corresponding virtual network card; S9. Based on the received network policy information created in the Kubernetes cluster, the network policy implementation device converts the network policy into parameter entries that the eBPF program can recognize, and sends them to the operating system kernel via a map method. S10. When Pods in the cluster initiate network communication, the data packets flow through the network card in the operating system kernel, triggering the hooks registered by the eBPF program. eBPF filters whether there are any matching network data packets through the parameter entries recorded in the map, and then allows or discards the data packets according to the behavior in the entries.

[0037] Furthermore, in step S1, the network policy implementation device coexists with the existing CNI components of the Kubernetes cluster. The device operates in a hot-swappable manner, achieving compatibility with multiple types of CNI components and multiple versions of the same type of CNI component without modifying the code of the existing CNI components in the Kubernetes cluster. The network policy implementation device can be used without replacing the existing Kubernetes cluster CNI components, and there is no need to worry about network mode affecting operational performance. Furthermore, in step S2, users can select and install CNI network plugins in the Kubernetes cluster according to their own needs, and specify the network mode, such as host-gateway, vxlan, IPIP, etc., when installing CNI plugins.

[0038] In step S3, the name of the network policy implementation device is added to the plugin list of the CNI configuration file of each node, so that the device can be added to the CNI processing chain.

[0039] In step S4, the steps for creating a virtual network interface for the Pod are as follows: The Kubernetes control plane executes according to the original Pod lifecycle flow, and the Kubelet calls the original CNI components to create the virtual network interface for the Pod. In step S4, the Kubelet calls the original CNI components in a chained sequence to create the virtual network interface for the Pod.

[0040] In step S7, the network policy implementation device compiles the eBPF program code for the virtual network card type into an adapted binary file according to the host machine's operating system version and CPU architecture type.

[0041] Step S8 is followed by the following steps: When a user deletes a network policy in a Kubernetes cluster, the network policy implementation device converts the network policy into parameter entries that the eBPF program can recognize based on the received information about deleting the network policy in the Kubernetes cluster. It then searches for the original related parameter entries in the map. If they are found, they are deleted to restore the original packet flow behavior.

[0042] More specifically: The diagram illustrates the interactions between the components of a Kubernetes cluster with added network policy implementation devices, refer to [reference needed]. Figure 4 As shown.

[0043] Among them, apiserver is a component in the Kubernetes control plane, which is used to expose the management interface for adding, deleting, modifying and querying various resources in Kubernetes. In the network policy implementation method described in this embodiment, it is mainly used to monitor changes in network policy resources. Kubelet is also a component in the Kubernetes control plane, distributed across nodes of various Kubernetes components. One of its functions is to manage the lifecycle of Pods. In the network policy implementation method described in this embodiment, it is used to perform chained calls to CNI components. CNI is a set of interfaces used by Kubelet to manage container networks. Components that implement this set of interfaces weave networks for containers through network patterns formed by various network devices such as bridge, veth, and vxlan.

[0044] By adding network policy implementation devices, the purpose of network policy functions can be achieved without relying on the Netfilter subsystem. This avoids the inefficiency of the Netfilter subsystem caused by too many Iptables rules, and also avoids the Netfilter subsystem from failing due to certain network modes, thus rendering the network policy ineffective.

[0045] The specific experimental procedure is as follows: Prepare two virtual machines configured with 8 cores / 16 gigabytes of RAM and a Linux operating system kernel of 4.19 or higher. Deploy a Kubernetes cluster, with one machine as the master node and the other as a worker node. Use Flannel, which does not support network policies, as the CNI component for the cluster.

[0046] Modify the ` / etc / cni / net.d / 10-flannel.conflist` file on both host machines to enable the network policy device as follows. { "name": "flannel", "cniVersion": "0.3.1", "plugins": [ { "type": "flannel", "delegate": { "hairpinMode": true, "isDefaultGateway": true } }, { "type": "portmap", "capabilities": { "portMappings": true } }, { "type": "cubecni } ] } Create two namespaces, ns-1 and ns-2, and create a workload mirrored from nginx:latest in each namespace.

[0047] Accessing the workload of ns-2 from the workload container group of ns-1 showed that it could be accessed normally.

[0048] Create a network policy resource with the resource manifest shown below, which means to prohibit all traffic from entering the container group in the ns-2 namespace.

[0049] apiVersion: networking.k8s.io / v1 kind: NetworkPolicy metadata: name: ingress namespace: ns-2 spec: podSelector: {} policyTypes: - Ingress When you re-enter the workload container group of ns-1 to access the workload of ns-2, the workload of ns-2 cannot be accessed at this time.

[0050] After deleting the above network policy, access the workload of ns-2 from the workload container group of ns-1. At this time, the workload of ns-2 is restored to normal access.

[0051] Example 3: Reference Figure 5 As shown, this embodiment of the invention also provides a storage medium storing a computer program 601. When executed by a processor, this program implements the steps of a network policy implementation method in Embodiment 2 described above. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes as described in Embodiment 2.

[0052] The storage medium may be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium may also include combinations of the above types of memory.

[0053] Example 4: Reference Figure 6 As shown, this embodiment of the invention also provides an electronic device, which may include a processor 51 and a memory 52, wherein the processor 51 and the memory 52 can be connected via a bus or other means. Figure 5 Taking the example of a connection between China and Israel via a bus.

[0054] Processor 51 can be a central processing unit (CPU). Processor 51 can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0055] The memory 52, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the corresponding program instructions / modules in the embodiments of the present invention. The processor 51 executes various functional applications and data processing of the processor by running the non-transitory software programs, instructions, and modules stored in the memory 52, thereby implementing a network strategy implementation method in the second embodiment described above.

[0056] The memory 52 may include a program storage area and a data storage area. The program storage area may store applications required for operating the device and at least one function; the data storage area may store data created by the processor 51, etc. Furthermore, the memory 52 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 52 may optionally include memory remotely located relative to the processor 51, and these remote memories may be connected to the processor 51 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0057] The one or more modules are stored in the memory 52, and when executed by the processor 51, they execute a network strategy implementation method as described in Embodiment 2.

[0058] The specific details of the above-mentioned electronic device can be understood by referring to the relevant descriptions and effects in Embodiment 2, and will not be repeated here.

[0059] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope of the present invention.

Claims

1. A network strategy implementation apparatus, characterized in that, It includes a connected identification module and a control module; the identification module includes a CNI component compatibility library and a network mode compatibility library; the control module includes a storage unit, a processing unit, an execution unit, and a distribution unit connected in sequence. The CNI component compatibility library and the network mode compatibility library are connected to the storage unit respectively; The CNI component compatibility library is used to pre-collect and record information on major CNI vendors in the open-source community, and is equipped with corresponding network modes to identify the virtual network interface information corresponding to the Pod. A network mode compatibility library is used to identify the network mode used by user-developed CNI plugins in order to identify the virtual network interface information corresponding to the Pod. The storage unit is used to persistently store virtual network interface card information and establish network device tags to provide an entry point for loading eBPF programs. The processing unit is used to compile eBPF program code for virtual network interface card types into adapted binary files; An execution unit is used to call the binary file and load it into the corresponding virtual network interface card; The distribution unit is used to convert user-created network policies into parameter entries that can be recognized by the eBPF program, and distribute them to the operating system kernel via a map method; The network policy implementation device coexists with the original CNI components of the Kubernetes cluster and operates in a hot-swappable manner.

2. The network policy implementation device according to claim 1, characterized in that, In the processing unit, the eBPF program code for the virtual network interface card type is compiled into an adapted binary file according to the host machine's operating system version and CPU architecture type.

3. A method for implementing a network strategy, based on the network strategy implementation apparatus according to any one of claims 1-2, characterized in that, Includes the following steps: S1. Deploy the network policy implementation device in a Kubernetes cluster; S2. Select and install the CNI network plugin in the Kubernetes cluster based on the received information; S3. Add the network policy implementation device to the CNI processing chain; S4. Create a Pod in the cluster and create a virtual network interface card for the Pod. After creating the virtual network interface card required by the Pod, call the created virtual network interface card to the network policy implementation device. S5. The network policy implementation device identifies the virtual network card information corresponding to the Pod; S6. The network policy implementation device persistently stores the virtual network card information and establishes network device tags to provide an entry point for loading the eBPF program. S7. The network policy implementation device compiles the eBPF program code for the virtual network card type into an adapted binary file. S8. The network policy implementation device calls the eBPF program binary file and loads it into the corresponding virtual network card; S9. Based on the received network policy information created in the Kubernetes cluster, the network policy implementation device converts the network policy into parameter entries that the eBPF program can recognize, and sends them to the operating system kernel via a map method. S10. When Pods in the cluster initiate network communication, the data packets flow through the network card in the operating system kernel, triggering the hooks registered by the eBPF program. eBPF filters whether there are any matching network data packets through the parameter entries recorded in the map, and then allows or discards the data packets according to the behavior in the entries.

4. The network strategy implementation method according to claim 3, characterized in that, In step S2, the network mode is specified when installing the CNI plugin.

5. A network strategy implementation method according to claim 3, characterized in that, In step S3, the name of the network policy implementation device is added to the plugin list of the CNI configuration file of each node, so that the device can be added to the CNI processing chain.

6. A network strategy implementation method according to claim 3, characterized in that, In step S4, the steps for creating a virtual network interface for the Pod are as follows: the Kubernetes control plane executes according to the original Pod lifecycle process, and the Kubelet calls the original CNI component to create a virtual network interface for the Pod.

7. A network strategy implementation method according to claim 6, characterized in that, In step S4, Kubelet calls the existing CNI components to create virtual network interfaces for the Pod in a chained order.

8. A network strategy implementation method according to claim 3, characterized in that, In step S4, the created virtual network card is invoked to the network policy implementation device by the CNI's chained call mechanism.

9. A network strategy implementation method according to claim 3, characterized in that, In step S7, the network policy implementation device compiles the eBPF program code for the virtual network card type into an adapted binary file according to the host machine's operating system version and CPU architecture type.

10. A network strategy implementation method according to claim 3, characterized in that, Step S8 is followed by the following steps: Based on the received information about deleting network policies in the Kubernetes cluster, the network policy implementation device converts the network policy into parameter entries that the eBPF program can recognize, and searches for the original related parameter entries in the map. If they are found, they are deleted to restore the original packet flow behavior.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute a network policy implementation method as described in any one of claims 3-10.

12. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform a network strategy implementation method as described in any one of claims 3-10.

Images