Network function control method based on container network, medium, equipment and product

Abstract

The invention provides a network function control method based on a container network, a medium, equipment and a product, and relates to the technical field of computers.The method comprises the steps that a component operation request is received through a function extension framework, a target extension function component is operated through the function extension framework, and when the target extension function component is operated, the component operation request is received; through the data query interface of the function extension framework, the container network data of the core function component required by the operation of the target extension function component is obtained from the daemon process, so that the extension function component of the container network interface and the core function component of the container network interface can be decoupled; therefore, the extended function component with the non-core function can be developed independently, and rapid iteration and deployment of the extended function are ensured. Besides, the extended function can be deployed, operated and destroyed in real time according to actual scene requirements, and interference of global deployment on non-target nodes and containers is avoided.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular, to a network function control method, medium, device, and product based on a container network. Background Art

[0002] In the cloud native field, the Container Network Interface (CNI) is a unified interface for configuring and managing container network communications. For container runtimes, different CNI implementations can be installed according to network requirements, and the corresponding interfaces can be called according to specifications to complete basic network configuration and management of the container.

[0003] In the related art, the function extension of the container network interface is generally achieved by connecting multiple CNI binary standardized function extensions in series or by nesting function extensions through a CNI daemon.

[0004] However, in the scenario of large-scale container deployment, in order to adapt to different business needs, CNI will continuously iterate new functional features. Since the above two methods are to develop extended functions based on the original CNI binary or daemon code, this will lead to a high development threshold for extended functions, high deployment overhead and poor maintainability. Summary of the invention

[0005] This summary is provided to introduce concepts in a brief form that will be described in detail in the detailed description below. This summary is not intended to identify key features or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0006] In a first aspect, the present disclosure provides a network function control method based on a container network, comprising: A component operation request is received through a function extension framework running on a container network interface daemon process, wherein the function extension framework operates and maintains a core function component and an extended function component of the container network interface in a decoupled mode, and the component operation request is used to instruct the operation of a target extended function component that performs a preset network management action on the container network interface; In response to the component running request, the target extended functional component is run through the functional extension framework. When the target extended functional component is running, the container network data of the core functional component required for the running of the target extended functional component is obtained from the daemon process through the data query interface of the functional extension framework.

[0007] In a second aspect, the present disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the method described in the first aspect.

[0008] In a third aspect, the present disclosure provides an electronic device, including: a storage device having a computer program stored thereon; A processing device is used to execute the computer program in the storage device to implement the steps of the method described in the first aspect.

[0009] In a fourth aspect, the present disclosure provides a computer program product, comprising a computer program, which implements the steps of the method described in the first aspect when executed by a processor.

[0010] Based on the above technical solution, a component operation request is received through a function extension framework running on a container network interface daemon process, and a component operation request is responded to, and a target extended function component is run through the function extension framework. When the target extended function component is running, the container network data of the core function component required for the target extended function component to run is obtained from the daemon process through the data query interface of the function extension framework, so that the extended function component of the container network interface can be decoupled from the core function component of the container network interface, thereby ensuring that the core function component of CNI can be kept simple and clean logically, and the business logic is clear, so as to facilitate the location of problems. Moreover, by decoupling the extended function component from the core function component, the extended function component of the non-core function can also be developed independently, ensuring the rapid iteration and deployment of the extended function. In addition, by decoupling the extended function component from the core function component, the extended function can also be deployed, run, and destroyed instantly according to the actual scenario requirements within a specific range, avoiding the interference of global deployment on non-target nodes and containers.

[0011] Other features and advantages of the present disclosure will be described in detail in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale. In the drawings: Figure 1 The present invention is a flowchart of a method for controlling network functions based on a container network according to some embodiments.

[0013] Figure 2 is a schematic diagram of the architecture of a functional extension framework according to some embodiments.

[0014] Figure 3 is a flowchart of running a target expansion functional component according to some embodiments.

[0015] Figure 4 is a logical diagram of a scheduling layer according to some embodiments.

[0016] Figure 5 is a schematic diagram of the architecture of a functional extension framework according to some further embodiments.

[0017] Figure 6 The present invention is a flowchart of a network function control method based on a container network according to some further embodiments.

[0018] Figure 7 It is a structural schematic diagram of a network function control device based on a container network according to some embodiments.

[0019] Figure 8 It is a structural schematic diagram of a network function control device based on a container network according to some further embodiments.

[0020] Fig. 9 is a schematic diagram of the structure of an electronic device according to some embodiments. DETAILED DESCRIPTION

[0021] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments described herein, which are instead provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0022] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0023] The term "including" and its variations used herein are open inclusions, i.e., "including but not limited to". The term "based on" means "based at least in part on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0024] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0025] It should be noted that the modifications of "one" and "plurality" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, it should be understood as "one or more".

[0026] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0027] In related technologies, in order to meet various network requirements of upper-layer container instances and expand more abundant network functions while ensuring the basic connectivity of containers, container network functions can be expanded in the following two ways.

[0028] The first method: In the standard CNI interface specification, the binary products of each CNI functional component will be called when the container is created and deleted, and the network function configuration of the container instance can be performed by connecting different CNI binaries in series. Specifically, the binary of a single CNI functional component has a specific set of functions, but by specifying the CNI set and calling order through the conflist configuration file, multiple CNI components can be called in series to configure the container network.

[0029] However, although the concatenation of different CNI binaries can integrate rich functional features for containers, this functional expansion method cannot perform global state maintenance and unified scheduling of distributed nodes. Moreover, due to the CNI standard specification, it is limited to passive triggering when the container is created and deleted, and dynamic updates and configurations can no longer be performed during the operation of the container. Due to the CNI standard specification, the parameters passed into the container have strict format restrictions, and more complex network functions cannot be implemented through richer network configuration semantics. In addition, the execution order of multiple CNI functional components is fixed, and all container configuration processes of all nodes need to be executed according to the configuration files uniformly issued by the entire cluster.

[0030] The second method is to maintain the network status and dynamically configure network functions through the CNI daemon. Through the daemon configured on the host, the intermediate status of the CNI functional components can be maintained, so that the network status of the container instance can be managed arbitrarily in the container cluster. For example, through the CNI daemon, the network connectivity of the container can be continuously observed and reported. Through observation, the container network configuration failure caused by accidents can be automatically discovered and restored. It can sense the edge of the container status or external requests and dynamically configure the container network.

[0031] Although the above two methods can meet the basic functions of CNI, in large-scale deployment, CNI will continuously iterate new features to meet the needs of different businesses. However, when introducing new extended functions on CNI, the following problems will occur: 1. The extended functions are slow to go online. Since the extended functions of CNI rely on the original CNI binary / daemon code, you need to be familiar with CNI to develop and verify based on the code of the original components. And since CNI functional components need to be deployed on each node in each cluster, all developed extended functions need to be upgraded on each node, which makes it impossible to quickly and massively deploy the extended functions.

[0032] 2. Poor maintainability. Since the extension functions are coupled with the CNI core functions at the code level, decoupling each extension function into independent components leads to problems such as difficult deployment and high operation and maintenance costs.

[0033] 3. Poor isolation. Since the extension functions and CNI core functions are coupled in one CNI component, some customized CNI extension functions will be integrated into the critical path of the data link of the container network. Even if the extension functions are normally closed, it will inevitably cause resource waste and performance impact. For example, the CNI based on the eBPF forwarding point on the data plane will mount the BPF program for the container network card. Some extension functions will be inserted into the critical path of the data link of the container network in the form of bpf instructions, affecting the throughput and latency of the container network. Moreover, some extension functions may cause memory leaks and CPU surges due to code defects, thereby affecting the normal operation of the CNI core functional components. For example, the container traffic observation component may cause greater CPU pressure due to high-frequency traffic collection behavior, resulting in the impact of the traffic of the CNI core functional components and even other containers.

[0034] Based on the above technical problems, the present invention provides a network function control method based on a container network, so that the core function component of the container network interface is decoupled from the extended function component of the container network interface. The method receives a component operation request through a function extension framework running on the container network interface daemon process, and responds to the component operation request, runs the target extended function component through the function extension framework, and when the target extended function component is running, obtains the container network data of the core function component required for the target extended function component to run from the daemon process through the data query interface of the function extension framework, so that the extended function component of the container network interface can be decoupled from the core function component of the container network interface, thereby ensuring that the core function component of the CNI can be logically kept simple and clean, and the business logic is clear, so as to facilitate the location of the problem. Moreover, by decoupling the extended function component from the core function component, the extended function component of the non-core function can also be independently developed to ensure the rapid iteration and deployment of the extended function. In addition, by decoupling the extended function component from the core function component, the extended function can also be deployed, run, and destroyed instantly according to the actual scenario requirements within a specific range, avoiding the interference of global deployment on non-target nodes and containers.

[0035] Figure 1 FIG. 1 is a flow chart of a method for controlling network functions based on a container network according to some embodiments. Figure 1 As shown, the embodiment of the present disclosure provides a network function control method based on a container network, which can be executed by an electronic device, specifically by a network function control device based on a container network, which can be implemented by software and / or hardware and configured in an electronic device. It should be understood that the electronic device can be a server. Figure 1 As shown, the method may include the following steps.

[0036] In step 110, a component running request is received through a function extension framework running on a container network interface daemon process, where the component running request is used to instruct running a target extended function component that performs a preset network management action on a container network interface.

[0037] Here, the daemon of the container network interface refers to the background process that works with the container network interface in the Kubernetes cluster. The daemon is responsible for maintaining and managing the network connection and configuration of the container. The function extension framework can be understood as a scaffolding, which is used to provide the environment required for the operation of the extended function component.

[0038] The component running request may be a request sent by the client to instruct the function extension framework to run the specified target extended function component. The client may refer to the operation and maintenance platform. Exemplarily, the client may send a component running request to the daemon process of the container network interface, the daemon process receives the component running request, and forwards the component running request to the function extension framework running on the daemon process. It is worth noting that the component running request may be an HTTP request.

[0039] The core functional component of the container network interface refers to the basic functional component used by the container network interface for network configuration. For example, the core functional component can be used to configure basic functional components such as container devices, IP (Internet Protocol) allocation, and routing configuration. In addition to the core functional component, users can expand and develop different extended functional components according to different business needs to enable the container network interface to achieve more extended functions. For example, when the network connectivity of the container fails, an extended functional component can be used to quickly check whether the network namespace of the container exists, whether the network card is pulled up, and whether the IP allocation is normal. For another example, when it is necessary to capture the traffic of the container network, an extended functional component can be used to collect the traffic of the container. For another example, during the peak traffic period, it is necessary to repeatedly adjust the packet priority of the traffic of a specific container, and a traffic control component can be used to perform customized traffic management. It should be noted that the extended functional component can be understood as a third-party CNI extension program from the outside.

[0040] It should be understood that in the embodiments of the present disclosure, the functional extension framework adopts a decoupled mode to operate and maintain the core functional components and extended functional components of the container network interface. In other words, the functional extension framework is used to achieve the decoupling of the core functional components and extended functional components of the container network interface. Since the extended functional components of the container network interface are decoupled from the core functional components of the container network interface, the extended functional components do not have to rely on the original CNI binary / daemon code, but can be obtained through binary development through an independent code repository, which makes the development threshold of the extended functional components low and can ensure rapid iteration.

[0041] By providing a general function extension framework for running extended function components on the daemon of the container network interface, the extended function components of the container network interface can be decoupled from the core function components of the container network interface, so that the extended function components do not rely on the code of the core function components / daemon process and are developed in the form of independent binaries. In other words, by running the extended function components through the function extension framework, there is no need to nest the extended function components in the daemon process or connect them in series with the core function components, thereby achieving the decoupling of the extended function components of the container network interface from the core function components.

[0042] When an extended function component needs to be run in a node of the container cluster, the extended function component can be sent to the node alone. When the extended function component does not need to be run on the node, the extended function component is no longer sent to the node to avoid wasting node resources.

[0043] In step 120, in response to the component running request, the target extended functional component is run through the functional extension framework. When the target extended functional component is running, the container network data of the core functional component required for the target extended functional component to run is obtained from the daemon process through the data query interface of the functional extension framework.

[0044] Here, the function extension framework responds to the component operation request, and runs the target extended function component indicated by the component operation request in the function extension framework to perform a preset network management action on the container network interface. Among them, the preset network management action refers to the function corresponding to the target extended function component. When the target extended function component is running, the target extended function component can obtain the container network data of the core function component required for the operation of the target extended function component through the data query interface provided by the function extension framework.

[0045] It is worth noting that when the target extended functional component is running, it may also need to dynamically obtain the container network data of the container. The container network data may include the container list of this node, the network namespace of each container, the network device information assigned to each container (including device name, device ID (Identity document, unique code), driver type, etc.) and at least one of the IP addresses assigned to each container. Since the network device and IP address of the container are created and assigned by the core functional component of the container network interface, the container network data of the container will be maintained inside the daemon process of the container network interface. Through the data query interface provided by the functional extension framework, when the target extended functional component is running, the target extended functional component can obtain the container network data of the core functional component required for the operation of the target extended functional component from the daemon process through the data query interface.

[0046] Through the data query interface, real-time and queryable container network data of the core function components can be provided to the extended function components during their runtime to support the operation of the extended function components, so that the extended function components can obtain the container network data required for operation without relying on the code of the core function components, thereby achieving decoupling of the extended function components and the core function components, allowing the extended function components and the core function components to run independently.

[0047] Figure 2 FIG. 1 is a schematic diagram of an architecture of a functional expansion framework according to some embodiments. Figure 2As shown, a container is deployed in a host machine (which can be a physical machine or a virtual machine), and the core functions of the container network interface are configured by the CNI core function component. Among them, the core functions include IP allocation, routing management, and network card management. The extended functions of the container network interface are configured by running the corresponding extended function components through the function extension framework. Among them, the extended functions can include dynamic traffic observation, customized policies, dynamic traffic governance, diagnosis, traffic packet capture, and other extended functions. The function extension framework runs the extended function components used to implement specific extended functions. When the extended function components are running, they obtain the container network data required by the extended function components through the data query interface.

[0048] In some embodiments, the extended functional component includes at least one of the following: a detection component for detecting the health status of the container network interface, a traffic packet capture component for capturing the container traffic of the container network interface, and a traffic management component for adjusting the traffic control policy of the container network interface.

[0049] For example, in a production environment, in order to ensure the network connectivity of the container, CNI needs to have a self-checking function to check the health status of CNI and its upstream and downstream dependencies, verify the host's routing, network card configuration, etc. Since the process of these self-checking operations is relatively lengthy, they are often triggered to run under abnormal circumstances and do not need to be run continuously / regularly in the CNI core function. At this time, running the detection component through the function extension framework can decouple the detection function from the core function of CNI.

[0050] When a communication anomaly occurs in a container in an online environment, it is often necessary to capture the traffic of the corresponding container. Through the function extension framework provided in the embodiment of the present disclosure, CNI can support the extended function components issued by the operation and maintenance platform for implementing the traffic packet capture function, and run the traffic packet capture component through the function extension framework to ensure that the traffic packet capture action can be completed safely and timely.

[0051] In addition, there are different traffic management methods in different scenarios. For example, traffic management includes operations such as modifying the traffic DSCP priority, configuring network card queues and network card queuing rules, changing container network system parameters, etc. If the management functions of all scenarios are integrated into the core functional components of the container network interface, the core functional components will be extremely bloated and have high maintenance costs, and some traffic management methods will even cause performance losses in unused scenarios. Through the function extension framework provided by the embodiment of the present disclosure, the traffic management component for realizing dynamic traffic management applicable to the scenario can be dynamically sent to the function extension framework based on different scenarios, so that the function extension framework executes the traffic management component to realize the traffic management of the corresponding scenario, and after the traffic management is completed, the traffic management component is immediately cleaned up to avoid performance loss. It should be noted that adjusting the traffic control strategy of the container network interface includes operations such as modifying the traffic DSCP priority, configuring network card queues and network card queuing rules, and changing the container network system parameters.

[0052] It is worth noting that after the function extension framework receives the component operation request, the function extension framework authenticates the component operation request, and after the authentication is passed, the function extension framework responds to the component operation request and operates the target extended function component through the function extension framework. Exemplarily, the component operation request may carry the identity information and authentication information of the client sending the component operation request, and the function extension framework performs authentication based on the identity information and authentication information.

[0053] Thus, by receiving the component operation request through the function extension framework running on the container network interface daemon process, and responding to the component operation request, the target extended function component is run through the function extension framework, and when the target extended function component is running, the container network data of the core function component required for the target extended function component to run is obtained from the daemon process through the data query interface of the function extension framework, so that the extended function component of the container network interface can be decoupled from the core function component of the container network interface, thereby ensuring that the core function component of CNI can be kept simple and clean logically, and the business logic is clear, so as to facilitate the location of problems. Moreover, by decoupling the extended function component from the core function component, the extended function component of the non-core function can also be developed independently, ensuring the rapid iteration and deployment of the extended function. In addition, by decoupling the extended function component from the core function component, the extended function can also be deployed, run, and destroyed instantly according to the actual scenario requirements within a specific range, avoiding the interference of global deployment on non-target nodes and containers.

[0054] In some feasible implementations, in step 120, an operating environment isolated from core functional component resources may be created through the execution layer of the functional extension framework, and the target extended functional component may be run based on the operating environment.

[0055] Here, the resource-isolated operating environment means that the resources used by the operating environment of the extended functional component are isolated from the resources used by the core functional component. By providing a resource-isolated operating environment, the extended functional component can be prevented from crashing and affecting the core functional component when it is running.

[0056] It is worth mentioning that the execution layer of the function extension framework is responsible for creating a resource-isolated operating environment and running extended function components.

[0057] Therefore, by running the target extension function component in a resource-isolated operating environment, it is possible to avoid the hardware resource pressure on the CNI core function component caused by running the target extension function component, thereby avoiding affecting the core business logic.

[0058] Figure 3 FIG. 1 is a flowchart of operating a target expansion functional component according to some embodiments. Figure 3 As shown, in some possible implementations, the target extension function component can be run through the following steps.

[0059] In step 301, resource restriction information, operation parameters and a download link of an executable file corresponding to a target extended function component are read from a component operation request.

[0060] Here, the resource restriction information refers to the information about the resources that the target extended function component can use. Exemplarily, the resource restriction information may include at least one of the maximum running time of the extended function component, the upper limit of the CPU resources used by the extended function component, the upper limit of the memory resources used by the extended function component, and the number of instances of the same extended function component running simultaneously on the same node.

[0061] The operation parameters may refer to basic parameters used to pass into the extended function component, so as to indicate the object on which the extended function component acts through the operation parameters. Before the extended function component runs, the function extension framework renders the corresponding values ​​in the extended function component as corresponding operation parameters to initialize the extended function component.

[0062] Exemplarily, the operating parameters may include at least one of Table 1.

[0063] Table 1:

[0064] The download link of the executable file (also called binary file) corresponding to the target extended functional component refers to the remote address where the executable file corresponding to the target extended functional component is located. For example, the download link may be a repository link of the code repository where the executable file is located.

[0065] The component operation request may carry resource restriction information, operation parameters and download links, and the function extension framework reads the corresponding information from the component operation request. Of course, the component operation request may also carry the name of the extended function component, the dependency information of the extended function component and other information. Among them, the dependency information means that the operation of a certain extended function component depends on other extended function components. By carrying the dependency information, the target extended function component can be guaranteed to run successfully.

[0066] In step 302, the executable file of the target extended functional component is downloaded based on the download link through the execution layer, and a resource group isolated from the core functional component resources is created for the executable file and hardware resources matching the resource restriction information are allocated to the resource group.

[0067] Here, before the target extended functional component is started, the execution layer of the functional extension framework downloads the corresponding executable file from the remote end where the target extended functional component is stored according to the download link carried in the component running request. It should be noted that the interface layer of the functional extension framework does not directly transmit the executable file of the target extended functional component. After the task corresponding to the target extended functional component is scheduled to the execution thread, the execution layer downloads the executable file through the download link.

[0068] The execution layer of the function extension framework creates a resource isolation resource group (cgroup) for each extended function component, and allocates corresponding hardware resources to the resource group according to the resource restriction information carried in the component operation request. Of course, in this process, the execution layer will also allocate an independent working directory for each extended function component to store the operation logs, monitoring information, operation results, etc. generated by the extended function component during operation.

[0069] In step 303, the executable file is started according to the running parameters, and the executable file is run based on the resource group.

[0070] Here, the execution layer of the function extension framework starts the executable file according to the running parameters carried in the component running request, and redirects the running logs, monitoring information, running results, etc. generated by the extended function component during running to the working directory. Then, the execution layer of the function extension framework runs the executable file corresponding to the target extended function component based on the configured resource group.

[0071] It should be noted that starting the executable file according to the running parameters can be understood as rendering the running parameters to the parameter positions corresponding to the executable file to complete the initialization of the executable file.

[0072] Therefore, through the above implementation, the target extended functional component runs under a resource group with resource isolation, which can prevent the target extended functional component from affecting the core functional component.

[0073] In some achievable implementations, the component running status of the target extended functional component can also be obtained through the execution layer, and the component running status can be reported to the scheduling layer of the functional extension framework. The life cycle of the target extended functional component can be controlled based on the component running status through the scheduling layer, and / or the component running status can be fed back to the client that sent the component running request through the scheduling layer.

[0074] Here, during the operation of the target extended functional component, the functional extension framework will continuously observe the component operation status of the target extended functional component and report it to the scheduling layer of the functional extension framework. The scheduling layer of the functional extension framework controls the life cycle of the target extended functional component based on the component operation status. For example, when the host machine resources are insufficient, the scheduling layer can terminate the operation of the extended functional component in time based on the component operation status.

[0075] Of course, the scheduling layer of the function extension framework can feedback the component running status to the client that sends the component running request, so that the operation and maintenance personnel can grasp the component running status of the target extended function component. In some application scenarios, the client can request the function extension framework to terminate the running of the extended function component according to the component running status.

[0076] It is worth noting that, in the embodiment of the present disclosure, the execution layer of the function extension framework is responsible for creating a resource-isolated operating environment, downloading and running corresponding executable files, and providing real-time component operating status observation.

[0077] Therefore, by acquiring the component running status of the target extended functional component through the execution layer, the component running status can be observed in real time, and the component running status of the extended functional component can be globally maintained.

[0078] In some feasible implementation manners, when the target extended functional component terminates execution, the execution layer may also clean up the execution environment and the target extended functional component.

[0079] Here, the termination of the target extended functional component may refer to the completion of the execution of the target extended functional component, or may refer to the passive termination of the target extended functional component. For example, the client may terminate the operation of the target extended functional component at any time, and the scheduling layer of the functional extension framework may also terminate the operation of the target extended functional component according to the component operation status. In other words, the termination of the operation of the target extended functional component may be active or passive.

[0080] When the target extended function component stops running, the executable file corresponding to the target extended function component will be completely cleaned up to avoid wasting resources and affecting container performance. At the same time, when the target extended function component stops running, the operating environment corresponding to the target extended function component will also be cleaned up to release resources. Exemplarily, when the target extended function component stops running, the execution layer can clean up the working directory and resource group corresponding to the target extended function component.

[0081] It is worth noting that when the target extended function component terminates its operation, the execution layer cleans up the operating environment and the target extended function component of the target extended function component, so that the extended function component can be triggered, run and cleaned up immediately.

[0082] Therefore, through the above implementation, by immediately cleaning up the running environment and executable files, it is possible to avoid wasting resources and affecting container performance.

[0083] In some feasible implementations, in step 120, based on the scheduling layer of the function extension framework, a target thread is allocated to the target extension function component, and the execution layer of the function extension framework is called to run the target extension function component based on the target thread, and during the running of the target extension function component, the scheduling layer manages the life cycle of the target extension function component.

[0084] Here, the function extension framework receives component operation requests through the interface layer and distributes the component operation requests to the scheduling layer. The scheduling layer executes the corresponding component operation requests through different schedulers.

[0085] The scheduling layer of the function extension framework holds a thread pool. The scheduling layer can check whether the target extension function component can be run according to the concurrency and resource requirements of the component running request. When the target extension function component can be run, the scheduling layer allocates a target thread to the target extension function component. It should be understood that the target thread allocated to the target extension function component can be an available thread.

[0086] Next, the scheduling layer calls the execution layer of the function extension framework to run the target extension function component based on the target thread, and during the operation of the target extension function component, the scheduling layer manages the life cycle of the target extension function component. That is, in the embodiment of the present disclosure, the scheduling layer is used to manage the thread resources and life cycle of the extension function component.

[0087] Therefore, through the above implementation, the scheduling layer can schedule the execution layer to run the target extended functional component, and the scheduling layer can manage the life cycle of the target extended functional component.

[0088] In some achievable implementations, the component operation logic corresponding to the target extended functional component is determined according to the component operation type of the target extended functional component, and according to the component operation logic, the execution layer is called to operate the target extended functional component based on the target thread.

[0089] Here, the component running type is used to indicate the task type corresponding to the extended function component. In the embodiment of the present disclosure, different extended function components may correspond to different component running types. The component running type may include a synchronous task type, an asynchronous task type, and a background resident task type.

[0090] Exemplarily, the component running request may carry the component running type corresponding to the target extended function component, and the scheduling layer may obtain the component running type from the component running request.

[0091] The component operation logic may refer to the operation mode of the extended function component. For extended function components of different component operation types, there are different component operation logics, so that the scheduling layer can execute the extended function components on demand in different ways. For example, for extended function components of synchronous task type and asynchronous task type, the corresponding component operation logic includes registering a timeout timer and terminating the operation of the extended function component after the timeout timer times out. For extended function components of background resident task type, there is no need to register a timeout timer, that is, the extended function component of the background resident task type will not terminate due to timeout.

[0092] In addition, for extended functional components of synchronous task types that need to return results immediately, the component operation logic also includes pulling up available threads to call the execution layer to block the execution of the extended functional components, and after completion, notifying the interface layer to return the results to the client or actively calling the execution layer to terminate the extended functional components when the timeout occurs. For example, when the network connectivity of the container fails, the operation and maintenance personnel can send an immediate extended functional component for diagnosis through the operation and maintenance platform. This extended functional component will quickly check whether the network namespace of the container exists, whether the network card is pulled up, whether the IP allocation is normal, and other inspection items.

[0093] For extended function components of asynchronous task types that do not require blocking and waiting, the component operation logic also includes the scheduler notifying the interface layer to return the http response immediately after calling the execution layer to start asynchronous execution, and polling to check the component operation status, waiting for the extended function component to complete execution or actively terminating the extended function component after timeout. For example, when it is necessary to capture the traffic of the container network, the operation and maintenance personnel can send and send the extended function component for packet capture through the operation and maintenance platform. This extended function component will run the specified event in the background and upload the collected traffic back to the operation and maintenance platform.

[0094] For extended function components of the background resident task type, the component operation logic also includes scheduling to pull up the extended function components and continuously monitoring the health status of the extended function components. For example, during peak traffic periods, it is necessary to repeatedly prioritize the data packets of the traffic of a specific container. The operation and maintenance personnel can issue extended function components for traffic control to achieve customized traffic management.

[0095] That is to say, the component operation logic of the extended function component includes the pre-operation of initializing the extended function component (such as registering a timer, etc.) and the scheduling operation when the extended function component is running. It is worth noting that according to different component operation logics, different extended function components can be assigned to different task queues for scheduling and execution.

[0096] Figure 4 FIG. 1 is a logical diagram of a scheduling layer according to some embodiments. Figure 4 As shown, the scheduling layer determines the extended function component to be scheduled from the component running request and verifies the component concurrency. When the concurrency is met, it requests available threads from the thread pool. When the concurrency is exceeded, it returns that the component failed to run. Among them, the scheduling layer can query the executing task (Working) from the thread pool, and the thread pool returns the task list. The scheduling layer verifies the component concurrency based on the task list. When the concurrency is met, the scheduling layer requests threads from the thread pool, and the thread pool selects available threads from the idle threads (Free) and returns the available threads.

[0097] Next, the scheduling layer performs synchronous component scheduling, asynchronous component scheduling, or resident component scheduling according to the component operation type of the extended function component to schedule the execution layer to run the extended function component. Among them, synchronous component scheduling and asynchronous component scheduling require the registration of a timeout timer. When the timeout occurs, the scheduling layer notifies the execution layer to terminate the operation of the extended function component. For extended function components scheduled by synchronous components, the scheduling layer blocks the execution of the extended function component and returns the operation result to the client. For asynchronous component scheduling or resident component scheduling, the operation result is returned to the client after the extended function component is completed.

[0098] Therefore, through the above implementation, for extended function components of different component operation types, the execution layer can be scheduled to run the extended function components according to different component operation logics, so as to run the extended function components on demand in different ways.

[0099] In some feasible implementations, the function extension framework may also return the running result and / or component running status of the target extended function component to the client that sends the component running request.

[0100] Here, the function extension framework may actively or passively return the operation result and / or component operation status of the target extended function component to the client. For example, after the target extended function component has finished running, the function extension framework actively returns the operation result to the client. For another example, the function extension framework may receive a query request sent by the client, and the function extension framework returns the operation result to the client in response to the query request.

[0101] The operation result of the extended function component includes the start operation time, the end operation time, the component operation state, and the result indicating success or failure. Of course, if the component fails to operate, the reason for the component failure can also be included in the operation result.

[0102] It is worth noting that each extended function component running in the function extension framework may have a corresponding task identifier, and the client may query the running result and / or component running status of the corresponding extended function component through the task identifier.

[0103] Therefore, through the above implementation, the function extension framework can feed back the operation result and / or component operation status of the extended function component to the client, so that the operation and maintenance personnel can accurately understand the operation status of the component.

[0104] In some feasible implementations, in step 110, a component execution request is received through an external interface provided by a function extension framework.

[0105] Here, the external interface is used to support the function extension framework to perform data interaction with the client, wherein the data interaction includes receiving a component operation request sent by the client and returning an operation result and / or a component operation status to the client.

[0106] The component running request is sent by the client to at least one node in the container cluster. That is, the client can indicate at least one node in the container cluster as a target node to indicate running the target extended function component on the target node.

[0107] It is worth noting that by sending a component running request to at least one node in the container cluster, the client can select one or more nodes to run the target extended functional component, instead of all nodes in the container cluster running the target extended functional component, thereby realizing on-demand running of the extended functional component to reduce the overhead of the extended functional component.

[0108] Therefore, through the above implementation, the function extension framework can interact with the client through the external interface, and enable the client to instruct one or more nodes in the container cluster to run the extended function component, thereby running the extended function component on demand and reducing overall overhead.

[0109] In some feasible implementations, a component running request sent by a client is received through a function extension framework, wherein a target extended function component carried in the component running request is dynamically determined by the client according to a network status of a container network interface and sent to the function extension framework.

[0110] Here, the network status of the container network interface may refer to a network anomaly that occurs in the container network interface or to the real-time traffic status of the container network interface. Different extended functional components may correspond to different network statuses. The client may select a corresponding extended functional component for the container network interface based on the network status of the container network interface of each node in the container cluster and send the extended functional component to the corresponding node.

[0111] Therefore, the client can dynamically send extended function components that meet the requirements of the node to each node in the container cluster through component running requests.

[0112] Therefore, through the above implementation, the extended function component can be dynamically delivered to each node of the container cluster to meet the different network requirements of different nodes.

[0113] In some possible implementations, the function extension framework includes an interface layer, a scheduling layer, and an execution layer; The interface layer includes an external interface and a data query interface. The external interface is used to receive component operation requests and distribute component operation requests to the scheduling layer. The data query interface is used to obtain the container network data of the core functional components required for the operation of the target extended functional components from the daemon process. The scheduling layer is used to respond to component running requests, allocate thread resources to the target extended function component, and schedule the execution layer to run the target extended function component, and manage the life cycle of the target extended function component during the running process of the target extended function component; The execution layer is used to respond to the scheduling request of the scheduling layer, create an operating environment isolated from the core functional component resources, and run the target extended functional component based on the operating environment.

[0114] Figure 5 FIG. 1 is a schematic diagram of the architecture of a function expansion framework according to some other embodiments. Figure 5As shown, the extended function framework includes an interface layer, a scheduling layer, and an execution layer. Among them, the interface layer includes an external interface and a data query interface, through which data can be interacted with the client to support the distribution of extended function components and query of operation results. Of course, the component operation request can also be authenticated through the external interface. The data query interface is used for the extended function component to obtain the required container network data of the core function component. The scheduling layer receives the component operation request distributed by the external interface, and performs synchronous component scheduling, asynchronous component scheduling, or resident component scheduling according to the component operation type of the extended function component through the scheduler to schedule the execution layer to run the target extended function component. The execution layer encapsulates the action of pulling up / terminating the scheduling layer thread. The execution layer is used to respond to the scheduling of the scheduling layer, create and clean up the resource-isolated operating environment (resource group), download and run the executable file, and provide real-time component operation status observation. When running the executable file of the target extended function component, the executable file obtains the container network data required for the executable file to run from the daemon process through the data query interface.

[0115] Figure 6 FIG. 1 is a flow chart of a method for controlling network functions based on a container network according to some other embodiments. Figure 6 As shown, the embodiment of the present disclosure provides a network function control method based on a container network, which can be executed by an electronic device, specifically by a network function control device based on a container network, which can be implemented by software and / or hardware and configured in an electronic device. It should be understood that the electronic device can be a client. Figure 6 As shown, the method may include the following steps.

[0116] S601, sending a component running request to the function extension framework running on the container network interface daemon process, the component running request is used to instruct the function extension framework to run the target extended function component that performs a preset network management action on the container network interface, the component running request is used to enable the function extension framework to run the target extended function component, when the target extended function component is running, the container network data required for the operation of the target extended function component is obtained from the core function component of the container network interface through the data query interface of the function extension framework, the function extension framework adopts a decoupled mode to operate and maintain the core function components and extended function components of the container network interface.

[0117] It is worth noting that the detailed description of the above implementation mode can refer to the relevant description of the above embodiment, which will not be repeated here.

[0118] In some practicable implementations, at least one target node may be determined from nodes included in the container cluster, and a function extension framework on the at least one target node may send a component running request.

[0119] Here, the operation and maintenance personnel can select one or more nodes in the container cluster through the client to run the target extended functional component, instead of all nodes in the container cluster running the target extended functional component, thereby running the extended functional component on demand to reduce the overhead of the extended functional component.

[0120] Therefore, through the above implementation, it is possible to run the extended functional components on demand and reduce the overall overhead.

[0121] In some feasible implementations, the running result and / or component running status of the target extended functional component returned by the functional extension framework may be received.

[0122] Figure 7 FIG. 1 is a schematic diagram of a network function control device based on a container network according to some embodiments. Figure 7 As shown, the embodiment of the present disclosure provides a network function control device 700 based on a container network, and the network function control device 700 based on a container network includes: The receiving module 701 is configured to receive a component operation request through a function extension framework running on a container network interface daemon process, wherein the function extension framework operates and maintains the core function components and the extended function components of the container network interface in a decoupled mode, and the component operation request is used to instruct the operation of a target extended function component that performs a preset network management action on the container network interface; The running module 702 is configured to respond to the component running request, run the target extended functional component through the functional extension framework, and when the target extended functional component is running, obtain the container network data of the core functional component required for the running of the target extended functional component from the daemon process through the data query interface of the functional extension framework.

[0123] Optionally, the operation module 702 is specifically configured to: An operating environment isolated from the core functional component resources is created through the execution layer of the functional extension framework, and the target extended functional component is operated based on the operating environment.

[0124] Optionally, the operation module 702 is specifically configured to: Reading resource restriction information, operation parameters and a download link of an executable file corresponding to the target extended function component from the component operation request; Downloading the executable file of the target extended functional component based on the download link through the execution layer, creating a resource group isolated from the core functional component resources for the executable file, and allocating hardware resources matching the resource restriction information to the resource group; The executable file is started according to the running parameter, and the executable file is run based on the resource group.

[0125] Optionally, the operation module 702 is further configured to: Acquire the component running status of the target extended functional component through the execution layer, and report the component running status to the scheduling layer of the functional extension framework; The scheduling layer controls the life cycle of the target extended functional component based on the component running state, and / or the scheduling layer feeds back the component running state to the client sending the component running request.

[0126] Optionally, the operation module 702 is further configured to: When the target extended functional component stops running, the execution layer cleans up the running environment of the target extended functional component and the target extended functional component.

[0127] Optionally, the operation module 702 is specifically configured to: Allocating a target thread to the target extended functional component based on the scheduling layer of the functional extension framework; The execution layer of the function extension framework is called to run the target extension function component based on the target thread, and the scheduling layer manages the life cycle of the target extension function component during the running of the target extension function component.

[0128] Optionally, the operation module 702 is specifically configured to: Determining the component operation logic corresponding to the target extended functional component according to the component operation type of the target extended functional component; According to the component running logic, the execution layer is called to run the target extended function component based on the target thread.

[0129] Optionally, the container network-based network function control 700 further includes: The return module is configured to return the running result and / or component running status of the target extended functional component to the client sending the component running request through the functional extension framework.

[0130] Optionally, the receiving module 701 is specifically configured to: The component running request is received through an external interface provided by the function extension framework, wherein the component running request is sent by a client to at least one node in the container cluster, and the external interface is used to support data interaction between the function extension framework and the client.

[0131] Optionally, the functional extension framework includes an interface layer, a scheduling layer and an execution layer; The interface layer includes an external interface and a data query interface, the external interface is used to receive the component operation request and distribute the component operation request to the scheduling layer, and the data query interface is used to obtain the container network data of the core functional component required for the operation of the target extended functional component from the daemon process; The scheduling layer is used to respond to the component running request, allocate thread resources to the target extended functional component, schedule the execution layer to run the target extended functional component, and manage the life cycle of the target extended functional component during the running process of the target extended functional component; The execution layer is used to create an operating environment isolated from the core functional component resources in response to the scheduling request of the scheduling layer, and run the target extended functional component based on the operating environment.

[0132] Optionally, the receiving module 701 is specifically configured to: The component running request sent by the client is received through the function extension framework, wherein the target extended function component carried by the component running request is dynamically determined by the client according to the network status of the container network interface and sent to the function extension framework.

[0133] Optionally, the extended function component includes at least one of the following: A detection component for detecting the health status of the container network interface, a traffic packet capture component for capturing the container traffic of the container network interface, and a traffic management component for adjusting the traffic control strategy of the container network interface.

[0134] Regarding the logic of the method executed by each functional module in the above-mentioned container network-based network function control device 700, reference can be made to the part of the method related to the above-mentioned embodiment, which will not be repeated here.

[0135] Figure 8 FIG. 1 is a schematic diagram of a network function control device based on a container network according to some other embodiments. Figure 8 As shown, the embodiment of the present disclosure provides a network function control 800 based on a container network. The network function control device 800 based on a container network includes: The sending module 801 is configured to send a component running request to the function extension framework running on the container network interface daemon process, where the component running request is used to instruct the function extension framework to run the target extended function component that performs a preset network management action on the container network interface. The component running request is used to enable the function extension framework to run the target extended function component. When the target extended function component is running, the container network data required for the operation of the target extended function component is obtained from the core function component of the container network interface through the data query interface of the function extension framework. The function extension framework adopts a decoupled mode to operate and maintain the core function components and extended function components of the container network interface.

[0136] Optionally, the sending module 801 is specifically configured to: At least one target node is determined from the nodes included in the container cluster, and a component running request is sent to a function extension framework on the at least one target node.

[0137] Regarding the logic of the method executed by each functional module in the above-mentioned container network-based network function control device 800, reference can be made to the part of the method related to the above-mentioned embodiment, and no further details will be given here.

[0138] Reference below Fig. 9 , which shows a schematic diagram of the structure of an electronic device (such as the client or server in the above embodiment) 900 suitable for implementing the embodiment of the present disclosure. The terminal device in the embodiment of the present disclosure may include but is not limited to mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle terminals (such as vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Fig. 9 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0139] like Fig. 9 As shown, the electronic device 900 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage device 908 into a random access memory (RAM) 903. In the RAM 903, various programs and data required for the operation of the electronic device 900 are also stored. The processing device 901, the ROM 902, and the RAM 903 are connected to each other via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0140] Typically, the following devices may be connected to the I / O interface 905: an input device 906 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 907 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 908 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 909. The communication device 909 may allow the electronic device 900 to communicate with other devices wirelessly or by wire to exchange data. Although Fig. 9 The electronic device 900 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0141] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device 909, or installed from a storage device 908, or installed from a ROM 902. When the computer program is executed by the processing device 901, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

[0142] It should be noted that the computer-readable medium mentioned above in the present disclosure may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. Computer readable signal media may also be any computer readable medium other than computer readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0143] In some embodiments, the client and the server may communicate using any currently known or future developed network protocol such as HTTP (HyperText Transfer Protocol), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or future developed network.

[0144] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device.

[0145] The computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device: receives a component operation request through a function extension framework running on a container network interface daemon process, wherein the function extension framework operates and maintains the core function components and the extended function components of the container network interface in a decoupled mode, and the component operation request is used to indicate the operation of a target extended function component that performs a preset network management action on the container network interface; responds to the component operation request, operates the target extended function component through the function extension framework, and when the target extended function component is running, obtains the container network data of the core function component required for the operation of the target extended function component from the daemon process through the data query interface of the function extension framework.

[0146] Alternatively, the computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device: sends a component running request to a function extension framework running on a container network interface daemon process, the component running request is used to instruct the function extension framework to run a target extended function component that performs a preset network management action on the container network interface, the component running request is used to enable the function extension framework to run the target extended function component, when the target extended function component is running, the container network data required for the operation of the target extended function component is obtained from the core function component of the container network interface through the data query interface of the function extension framework, and the function extension framework adopts a decoupled mode to operate and maintain the core function components and extended function components of the container network interface.

[0147] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages ​​or a combination thereof, including, but not limited to, object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0148] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0149] The modules involved in the embodiments described in the present disclosure may be implemented by software or hardware, wherein the name of a module does not, in some cases, limit the module itself.

[0150] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0151] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0152] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present disclosure (but not limited to) by each other to form a technical solution.

[0153] In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

[0154] Although the subject matter has been described in language specific to structural features and / or method logic actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims. Regarding the device in the above embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

Claims

1. A network function control method based on container network, characterized in that: include: A component operation request is received through a function extension framework running on a container network interface daemon process, wherein the function extension framework operates and maintains a core function component and an extended function component of the container network interface in a decoupled mode, and the component operation request is used to instruct the operation of a target extended function component that performs a preset network management action on the container network interface; In response to the component running request, the target extended functional component is run through the functional extension framework. When the target extended functional component is running, the container network data of the core functional component required for the running of the target extended functional component is obtained from the daemon process through the data query interface of the functional extension framework.

2. The method according to claim 1, characterized in that: The step of running the target extended functional component through the functional extension framework includes: An operating environment isolated from the core functional component resources is created through the execution layer of the functional extension framework, and the target extended functional component is operated based on the operating environment.

3. The method according to claim 2, characterized in that The step of creating an operating environment isolated from the core functional component resources through the execution layer of the functional extension framework, and running the target extended functional component based on the operating environment, includes: Reading resource restriction information, operation parameters and a download link of an executable file corresponding to the target extended function component from the component operation request; Downloading the executable file of the target extended functional component based on the download link through the execution layer, creating a resource group isolated from the core functional component resources for the executable file, and allocating hardware resources matching the resource restriction information to the resource group; The executable file is started according to the running parameter, and the executable file is run based on the resource group.

4. The method according to claim 2, characterized in that: The method further comprises: Acquire the component running status of the target extended functional component through the execution layer, and report the component running status to the scheduling layer of the functional extension framework; The scheduling layer controls the life cycle of the target extended functional component based on the component running state, and / or the scheduling layer feeds back the component running state to the client sending the component running request.

5. The method according to claim 2, characterized in that: The method further comprises: When the target extended functional component stops running, the execution layer cleans up the running environment of the target extended functional component and the target extended functional component.

6. The method according to claim 1, characterized in that The step of running the target extended functional component through the functional extension framework includes: Allocating a target thread to the target extended functional component based on the scheduling layer of the functional extension framework; The execution layer of the function extension framework is called to run the target extension function component based on the target thread, and the scheduling layer manages the life cycle of the target extension function component during the running of the target extension function component.

7. The method according to claim 6, characterized in that The execution layer calling the function extension framework runs the target extension function component based on the target thread, including: Determining the component operation logic corresponding to the target extended functional component according to the component operation type of the target extended functional component; According to the component running logic, the execution layer is called to run the target extended function component based on the target thread.

8. The method according to claim 1, characterized in that: The receiving a component running request through a function extension framework running on a container network interface daemon process includes: The component running request is received through an external interface provided by the function extension framework, wherein the component running request is sent by a client to at least one node in the container cluster, and the external interface is used to support data interaction between the function extension framework and the client.

9. The method according to claim 1, characterized in that: The functional expansion framework includes an interface layer, a scheduling layer and an execution layer; The interface layer includes an external interface and a data query interface, the external interface is used to receive the component operation request and distribute the component operation request to the scheduling layer, and the data query interface is used to obtain the container network data of the core functional component required for the operation of the target extended functional component from the daemon process; The scheduling layer is used to respond to the component running request, allocate thread resources to the target extended functional component, schedule the execution layer to run the target extended functional component, and manage the life cycle of the target extended functional component during the running process of the target extended functional component; The execution layer is used to create an operating environment isolated from the core functional component resources in response to the scheduling request of the scheduling layer, and run the target extended functional component based on the operating environment.

10. The method according to claim 1, characterized in that The receiving a component running request through a function extension framework running on a container network interface daemon process includes: The component running request sent by the client is received through the function extension framework, wherein the target extended function component carried by the component running request is dynamically determined by the client according to the network status of the container network interface and sent to the function extension framework.

11. The method according to any one of claims 1 to 10, characterized in that The extended function component includes at least one of the following: A detection component for detecting the health status of the container network interface, a traffic packet capture component for capturing the container traffic of the container network interface, and a traffic management component for adjusting the traffic control strategy of the container network interface.

12. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processing device, the steps of the method according to any one of claims 1 to 11 are implemented.

13. An electronic device, characterized in that: include: a storage device having a computer program stored thereon; A processing device, configured to execute the computer program in the storage device to implement the steps of the method according to any one of claims 1 to 11.

14. A computer program product comprising a computer program, 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 11 are implemented.

Images