Application orchestration method and apparatus, electronic device, and storage medium
By creating virtual nodes on Kubernetes tools and performing compatibility updates, the problem of non-containerized applications being unable to be orchestrated is solved, achieving unified orchestration of containerized and non-containerized applications, and reducing operational complexity and maintenance costs.
Patent Information
- Application Number
- CN202610184072.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-02-09
- Publication Date
- 2026-06-26
Smart Images
Figure CN122285173A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of cloud computing technology, and in particular to an application orchestration method and apparatus, electronic device and storage medium. Background Technology
[0002] In the field of cloud computing technology, Kubernetes tools are used to orchestrate containerized applications, automatically placing them on local servers to start and continuously run, thereby enabling rapid deployment of containerized applications. However, this Kubernetes-based orchestration approach still has limitations when dealing with non-containerized applications such as binary files or Java packages.
[0003] Currently, some industry methods have extended the design of Kubernetes tools. However, these modifications only improve the flexibility of orchestrating containerized applications; they still cannot orchestrate non-containerized applications. Furthermore, some methods directly replace Kubernetes with Ansible to orchestrate non-containerized applications. However, since containerized and non-containerized applications coexist in real-world applications, this approach requires operators to orchestrate both types of applications separately using different tools, increasing operational complexity and maintenance costs. Therefore, how to achieve unified orchestration of non-containerized and containerized applications based on Kubernetes tools is a pressing technical problem that needs to be solved in the industry. Summary of the Invention
[0004] The main objective of this application is to propose an application orchestration method and apparatus, electronic device and storage medium, which aims to achieve unified orchestration of non-containerized and containerized applications based on Kubernetes tools.
[0005] To achieve the above objectives, a first aspect of this application proposes an application orchestration method applied to a central server in a server cluster, the method comprising: A target virtual node is created using the virtual task component of the central server; wherein, the target virtual node is configured with a deployment file call interface; Based on the interface call specification of the deployment file call interface, determine the runtime environment deployment file of the non-containerized application and the configuration parameter record file corresponding to the runtime environment deployment file; Obtain the first orchestration request for the non-containerized application and the initial workload description file; The initial workload description file is updated for compatibility adaptation based on the configuration parameter record file to obtain the first workload description file of the non-containerized application; The first workload description file is scheduled to the target virtual node according to the first orchestration request; In the target virtual node, the plugin deployment is parsed according to the first workload description file to obtain the target application deployment information of the non-containerized application, and the runtime environment deployment file of the non-containerized application is called according to the target application deployment information to orchestrate the non-containerized application.
[0006] In some embodiments, the step of updating the initial workload description file according to the configuration parameter log file to obtain the first workload description file for the non-containerized application includes: The configuration parameter record file is parsed to obtain the file identification information of the runtime environment deployment file; The initial workload description file is written with parameters according to the file identification information to obtain the first workload description file of the non-containerized application.
[0007] In some embodiments, the step of updating the initial workload description file according to the configuration parameter log file to obtain the first workload description file for the non-containerized application includes: The configuration parameter record file is parsed to obtain the file identification information of the runtime environment deployment file; The initial workload description file is written with parameters according to the file identification information to obtain the first workload description file of the non-containerized application.
[0008] In some embodiments, the step of invoking the runtime environment deployment file of the non-containerized application based on the target application deployment information to orchestrate the non-containerized application includes: The runtime environment deployment file of the non-containerized application is invoked based on the file identification information corresponding to the target application deployment information; Based on the target orchestration requirement parameters of the target application deployment information, the runtime environment deployment file of the non-containerized application is adapted and generated with orchestration instructions to obtain the non-containerized orchestration instructions of the non-containerized application. The non-containerized application is orchestrated according to the non-containerized orchestration instructions.
[0009] In some embodiments, the target virtual node is further configured with a workload transformation interface, and the method further includes: Obtain a second orchestration request for the containerized application and a second workload description file; Schedule the second workload description file to the target virtual node; In the target virtual node, the containerized application is orchestrated according to the workload transformation interface and the second workload description file.
[0010] In some embodiments, orchestrating the containerized application according to the workload transformation interface and the second workload description file includes: The application configuration is parsed according to the workload conversion interface to obtain the application description information of the containerized application. Based on the workload transformation interface and the application description information, orchestration instructions are adapted and generated to obtain the containerized orchestration instructions for the containerized application. The containerized application is orchestrated according to the containerization orchestration instructions.
[0011] In some embodiments, determining the runtime environment deployment file of the non-containerized application and the configuration parameter record file corresponding to the runtime environment deployment file based on the interface call specification of the deployment file call interface includes: Based on the interface call specifications of the deployment file call interface, the initial runtime environment deployment file for the non-containerized application is determined; The initial runtime environment deployment file is used for availability verification to obtain availability verification results; If the availability verification result meets the preset availability conditions, the initial runtime environment deployment file is determined as the runtime environment deployment file of the non-containerized application, and the configuration parameter record file corresponding to the runtime environment deployment file is determined based on the interface call specification of the deployment file calling interface.
[0012] To achieve the above objectives, a second aspect of this application provides an application orchestration apparatus applied to a central server in a server cluster, the apparatus comprising: A virtual node creation unit is used to create a target virtual node using the virtual task component of the central server; wherein, the target virtual node is configured with a deployment file call interface; The deployment file generation unit is used to determine the runtime environment deployment file of the non-containerized application and the configuration parameter record file corresponding to the runtime environment deployment file based on the interface call specification of the deployment file call interface. The workload file acquisition unit is used to acquire the first orchestration request for the non-containerized application and the initial workload description file; The workload file adaptation unit is used to perform compatibility adaptation and update of the initial workload description file according to the configuration parameter record file to obtain the first workload description file of the non-containerized application. A virtual node scheduling unit is used to schedule the first workload description file to the target virtual node; The application orchestration unit is used to perform plugin deployment parsing based on the first workload description file in the target virtual node to obtain the target application deployment information of the non-containerized application, and to call the runtime environment deployment file of the non-containerized application based on the target application deployment information to orchestrate the non-containerized application.
[0013] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.
[0014] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.
[0015] The application orchestration method, apparatus, electronic device, and storage medium proposed in this application create a target virtual node using the virtual task component of a central server. Then, the deployment file call interface of the target virtual node is configured to determine the runtime environment deployment file of the non-containerized application and the corresponding configuration parameter record file. Next, a first orchestration request for the non-containerized application and an initial workload description file are obtained. The initial workload description file is then updated for compatibility adaptation based on the configuration parameter record file to obtain the first workload description file for the non-containerized application. Furthermore, the first workload description file is scheduled to the target virtual node according to the first orchestration request. Finally, in the target virtual node, plugin deployment parsing is performed based on the first workload description file to obtain the target application deployment information for the non-containerized application. The runtime environment deployment file of the non-containerized application is then called based on the target application deployment information to orchestrate the non-containerized application. Thus, by converting the orchestration requirements of non-containerized applications into configuration parameter log files and writing them into the initial workload description file, a first workload description file that can be recognized and scheduled by Kubernetes is generated. This file is then scheduled to the target virtual node. With the help of the node's deployment file call interface and plugin deployment parsing mechanism, the corresponding runtime environment deployment file is called to complete the orchestration of non-containerized applications. Finally, combined with the orchestration capabilities already provided by the Kubernetes tools, the orchestration of containerized applications is achieved. In other words, this application can achieve unified orchestration of non-containerized applications and containerized applications on the basis of Kubernetes tools. Attached Figure Description
[0016] Figure 1 This is a schematic diagram illustrating the principle of Kubernetes tools for orchestrating containerized applications, as provided in the embodiments of this application. Figure 2 This is a flowchart of an application orchestration method provided in an embodiment of this application; Figure 3 yes Figure 2 The flowchart of step S204 in the process; Figure 4 yes Figure 2 A flowchart of step S206 in the process; Figure 5 yes Figure 2 Another flowchart of step S206 in the process; Figure 6 This is another flowchart of the application orchestration method provided in the embodiments of this application; Figure 7 yes Figure 6 The flowchart of step S603 in the process; Figure 8 yes Figure 2 The flowchart of step S202 in the text; Figure 9 This is a schematic diagram of the application orchestration device provided in the embodiments of this application; Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation
[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0018] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.
[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.
[0020] First, let's analyze some of the terms used in this application: Containerized applications refer to applications that package their entire dependencies into container images and run them by creating isolated instances using a container runtime. The foundation of containerized applications is container technology, whose core principle leverages Linux kernel features such as namespaces and control groups to achieve process-level resource isolation and limitation. The container image upon which a containerized application depends is an immutable file containing application code, runtime, system tools, and libraries, ensuring consistency in operation across different environments.
[0021] Kubernetes tools are tools used to organize one or more local servers into a cluster for orchestrating containerized applications. A cluster built with Kubernetes tools includes core components such as an interface server (Kubernetes-api-server), a key-value store (Etcd), a scheduler, a controller-manager, and node agents (Kubelet). These components work together to pull container images, create, start, stop, and remove containers, thus completing the orchestration process for containerized applications.
[0022] To better understand the orchestration principles of Kubernetes tools, please refer to [link / reference]. Figure 1 , Figure 1This is a schematic diagram illustrating the principle of orchestrating containerized applications using the Kubernetes tool provided in this application embodiment. Specifically, it includes: First, organizing local servers into a cluster using the Kubernetes tool, with each local server acting as a local node within the cluster. A node agent component is deployed on the local node, and the interface server, key-value store, scheduler, and control manager are jointly deployed as the cluster's control plane. Then, when a user needs to orchestrate a specific containerized application, they can submit a workload description file corresponding to that specific application to the interface server. This workload description file records the user's desired resource status, including the container image information required by the application. Further, the scheduler listens for and obtains the workload description file, allocates a suitable local node for the workload based on the cluster resource status, and updates the scheduling decision to the key-value store. Subsequently, the node agent component on the scheduled local node listens for the workload's scheduling binding event and obtains its detailed configuration. Based on the configuration information, the node agent calls the container runtime deployed on the local node through the Container Runtime Interface (CRI) to sequentially perform operations such as pulling the specified container image, creating a container based on the image, starting the container, stopping the container, and deleting the container. Ultimately, the container successfully runs on the local node, forming a Pod that hosts the user application. The node agent continuously monitors the status of the container within the Pod and synchronizes the status information to the key-value store through the interface server, thus completing the entire orchestration process for the containerized application from description to actual operation.
[0023] Non-containerized applications refer to applications that are not packaged and isolated using container technology. Their operation directly depends on the underlying operating system environment and cannot be natively managed by container orchestration tools. For example, a non-containerized application can be a binary executable file running on a Windows system, a Java JAR or WAR file, or an application deployed in a virtual machine image, etc., with no specific limitations. The operation of non-containerized applications directly depends on the kernel interface and system libraries of the underlying operating system. Without the isolation of a container runtime, their deployment relies on manual installation, script automation, or configuration management tools such as Ansible.
[0024] Containerized applications are natively supported by Kubernetes tools and can be directly managed through their orchestration mechanism. However, under the current technology framework, even with extensions to Kubernetes tools, the scheduling and deployment of containerized applications can only be extended to servers outside the cluster, not to the direct orchestration of non-containerized applications. In real-world production environments, containerized and non-containerized applications often coexist. If independent tools other than Kubernetes (such as Ansible) are still needed to deploy and manage non-containerized applications, it leads to fragmented operational processes, increased toolchain complexity, and significantly increased operational complexity and system maintenance costs. Therefore, this application provides an application orchestration method and apparatus, electronic device, and storage medium, aiming to achieve unified orchestration of non-containerized and containerized applications based on Kubernetes tools, addressing a pressing technical problem in the industry.
[0025] The application orchestration method provided in this application relates to the field of cloud computing technology. The application orchestration method provided in this application can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the application orchestration method, but is not limited to the above forms.
[0026] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.
[0027] Figure 2This is an optional flowchart of the application orchestration method provided in the embodiments of this application. Figure 2 The method described above is applied to the central server in a server cluster, and the method may include, but is not limited to, steps S201 to S206: Step S201: Create the target virtual node using the virtual task component of the central server; Step S202: Based on the interface call specification of the deployment file calling interface, determine the runtime environment deployment file of the non-containerized application and the configuration parameter record file corresponding to the runtime environment deployment file; Step S203: Obtain the first orchestration request for the non-containerized application and the initial workload description file; Step S204: Update the initial workload description file according to the configuration parameter record file to ensure compatibility and adaptability, and obtain the first workload description file for the non-containerized application. Step S205: Schedule the first workload description file to the target virtual node according to the first orchestration request; Step S206: In the target virtual node, the plugin deployment is parsed according to the first workload description file to obtain the target application deployment information of the non-containerized application, and the runtime environment deployment file of the non-containerized application is called according to the target application deployment information to orchestrate the non-containerized application.
[0028] Steps S201 to S206 of this embodiment involve creating a target virtual node using the virtual task component of the central server; then, determining the runtime environment deployment file and the corresponding configuration parameter record file of the non-containerized application by using the interface call specification of the deployment file call interface configured on the target virtual node; next, obtaining the first orchestration request and the initial workload description file for the non-containerized application, and then updating the initial workload description file for compatibility adaptation according to the configuration parameter record file to obtain the first workload description file for the non-containerized application; further, scheduling the first workload description file to the target virtual node; finally, in the target virtual node, performing plugin deployment parsing based on the first workload description file to obtain the target application deployment information of the non-containerized application, and calling the runtime environment deployment file of the non-containerized application according to the target application deployment information to orchestrate the non-containerized application. Thus, by converting the orchestration requirements of non-containerized applications into configuration parameter log files and writing them into the initial workload description file, a first workload description file that can be recognized and scheduled by Kubernetes is generated. This file is then scheduled to the target virtual node. With the help of the node's deployment file call interface and plugin deployment parsing mechanism, the corresponding runtime environment deployment file is called to complete the orchestration of non-containerized applications. Finally, combined with the orchestration capabilities already provided by the Kubernetes tool itself, the orchestration of containerized applications is achieved. That is, the embodiments of this application can achieve unified orchestration of non-containerized applications and containerized applications on the basis of the Kubernetes tool.
[0029] In step S201 of some embodiments, a server cluster can refer to a resource set consisting of at least one server connected via a network, used for collaborative processing of computing tasks. For example, a server cluster may include three local servers; or, a server cluster may include two local servers and two virtual servers, without specific limitations. A central server can refer to the core server in the server cluster used for unified management, coordination, and control of the overall behavior and resources of the cluster. For example, if the server cluster includes three local servers, one local server can be used as the central server to deploy the control plane corresponding to the Kubernetes tool, and the other two local servers can be used as local nodes to deploy node agents; or, if the server cluster includes only one local server, that server can simultaneously serve as the central server and a local node to deploy the control plane and node agents corresponding to the Kubernetes tool, without specific limitations.
[0030] A virtual task component can refer to a component running on a central server used to create and manage virtual nodes. A target virtual node can refer to a logical compute node created by the virtual task component, used to receive and forward the first orchestration request. The target virtual node is stored on the central server and configured with a deployment file invocation interface. For example, a target virtual node can be a virtual node agent (Virtual Kubelet), which can include an interaction component and a deployment file invocation interface; the interaction component is used to communicate with the interface server (Kubernetes-api-server) to listen for workload description files corresponding to a specific non-containerized application scheduled to the target virtual node; the deployment file invocation interface can refer to a program interface configured on the target virtual node used to invoke the deployment file corresponding to a specific non-containerized application. For example, if orchestration of binary executables is required, the deployment file invocation interface can be configured to point to a dedicated invocation plugin for deploying binary executables when creating the target virtual node. It is understood that the specific type of the deployment file invocation interface can be adjusted according to actual needs.
[0031] In step S202 of some embodiments, the interface call specification can refer to a set of format, protocol, and parameter rules defined for calling the interface of the deployment file. For example, the interface call specification can be a set of parsing rules for specific fields (such as "deployer") in the workload description file; or, the interface call specification can be a set of predefined function signatures or application programming interface conventions, without specific limitations. The runtime environment deployment file can refer to an executable file or script used to actually perform the deployment, startup, and management operations of the non-containerized application. For example, the runtime environment deployment file can be an executable program that encapsulates the deployment logic of a Java application, used to download a specified Jar package and start the Java Virtual Machine; or, the runtime environment deployment file can be an automation script used to configure environment variables, download binary packages, and start the corresponding processes, without specific limitations. The configuration parameter log file can refer to a file stored on a central server that records the access path and identification information of the runtime environment deployment file corresponding to the non-containerized application. For example, if the non-containerized application is a binary executable file, the configuration parameter log file can be a YAML-formatted manifest that explicitly records the identifier of the runtime environment deployment file specific to the binary file and its local access path on the central server; or, the configuration parameter log file can be a JSON-formatted entry that records the name of the runtime environment deployment file and its access path on a specific server, without any specific limitation.
[0032] In step S203 of some embodiments, the first orchestration request may refer to an instruction issued by the interface server requesting the deployment of a workload of a specific non-containerized application to a target virtual node. The initial workload description file may refer to a workload description file that conforms to the native format defined by Kubernetes tools and serves as the basic template for non-containerized application orchestration. For example, the initial workload description file may be a file including container image placeholders and resource request definitions corresponding to a binary executable file; or, the initial workload description file may also be a file including standard container specification fields and scheduling constraints corresponding to a binary executable file, without specific limitations.
[0033] In step S204 of some embodiments, compatibility adaptation update may refer to the process of updating the initial workload description file based on the identification information and access path of the runtime environment deployment file recorded in the configuration parameter log file. The first workload description file may refer to the file obtained after the compatibility adaptation update, which is used to instruct the target virtual node to call a specific runtime environment deployment file to execute non-containerized application orchestration.
[0034] In steps S205 to S206 of some embodiments, scheduling the first workload description file to the target virtual node can refer to the process of allocating the first workload description file to the target virtual node using Kubernetes tools based on the specification of the target virtual node in the first orchestration request. Plugin deployment parsing can refer to the step of the target virtual node processing the received first workload description file to extract configuration information for calling the runtime environment deployment file. Target application deployment information can refer to the instruction information extracted from the first workload description file through plugin deployment parsing, which instructs the deployment file call interface to call a specific runtime environment deployment file and its specific parameters. Orchestration of non-containerized applications can refer to the target virtual node, based on the target application deployment information, calling the specified runtime environment deployment file through its deployment file call interface, and the runtime environment deployment file executing the complete process of specific deployment, startup, and lifecycle management of the non-containerized application on a specific server.
[0035] Please see Figure 3 In some embodiments, step S204 may include, but is not limited to, steps S301 to S302: Step S301: Parse the configuration parameter record file for plugin configuration to obtain the file identification information of the runtime environment deployment file; Step S302: Write parameters to the initial workload description file according to the file identification information to obtain the first workload description file of the non-containerized application.
[0036] In step S301 of some embodiments, plugin configuration parsing may refer to the process of reading and parsing the structured content of a configuration parameter record file to extract the predefined identifier name and location information of the runtime environment deployment file associated with a specific non-containerized application type. The file identifier information may refer to data obtained after plugin configuration parsing, used to uniquely identify and access the corresponding runtime environment deployment file. For example, the file identifier information may be the name of the runtime environment deployment file, such as binary-executor; or it may be the complete access path of the runtime environment deployment file, such as / opt / plugins / java-deployer. It is understood that the specific content of the file identifier information can be adjusted according to the storage and management method of the runtime environment deployment file.
[0037] In step S302 of some embodiments, parameter writing can refer to the process of filling file identification information and related application configuration parameters into specific annotation fields of the initial workload description file according to the data format specified by the container orchestration tool. The first workload description file can refer to the workload description file generated after the parameter writing is completed, which carries complete non-containerized application deployment instructions. For example, in this embodiment, a JSON structure containing key-value pairs such as deployer and config can be written into the metadata.annotations field of the initial workload description file to obtain the first workload description file; or, in this embodiment, file identification information and parameter strings can be directly written under specific annotation keys of the initial workload description file, without specific limitations.
[0038] It is understood that, in this embodiment of the application, the configuration parameter log file can be parsed using a plugin to obtain the file identification information of the runtime environment deployment file. Then, parameters are written to the initial workload description file based on the file identification information to obtain the first workload description file for the non-containerized application. In this way, the specific deployment logic and configuration for non-containerized applications can be converted into a standard workload description that conforms to the Kubernetes tool specification and can be scheduled by it, thereby providing compatible input for unified orchestration.
[0039] Please see Figure 4 In some embodiments, step S206, which involves parsing the plugin deployment based on the first workload description file to obtain the target application deployment information for the non-containerized application, may include, but is not limited to, steps S401 to S403: Step S401: Extract configuration information from the first workload description file to obtain file identification information for non-containerized applications; Step S402: Extract orchestration requirement information from the first workload description file to obtain the target orchestration requirement parameters for the non-containerized application. Step S403: Determine the target application deployment information for the non-containerized application based on the file identification information and target orchestration requirement parameters.
[0040] In step S401 of some embodiments, configuration information extraction may refer to the process by which the target virtual node parses the received first workload description file to locate and obtain configuration data for determining the runtime environment deployment file from its predetermined structure fields. File identification information may refer to identification data obtained through configuration information extraction, used to instruct the target virtual node to call a specific runtime environment deployment file.
[0041] In step S402 of some embodiments, orchestration requirement information extraction may refer to the process by which the target virtual node parses the first workload description file to locate and obtain parameters describing the specific operational requirements and behavioral constraints of the non-containerized application. Target orchestration requirement parameters may refer to parameters obtained through orchestration requirement information extraction that define the specific startup and running behavior of the non-containerized application. For example, target orchestration requirement parameters may be the startup command and command-line parameter list of the non-containerized application; or, target orchestration requirement parameters may also be the computing resource requests and limitations required for application operation, such as the number of CPU cores and memory capacity. The specific content of the target orchestration requirement parameters can be adjusted according to actual needs.
[0042] In step S403 of some embodiments, the target application deployment information may refer to request information that is formed by integrating file identification information and target orchestration requirement parameters, and that can instruct the deployment file call interface to call a specific runtime environment deployment file and pass all necessary parameters, and can be directly used by the deployment file call interface. For example, the target application deployment information may be a request message body that conforms to the deployment file call interface specification, which includes the identification information of the runtime environment deployment file, the startup command, and memory limits; or, the target application deployment information may also be a call information that integrates elements such as binary file path, execution parameters, and the required number of CPU cores, etc., without specific limitations.
[0043] It is understood that this embodiment of the application extracts configuration information from the first workload description file to obtain the file identification information of the non-containerized application, then extracts orchestration requirement information from the first workload description file to obtain the target orchestration requirement parameters of the non-containerized application, and finally determines the target application deployment information of the non-containerized application based on the file identification information and the target orchestration requirement parameters. In this way, the static configuration and dynamic requirements carried in the first workload description file can be decoupled and recombined to generate a complete and clearly formatted deployment information to accurately drive the target virtual node to perform subsequent orchestration operations.
[0044] Please see Figure 5 In some embodiments, step S206, which involves calling the runtime environment deployment file of the non-containerized application based on the target application deployment information to orchestrate the non-containerized application, may include, but is not limited to, steps S501 to S503: Step S501: Retrieve the runtime environment deployment file of the non-containerized application based on the file identifier information corresponding to the target application deployment information; Step S502: Based on the target orchestration requirement parameters of the target application deployment information, the runtime environment deployment file of the non-containerized application is adapted and generated with orchestration instructions to obtain the non-containerized orchestration instructions for the non-containerized application. Step S503: Orchestrate the non-containerized application according to the non-containerized orchestration instructions.
[0045] In step S501 of some embodiments, calling the runtime environment deployment file of a non-containerized application can refer to the target virtual node calling its deployment file interface to locate and start the processing of the corresponding runtime environment deployment file based on the file identification information carried in the target application deployment information. For example, the target virtual node can parse the target application deployment information, extract the file identification information, and then initiate a call request to the runtime environment deployment file that matches the identification in the configuration through its deployment file call interface to start the execution logic of the deployment file; or, the target virtual node can also execute a local command or script through the deployment file call interface. This command locates a pre-deployed executable program based on the identification information and directly starts the program process, thereby completing the call to the runtime environment deployment file. The calling process of the runtime environment deployment file can be adjusted according to actual needs.
[0046] In step S502 of some embodiments, orchestration instruction adaptation generation can refer to the process by which the invoked runtime environment deployment file generates a set of command sequences or control logic that it can directly execute to complete specific deployment operations of non-containerized applications, based on the target orchestration requirement parameters carried in the target application deployment information. Non-containerized orchestration instructions can refer to the specific set of instructions obtained through orchestration instruction adaptation generation, which are used to directly drive the runtime environment deployment file to perform application deployment operations.
[0047] In step S503 of some embodiments, orchestrating a non-containerized application can refer to the target virtual node driving or calling the corresponding runtime environment deployment file to perform specific operations according to the non-containerized orchestration instructions, thereby completing the complete process of deploying and starting the non-containerized application on a specific server.
[0048] It is understood that this embodiment of the application calls the runtime environment deployment file of the non-containerized application based on the file identifier information corresponding to the target application deployment information, then adapts the orchestration instructions of the runtime environment deployment file of the non-containerized application to generate orchestration instructions based on the target orchestration requirement parameters of the target application deployment information, thereby obtaining the non-containerized orchestration instructions for the non-containerized application, and finally orchestrates the non-containerized application according to the non-containerized orchestration instructions. In this way, the orchestration information of the non-containerized application can be converted into operation instructions that can be directly executed on the target server, thereby completing the specific deployment and startup of the non-containerized application.
[0049] Please see Figure 6 This application embodiment also provides another optional flowchart of the application orchestration method, in which the target virtual node is further configured with a workload transformation interface, and the method may include, but is not limited to, steps S601 to S603: Step S601: Obtain the second orchestration request for the containerized application and the second workload description file; Step S602: Schedule the second workload description file to the target virtual node; Step S603: In the target virtual node, the containerized application is orchestrated according to the workload transformation interface and the second workload description file.
[0050] In step S601 of some embodiments, the second orchestration request may refer to an instruction issued by a user to the interface server requesting orchestration of a containerized application. The second workload description file may refer to a workload description file that conforms to the native format defined by Kubernetes tools and contains complete container configurations such as container image identifiers.
[0051] In some embodiments, step S602, scheduling the second workload description file to the target virtual node, may refer to the process of allocating the second workload description file to the target virtual node through Kubernetes tools based on the second orchestration request.
[0052] In step S603 of some embodiments, the workload translation interface may refer to a program interface configured on the target virtual node for translating the workload description of the containerized application into a low-level executable operation. Orchestration of the containerized application may refer to the target virtual node using the workload translation interface to convert the second workload description file into instructions suitable for executing the containerized application on the target server, and calling the corresponding container runtime environment to complete the process of deploying and starting the containerized application.
[0053] It is understood that, in this embodiment of the application, a second orchestration request and a second workload description file for a containerized application are obtained, the application is scheduled to a target virtual node, and the containerized application is orchestrated using a workload transformation interface. In this way, containerized applications can be orchestrated through the target virtual node, enabling the target virtual node to handle orchestration requests from both containerized and non-containerized applications simultaneously, providing a unified orchestration entry point and flexible execution adaptation capabilities.
[0054] Please see Figure 7 In some embodiments, step S603 may include, but is not limited to, steps S701 to S703: Step S701: Parse the application configuration according to the workload conversion interface to obtain the application description information of the containerized application; Step S702: Based on the workload transformation interface and application description information, the orchestration instructions are adapted and generated to obtain the containerized orchestration instructions for the containerized application. Step S703: Orchestrate the containerized application according to the containerization orchestration instructions.
[0055] In step S701 of some embodiments, application configuration parsing may refer to the process by which the workload transformation interface parses the second workload description file to extract core configuration information required for container operation, such as container image identifier and resource specifications. Application description information may refer to a set of configuration data obtained through application configuration parsing that describes the runtime specifications of the containerized application. For example, application description information may be a set of data containing container image identifiers and resource requests; or, application description information may also be a set of data containing container image identifiers, environment variable configurations, and port mapping definitions, without specific limitations.
[0056] In step S702 of some embodiments, orchestration instruction adaptation generation can refer to the process by which the workload transformation interface generates a set of commands or requests conforming to the container runtime interface specification for creating and starting containers, based on application description information. Containerization orchestration instructions can refer to specific instructions obtained through orchestration instruction adaptation generation, used to directly drive the container runtime to execute containerized application deployment.
[0057] In step S703 of some embodiments, orchestrating the containerized application can refer to the target virtual node executing or forwarding containerization orchestration instructions through a workload conversion interface, and the target virtual node completing the creation, startup, and lifecycle management of the containerized application according to the instructions. For example, the target virtual node can parse the container image identifier and resource configuration according to the instructions, and call the container runtime on the local server in the cluster to pull the image and start the corresponding containerized application; or, the target virtual node can also forward the complete description and runtime requirements of the containerized application to an external server according to the instructions, and the external server can call the container runtime to start and manage the corresponding containerized application, without being limited to any specific method.
[0058] It is understood that, in this embodiment of the application, application configuration parsing is performed based on the workload conversion interface to obtain application description information of the containerized application. Then, orchestration instructions are adapted and generated based on the workload conversion interface and application description information to obtain containerized orchestration instructions for the containerized application. Finally, the containerized application is orchestrated according to the containerized orchestration instructions. In this way, the orchestration process of containerized applications can be standardized and integrated into the unified processing framework of the target virtual node, thereby completing the hybrid scheduling and unified management of containerized and non-containerized applications on the same logical node.
[0059] Please see Figure 8 In some embodiments, step S202 may include, but is not limited to, steps S801 to S803: Step S801: Based on the interface call specification of the deployment file calling interface, determine the initial runtime environment deployment file for the non-containerized application; Step S802: Perform availability verification on the initial runtime environment deployment file to obtain the availability verification results; Step S803: If the availability verification result meets the preset availability conditions, the initial runtime environment deployment file is determined as the runtime environment deployment file for non-containerized applications, and the configuration parameter record file corresponding to the runtime environment deployment file is determined based on the interface call specification of the deployment file calling interface.
[0060] In step S801 of some embodiments, the initial runtime environment deployment file may refer to an executable file or script pre-selected according to the interface call specification for deploying a specific non-containerized application.
[0061] In step S802 of some embodiments, availability verification may refer to the process of checking and testing the initial runtime environment deployment file to assess whether it can be successfully invoked and correctly respond to deployment requests. The availability verification result may refer to the judgment result obtained through availability verification, reflecting whether the file is in an available state. For example, the availability verification result may be a binary flag, such as "true" indicating availability or "false" indicating unavailability; or, the availability verification result may also be a quantitative availability score, such as a value between 0 and 100, without specific limitation.
[0062] In step S803 of some embodiments, the preset availability condition may refer to a pre-set standard used to determine whether the runtime environment deployment file is available. For example, if the availability verification result is a binary flag, the preset availability condition may be that the flag indicates an available state, such as "true"; or, if the availability verification result is a quantitative score, the preset availability condition may also be that the score is not lower than a preset qualified threshold, such as 80 points, and the specific condition is not limited. If the availability verification result meets the preset availability condition, it means that the initial runtime environment deployment file is in a normal state and can be reliably called, and can be formally determined as the runtime environment deployment file for subsequent orchestration; if the availability verification result does not meet the preset availability condition, it means that the file is currently unavailable or in an abnormal state, and will not be adopted. The central server can perform processing such as reselection, alarm, or adoption of a backup plan.
[0063] It is understood that, in this embodiment of the application, by determining the initial runtime environment deployment file and performing availability verification, the file is only determined as the final usable runtime environment deployment file and the corresponding configuration is generated after the verification is passed. This ensures that the deployment file stored in the central server is reliable and executable, guaranteeing the smooth execution of subsequent orchestration processes and improving orchestration reliability.
[0064] It is understood that the application orchestration method provided in this application creates a target virtual node on a central server and makes it listen to native Kubernetes scheduling instructions to obtain the workload description file of the corresponding containerized or non-containerized application. Then, in the target virtual node, the application is uniformly deployed and orchestrated based on the description file by calling the corresponding adaptation interface. Thus, the method in this application allows users to use the native Kubernetes toolchain and operating habits to achieve consistent management of heterogeneous applications. Furthermore, this method can generate corresponding runtime environment deployment files for different non-containerized applications, and can be compatible with the orchestration of multiple different non-containerized applications, thereby maintaining a unified orchestration experience while possessing broad scalability.
[0065] Please see Figure 9 This application also provides an application orchestration apparatus for use as a central server in a server cluster, capable of implementing the above-described application orchestration method. The apparatus includes: The virtual node creation unit 901 is used to create a target virtual node using the virtual task component of the central server; wherein, the target virtual node is configured with a deployment file call interface; The deployment file generation unit 902 is used to determine the runtime environment deployment file of the non-containerized application and the configuration parameter record file corresponding to the runtime environment deployment file based on the interface call specification of the deployment file call interface. The workload file acquisition unit 903 is used to acquire the first orchestration request for the non-containerized application and the initial workload description file; The workload file adaptation unit 904 is used to perform compatibility adaptation and update of the initial workload description file according to the configuration parameter record file to obtain the first workload description file of the non-containerized application. Virtual node scheduling unit 905 is used to schedule the first workload description file to the target virtual node; The application orchestration unit 906 is used to perform plugin deployment parsing based on the first workload description file in the target virtual node to obtain the target application deployment information of the non-containerized application, and to call the runtime environment deployment file of the non-containerized application based on the target application deployment information in order to orchestrate the non-containerized application.
[0066] The specific implementation of this application orchestration device is basically the same as the specific implementation of the application orchestration method described above, and will not be repeated here.
[0067] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described application programming method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.
[0068] Please see Figure 10 , Figure 10 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 1001 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 1002 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1002 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1002 and is called and executed by the processor 1001 using the application orchestration method of the embodiments of this application. Input / output interface 1003 is used to implement information input and output; The communication interface 1004 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1005 transmits information between various components of the device (e.g., processor 1001, memory 1002, input / output interface 1003, and communication interface 1004); The processor 1001, memory 1002, input / output interface 1003 and communication interface 1004 are connected to each other within the device via bus 1005.
[0069] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described application orchestration method.
[0070] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0071] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.
[0072] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.
[0073] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0074] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.
[0075] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0076] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0077] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0078] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0079] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0080] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0081] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.
Claims
1. An application arrangement method, characterized in that, The method, applied to a central server in a server cluster, includes: A target virtual node is created using the virtual task component of the central server; wherein, the target virtual node is configured with a deployment file call interface; Based on the interface call specification of the deployment file call interface, determine the runtime environment deployment file of the non-containerized application and the configuration parameter record file corresponding to the runtime environment deployment file; Obtain the first orchestration request for the non-containerized application and the initial workload description file; The initial workload description file is updated for compatibility adaptation based on the configuration parameter record file to obtain the first workload description file of the non-containerized application; The first workload description file is scheduled to the target virtual node according to the first orchestration request; In the target virtual node, the plugin deployment is parsed according to the first workload description file to obtain the target application deployment information of the non-containerized application, and the runtime environment deployment file of the non-containerized application is called according to the target application deployment information to orchestrate the non-containerized application.
2. The method of claim 1, wherein, The step of updating the initial workload description file according to the configuration parameter record file to obtain the first workload description file of the non-containerized application includes: The configuration parameter record file is parsed to obtain the file identification information of the runtime environment deployment file; The initial workload description file is written with parameters according to the file identification information to obtain the first workload description file of the non-containerized application.
3. The method of claim 2, wherein, The step of parsing the plugin deployment based on the first workload description file to obtain the target application deployment information of the non-containerized application includes: The configuration information of the first workload description file is extracted to obtain the file identification information of the non-containerized application. The orchestration requirement information is extracted from the first workload description file to obtain the target orchestration requirement parameters of the non-containerized application. The target application deployment information of the non-containerized application is determined based on the file identification information and the target orchestration requirement parameters.
4. The method of claim 3, wherein, The step of invoking the runtime environment deployment file of the non-containerized application based on the target application deployment information to orchestrate the non-containerized application includes: The runtime environment deployment file of the non-containerized application is invoked based on the file identification information corresponding to the target application deployment information; Based on the target orchestration requirement parameters of the target application deployment information, the runtime environment deployment file of the non-containerized application is adapted and generated with orchestration instructions to obtain the non-containerized orchestration instructions of the non-containerized application. The non-containerized application is orchestrated according to the non-containerized orchestration instructions.
5. The method of claim 1, wherein, The target virtual node is also configured with a workload transformation interface, and the method further includes: Obtain a second orchestration request for the containerized application and a second workload description file; Schedule the second workload description file to the target virtual node; In the target virtual node, the containerized application is orchestrated according to the workload transformation interface and the second workload description file.
6. The method according to claim 5, characterized in that, The orchestration of the containerized application based on the workload transformation interface and the second workload description file includes: The application configuration is parsed according to the workload conversion interface to obtain the application description information of the containerized application. Based on the workload transformation interface and the application description information, orchestration instructions are adapted and generated to obtain the containerized orchestration instructions for the containerized application. The containerized application is orchestrated according to the containerization orchestration instructions.
7. The method according to claim 1, characterized in that, The interface call specification based on the deployment file calls the interface determines the runtime environment deployment file for the non-containerized application and the configuration parameter record file corresponding to the runtime environment deployment file, including: Based on the interface call specifications of the deployment file call interface, the initial runtime environment deployment file for the non-containerized application is determined; The initial runtime environment deployment file is used for availability verification to obtain availability verification results; If the availability verification result meets the preset availability conditions, the initial runtime environment deployment file is determined as the runtime environment deployment file of the non-containerized application, and the configuration parameter record file corresponding to the runtime environment deployment file is determined based on the interface call specification of the deployment file calling interface.
8. An application orchestration apparatus, characterized by comprising: The device, used as a central server in a server cluster, includes: A virtual node creation unit is used to create a target virtual node using the virtual task component of the central server; wherein, the target virtual node is configured with a deployment file call interface; The deployment file generation unit is used to determine the runtime environment deployment file of the non-containerized application and the configuration parameter record file corresponding to the runtime environment deployment file based on the interface call specification of the deployment file call interface. The workload file acquisition unit is used to acquire the first orchestration request for the non-containerized application and the initial workload description file; The workload file adaptation unit is used to perform compatibility adaptation and update of the initial workload description file according to the configuration parameter record file to obtain the first workload description file of the non-containerized application. A virtual node scheduling unit is used to schedule the first workload description file to the target virtual node; The application orchestration unit is used to perform plugin deployment parsing based on the first workload description file in the target virtual node to obtain the target application deployment information of the non-containerized application, and to call the runtime environment deployment file of the non-containerized application based on the target application deployment information to orchestrate the non-containerized application.
9. An electronic device, comprising: The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the application orchestration method according to any one of claims 1 to 7.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the application orchestration method as described in any one of claims 1 to 7.