Deployment method and apparatus for a single-core operating system based on edge-departure in a serverless framework

Abstract

This invention discloses a deployment method for a serverless framework based on a single-core operating system with a sidecar-free architecture. The method integrates the functionality of the sidecar container into an external extension library within the single-core operating system, known as the Lib-Sidecar. The Lib-Sidecar includes three servers: a main server for traffic forwarding, a performance metrics server for detecting concurrency and used as a basis for scaling, and a health monitoring server for detecting the health of function containers. A Kubernetes instance deployment file is configured to deploy virtual machines using the Unikernel runtime. Knative identifies the deployed instance as a Unikernel, without injecting sidecar containers or starting Pod instances. During the Unikernel startup phase, Lib-Sidecar starts during the external library initialization phase, ensuring that the Unikernel runtime is compatible with the Knative framework. This method avoids the heavyweight nature of sidecars by designing the sidecar, reducing the memory consumption of service instances, and mitigating the performance loss caused by traffic forwarding from sidecar containers. Furthermore, the external library is integrated into the system kernel, without causing intrusive impact on application deployment.

Description

Technical Field

[0001] This invention belongs to the field of microservice technology, and specifically relates to a method and apparatus for deploying a single-core operating system based on edge-free vehicles in a serverless framework. Background Technology

[0002] Serverless frameworks like Knative allow deployed service instances (Pods) to adaptively scale based on traffic load. Sidecar architecture refers to supplementing a service's functionality by launching an additional component, making it compatible with the requirements of a specific framework. The auxiliary sidecar container starts within the same instance as the service container, freeing the service container from the details of integrating with the serverless framework. However, the sidecar container itself is a heavyweight component, significantly impacting service communication and startup performance within the serverless framework.

[0003] A single-core operating system (Unikernel) is a lightweight, high-performance operating system. It retains only essential system functions, has a much smaller memory footprint than container runtimes, and eliminates the overhead of user-kernel mode switching, resulting in superior service processing performance compared to containers. It is suitable for developing a customized operating system as a runtime for each function service and deploying it. However, the presence of heavyweight components alongside containers prevents Unikernel from fully realizing its advantages as a service runtime.

[0004] Kubernetes is a container orchestration technology that provides containers with a range of functions, including deployment, resource scheduling, service discovery, and dynamic scaling, improving the ease of managing large-scale container clusters. Knative, as an extension of the Kubernetes (K8s) environment, requires that the service container and the sidecar container run consistently when deploying services as instances. Deploying serverless services using Unikernel as the runtime requires developing a Unikernel version of the sidecar, resulting in a massive engineering implementation.

[0005] Existing lightweight serverless deployments that eliminate the need for sidecars are primarily based on the extended Berkeley Packet Filter (eBPF) implemented in container communication scenarios. Representative works include SPRIGHT [QiS, Monis L, Zeng Z, et al. SPRIGHT: extracting the server from serverless computing! high-performance eBPF-based event-driven, shared-memory processing [C] / / Proceedings of the ACM SIGCOMM 2022 Conference. 2022:780-794.] and Cilium [Cilium: eBPF-based Networking, Observability, Security. https: / / cilium.io.]. eBPF communication achieves remote calls between services by embedding bytecode within the system kernel and using shared memory. Its advantage lies in ensuring sidecar functionality while bypassing the heavy overhead of serialization, user-mode switching, and context switching in network communication. However, eBPF functionality is not supported for use in the Unikernel. Another major benefit of eBPF comes from the overhead of user-mode switching, but the monolithic operating system Unikernel itself only has one user mode and cannot fully enjoy the benefits of eBPF.

[0006] Therefore, the current work on achieving lightweight serverless deployment of edge removal vehicles cannot be applied to Unikernel, which is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0007] The purpose of this invention is to provide a method and apparatus for deploying a single-core operating system based on a sidecar in a serverless framework. This method avoids the heavyweight nature of the sidecar by designing a sidecar garage, reduces the memory occupied by service instances, avoids the performance loss caused by sidecar container traffic forwarding, and integrates external libraries into the system kernel without causing intrusive impact on application deployment.

[0008] This invention provides the following technical solution:

[0009] A deployment method for a single-core operating system based on edge-de-carriage in a serverless framework, wherein the deployment method is as follows:

[0010] The functionality of the sidecar container is integrated into an external extension library in a single-core operating system as the sidecar garage Lib-Sidecar. The sidecar garage Lib-Sidecar includes three servers: a main server for traffic forwarding, a performance index server for detecting concurrency and using it as a basis for scaling up and down, and a health detection server for detecting the health of function containers.

[0011] Configure the Kubernetes instance deployment file to deploy virtual machines using the single-core operating system Unikernel runtime. The serverless framework Knative recognizes the deployment instance as Unikernel and no longer injects sidecar containers and starts Pod instances.

[0012] After completing the above configuration, the single-core operating system Unikernel enters the startup phase, and the sidecar starts during the external library initialization phase, ensuring that Unikernel runtime is compatible with the Knative framework.

[0013] Addressing the limitation that current serverless deployment methods for achieving lightweight edgecar deployments cannot be applied to Unikernel, this invention leverages Unikernel's scalability by integrating the functionality of edgecar containers into Unikernel as an external extension library. Specifically, it optimizes Unikernel deployment in serverless scenarios by designing a sidecar library (Lib-Sidecar). This solves the problems of existing solutions being incompatible with Unikernel and the inherent limitations of serverless communication frameworks. Furthermore, the sidecar library avoids the heavyweight nature of edgecars, reduces service instance memory consumption, and mitigates performance losses caused by edgecar container traffic forwarding. Simultaneously, the external library is integrated into the system kernel, without intrusive impact on application deployment.

[0014] The Pod configuration file needs to add an annotation field to inform Kubernetes that the deployment object is a single-core operating system Unikernel. The specific method is as follows: Knative manages the templates for creating Pod services by maintaining a version management component and checks the fields in the annotation. If the field exists, the sidecar container will not be injected when the instance template is deployed.

[0015] The version management component writes the context information related to the sidecar container into the runtime context of the single-core operating system Unikernel for use in the Knative environment.

[0016] The deployment method also includes: developers registering business processing functions and business service functions in the main function to execute business logic when receiving external network requests.

[0017] That is, the user defines a handle_request function (business processing function) to handle requests sent from the gateway and other microservices, and defines the actual execution logic in the handle_service function (business service function).

[0018] In this invention, a serverless framework manages the operation of microservices, a single-core operating system serves as the runtime environment for the microservices, and a sidecar is a component of the single-core operating system that enables it to run within the serverless framework. However, the sidecar itself is merely a shell; users, i.e., developers, need to implement the specific network packet processing logic within `handle_request` and the business logic within `handle_service` after introducing the sidecar.

[0019] When requests sent by the gateway and other microservices arrive at the business processing function after being preprocessed in the Lib-sidecar, the business processing function analyzes and processes the incoming request headers, then calls the business service function to execute the actual logic of the gateway and other microservices. After execution, it returns, and the business processing function finally determines the response status of the network packet.

[0020] Specifically, the preprocessing method for the Lib-sidecar parking garage is as follows:

[0021] The main server in the Lib-sidecar is responsible for receiving incoming requests and executing subsequent actual business processes.

[0022] In Knative, performance metrics periodically send requests to the Lib-sidecar performance metrics server to obtain the current service concurrency, and use this as a basis to send to Knative's Autoscaler instance to implement the scaling of service instances.

[0023] The health monitoring server in the Lib-sidecar is responsible for receiving health status checks from Knative in order to maintain the lifecycle of instances under Knative.

[0024] Specifically, it can be:

[0025] `handle_request` primarily determines different processing logic based on the header of the incoming request packet and different states, while `handle_service` is used to execute the actual business logic. Since virtual machines can communicate via memory-sharing protocols such as virtual machine functions (vmfunc), this type of communication does not require network packet transmission; instead, it directly calls and executes the function logic of the other virtual machine.

[0026] Applications deployed in a serverless framework are typically microservices. A microservice is essentially an HTTP server that executes business logic when receiving external network requests. The Unikernel (a single-core operating system) serves as the runtime for these microservices. Lib-Sidecar is a component that builds the Unikernel, responsible for starting an HTTP server and preprocessing requests from the gateway, such as calculating network throughput and system health. However, Lib-Sidecar itself does not contain business function information. After preprocessing by Lib-Sidecar, network requests reach the business processing function `handle_request`, which requires registration by the user (developer) in the main function. `handle_request` analyzes and processes the incoming request headers. It then calls `handle_service` to execute the actual logic of the microservice, returns upon completion, and finally determines the response status of the network packet.

[0027] Specifically, `Handle_request` handles the status of network packets; for example, 200 indicates an OK request, while 404 indicates an invalid request. `handle_service` is the actual business function, which, for example, expects to store the data from the network packet in the database upon arrival. `handle_service` then tells `handle_request` whether to return 200 or 404 based on the execution result.

[0028] The present invention also provides a deployment apparatus for a single-core operating system based on a sidecar in a serverless framework, including a memory and one or more processors. The memory stores executable code, and when the one or more processors execute the executable code, they are used to implement the above-described deployment method of a single-core operating system based on a sidecar in a serverless framework.

[0029] The present invention also provides a computer-readable storage medium having a program stored thereon, which, when executed by a processor, is used to implement the above-described method for deploying a single-core operating system based on a sidecar in a serverless framework.

[0030] Compared with the prior art, the present invention has the following superior effects:

[0031] Unikraft, representing Unikernel, allows for the extension of system functionality through external libraries. Therefore, the functionalities required for serverless sidecar containers can be integrated into Unikernel as external libraries (Lib-sidecar). Since the Unikernel service itself possesses the necessary functionalities for deployment in a serverless framework, there is no longer a need to start a separate sidecar container, meaning there is no longer a need to implement a dedicated sidecar for the Unikernel runtime.

[0032] In serverless architectures, microservices are deployed as Hypertext Transfer Protocol (HTTP) servers, and Lib-sidecar is essentially an HTTP server as well. Therefore, a Unikernel with built-in microservice capabilities needs to include its own C language extension libraries and network libraries. Adding Lib-sidecar to a Unikernel's service functions does not require importing large third-party libraries; execution logic only needs to be written based on existing extension libraries. Therefore, the introduction of Lib-sidecar will not impact image size or startup time.

[0033] The existence of Lib-sidecar means that traffic requests sent by the gateway and other services no longer need to be forwarded to the Unikernel function on the main server, thus improving the overall system throughput.

[0034] Unikraft itself supports registering and starting external library execution logic during system startup. Therefore, importing Lib-sidecar as an external library to execute the function's logic is non-intrusive. Attached Figure Description

[0035] Figure 1 This is a flowchart of the deployment method in the embodiment.

[0036] Figure 2 This is a schematic diagram of the Lib-sidecar architecture and communication process. Detailed Implementation

[0037] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0038] It should be noted that, unless otherwise specified, the features in the following embodiments and implementation methods can be combined with each other.

[0039] like Figure 1 and Figure 2 As shown, the deployment method of the single-core operating system based on the edge-de-car in a serverless framework provided in this embodiment is as follows:

[0040] S1. Integrate the functionality of the sidecar container into an external extension library in a single-core operating system, as the sidecar garage Lib-Sidecar. The sidecar garage Lib-Sidecar includes three servers: a main server for traffic forwarding, a performance index server for detecting concurrency and using it as a basis for scaling up and down, and a health detection server for detecting the health of function containers.

[0041] Since Knative's sidecar container is implemented in Go, its main logic involves starting a main server (MainServer), a performance metrics server (MetricServer), and a health monitoring server (AdminServer) through three goroutines. These servers are used for traffic forwarding, detecting concurrency levels and serving as the basis for scaling up and down, and checking the health of function containers, respectively. Therefore, Lib-Sidecar, an external extension library that integrates the functionality of the sidecar container into a single-core operating system, also needs to possess the aforementioned sidecar container functionality.

[0042] S2. Configure the Kubernetes instance deployment file to deploy virtual machines using the Unikernel runtime. The serverless framework Knative recognizes the deployment instance as Unikernel and will no longer inject sidecar containers and start Pod instances.

[0043] The specific steps are as follows: The Pod configuration file needs to include the annotation `Unikernel=true` to inform Kubernetes that the deployed object is a Unikernel. Knative manages the templates for creating Pod services by maintaining a version management component (Revision). This component checks the `Unikernel` field in the annotations; if this field exists, the sidecar container will not be injected when deploying the instance template. The version management component writes the sidecar container's context information, such as security context and health probes, into the Unikernel's runtime context for use in the Knative environment.

[0044] S3. After completing the above configuration, the single-core operating system Unikernel enters the startup phase, and the sidecar library Lib-Sidecar starts during the external library initialization phase to ensure that Unikernel can run in the Knative framework.

[0045] S4. Developers register business processing functions and business service functions in the main function to execute business logic when receiving external network requests.

[0046] The specific operation method of S4 is as follows:

[0047] Developers define a `handle_request` function to handle requests arriving at the gateway and from other microservices, and define the actual execution logic in `handle_service`. `handle_request` primarily determines different processing logic based on the packet header and different states of the arriving request, while `handle_service` is used to execute the actual business logic. Since virtual machines can communicate via memory-sharing protocols such as virtual machine functions (vmfunc), this type of communication does not require network packet transmission; instead, it directly calls and executes the function logic of the other virtual machine.

[0048] The three servers in the Lib-sidecar are started during the boot process of the Unikernel virtual machine. Three threads are started in the Lib-sidecar to maintain three HTTP servers: the main server, the performance metrics server, and the health check server, respectively, listening on ports 8012, 8022, and 9090.

[0049] All traffic sent by the gateway and services will reach the corresponding three servers in the Lib-sidecar. The master server is responsible for receiving incoming HTTP requests and executing subsequent business logic. The performance metrics server is used to count the current concurrency of the service. The performance metrics in Knative periodically send requests to the Lib-sidecar performance metrics server to obtain the current concurrency of the service, and use this as a basis to send to the Knative autoscaler instance to implement the scaling of the service instance. The health check server is responsible for receiving health status checks from Knative to maintain the lifecycle of the instances under Knative.

[0050] This example uses a user information query program as an example. Developers deploy the application in Knative using the Unikernel runtime and Lib-sidecar. `Handle_request` receives the pre-processed request packet from Lib-sidecar and encapsulates it into `handle_service`. `handle_service` queries the database based on the user information in the request. If the user information exists, it returns the user information, and `handle_request` sets the request header status to 200, indicating a successful request. If the request does not exist, `handle_service` throws an error result flag, and `handle_request` sets the returned result request header to 404, indicating that the user does not exist. When the request volume increases, Lib-sidecar notifies the Autoscaler based on the statistical concurrency information, and Knative scales up the Pod instances. Similarly, it scales down when the request volume decreases. When there are no requests, the running instances are destroyed.

[0051] In this embodiment, Unikraft allows custom function libraries to be registered at different startup stages of the operating system, and is launched as a third-party library sidecar during the library function (Lib) stage. Service providers that need to use the sidecar functionality only need to reference the sidecar header file and implement `handle_request` and `handle_service`; they do not need to define a main function. Since the sidecar is a functional component of Unikernel, with the Lib-sidecar, Unikernel can connect to and run within the Serverless framework.

[0052] In summary, the single-core operating system deployment method based on edge-free vehicles provided in this embodiment avoids the heavyweight nature of edge vehicles by designing an edge vehicle garage, reduces the memory occupied by service instances, avoids the performance loss caused by edge vehicle container traffic forwarding, and integrates external libraries into the system kernel without causing intrusive impact on application deployment.

[0053] This invention also provides a deployment device for a single-core operating system based on a sidecar in a serverless framework, including one or more processors. Executable code is stored in the memory. When the processor executes the executable code, it implements the deployment method for the single-core operating system based on a sidecar in a serverless framework as described in the above embodiments. Taking software implementation as an example, as a logical device, it is formed by the processor of any data processing device in which it resides reading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, in addition to the processor, memory, network interface, and non-volatile memory, the data processing device in which the device resides in the embodiments may also include other hardware depending on the actual function of the data processing device, which will not be elaborated further.

[0054] This invention also provides a computer-readable storage medium storing a program that, when executed by a processor, implements the deployment method of a single-core operating system based on a sidecar in a serverless framework as described in the above embodiments. The computer-readable storage medium can be an internal storage unit of any data-processing device as described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be any data-processing device, such as a plug-in hard disk, smart media card (SMC), SD card, flash memory card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units of any data-processing device and external storage devices. The computer-readable storage medium is used to store the computer program and other programs and data required by the data-processing device, and can also be used to temporarily store data that has been output or will be output.

[0055] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A method for deploying a single-core operating system based on edge-free vehicles in a serverless framework, characterized in that: The deployment method is as follows: The functionality of the sidecar container is integrated into an external extension library in a single-core operating system as the sidecar garage Lib-Sidecar. The sidecar garage Lib-Sidecar includes three servers: a main server for traffic forwarding, a performance index server for detecting concurrency and using it as a basis for scaling up and down, and a health detection server for detecting the health of function containers. Configure the Kubernetes instance deployment file to deploy virtual machines using the single-core operating system Unikernel runtime. The serverless framework Knative recognizes the deployment instance as Unikernel and no longer injects sidecar containers and starts Pod instances. After completing the above configuration, the single-core operating system Unikernel enters the startup phase, and the sidecar starts during the external library initialization phase, ensuring that Unikernel runtime is compatible with the Knative framework.

2. The deployment method of a single-core operating system based on edge-free vehicles in a serverless framework according to claim 1, characterized in that, The Pod configuration file needs to add an annotation field to inform Kubernetes that the deployment object is a single-core operating system Unikernel. The specific method is as follows: Knative manages the templates for creating Pod services by maintaining a version management component and checks the fields in the annotation. If the field exists, the sidecar container will not be injected when the instance template is deployed.

3. The deployment method of a single-core operating system based on edge-de-car in a serverless framework according to claim 2, characterized in that, The version management component writes the context information related to the sidecar container into the runtime context of the single-core operating system Unikernel for use in the Knative environment.

4. The deployment method of a single-core operating system based on edge-free vehicles in a serverless framework according to claim 1, characterized in that, The deployment method also includes: developers registering business processing functions and business service functions in the main function to execute business logic when receiving external network requests.

5. The deployment method of a single-core operating system based on edge-free vehicles in a serverless framework according to claim 4, characterized in that, When requests sent by the gateway and other microservices arrive at the business processing function after being preprocessed in the Lib-sidecar, the business processing function analyzes and processes the incoming request headers, then calls the business service function to execute the actual logic of the gateway and other microservices. After execution, it returns, and the business processing function finally determines the response status of the network packet.

6. The deployment method of a single-core operating system based on a sidecar in a serverless framework according to claim 5, characterized in that, The main server in the Lib-sidecar is responsible for receiving incoming requests and executing subsequent actual business processes.

7. The deployment method of a single-core operating system based on edge-de-car in a serverless framework according to claim 5, characterized in that, In Knative, performance metrics periodically send requests to the Lib-sidecar performance metrics server to obtain the current service concurrency, and use this as a basis to send to Knative's Autoscaler instance to implement the scaling of service instances.

8. The deployment method of a single-core operating system based on edge-de-car in a serverless framework according to claim 5, characterized in that, The health monitoring server in the Lib-sidecar is responsible for receiving health status checks from Knative in order to maintain the lifecycle of instances under Knative.

9. A deployment apparatus for a single-core operating system based on a de-edge vehicle in a serverless framework, comprising a memory and one or more processors, wherein the memory stores executable code, and the one or more processors execute the executable code to implement the deployment method of the single-core operating system based on a de-edge vehicle in a serverless framework as described in any one of claims 1-8.

10. A computer-readable storage medium having a program stored thereon, which, when executed by a processor, is used to implement the deployment method of the single-core operating system based on the edge-de-cart as described in any one of claims 1-8 in a serverless framework.

Images