A containerized virtual network element service function chain construction method, device, equipment and medium

Abstract

The present application relates to a method, device, computer equipment and storage medium for constructing a containerized virtual network element service function chain. The method includes: constructing a cloud-native NFV platform, wherein the VNF constructs the network function implemented by itself as a container image, and starts in the Pod when instantiated. When the SFC construction module receives the SFC establishment request, the resource list file for establishing the Pod is obtained through the VNF template module according to the variable definition information in the SFC establishment request, and submitted to the Kubernetes platform for Pod establishment and initialization configuration, and the instantiation of the VNF is completed according to the SFC template module to obtain a newly created containerized virtual network element service function chain; wherein the established Pod is configured with multiple network ports. The container network mechanism based on multiple network ports of the present invention can meet the diverse software VNF implementation needs and can be well adapted to the existing software VNF.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, apparatus, computer equipment and storage medium for constructing a containerized virtual network element service function chain. Background Art

[0002] With the development of network technology, the complexity of the network itself is increasing. In recent years, cloud computing, mobile communications, and the Internet of Things have been rapidly promoted, and the demand for dynamic deployment and automatic orchestration of network functions has been growing. Network Function Virtualization (NFV) is based on virtualization technology to achieve software and hardware separation, deploy software-based virtualized network functions (VNF) on a general hardware platform, and provide centralized control and automatic orchestration capabilities.

[0003] Network building strategies usually require linking multiple VNFs together as a whole service function chain (SFC) to implement specific network functions. In a typical network service deployment scenario, a data flow needs to pass through multiple network function devices, such as firewalls, load balancers, and intrusion detection systems.

[0004] Traditional NFV platforms usually use virtual machine cloud platforms, such as OpenStack and VMware, to orchestrate and manage VNFs based on virtual machines. However, virtual machines have problems such as slow startup, high loss, and difficulty in expansion. In order to reduce resource virtualization overhead and improve flexibility, container-based cloud native technology has emerged. However, building NFVI and VNF based on cloud native technology still faces problems such as different environments and incomplete ecosystems, and its specific functions cannot meet the needs of actual applications. Summary of the invention

[0005] Based on this, it is necessary to provide a containerized virtual network element service function chain construction method, device, computer equipment and storage medium that can improve the functions of the cloud native platform in response to the above technical problems.

[0006] A method for constructing a containerized virtual network element service function chain, the method comprising:

[0007] A cloud-native NFV platform is constructed; the cloud-native NFV platform includes an NFVI module, an NFV MANO module and a VNF module; the NFVI module is constructed based on a Kubernetes platform, the NFV MANO module includes an SFC manager; the SFC manager includes a VNF template module, an SFC template module and an SFC construction module; a VNF is run in the VNF module, and the VNF instance constructs the network function implemented by itself as a container image, and is started in a Pod when instantiated;

[0008] When the SFC construction module receives the SFC establishment request, the VNF template module obtains a resource list file for establishing a Pod according to the variable definition information in the SFC establishment request, submits the resource list file for establishing the Pod to the Kubernetes platform for Pod establishment and initialization configuration, completes the instantiation of the VNF according to the SFC template module, and obtains a newly created containerized virtual network element service function chain; wherein the established Pod is configured with multiple network ports;

[0009] The newly created containerized virtual network element service function chain is managed in state, and the state data is stored in a database.

[0010] In one of the embodiments, it also includes: obtaining a resource list file for establishing a Pod according to the variable definition information in the SFC establishment request through the VNF template module; the variable definition information includes a VNFD list and parameter values.

[0011] In one of the embodiments, it also includes: specifying the number of multiple network ports as n through a Pod custom annotation mechanism;

[0012] When submitting the resource list file for establishing the Pod to the Kubernetes platform, calling the network controller through the event registration mechanism of the Core API;

[0013] The network controller creates a corresponding number of logical switch ports on OVN according to the number of the multiple network ports, and the OVN returns the mac address of the logical switch port and determines the implicit naming of the logical switch port;

[0014] Adding multiple network port mac address annotations according to the logical switch port mac address by the network controller;

[0015] When the Kubernetes platform calls the container network initialization interface, the network controller obtains a list of multiple network ports to be initialized according to the multiple network port mac address annotations;

[0016] The n virtual network ports required by the Pod are created in sequence through the network controller.

[0017] In one of the embodiments, it further includes: generating an implicit network port name according to the name of the currently created Pod and the network port sequence number, and creating a corresponding veth;

[0018] Add one end of the veth pair to the OVS of the physical node, and the other end to the network Namespace of the current Pod;

[0019] Disable veth TX offloading;

[0020] Bind the network port in the OVS to the logical switch port in the OVN;

[0021] Modify the virtual network port MAC address and maximum transmission unit configuration information.

[0022] In one of the embodiments, the method further includes: when the SFC construction module receives an SFC destruction request, releasing resources of the SFC and updating the status of the SFC in the database.

[0023] In one of the embodiments, the method further includes: when releasing the resources of the SFC, destroying the multiple network ports of the corresponding Pod.

[0024] In one of the embodiments, the further step includes: generating a Pod deletion request through the Kubernetes platform, and the network controller responding to the Pod deletion request;

[0025] Calling the OVN logical switch port destruction interface through the network controller;

[0026] Responding to a network resource release request by the network controller;

[0027] Read the annotation information of the corresponding Pod through the network controller, obtain the multi-network port information from the annotation information, and call to delete the network ports in sequence;

[0028] Delete the port and configuration of veth from the host OVS;

[0029] Delete veth.

[0030] A containerized virtual network element service function chain construction device, the device comprising:

[0031] A cloud-native NFV platform construction module is used to construct a cloud-native NFV platform; the cloud-native NFV platform includes an NFVI module, an NFV MANO module and a VNF module; the NFVI module is constructed based on the Kubernetes platform, the NFV MANO module includes an SFC manager; the SFC manager includes a VNF template module, an SFC template module and an SFC construction module; the VNF runs in the VNF module, and the VNF constructs the network function implemented by itself as a container image, which is started in a Pod when instantiated;

[0032] The SFC establishment module is used for obtaining a resource list file for establishing a Pod according to the variable definition information in the SFC establishment request through the VNF template module when the SFC construction module receives the SFC establishment request, submitting the resource list file for establishing the Pod to the Kubernetes platform for Pod establishment and initialization configuration, completing the instantiation of the VNF according to the SFC template module, and obtaining a newly created containerized virtual network element service function chain; wherein the established Pod is a multi-network port;

[0033] The state management module is used to manage the state of the newly created containerized virtual network element service function chain and store the state data in a database.

[0034] A computer device comprises a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0035] A cloud-native NFV platform is constructed; the cloud-native NFV platform includes an NFVI module, an NFV MANO module and a VNF module; the NFVI module is constructed based on a Kubernetes platform, the NFV MANO module includes an SFC manager; the SFC manager includes a VNF template module, an SFC template module and an SFC construction module; a VNF is run in the VNF module, and the VNF constructs the network function implemented by itself as a container image, and is started in a Pod when instantiated;

[0036] When the SFC construction module receives the SFC establishment request, the VNF template module obtains a resource list file for establishing a Pod according to the variable definition information in the SFC establishment request, submits the resource list file for establishing the Pod to the Kubernetes platform for Pod establishment and initialization configuration, completes the instantiation of the VNF according to the SFC template module, and obtains a newly created containerized virtual network element service function chain; wherein the established Pod is configured with multiple network ports;

[0037] The newly created containerized virtual network element service function chain is managed in state, and the state data is stored in a database.

[0038] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the following steps:

[0039] A cloud-native NFV platform is constructed; the cloud-native NFV platform includes an NFVI module, an NFV MANO module and a VNF module; the NFVI module is constructed based on a Kubernetes platform, the NFV MANO module includes an SFC manager; the SFC manager includes a VNF template module, an SFC template module and an SFC construction module; a VNF is run in the VNF module, and the VNF instance constructs the network function implemented by itself as a container image, and is started in a Pod when instantiated;

[0040] When the SFC construction module receives the SFC establishment request, the VNF template module obtains a resource list file for establishing a Pod according to the variable definition information in the SFC establishment request, submits the resource list file for establishing the Pod to the Kubernetes platform for Pod establishment and initialization configuration, completes the instantiation of the VNF according to the SFC template module, and obtains a newly created containerized virtual network element service function chain; wherein the established Pod is configured with multiple network ports;

[0041] The newly created containerized virtual network element service function chain is managed in state, and the state data is stored in a database.

[0042] The above containerized virtual network element service function chain construction method, device, computer equipment and storage medium build NFVI based on Kubernetes platform, and the cloud native NFV platform is composed of NFVI, NFV MANO and VNF, wherein VNF constructs the network function implemented by itself as a container image, and starts in the Pod when instantiated. When the SFC construction module receives the SFC establishment request, the VNF template module obtains the resource list file for establishing the Pod according to the variable definition information in the SFC establishment request, and submits the resource list file for establishing the Pod to the Kubernetes platform for Pod establishment and initialization configuration, and completes the instantiation of VNF according to the SFC template module to obtain a newly built containerized virtual network element service function chain; wherein the established Pod is configured with multiple network ports. Through the method of the present invention, virtual network functions can be constructed with lower virtualization overhead, and the overall resource utilization and service response speed of the NFV platform are improved. The container network mechanism based on multiple network ports can meet the diverse software VNF implementation needs and can be well adapted to the existing software VNF. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 A schematic diagram of a process of building a containerized virtual network element service function chain in one embodiment;

[0044] Figure 2 is a general structural diagram of an SFC manager in one embodiment;

[0045] Figure 3 A schematic diagram of an SFC construction process in an embodiment;

[0046] Figure 4 Creating an SFC flow chart for an SFC building block in one embodiment;

[0047] Figure 5 A schematic diagram of a multi-network port creation process in an embodiment;

[0048] Figure 6 A schematic diagram of a multi-network port destruction process in an embodiment;

[0049] Figure 7 It is a structural block diagram of a containerized virtual network element service function chain construction device in one embodiment;

[0050] Figure 8 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0051] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. 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.

[0052] In one embodiment, Figure 1 As shown, a method for constructing a containerized virtual network element service function chain is provided, comprising the following steps:

[0053] Step 102: Build a cloud-native NFV platform.

[0054] The cloud-native NFV platform includes the NFVI (NFV infrastructure) module, the NFV MANO (NFV management and orchestration) module and the VNF (virtualized network function) module; the NFVI module is built on the Kubernetes (K8s for short) platform, and the NFV MANO module includes the SFC manager; the SFC manager includes the VNF template module, the SFC template module and the SFC building module; the VNF runs in the VNF module, and the VNF builds the network functions it implements as a container image, which is started in the Pod when instantiated.

[0055] Kubernetes is used as a virtualized infrastructure management system. In this system, multiple containers can be instantiated as a whole called Pod, sharing network, computing, storage and other resources. This article uses the instantiated Pod as an implementation method of VNF instantiation. Pod is the smallest basic unit orchestrated by the Kubernetes system. Each Pod contains one or more related containers, sharing the same computing, network and storage resources. The internal containers can cooperate with each other through inter-process communication and file sharing to provide services to the outside world.

[0056] Specifically, the cloud-native NFV architecture on which the present invention is based follows the ETSI NFV basic framework as a whole, and the platform consists of three parts: NFVI, VNF and MANO.

[0057] The role of NFVI is to virtualize physical resources and provide computing, storage, network and other resources required for the actual VNF operation. In the cloud-native NFV platform, in order to realize containerized VNF deployment, the distributed container management system Kubernetes is used to build NFVI.

[0058] VNF is a network function instance actually running on the NFV platform, which constitutes a service function chain to provide actual network functions and end-to-end access and processing capabilities. In Kubernetes, the basic unit of management and deployment is Pod. Each Pod contains one or more container images, which run in the same Linux Namespace and share network storage and other resources. The present invention uses Pod as a containerized VNF deployment instance. Each VNF constructs the network function it implements as a container image, which is started in the Pod when instantiated. The VNF program filters or processes the messages in and out of the container to implement network functions such as vFW, vDPI, and vNAT.

[0059] MANO is a core component for managing and coordinating the NFV platform, arranging and rendering VNF and SFC. The cloud-native NFV platform constructed by the present invention includes three main functional components: virtualized infrastructure manager (VIM), containerized SFC manager and Dashboard. VIM is responsible for docking with Kubernetes and NFVI, providing the upper layer with a proxy interface for instantiation of virtual resources and perception of NFVI status, and is responsible for the allocation of actual computing, storage, network and other resources. The SFC manager is responsible for the management of the SFC lifecycle and SFC templates. Dashboard is responsible for providing SFC visual orchestration and a user interface for SFC operation management.

[0060] Among them, the SFC management background program is called sfc manager, which is developed in go language. Its overall structure is as follows Figure 2 As shown, it includes VNF template module (VNF template), SFC template module (SFC template), and SFC building module (SFCbackend). In terms of overall function, the RESTful service module receives HTTP requests and routes them to various sub-modules for processing. The SFC building module is connected to the network component, which includes the network controller.

[0061] The VNF template module is responsible for querying VNF packages and template rendering (not responsible for instantiation). The SFC template module is responsible for adding, deleting, modifying, and checking SFC data (not responsible for instantiation). The data processed by these two templates can be found in the "Data Structure Definition" document.

[0062] The overall SFC management functions are shown in Table 1.

[0063] Table 1 SFC management function description

[0064] Function describe VNF List Provides query of all VNF packages under the VNF directory SFC Template Provides query, management, and storage of SFC logic chains. SFC Build Complete the instantiation of SFC according to the provided SFC build request

[0065] Step 104, when the SFC construction module receives the SFC establishment request, the VNF template module obtains the resource list file for establishing the Pod according to the variable definition information in the SFC establishment request, submits the resource list file for establishing the Pod to the Kubernetes platform for Pod establishment and initialization configuration, completes the instantiation of the VNF according to the SFC template module, and obtains the newly created containerized virtual network element service function chain.

[0066] Among them, the established Pod is configured with multiple network ports.

[0067] The SFC instance module (SFC backend) is responsible for receiving SFC build requests, using the variable definition in the request and the template rendering engine to obtain a complete YAML file, which is a resource list file for building a Pod. It calls the Kubernetes interface to create and start the Pod required in the SFC. Then, based on the topological relationship between VNFs, it communicates with the NFV platform network components to build the data path of the SFC. You can refer to Figure 3 Complete SFC construction process.

[0068] Specifically, when the SFC construction module completes the SFC construction, its various component processes are as follows Figure 4 ,When the server receives the POST SFC request (JSON format), it uses the VNF template request to complete the YAML document rendering, and then submits it to Kubernetes to complete the Pod creation.

[0069] Step 106: Perform status management on the newly created containerized virtual network element service function chain and store the status data in a database.

[0070] Send down the flow rules to complete the SFC establishment and update the status in the leveldb database.

[0071] In the above containerized virtual network element service function chain construction method, NFVI is constructed based on the Kubernetes platform, and a cloud native NFV platform is formed by NFVI, NFV MANO and VNF, wherein VNF constructs the network function implemented by itself as a container image, and starts in the Pod when instantiated. When the SFC construction module receives the SFC establishment request, the VNF template module obtains the resource list file for establishing the Pod according to the variable definition information in the SFC establishment request, and submits the resource list file for establishing the Pod to the Kubernetes platform for Pod establishment and initialization configuration, and completes the instantiation of VNF according to the SFC template module to obtain a newly created containerized virtual network element service function chain; wherein the established Pod is configured with multiple network ports. Through the method of the present invention, virtual network functions can be constructed with lower virtualization overhead, which improves the overall resource utilization and service response speed of the NFV platform. The container network mechanism based on multiple network ports can meet the diverse software VNF implementation needs and can be well adapted to the existing software VNF.

[0072] In one of the embodiments, it also includes: obtaining a resource list file for establishing a Pod according to variable definition information in an SFC establishment request through a VNF template module; the variable definition information includes a VNFD list and parameter values.

[0073] The VNFD list and parameter values ​​are the information in the cloud native VNFD. The cloud native VNFD definition mechanism uses a parameterized template mechanism to standardize the VNF packaging and distribution process, provides a VNF unified orchestration interface for the cloud native NFV MANO, and proposes a SFC description mechanism with good scalability as a unified definition model for service function chain topology orchestration and predefined knowledge base establishment in NFV MANO.

[0074] The variables that need to be provided to the SFC management platform are shown in Table 2.

[0075] Table 2 Configuration variables provided to the SFC management platform

[0076] Variable Name describe Name Used to specify the pod name of the VNF runtime Host Used to specify which host the VNF runs on Mac The network card Mac used to specify the pod IP Used to specify the pod's IP CPU Used to specify the CPU required for pod to run Memory Used to specify the memory required for pod operation

[0077] In one embodiment, if Figure 5 , providing steps for creating multiple network ports in the containerized virtual network element service function chain construction method, including:

[0078] Step 1: Before building the VNF container, use the Pod custom annotation mechanism to specify the number of multiple network ports as n using "nfv / nf_multi_if: n";

[0079] Step 2: When the VNF instantiated Pod creation request is submitted to the Kubernetes platform, the network controller is called through the event registration mechanism of the core API;

[0080] Step 3: The network controller creates the corresponding number of logical switch ports on OVN based on the value of "nfv / nf_multi_if". The logical ports use the implicit name net(n)_nf-name_sfc-name.

[0081] Step 4: The network controller modifies the Pod description, adds the multi-port mac address annotation "nfv / nf_multi_if_mac_address", and fills in the n logical port mac addresses returned by OVN in the previous step;

[0082] Step 5: When the Kubernetes platform calls the container network initialization interface, the network controller obtains the list of multiple network ports that need to be initialized based on the annotation;

[0083] Step 6: The network controller creates n virtual network ports required by the VNF container in sequence;

[0084] Step 6.1: Generate an implicit network port name net(n) based on the Pod name and network port number, and create the corresponding veth;

[0085] Step 6.2: Add one end of the veth pair to the OVS of the physical node and the other end to the network Namespace of the Pod; the physical node is the actual physical platform where the VNF runs;

[0086] Step 6.3: Disable veth TX offloading

[0087] Step 6.4: Modify the external_ids of the network port in OVS: iface-id = net(n)_nf-name_sfc-name to correspond to the logical port in OVN, thereby completing the binding;

[0088] Step 6.5: Modify the virtual network port MAC address and MTU configuration.

[0089] like Figure 6 , providing the steps of destroying multiple network ports in the containerized virtual network element service function chain construction method, including:

[0090] Step 1: Kubernetes generates a Pod deletion event and the network controller responds to the request.

[0091] Step 2: The network controller calls the OVN logical port destruction interface;

[0092] Step 3: The network controller responds to the network resource release request;

[0093] Step 4: The network controller reads the annotation of the Pod, obtains information about multiple network ports, and calls to delete the network ports one by one;

[0094] Step 4.1: Delete the veth-related ports and configurations from the host OVS; the host is the actual physical platform where the VNF runs;

[0095] Step 4.2: Delete veth.

[0096] The Pod custom annotation mechanism belongs to the existing technology in the Kubernetes platform. It can be added manually by the user or automatically attached and used by the tool program. OVN (Open Virtual Network) is a native virtualized network solution provided by the open source "virtual switch" OVS (Open vSwitch), which provides network features such as distributed switches, distributed routers, ACL, QoS and NAT. At the same time, in the virtual two-layer distributed switch, the logical flow table extended by OVN can be issued to realize more complex network functions. Since Kubernetes itself does not have too many specifications for the implementation of network functions, the network functions are relatively simple. Therefore, the present invention uses Kube-OVN as a Kubernetes network plug-in. Based on the OVN controller, Kube-OVN fully meets the Kubernetes network resource management requirements.

[0097] Traditional container orchestration platforms only support single-port networking, but single-port VNFs will increase the difficulty of SFC forwarder design and limit VNF ​​forwarding performance. In the process of implementing the service function chain, the most critical link is the traffic manipulation link. For a given network flow, a general VNF needs to simultaneously process traffic from the client to the server and from the server to the client. When the traffic in each direction is processed by the VNF, it is necessary to further distinguish the traffic entering the VNF and flowing out of the VNF. The SFC forwarder sets different forwarding paths for these four types of traffic. For VNFs with a single network port, since there is only one TX and one RX, it is necessary to further analyze the header of the message and record the flow status at the same time to distinguish these flows. Further encapsulation protocols are also required to simplify the forwarding model at the SFC forwarder layer. Secondly, since a single network port is used to process traffic in two directions at the same time, the traffic in the two directions will compete for the same queue, which will limit the VNF throughput and message latency.

[0098] Based on multi-port virtual network elements, the complexity of designing and implementing the service function chain can be significantly reduced. Using two pairs of TX and RX of dual network ports can make the VNF correspond to the traditional physical network function model. When designing the forwarding strategy, you can choose to connect the VNFs in series, which is consistent with the traditional network function topology and realizes transparent forwarding. Or forward through the SFC forwarder, at this time, you only need to distinguish from the network port to realize the flow path planning, and can realize stateless forwarding. In addition, the use of a multi-port mechanism is more friendly to the design and implementation of VNFs. VNFs can set different forwarding rules for inbound and outbound traffic according to the network port. Some existing software implementation network elements such as Snort are also designed for multi-port scenarios, and it is easier to migrate these VNFs to the NFV platform.

[0099] The existing solution to realize multiple network ports in the container is the Multus CNI mechanism. However, the basic principle of this mechanism is to allow the Kubernetes platform to access multiple CNI interfaces so that the container can access multiple networks. It does not meet the single network and multiple network port requirements required by the SFC networking. The multi-network port method proposed in the method of the present invention is to create and access multiple network ports that can control the traffic forwarding path for the container through one CNI.

[0100] The container network mechanism based on multiple network ports can meet the needs of various software VNF implementations and can be well adapted to existing software VNFs.

[0101] It should be understood that although Figure 1 , 5 The steps in the flowchart of 6 are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, Figure 1 , 5 At least part of the steps in 6 may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0102] In one embodiment, Figure 7 As shown, a containerized virtual network element service function chain construction device is provided, including: a cloud native NFV platform construction module 702, an SFC establishment module 704 and a state management module 706, wherein:

[0103] The cloud native NFV platform construction module 702 is used to build a cloud native NFV platform; the cloud native NFV platform includes an NFVI module, an NFV MANO module and a VNF module; the NFVI module is built based on the Kubernetes platform, and the NFV MANO module includes an SFC manager; the SFC manager includes a VNF template module, an SFC template module and an SFC construction module; the VNF runs in the VNF module, and the VNF builds the network functions implemented by itself into a container image, which is started in the Pod when instantiated;

[0104] The SFC establishment module 704 is used for obtaining a resource list file for establishing a Pod according to the variable definition information in the SFC establishment request through the VNF template module when the SFC construction module receives the SFC establishment request, submitting the resource list file for establishing the Pod to the Kubernetes platform for Pod establishment and initialization configuration, completing the instantiation of the VNF according to the SFC template module, and obtaining a newly created containerized virtual network element service function chain; wherein the established Pod is a multi-network port;

[0105] The state management module 706 is used to manage the state of the newly created containerized virtual network element service function chain and store the state data in the database.

[0106] The SFC establishment module 704 is also used to specify the number of multiple network ports as n through the Pod custom annotation mechanism; when submitting the resource list file for establishing the Pod to the Kubernetes platform, the network controller is called through the event registration mechanism of the Core API; the network controller creates a corresponding number of logical switch ports on OVN according to the number of multiple network ports, and OVN returns the mac address of the logical switch port and determines the implicit naming of the logical switch port; the network controller adds a multi-network port mac address annotation according to the mac address of the logical switch port; when the Kubernetes platform calls the container network initialization interface, the network controller obtains a list of multiple network ports to be initialized according to the multi-network port mac address annotation; and the network controller sequentially creates n virtual network ports required by the Pod.

[0107] The SFC establishment module 704 is also used to generate an implicit network port name according to the name of the currently created Pod and the network port serial number, and create the corresponding veth; add one end of the veth pair to the OVS of the physical node, and the other end to the network Namespace of the current Pod; turn off the TX offloading of the veth; bind the network port in OVS to the logical switch port in OVN; modify the virtual network port mac address and the maximum transmission unit configuration information.

[0108] The SFC establishing module 704 is further configured to release the resources of the SFC and update the status of the SFC in the database when the SFC building module receives an SFC destroying request.

[0109] The SFC establishing module 704 is further used to destroy the multiple network ports of the corresponding Pod when releasing the resources of the SFC.

[0110] The SFC establishment module 704 is also used to generate a Pod deletion request through the Kubernetes platform, and the network controller responds to the Pod deletion request; calls the OVN logical switch port destruction interface through the network controller; responds to the network resource release request through the network controller; reads the annotation information of the corresponding Pod through the network controller, obtains multiple network port information from the annotation information, and calls to delete the network ports in sequence; deletes the port and configuration corresponding to veth from the host OVS; deletes veth.

[0111] For the specific limitations of the containerized virtual network element service function chain construction device, please refer to the limitations of the containerized virtual network element service function chain construction method above, which will not be repeated here. Each module in the above-mentioned containerized virtual network element service function chain construction device can be implemented in whole or in part through software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0112] In one embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as follows: Figure 8 As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a method for constructing a containerized virtual network element service function chain is implemented. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad provided on the housing of the computer device, or an external keyboard, touchpad or mouse, etc.

[0113] Those skilled in the art will understand that Figure 8The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0114] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps in the above method embodiment when executing the computer program.

[0115] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above method embodiment are implemented.

[0116] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0117] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0118] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A method for constructing a containerized virtual network element service function chain, characterized in that: The method comprises: A cloud-native NFV platform is constructed; the cloud-native NFV platform includes an NFVI module, an NFV MANO module and a VNF module; the NFVI module is constructed based on a Kubernetes platform, the NFV MANO module includes an SFC manager; the SFC manager includes a VNF template module, an SFC template module and an SFC construction module; a VNF is run in the VNF module, and the VNF constructs the network function implemented by itself as a container image, and is started in a Pod when instantiated; When the SFC construction module receives the SFC establishment request, the VNF template module obtains a resource list file for establishing a Pod according to the variable definition information in the SFC establishment request, submits the resource list file for establishing the Pod to the Kubernetes platform for Pod establishment and initialization configuration, completes the instantiation of the VNF according to the SFC template module, and obtains a newly created containerized virtual network element service function chain; wherein the established Pod is configured with multiple network ports; Performing state management on the newly created containerized virtual network element service function chain and storing state data in a database; When creating a Pod with multiple network ports, the steps to create multiple network ports include: Through the Pod custom annotation mechanism, specify the number of multiple network ports as n; When submitting the resource list file for establishing the Pod to the Kubernetes platform, calling the network controller through the event registration mechanism of the Core API; The network controller creates a corresponding number of logical switch ports on OVN according to the number of the multiple network ports, and the OVN returns the mac address of the logical switch port and determines the implicit naming of the logical switch port; Adding multiple network port mac address annotations according to the logical switch port mac address by the network controller; When the Kubernetes platform calls the container network initialization interface, the network controller obtains a list of multiple network ports to be initialized according to the multiple network port mac address annotations; The n virtual network ports required by the Pod are created in sequence through the network controller.

2. The method according to claim 1, characterized in that The VNF template module obtains a resource list file for establishing a Pod according to the variable definition information in the SFC establishment request, including: The VNF template module obtains a resource list file for establishing a Pod according to the variable definition information in the SFC establishment request; the variable definition information includes a VNFD list and parameter values.

3. The method according to claim 1, characterized in that The n virtual network ports required by the Pod are created in sequence through the network controller, including: Generate an implicit network port name based on the name of the currently created Pod and the network port sequence number, and create the corresponding veth; Add one end of the veth pair to the OVS of the physical node, and the other end to the network Namespace of the current Pod; Disable veth TX offloading; Bind the network port in the OVS to the logical switch port in the OVN; Modify the virtual network port MAC address and maximum transmission unit configuration information.

4. The method according to claim 3, characterized in that The method further comprises: When the SFC construction module receives the SFC destruction request, it releases the resources of the SFC and updates the status of the SFC in the database.

5. The method according to claim 4, characterized in that When releasing SFC resources, it also includes: Destroy the multiple network ports of the corresponding Pod.

6. The method according to claim 5, characterized in that The steps to destroy the multiple network ports of the corresponding Pod include: Generate a Pod deletion request through the Kubernetes platform, and the network controller responds to the Pod deletion request; Calling the OVN logical switch port destruction interface through the network controller; Responding to a network resource release request by the network controller; Read the annotation information of the corresponding Pod through the network controller, obtain the multi-network port information from the annotation information, and call to delete the network ports in sequence; Delete the port and configuration of veth from the OVS of the physical node; Delete veth.

7. A containerized virtual network element service function chain construction device, characterized in that: The device is used to implement the containerized virtual network element service function chain construction method according to any one of claims 1 to 6, comprising: A cloud-native NFV platform construction module is used to construct a cloud-native NFV platform; the cloud-native NFV platform includes an NFVI module, an NFV MANO module and a VNF module; the NFVI module is constructed based on the Kubernetes platform, the NFV MANO module includes an SFC manager; the SFC manager includes a VNF template module, an SFC template module and an SFC construction module; the VNF runs in the VNF module, and the VNF constructs the network function implemented by itself as a container image, which is started in a Pod when instantiated; The SFC establishment module is used for obtaining a resource list file for establishing a Pod according to the variable definition information in the SFC establishment request through the VNF template module when the SFC construction module receives the SFC establishment request, submitting the resource list file for establishing the Pod to the Kubernetes platform for Pod establishment and initialization configuration, completing the instantiation of the VNF according to the SFC template module, and obtaining a newly created containerized virtual network element service function chain; wherein the established Pod is a multi-network port; The state management module is used to manage the state of the newly created containerized virtual network element service function chain and store the state data in a database.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images