Method for scheduling windows application on kubernetes based on computing pool software virtualization mode

Abstract

The application discloses a method for scheduling a Windows application on Kubernetes based on a computing pool software virtualization mode. Compared with a traditional Kubernetes, the technical method can schedule non-containerized applications in a cloud cluster, and solves the problem that some Windows applications cannot be containerized and then scheduled on the cloud. The application can be used for solving the scheduling problem of traditional applications that cannot be adapted to a container environment on the cloud, and has great significance in application.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing, specifically relating to a method for scheduling Windows applications on Kubernetes based on a computing pool-based software virtualization approach. Background Technology

[0002] Cloud computing refers to providing computing services via the internet, rather than relying on the computing power of local devices. It is a new computing model based on virtualization technology and distributed computing, providing users with computing, storage, network, and security resources through internet connectivity. In cloud computing, users can dynamically request and release computing resources according to their needs. This eliminates the need for businesses or individuals to invest heavily in purchasing and maintaining their own hardware, and allows for rapid expansion or contraction of computing power as needed. Cloud computing typically includes three service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), each providing different levels of service and management to meet user needs in different fields and scenarios.

[0003] Containerization is a virtualization technology that packages an application and its dependencies together to form a lightweight, portable runtime environment called a container. Containers provide an isolated runtime environment, allowing applications to run on different computing environments without modification or configuration. Compared to virtual machines, containerization is more lightweight because containers share the host's operating system and only need to contain the application, its dependencies, and some necessary library files. This means containers can start and stop faster and more efficiently, while making better use of host resources, resulting in higher performance and scalability. Another important feature of containerization is portability, as containers provide a consistent runtime environment that can be ported across different computers and cloud service providers. This makes containerization an important tool for modern application development and deployment, especially in microservice architectures and cloud-native applications. Common containerization technologies include Docker and Kubernetes. Docker is a commonly used containerization platform that provides a simple way to package, deploy, and run applications. Kubernetes is a container orchestration platform that automates the management and deployment of containers, achieving high availability and scalability for applications.

[0004] A registry center is a component in a distributed system used to manage service registration and discovery. In a microservices architecture, services are typically broken down into multiple smaller services that need to collaborate to complete business logic. The registry center acts as a bridge between service providers and consumers, enabling them to discover, invoke, and communicate with each other. Registries typically provide the following functionalities: service registration, service discovery, health checks, and load balancing. Commonly used registry centers include ZooKeeper, Consul, and Eureka, all of which can serve as central components for service registration and discovery in microservices architectures. By using a registry center, automated management and reliable communication of services in a microservices architecture can be achieved, thereby improving system reliability and scalability. Summary of the Invention

[0005] The purpose of this invention is to solve the problems existing in the prior art and to provide a method for scheduling Windows applications on Kubernetes based on a computing pool-based software virtualization approach.

[0006] The specific technical solution adopted in this invention is as follows: A method for scheduling Windows applications on Kubernetes using a compute pool-based software virtualization approach includes the following steps: S1. Install Windows applications using the Windows Install file via command line on a virtual machine or physical machine running a Windows operating system. S2. Serverize the installed Windows application, enabling it to provide an RPC server port in the cluster, thus forming a Windows-Server; at the same time, the Windows-Server registers its services with the cluster registry center. S3. Configure a unified scheduling service center (Center-Server) for all Windows Servers within the cluster. The Center-Server provides a unified service interface to external users, including user login and registration, data upload, task submission, and task feedback. Configure a compute pool within the Center-Server to schedule user tasks to a specific compute node. The compute pool implements functions such as a scheduling center, task buffer queue, communication thread pool, timeout handling, and error handling. Deploy the Center-Server and the registry center on Kubernetes in a containerized manner. The scheduling center obtains information about computing nodes within the cluster through the registration center and determines the target computing node for task allocation based on basic information including CPU utilization, memory utilization, and graphics card memory utilization. The task buffer queue is divided into a strong real-time buffer queue and a weak real-time buffer queue. After a user submits a task, the system selects to add the task to the corresponding buffer queue according to the task's real-time requirements. Tasks whose real-time requirements meet the weak real-time standard are added to the weak real-time buffer queue, while tasks whose real-time requirements do not meet the weak real-time standard are added to the strong real-time buffer queue. The communication thread pool is divided into an active communication thread pool and an inactive communication thread pool according to the buffer queue; the active thread pool handles tasks in the strong real-time buffer queue, while the inactive thread pool handles tasks in the weak real-time buffer queue. In the timeout and error handling, the scheduling center determines the task timeout time based on the task's real-time nature and scale when assigning tasks. After a task times out or returns an error, the corresponding communication thread will resend the request or re-add the task to the task buffer queue. After resending more than a certain number of times, an error message will be returned to the user.

[0007] Preferably, in step S1, the Windows application must provide a Windows Install file, and the Windows application must support installation via command line and have a command line interface.

[0008] Preferably, in step S2, when the Windows-Server registers its services with the cluster registry center, the registration information includes the host IP address, service port number, CPU usage, memory usage, graphics card memory usage, and number of running tasks; and the Windows-Server needs to periodically upload its configuration information to the registry center, preferably at intervals of 2 seconds.

[0009] Preferably, the timeout time of the weak real-time task is determined by the scheduling center through calculation. The determination method is as follows: input the data scale of the current task into the fitting model of data scale and running time, estimate the expected running time of the current task, and then add a random number specified by the administrator to the expected running time to obtain the timeout time of the current task.

[0010] Preferably, the fitting model is obtained by fitting the data scale and running time of historical tasks that were completed normally.

[0011] Preferably, the timeout period for the real-time task is specified directly by the administrator, and the preferred timeout period is 100ms.

[0012] As a preferred approach, each task is pre-determined by the administrator to be either highly real-time or weakly real-time. After a user submits a task, the system adds it to the corresponding buffer queue based on the real-time classification determined by the administrator for that type of task.

[0013] Preferably, the waiting time for a strong real-time buffer queue task should not exceed 100ms. If the waiting time exceeds this, a timeout message should be returned to the user. The weak real-time buffer queue task does not have a timeout setting, but the weak real-time task needs to provide the user with a task cancellation interface.

[0014] Preferably, the number of inactive communication threads corresponds to the maximum number of computing tasks, and this number cannot be changed. If a new Windows-Server node joins the cluster and registers its service with the registry center, the Center-Server will increase the number of inactive communication threads to respond to more computing requests. If some Windows-Server nodes fail and the registry center does not receive information about those nodes for a certain period of time, the Center-Server will reduce the number of inactive communication threads to release system resources.

[0015] As a preferred approach, for tasks with strong real-time requirements, the request will not be resent after a timeout or error occurs; instead, a timeout or error message will be returned directly to the user. For tasks with weak real-time requirements, the request will be resent three times, and if a timeout or error occurs, a timeout or error message will be returned to the user.

[0016] Compared with the prior art, the present invention has the following advantages: Compared to traditional Kubernetes, the technical method of this invention can schedule non-containerized applications in cloud clusters, solving the problem of scheduling certain Windows applications in the cloud after containerization. This invention can be used to solve the scheduling problem of traditional applications that cannot adapt to container environments in the cloud, and its application is of great significance. Attached Figure Description

[0017] Figure 1 This diagram illustrates the steps involved in scheduling Windows applications on Kubernetes using a compute pool software virtualization approach.

[0018] Figure 2 This is a flowchart illustrating the communication process for scheduling Windows applications on Kubernetes using a compute pool-based software virtualization approach. Detailed Implementation

[0019] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention can be practiced in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below. Technical features in the various embodiments of the present invention can be combined accordingly without mutual conflict.

[0020] In the description of this invention, it should be understood that when an element is considered to be "connected" to another element, it can be a direct connection to the other element or an indirect connection, i.e., there is an intermediate element. Conversely, when an element is said to be "directly" connected to another element, there is no intermediate element.

[0021] In the description of this invention, it should be understood that the terms "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include at least one of those features.

[0022] In a preferred embodiment of the present invention, a software virtualization method based on a computing pool is provided for scheduling Windows applications on Kubernetes (K8S). Compared with traditional Kubernetes, the method of the present invention can schedule non-containerized applications in a cloud cluster, solving the problem of scheduling certain Windows applications in the cloud after containerization. This invention can be used to solve the scheduling problem of traditional applications that cannot adapt to container environments in the cloud, and its application is of great significance. Figure 1 As shown, in this embodiment, the method for scheduling Windows applications on Kubernetes based on software virtualization using a compute pool includes the following steps: S1. Install Windows applications using the command line via a Windows Install file (.msi file) on a virtual machine or physical machine running a Windows operating system.

[0023] It should be noted that this Windows application requires an installation file, such as setup, install, installer, or installation. In this example, a Windows Install file (.msi file) is preferred. Additionally, this installation file needs to be installable via the command line, such as Windows PowerShell.

[0024] S2. Serverize the installed traditional Windows applications by providing an RPC server port in the cluster. The serverized Windows applications will be referred to as Windows-Server. At the same time, Windows-Server registers its services with the cluster registry center. The registration information includes basic information such as host IP address, service port number, CPU usage, memory usage, graphics card memory usage, and number of running tasks.

[0025] It's important to note that to serverize a traditional Windows application, the application must provide a command-line interface so that the Windows-Server can use the application via command-line calls. Additionally, the Windows-Server needs to periodically upload its configuration information to the registry center; this interval is preferably 2 seconds.

[0026] In addition, Windows Server and Center Server need to agree on RPC interface information. RPC stands for Remote Procedure Call, which is a communication protocol used for communication between different processes in a distributed system. It will not be described in detail here.

[0027] In addition, commonly used service registry centers include ZooKeeper, Consul, and Eureka, all of which can serve as central components for service registration and discovery in microservice architectures. Preferably, this invention uses ZooKeeper as the service registry center.

[0028] S3. Implement a unified scheduling service center for all Windows Servers within the cluster, hereinafter referred to as Center-Server. Center-Server provides a unified service interface to external users, and the service functions include, but are not limited to, user login and registration, data upload, task submission, and task feedback. Implement a computing pool in Center-Server to schedule user tasks to a specific computing node. The main functions implemented by the computing pool include scheduling center, task buffer queue, communication thread pool, timeout handling, and error handling. Deploy Center-Server and the registry center in a containerized manner on Kubernetes.

[0029] The scheduling center, task buffer queue, communication thread pool, timeout handling, and error handling in the above computing pool are described in detail below.

[0030] 1) The scheduling center obtains information about computing nodes within the cluster through the registration center, and determines the task to be assigned to a target computing node based on basic information such as CPU utilization, memory utilization, and graphics card memory utilization.

[0031] It should be noted that the scheduling center calculates the expected running time of a task. For general computing tasks, the scheduling center estimates the task running time based on the scale of uploaded data. The main method is to fit the data scale and running time of historically completed tasks to estimate the expected running time of the current task. Preferably, in practice, a random number is added, which is specified by the administrator. For highly real-time tasks, such as obtaining task running progress, the administrator specifies a timeout period. Preferably, in actual operation, this timeout period is 100ms.

[0032] 2) The task buffer queue is divided into a strong real-time buffer queue and a weak real-time buffer queue. Tasks with high real-time requirements should be added to the strong real-time buffer queue, while tasks with lower real-time requirements should be added to the weak real-time buffer queue. The specific criteria for distinguishing between strong and weak real-time tasks can be determined based on the actual task situation. Generally speaking, except for long-running computational tasks, which can be considered weak real-time tasks, other tasks can be considered strong real-time tasks. After a user submits a task, the system selects to add the task to the corresponding buffer queue based on its real-time requirements. Tasks whose real-time requirements meet the weak real-time criteria are added to the weak real-time buffer queue, while tasks whose real-time requirements do not meet the weak real-time criteria are added to the strong real-time buffer queue.

[0033] It is important to note that in this invention, the classification of tasks into strong real-time and weak real-time tasks can be pre-defined by the administrator, who can specify the real-time category for each task. In other words, the administrator determines beforehand whether each task is strong or weak real-time. After a user submits a task, the system can add it to the corresponding buffer queue based on the real-time category pre-determined by the administrator.

[0034] In addition, when allocating tasks, the scheduling center can determine the task timeout based on the task's real-time nature and scale, so as to promptly return timeout information to the user. Generally, the timeout for weak real-time tasks can be determined by the scheduling center through calculation. The method is as follows: input the current task's data scale into a fitting model of data scale and runtime to estimate the expected runtime of the current task, and then add a random number specified by the administrator to this expected runtime to obtain the current task's timeout. The fitting model used here can be obtained by fitting a large number of historically completed tasks with their data scale and runtime as samples. For strong real-time tasks, the timeout can be directly specified by the administrator. In a preferred embodiment of the present invention, the timeout for strong real-time tasks can be directly set to 100ms, meaning that the waiting time for tasks in the strong real-time buffer queue does not exceed 100ms. If this time is exceeded, a timeout message is returned to the user. Furthermore, tasks in the weak real-time buffer queue do not need to have a timeout set, but weak real-time tasks need to provide a task cancellation interface to the user.

[0035] However, it should be noted that the above criteria for judging the real-time performance of tasks and the corresponding timeout periods are preferred methods, and adjustments can be made according to the actual situation in practical applications.

[0036] 3) The communication thread pool is divided into an active communication thread pool and an inactive communication thread pool according to the buffer queue; the active thread pool handles tasks in the strong real-time buffer queue, while the inactive thread pool handles tasks in the weak real-time buffer queue.

[0037] It's important to note that the number of inactive communication threads corresponds to the maximum number of computation tasks, and this number generally cannot be changed. Since the number of Windows Server nodes changes in real time, the number of inactive communication threads also needs to be adjusted accordingly. If a new Windows Server node joins the cluster and registers its service with the registry center, the Center Server will increase the number of inactive communication threads to respond to more computation requests. Conversely, if some Windows Server nodes fail and the registry center does not receive information about those nodes for an extended period, the Center Server will reduce the number of inactive communication threads to free up system resources.

[0038] 4) In timeout and error handling, the scheduling center determines the task timeout time based on the task's real-time nature and scale when assigning tasks. After a task times out or returns an error, the corresponding communication thread will resend the request or re-add the task to the task buffer queue. After a certain number of resends, an error message will be returned to the user.

[0039] It should be noted that, in the preferred embodiment of the present invention, different timeout or error return principles can be set for strong real-time tasks and weak real-time tasks respectively: for strong real-time tasks, after a timeout or error occurs, the request will not be resent and the timeout or error information will be returned directly to the user; for weak real-time tasks, after resending 3 times, if a timeout or error occurs, the timeout or error information will be returned to the user.

[0040] like Figure 2 As shown, the above is illustrated. Figure 2 A communication flowchart illustrating the methods for scheduling Windows applications on Kubernetes.

[0041] In this embodiment, the Windows application software used can be selected according to actual needs. For example, the Windows application could be RealityCapture, a powerful 3D scanning software that can convert 2D and 3D data generated by various devices into high-quality 3D models and maps. This software supports command-line installation and provides a powerful command-line interface. Its main computational task is to realize the 3D reconstruction of uploaded images. In this embodiment, RealityCapture is scheduled on Kubernetes using the methods described in S1~S3 above, enabling multiple users to upload images and multiple tasks to be computed simultaneously.

[0042] Of course, this invention is not only applicable to RealityCapture's scheduling on Kubernetes, but also theoretically applicable to any Windows application that provides a command-line interface, and there are no limitations on this.

[0043] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the invention. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the invention. Therefore, all technical solutions obtained through equivalent substitution or transformation fall within the protection scope of the present invention.

Claims

1. A method for scheduling Windows applications on Kubernetes using a software virtualization approach based on a compute pool, characterized in that, Includes the following steps: S1. Install Windows applications using the Windows Install file via command line on a virtual machine or physical machine running a Windows operating system. S2. Serverize the installed Windows application, enabling it to provide an RPC server port in the cluster, thus forming a Windows-Server; at the same time, the Windows-Server registers its services with the cluster registry center. S3. Configure a unified scheduling service center (Center-Server) for all Windows Servers within the cluster. The Center-Server provides a unified service interface to external users, including user login and registration, data upload, task submission, and task feedback. Configure a compute pool within the Center-Server to schedule user tasks to a specific compute node. The compute pool implements functions such as a scheduling center, task buffer queue, communication thread pool, timeout handling, and error handling. Deploy the Center-Server and the registry center on Kubernetes in a containerized manner. The scheduling center obtains information about computing nodes within the cluster through the registration center and determines the target computing node for task allocation based on basic information including CPU utilization, memory utilization, and graphics card memory utilization. The task buffer queue is divided into a strong real-time buffer queue and a weak real-time buffer queue. After a user submits a task, the system selects to add the task to the corresponding buffer queue according to the task's real-time requirements. Tasks whose real-time requirements meet the weak real-time standard are added to the weak real-time buffer queue, while tasks whose real-time requirements do not meet the weak real-time standard are added to the strong real-time buffer queue. The communication thread pool is divided into an active communication thread pool and an inactive communication thread pool according to the buffer queue. The active thread pool handles tasks in the high real-time buffer queue, while the inactive thread pool handles tasks in the low real-time buffer queue. In the timeout and error handling, the scheduling center determines the task timeout time based on the task's real-time nature and scale when assigning tasks. After a task times out or returns an error, the corresponding communication thread will resend the request or add the task back to the task buffer queue. After a certain number of resends, an error message is returned to the user.

2. The method for scheduling Windows applications on Kubernetes using a software virtualization approach based on a computing pool as described in claim 1, characterized in that, In step S1, the Windows application must provide a Windows Install file, and the Windows application must support installation via command line and have a command line interface.

3. The method for scheduling Windows applications on Kubernetes using a software virtualization approach based on a computing pool as described in claim 1, characterized in that... In S2, when Windows-Server registers its services with the cluster registry center, the registration information includes the host IP address, service port number, CPU usage, memory usage, graphics card memory usage, and number of running tasks; and Windows-Server needs to upload its configuration information to the registry center periodically at 2-second intervals.

4. The method for scheduling Windows applications on Kubernetes using a software virtualization approach based on a computing pool as described in claim 1, characterized in that, The timeout for tasks with weak real-time requirements is determined by the scheduling center through calculation. The method is as follows: input the data size of the current task into the fitting model of data size and running time to estimate the expected running time of the current task, and then add a random number specified by the administrator to the expected running time to obtain the timeout of the current task.

5. The method for scheduling Windows applications on Kubernetes using a software virtualization approach based on a computing pool as described in claim 4, characterized in that... The fitting model was obtained by fitting the data scale and running time of historical tasks that were completed normally.

6. The method for scheduling Windows applications on Kubernetes using a software virtualization approach based on a computing pool as described in claim 1, characterized in that, The timeout for highly real-time tasks is specified directly by the administrator, and the timeout for this task is 100ms.

7. The method for scheduling Windows applications on Kubernetes using a software virtualization approach based on a computing pool as described in claim 1, characterized in that, Each task is pre-determined by the administrator to be either strong real-time or weak real-time. After a user submits a task, the system adds it to the corresponding buffer queue according to the real-time classification determined by the administrator for that type of task.

8. The method for scheduling Windows applications on Kubernetes using a software virtualization approach based on a computing pool as described in claim 1, characterized in that, Strong real-time buffer queue tasks have a waiting time of no more than 100ms. If the waiting time exceeds this, a timeout message will be returned to the user. Weak real-time buffer queue tasks do not have a timeout setting, but weak real-time tasks need to provide the user with a task cancellation interface.

9. The method for scheduling Windows applications on Kubernetes using a software virtualization approach based on a computing pool as described in claim 1, characterized in that, The number of inactive communication threads corresponds to the maximum number of computing tasks, and this number cannot be changed. If a new Windows Server node joins the cluster and registers its service with the registry center, the Center Server will increase the number of inactive communication threads to respond to more computing requests. If some Windows Server nodes fail and the registry center does not receive information about those nodes for a certain period of time, the Center Server will reduce the number of inactive communication threads to release system resources.

10. The method for scheduling Windows applications on Kubernetes using a software virtualization approach based on a computing pool as described in claim 1, characterized in that, For tasks requiring strong real-time performance, requests will not be resent after a timeout or error; instead, a timeout or error message will be returned directly to the user. For tasks requiring weak real-time performance, requests will be resent three times, and if a timeout or error occurs, a timeout or error message will be returned to the user.

Images