Collaborative management system and method

Abstract

The disclosure provides a kind of collaborative management system and method, it is related to cloud computing technical field.Collaborative management system is deployed in virtual machine monitor layer, including virtual function (VF) monitoring module, VF docking module and VF control module;VF control module obtains the VF demand information of network card from PaaS layer, and sends VF demand information to VF monitoring module;VF monitoring module carries out monitoring to VF state and collects the VF data of network card, based on the VF demand information of network card, in the VF data of collection, target VF information is inquired, and target VF information is available VF information;VF control module obtains target VF information, and sends target VF information and VF demand information to VF docking module;VF docking module is based on target VF information and VF demand information, completes VF customization task.According to the embodiment of the present disclosure, the expansion capacity of VF can be provided for virtual machine container cluster scene, and the k8s schedulable allocation is guaranteed while configuring VF for virtual machine access on demand.

Description

Technical Field

[0001] This disclosure relates to the field of cloud computing technology, and in particular to a collaborative management system and method. Background Technology

[0002] With the development of network virtualization, network virtualization of virtual machine containers is evolving towards cloud-native container clusters supporting network applications. Cloud-native container clusters leverage cloud computing virtualization capabilities, deploying physical machines on virtualized systems and then deploying container clusters on virtual nodes provided by the virtualization system. Containers are lightweight and flexible. Based on process virtualization, containers feature lightweight, fast startup, Cgroup isolation technology, and open interface standards for container execution, storage, and scheduling. Container clusters achieve large-scale container calls and deployments by calling container interface standards.

[0003] However, applications that support carrier-grade network functions require high-performance physical network interface card (NIC) capabilities. Deploying network applications in the current virtual machine cluster environment creates a substantial contradiction: the NIC virtualization (VF) required by container applications cannot effectively meet the elasticity requirements of cloud-native applications.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] This disclosure provides a collaborative management system and method that, to at least some extent, solves the problem of container clusters struggling to scale up or down their VF (Virtualization Function) resources, and the inability of container clusters to request additional VFs from the IaaS layer virtualization system as needed.

[0006] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part by practice of this disclosure.

[0007] According to one aspect of this disclosure, a collaborative management system is provided, deployed at the virtual machine monitor layer, the collaborative management system including a virtual function (VF) monitoring module, a VF interface module, and a VF control module;

[0008] The VF control module obtains the VF requirement information of the network card from the PaaS (Platform as a Service) layer and sends the VF requirement information to the VF listening module.

[0009] The VF monitoring module listens to the VF status and collects the VF data of the network card. Based on the VF requirement information of the network card, it queries the collected VF data for target VF information, which is the available VF information.

[0010] The VF control module acquires the target VF information and sends the target VF information and VF requirement information to the VF docking module;

[0011] The VF docking module completes the VF customization task based on the target VF information and VF requirement information.

[0012] In one embodiment of this disclosure, the VF control module sends the VF information customized by the input / output virtualization agent (neutron-sriov-agent) module to the upper-layer PaaS to complete the virtual network card customization task of this layer.

[0013] In one embodiment of this disclosure, the VF docking module completes the VF customization task through the input / output virtualization agent (neutron-sriov-agent) module based on the target VF information and VF requirement information.

[0014] In one embodiment of this disclosure, the VF docking module includes a first docking unit and a second docking power supply;

[0015] The first docking unit is used to control the VF resource docking with the virtual machine and to dock the input / output virtualization agent (neutron-sriov-agent) plugin;

[0016] The second docking unit is responsible for docking the control information sent to the nodes by the container network plugin in the Kubernetes cluster.

[0017] In one embodiment of this disclosure, the VF control module includes a first control unit and a second control unit;

[0018] The first control unit is deployed at the virtual machine monitor layer to issue docking tasks to the first docking unit;

[0019] The first control unit is deployed at the Kubernetes layer and is responsible for receiving VF control information and sending docking tasks to the second docking unit.

[0020] In one embodiment of this disclosure, a virtual network interface controller is deployed in the PaaS layer, which sends the VF requirement information of the network interface card to the VF control module.

[0021] In one embodiment of this disclosure, the VF request information sent by the virtual network interface controller is in another markup language, YAML format.

[0022] In one embodiment of this disclosure, the VF requirement information is derived from a requirement form filled out by the user when deploying a web application.

[0023] According to another aspect of this disclosure, a collaborative management method is provided, which is applied to the collaborative management system of any one of claims 1-8. The collaborative management method includes:

[0024] Acquire VF demand information of the network card from the PaaS layer;

[0025] Monitor the VF status and collect VF data of the network card;

[0026] Query target VF information in the collected VF data based on the VF demand information of the network card, where the target VF information is available VF information;

[0027] Complete the VF customization task based on the target VF information and the VF demand information.

[0028] In an embodiment of the present disclosure, the VF demand information is derived from a demand form filled in by a user during a network application deployment task.

[0029] According to yet another aspect of the present disclosure, an electronic device is provided, comprising: a memory configured to store instructions; and a processor configured to call the instructions stored in the memory to implement the above-mentioned collaborative management method.

[0030] According to yet another aspect of the present disclosure, a computer-readable storage medium is provided, on which computer instructions are stored, and the computer instructions, when executed by a processor, implement the above-mentioned collaborative management method.

[0031] According to yet another aspect of the present disclosure, a computer program product is provided, the computer program product storing instructions that, when executed by a computer, cause the computer to perform the above-mentioned collaborative management method.

[0032] According to yet another aspect of the present disclosure, a chip is provided, comprising at least one processor and an interface;

[0033] The interface is configured to provide program instructions or data to the at least one processor;

[0034] The at least one processor is configured to execute program instructions to implement the above-mentioned collaborative management method.

[0035] The collaborative management system and method provided by the embodiments of the present disclosure acquire VF demand information of a network card from the PaaS layer, query target VF information in collected VF data based on the VF demand information of the network card, and complete a VF customization task based on the target VF information and the VF demand information. The embodiments of the present disclosure provide VF expansion capability for virtual machine container cluster scenarios, which can form linkage with the sriov-agent at the openstack layer to configure VF access for virtual machines on demand while ensuring schedulable allocation by k8s.

[0036] It should be understood that the foregoing general description and the following detailed description are merely exemplary and explanatory and do not limit the present disclosure. Attached Figure Description

[0037] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0038] Obviously, the accompanying drawings described below are merely some embodiments of this disclosure. Those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0039] Figure 1 A schematic diagram of the architecture of a collaborative management system according to an embodiment of this disclosure is shown;

[0040] Figure 2 A schematic diagram of the architecture of another collaborative management system in an embodiment of this disclosure is shown;

[0041] Figure 3 A schematic diagram of the architecture of yet another collaborative management system according to an embodiment of this disclosure is shown;

[0042] Figure 4 This diagram illustrates a flowchart of a collaborative management method according to an embodiment of the present disclosure;

[0043] Figure 5 This invention discloses a flowchart of another collaborative management method in an embodiment of the present invention.

[0044] Figure 6 A structural block diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0045] The exemplary implementation will now be described more fully with reference to the accompanying drawings.

[0046] It should be noted that the example implementation can be implemented in many forms and should not be construed as being limited to the examples set forth herein.

[0047] As can be seen from the background section, deploying network applications in a virtual machine cluster environment currently creates a substantial contradiction: the network interface virtualization (VF) required by container applications cannot effectively meet the elasticity requirements of cloud-native applications.

[0048] Specifically, the inventors discovered that the virtualization capabilities of physical network cards provided by cloud computing physical hosts are locked at the IaaS (Infrastructure as a Service) layer; virtual machines provided by the IaaS layer are only allocated VFs during the creation phase; when the CaaS (Communications as a Service) / PaaS (Platform as a Service) layer container resource scheduling system creates multiple containers, it can only call VFs from the virtual machine system. Therefore, the following problems arise:

[0049] 1. Container clusters face difficulties in scaling up and down VF resources: Container clusters cannot request additional VFs from the IaaS layer virtualization system as needed.

[0050] 2. The demand for large-scale VF cannot be coordinated with virtual machines: The number of VF supported by a single-node virtual machine is limited, and the use of large-scale VF resources also needs to be coordinated and scheduled with the container cluster system.

[0051] Given the limited resources of VF and the need for collaborative expansion with the IaaS layer virtualization system, this embodiment adds a management and collaboration system to uniformly manage the IaaS layer VF resources while undertaking PaaS layer scheduling strategies to achieve cloud-native-level network elasticity for supporting network applications.

[0052] The following detailed description of this exemplary implementation method is provided in conjunction with the accompanying drawings and embodiments.

[0053] Figure 1 This disclosure illustrates a collaborative management system deployed at the hypervisor layer, as shown in an embodiment of the present disclosure. Figure 1 As shown, the collaborative management system includes a VF (Virtual Function) monitoring module 10, a VF docking module 20, and a VF control module 30.

[0054] The VF control module 30 obtains the VF requirement information of the network card from the PaaS layer and sends the VF requirement information to the VF listening module 10.

[0055] The VF monitoring module 10 monitors the VF status and collects the VF data of the network card. Based on the VF requirement information of the network card, it queries the target VF information in the collected VF data. The target VF information is the available VF information.

[0056] VF control module 30 acquires target VF information and sends the target VF information and VF requirement information to VF docking module 20;

[0057] The VF docking module 20 completes the VF customization task based on the target VF information and VF requirement information.

[0058] In some embodiments, the VF control module 30 sends the VF information customized by the input / output virtualization agent (neutron-sriov-agent) module to the upper-layer PaaS to complete the virtual network card customization task of this layer.

[0059] In some embodiments, the VF docking module 20 completes the VF customization task through the input / output virtualization agent (neutron-sriov-agent) module based on the target VF information and VF requirement information.

[0060] In some embodiments, the VF docking module 20 includes a first docking unit and a second docking power supply;

[0061] The first docking unit is used to control the VF resource docking with the virtual machine and to dock the input / output virtualization agent (neutron-sriov-agent) plugin;

[0062] The second docking unit is responsible for docking the sriov control information sent to the nodes by the container network plugin (such as sriov-cni) in the Kubernetes cluster.

[0063] In some embodiments, the VF control module 30 includes a first control unit and a second control unit;

[0064] The first control unit is deployed at the virtual machine monitor layer to issue docking tasks to the first docking unit;

[0065] The first control unit is deployed at the Kubernetes layer and is responsible for receiving VF control information and sending docking tasks to the second docking unit.

[0066] In some embodiments, the VF requirement information sent by the virtual network interface controller is in YAML format.

[0067] In some embodiments, VF requirement information is derived from a requirement form filled out by the user when deploying a web application.

[0068] Figure 2 This disclosure illustrates a collaborative management system deployed at the virtual machine monitor layer, as shown in an embodiment of the present disclosure. Figure 2 As shown, the collaborative management system includes a VF monitoring module 10, a VF docking module 20, and a VF control module 30; a virtual network interface controller is deployed in the PaaS layer.

[0069] The virtual network interface controller sends the VF requirement information of the network interface card to the VF control module 30.

[0070] VF control module 30 is responsible for receiving northbound messages and connecting with VF listening module 10 and VF docking module 20 to complete the functions of virtual network card resource query, resource binding and message feedback. VF control module 30 is the central control module of the virtual machine monitor layer and is the main message entry and message exit.

[0071] The northbound input of the VF control module 30 is the entry point for receiving YAML formatted information from PaaS, and is the first step in processing network card requests.

[0072] The northbound output of the VF control module 30 is the feedback outlet for the final status information of the network card resources, and the output format is the same as the input format.

[0073] The southbound output of the VF control module 30 directly transmits information obtained by trimming the YAML file (which is not related to the network card) to the VF monitoring module 10; and transmits information obtained from the network card resource query and the concatenated YAML file to the VF interface module 20.

[0074] The south-facing input of the VF control module 30 is only connected to the VF monitoring module 10 and contains formatted information obtained from querying the network card.

[0075] VF monitoring module 10 is responsible for querying and monitoring network card resources. It queries the amount of VF resources and related details under the PF network card by connecting to the PF Driver in SRIOV.

[0076] The northbound input of the VF monitoring module 10 is the YAML format information interface for the VF controller.

[0077] The northbound output of the VF monitoring module 10 is YAML-formatted information obtained from the queried network card information.

[0078] The southbound output of the VF monitoring module 10 contains the filtered information required for querying the PF Driver.

[0079] The southbound input of the VF monitoring module 10 is the network card information obtained from the PF Driver query.

[0080] VF interface module 20 is responsible for binding network interface card (NIC) resources. This module is mainly responsible for filtering and summarizing relevant NIC information and converting it into the format required by the lower layer. It completes the NIC resource extraction and binding task by connecting to the neutron-sriov-agent input / output virtualization agent (neutron-sriov-agent).

[0081] The input terminal of the VF interface module 20 is the YAML format information interface of the VF controller.

[0082] The output of the VF docking module 20 contains formatted information created for the network interface card required by the input / output virtualization agent (neutron-sriov-agent).

[0083] This disclosure provides embodiments that enhance user usability by adding VF resources through a declarative API; enable virtual network interface card (NIC) network capabilities to connect virtual machines to container cluster POD resources; and facilitate the collaboration of IaaS and PaaS capabilities.

[0084] Figure 3 This diagram illustrates the architecture of a collaborative management system according to an embodiment of the present disclosure, such as... Figure 3 As shown, the collaborative management system includes a VF monitoring module 10, a VF docking module 20, and a VF control module 30.

[0085] The VF monitoring module 10 is responsible for monitoring the VF state at the Hypervisor layer and collecting VF data to send to the VF control module 30.

[0086] VF docking module 20 is responsible for performing VF docking tasks.

[0087] The first docking unit, also known as the VMM docking module, is responsible for controlling the docking of VF resources with virtual machines and docking with the input / output virtualization agent (neutron-sriov-agent) plugin.

[0088] The second docking unit, also known as k8s-vf-agent, is responsible for docking the sriov control information sent to the nodes by sriov-cni in the k8s cluster.

[0089] VF control module 30: It is divided into two modules, which synchronize information through a message queue.

[0090] The first control unit, also known as VMM-multi_vf-controller, is deployed at the Hypervisor layer to issue docking tasks to the VMM docking module.

[0091] The second control unit, also known as k8s-multi_vf-controller, is deployed at the k8s layer and is responsible for receiving VF control information and sending docking tasks to k8s-vf-agent.

[0092] The PaaS layer primarily uses the Kubernetes virtual network interface controller (k8s) to interface with the virtual machine monitor layer, sriov-cni to handle pre-defined Virtual Frame (VF) allocation, and an agent to manage and monitor virtual network interface applications on worker nodes. Key components include k8s-vf-agent, k8s-vf-controller, and sriov-cni.

[0093] The virtual machine monitor layer primarily receives messages from the upper layer through the VMM virtual network interface controller. It sends the port requests of the SRIOV network interface to the VF listening module 10 to query available VF information, and then sends the obtained VF information, along with the required VF-related information from the request, to the VMM interface module. Finally, the VMM interface module filters, organizes, and summarizes the messages before sending them to the input / output virtualization agent module to complete the VF customization task. After receiving the final VF information, the VMM virtual network interface controller sends a message to the upper-layer PaaS to complete the virtual network interface customization task at this layer. Key components include the VMM-multi_vf-controller, the VF listening module 10, and the VMM interface module.

[0094] In related technologies, VF functionality in multi-pod networks is investigated, but the VF traversal and retrieval are limited to the VFs already allocated on the Kubernetes node. In contrast, the embodiments of this disclosure traverse all VFs of the physical network interface card and map and allocate them to the pods.

[0095] Related technologies configure VirtualF (VF) for Kubernetes pods, but cannot configure a substantial network interface mapping (NIC) for Kubernetes clusters within virtual machines. The method proposed in this disclosure allows VF to penetrate the mapping between virtual machines and pods.

[0096] Related technologies configure the network interface cards (NICs) of a virtual machine cluster, but cannot finely distinguish the Virtual Functions (VFs) of multiple physical NICs and cannot actively schedule virtual machine VFs. This disclosed embodiment links the sriov-agent of the OpenStack layer, enabling on-demand configuration of virtual machine access to VFs while ensuring Kubernetes (k8s) can schedule and allocate resources.

[0097] In the embodiments disclosed herein, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The concepts of "first," "second," etc., mentioned in this disclosure are only used to distinguish different devices, modules, or units and are not used to define the order of functions performed by these devices, modules, or units or their interdependencies.

[0098] In this disclosure, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0099] It should be noted that although several modules or units of the device used for action execution are mentioned in the detailed description above, this division is not mandatory.

[0100] In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0101] Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0102] Based on the same inventive concept, this disclosure also provides a collaborative management method, such as... Figure 4 As shown, the collaborative management method is applied to the collaborative management system provided in any of the above embodiments, and the collaborative management method includes steps S401-S404.

[0103] In S401, the VF requirement information of the network card is obtained from the PaaS layer;

[0104] In S402, the VF status is monitored and the VF data of the network card is collected;

[0105] In S403, based on the VF requirement information of the network card, the target VF information is queried from the collected VF data. The target VF information is the available VF information.

[0106] In S404, the VF customization task is completed based on the target VF information and VF requirement information.

[0107] In some embodiments, VF requirement information is derived from a requirement form filled out by the user when deploying a web application.

[0108] Figure 5 This disclosure illustrates a collaborative management method provided by an embodiment of the present disclosure, such as... Figure 5 As shown, this collaborative management method includes S501-S510.

[0109] In S501, when a web application deployment task is performed, a YAML form is filled out and sent to the controller by the API Server;

[0110] In S502, k8s-vf-controller receives YAML forms;

[0111] In S503, query the database to see if it contains a VF network interface message that matches the YAML request;

[0112] If the message exists, proceed to step S508;

[0113] The message does not exist; proceed to step S504.

[0114] In S504, the network card-related information in the YAML file is sent to the VMM-VF-Controller;

[0115] In S505, vmm-vf-controller can be used to view the sriov network interface resource quantity of the VF listener module;

[0116] In S506, the VMM interface module filters, organizes, and summarizes messages before sending them to the input / output virtualization agent module.

[0117] Does the S507 have a matching network interface card (NIC) resource?

[0118] No matching resources are found. Proceed to step S502.

[0119] If relevant matching resources exist, the input / output virtualization agent module will extract and customize the virtual network card according to the message obtained in the previous step, complete the declaration of the virtual network card, and send the obtained VF message to vmm-vf-controller, and jump to step S502.

[0120] In S508, the k8s-vf-controller executes YAML and assigns VF virtual network interface ports to the relevant k8s-vf-agent;

[0121] In S509, sriov-cni obtains the VF virtual network interface port and creates a connection to that virtual network interface port;

[0122] In S510, complete the expansion of virtual network cards.

[0123] This disclosure provides the VF scaling capability for virtual machine container cluster scenarios; the IaaS layer capability supports declarative API calls at the PaaS layer; and the VF scaling capability enables precise scheduling to node nodes.

[0124] The following reference Figure 6 This describes the electronic device provided in the embodiments of this disclosure. Figure 6 The electronic device 600 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0125] Figure 6 This diagram illustrates the architecture of an electronic device 600 according to an embodiment of the present invention. Figure 6 As shown, the electronic device 600 includes, but is not limited to, at least one processor 610 and at least one memory 620.

[0126] Memory 620 is used to store instructions.

[0127] In some embodiments, memory 620 may include a readable medium in the form of volatile memory cells, such as random access memory (RAM) 6201 and / or cache memory 6202, and may further include read-only memory (ROM) 6203.

[0128] In some embodiments, the memory 620 may also include a program / utility 6204 having a set (at least one) of program modules 6205, such program modules 6205 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0129] In some embodiments, memory 620 may store an operating system. This operating system may be a real-time operating system (RTX), such as Linux, UNIX, Windows, or OS X.

[0130] In some embodiments, the memory 620 may also store data.

[0131] As an example, processor 610 can read data stored in memory 620, which may be stored at the same memory address as the instructions, or the data may be stored at a different memory address than the instructions.

[0132] Processor 610 is configured to invoke instructions stored in memory 620 to implement the steps described in the "Exemplary Methods" section above, according to various exemplary embodiments of this disclosure. For example, processor 610 may execute the following steps of the above method embodiments:

[0133] Obtain VF requirement information from the PaaS layer;

[0134] Monitor the VF status and collect VF data from the network interface card;

[0135] Based on the network interface card's VF requirement information, the target VF information is queried from the collected VF data. The target VF information is the available VF information.

[0136] Based on the target VF information and VF requirement information, complete the VF customization task.

[0137] It should be noted that the processor 610 described above can be a general-purpose processor or a special-purpose processor. The processor 610 may include one or more processing cores, and the processor 610 executes various functional applications and data processing by running instructions.

[0138] In some embodiments, processor 610 may include a central processing unit (CPU) and / or a baseband processor.

[0139] In some embodiments, the processor 610 may determine an instruction based on the priority identifier and / or function category information carried in each control instruction.

[0140] In this disclosure, the processor 610 and the memory 620 can be configured separately or integrated together.

[0141] As an example, the processor 610 and memory 620 can be integrated on a single board or a system-on-a-chip (SOC).

[0142] like Figure 6 As shown, electronic device 600 is embodied in the form of a general-purpose computing device. Electronic device 600 may also include bus 630.

[0143] Bus 630 can represent one or more of several types of bus structures, including a memory bus or memory controller, peripheral bus, graphics acceleration port, processor, or a local bus using any of the various bus structures.

[0144] Electronic device 600 can also communicate with one or more external devices 640 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). Such communication can be performed through input / output (I / O) interface 650.

[0145] Furthermore, the electronic device 600 can also communicate with one or more networks (such as local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via the network adapter 660.

[0146] like Figure 6 As shown, network adapter 660 communicates with other modules of electronic device 600 via bus 630.

[0147] It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0148] It is understood that the structures illustrated in the embodiments of this disclosure do not constitute a specific limitation on the electronic device 600. In other embodiments of this disclosure, the electronic device 600 may include more than Figure 6 This may involve more or fewer components, or combining certain components, or splitting certain components, or different component arrangements. Figure 6 The components shown can be implemented in hardware, software, or a combination of both.

[0149] This disclosure also provides a computer-readable storage medium storing computer instructions thereon, which, when executed by a processor, implement the collaborative management method described in the above method embodiments.

[0150] In this embodiment of the disclosure, the computer-readable storage medium is a computer instruction that can be sent, propagated, or transmitted for use by or in conjunction with an instruction execution system, apparatus, or device.

[0151] As an example, a computer-readable storage medium is a non-volatile storage medium.

[0152] In some embodiments, more specific examples of computer-readable storage media in this disclosure may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, USB flash drives, portable hard drives, or any suitable combination of the foregoing.

[0153] In this embodiment of the disclosure, the computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, wherein computer instructions (readable program code) are carried.

[0154] The transmitted data signal can take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof.

[0155] In some examples, computational instructions contained on a computer-readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0156] This disclosure also provides a computer program product that stores instructions that, when executed by a computer, cause the computer to implement the collaborative management method described in the above method embodiments.

[0157] The aforementioned instructions can be program code. In practice, the program code can be written using any combination of one or more programming languages.

[0158] Programming languages ​​include object-oriented programming languages—such as Java and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages.

[0159] The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0160] In cases involving remote computing devices, the remote computing devices can be connected to user computing devices via any type of network, including local area networks (LANs) or wide area networks (WANs), or they can be connected to external computing devices (e.g., via the Internet using an Internet service provider).

[0161] This disclosure also provides a chip, including at least one processor and an interface;

[0162] An interface is used to provide program instructions or data to at least one processor;

[0163] At least one processor is used to execute program instructions to implement the collaborative management method described in the above method embodiments.

[0164] In some embodiments, the chip may further include a memory for storing program instructions and data, the memory being located within or outside the processor.

[0165] Those skilled in the art will understand that all or part of the steps of the above embodiments can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, which can be collectively referred to as "circuit", "module" or "system".

[0166] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein.

[0167] This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

Claims

1. A collaborative management system, characterized in that, Deployed at the virtual machine monitor layer, the collaborative management system includes a Virtual Functions (VF) monitoring module, a VF interface module, and a VF control module. The VF control module obtains the VF requirement information of the network card from the Platform as a Service (PaaS) layer and sends the VF requirement information to the VF monitoring module. The VF monitoring module monitors the VF status and collects the VF data of the network card. Based on the VF requirement information of the network card, it queries the collected VF data for target VF information, which is available VF information. The VF control module acquires the target VF information and sends the target VF information and the VF requirement information to the VF docking module; The VF docking module completes the VF customization task based on the target VF information and the VF requirement information; The VF docking module includes a first docking unit and a second docking unit; The first docking unit is used to control the VF resource docking with the virtual machine and docking with the input / output virtualization proxy plugin; The second docking unit is used to dock the control information sent by the container network plugin to the node in the Kubernetes cluster; Based on the target VF information and the VF requirement information, the first docking unit calls the input / output virtualization proxy module to enable the input / output virtualization proxy module to complete the VF customization task.

2. The collaborative management system according to claim 1, characterized in that, The VF control module sends the VF information customized by the input / output virtualization agent module to the upper-layer Platform as a Service (PaaS) to complete the virtual network interface card (NIC) customization task of this layer.

3. The collaborative management system according to claim 1, characterized in that, The VF control module includes a first control unit and a second control unit; The first control unit is deployed in the virtual machine monitor layer and issues docking tasks to the first docking unit; The first control unit is deployed at the Kubernetes layer and is responsible for receiving VF control information and sending docking tasks to the second docking unit.

4. The collaborative management system according to claim 1, characterized in that, The PaaS layer is equipped with a virtual NIC controller, which sends the VF requirement information of the NIC to the VF control module.

5. The collaborative management system according to claim 4, characterized in that, The VF requirement information sent by the virtual network interface controller is in YAML format.

6. The collaborative management system according to claim 4, characterized in that, The VF requirement information comes from the requirement form filled out by the user when deploying the network application.

7. A collaborative management method, characterized in that, The collaborative management method is applied to the collaborative management system according to any one of claims 1-6, and the collaborative management method includes: Obtain VF requirement information from the PaaS layer; Monitor the VF status and collect VF data from the network interface card; Based on the VF requirement information of the network card, the target VF information is queried from the collected VF data, and the target VF information is the available VF information; Based on the target VF information and the VF requirement information, the input / output virtualization proxy module is invoked through the first docking unit in the VF docking module, so that the input / output virtualization proxy module can complete the VF customization task.

8. The collaborative management method according to claim 7, characterized in that, The VF requirement information comes from the requirement form filled out by the user when deploying the network application.

Images