Service deployment method and system based on Kubernetes

Abstract

The invention provides a service deployment method and a service deployment system based on Kubernetes. The method comprises the following steps: receiving a deployment instruction carrying an overall planning script package, wherein the overall planning script package comprises an overall planning file, a global configuration file and a plurality of sub-script packages; analyzing the overall arrangement file to determine the execution sequential logic of each sub-script package, and extracting a target configuration parameter from the global configuration file; the sub-script packages are scheduled in sequence, sub-script package description files in the sub-script packages are read, and instantiation deployment parameters are generated in combination with local parameters; analyzing an instruction definition file in the sub-script package to identify an extension instruction; and executing the instruction according to the instantiated parameters, and completing container deployment, database initialization and configuration issuing of business services by issuing an atomic operation instruction to a Kubernetes cluster. According to the method, a complex deployment process is abstracted into a unified arrangement and scheduling process, and the efficiency and reliability of service deployment are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a service deployment method and system based on Kubernetes. Background Technology

[0002] Kubernetes (K8S) is a container orchestration system that has been widely used to automate the deployment, scaling and management of applications, making large-scale applications running in container environments more efficient.

[0003] Specifically, Kubernetes (K8S) effectively improves the productivity of development and operations teams by managing container lifecycles, providing load balancing and service discovery, enabling automated resource scheduling, and offering self-healing capabilities. However, the K8S cluster configuration and management process is relatively complex, requiring users to have a deep understanding of its core components (such as etcd, kube-apiserver, kube-scheduler, kube-controller-manager, etc.) and configuration files (such as YAML files).

[0004] In related technologies, the deployment of business services within Kubernetes (K8S) is typically done manually, which is not only time-consuming and error-prone, but also requires operators to have a high level of technical skill, needing to be familiar with the meaning of various configurations, thus increasing the workload and learning costs for operations and maintenance personnel. Therefore, the complexity and high cost of deploying and maintaining business services within K8S have become major obstacles.

[0005] Therefore, there is an urgent need for an efficient service deployment solution within Kubernetes.

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

[0007] In view of the problems in the prior art, the purpose of this invention is to provide a service deployment method and system based on Kubernetes, overcome the difficulties of related technologies, and solve the technical problem of low efficiency in Kubernetes-based service deployment schemes in related technologies.

[0008] The first aspect of this disclosure provides a service deployment method based on Kubernetes, which includes: Receive deployment instructions for the target solution. The deployment instructions carry a coordination script package, which includes a coordination orchestration file, a global configuration file, and multiple sub-script packages. The overall orchestration file is parsed to determine the execution timing logic between multiple sub-script packages, and the target configuration parameters corresponding to each sub-script package are extracted from the global configuration file. According to the execution sequence logic, each sub-script package is scheduled sequentially. For the currently scheduled target sub-script package, the following sub-steps are executed: Read the sub-script package description file within the target sub-script package, and generate instantiation deployment parameters based on the target configuration parameters and the local parameters provided by the sub-script package; Parse the instruction definition file within the target sub-script package and identify multiple defined extended instructions; Execute extended instructions based on instantiation deployment parameters, and complete container deployment, database initialization and configuration distribution for the corresponding business service by issuing atomic operation instructions to the target Kubernetes cluster.

[0009] Alternatively, Kubernetes-based service deployment methods also include: Before receiving deployment instructions for the target solution, the script package import interface is displayed through the deployment management interface. The system receives the overall planning script package uploaded by the user based on the script package import interface until the deployment instructions for the target solution are received.

[0010] Alternatively, Kubernetes-based service deployment methods also include: Before receiving deployment instructions for the target solution, a list of available physical resources is displayed through an interactive interface; Parse the selection operation for the physical resource list to obtain the target deployment environment parameters. The target deployment environment parameters include at least the target cluster identifier, namespace, and deployment domain information. The target deployment environment parameters are used to determine the target of the atomic operation command. The global configuration file in the overall planning script package is parsed, the parameters to be configured are extracted, and the parameters to be configured are visualized and rendered based on a predefined template. Based on the modification operations on the rendering parameters, update the parameters to be configured, and generate the target configuration parameters based on the updated parameters to be configured and the target deployment environment parameters.

[0011] Optionally, the overall planning and organization documents are parsed, including: Using a pre-defined domain-specific language parser, semantic analysis is performed on the overall orchestration documents to construct a deployment logic topology diagram; Based on the deployment logic topology diagram, the prerequisite dependencies between each sub-script package are identified, and the execution timing logic is generated using the topology sorting algorithm. During the parsing and orchestration of the file, a resource status table is created. This table is used to map the Pod lifecycle status, database connection handle, and configuration file mount path of each sub-script package in real time, so as to dynamically constrain and verify the execution timing logic during the execution of the sub-script package scheduling.

[0012] Optionally, each sub-script package is sequentially scheduled as an asynchronous execution process based on a state machine, including: Upon receiving the deployment confirmation instruction, the deployment task is submitted to the asynchronous job queue, and a task processing identifier is returned. Each sub-script package is scheduled according to the execution timing logic to complete the pipeline operation from image acquisition, storage volume creation, database initialization to application Pod pull; The deployment is considered complete when all Pods corresponding to the business service reach the Ready state and the service discovery endpoint has been registered, by monitoring the Pod status through the probe interface.

[0013] Optionally, the assembly line operation also includes: Based on the image list, perform image fetching or distribution on the target node in advance; Start a background observer process to monitor resource status changes in the target Kubernetes cluster and obtain deployment progress.

[0014] Optionally, extended instructions are executed based on instantiation deployment parameters, including: If a database operation command is detected, a management container is created within the target Kubernetes cluster and an SQL file is mounted. The built-in driver is used to execute the SQL operation to complete the initialization of the database instance. If a log operation command is detected, the log collection rules are encapsulated into a Sidecar container configuration and injected into the target business Pod; If a configuration operation command is detected, the business configuration file in the overall planning script package will be converted into a Kubernetes native storage object, or a container environment variable will be generated according to the target configuration parameters, and the mounting operation will be performed to the container's preset path.

[0015] Optionally, after completing the container deployment of the corresponding business service, the Kubernetes-based service deployment method also includes: Maintain the deployment session state associated with the overall planning script package, respond to fine-tuning operations for deployed business services, and selectively update native storage objects or container environment variables to trigger hot configuration changes for the target business service.

[0016] Optionally, during the sequential scheduling of each sub-script package, the Kubernetes-based service deployment method also includes: The output data stream during the execution of the target sub-script package is captured through a two-way communication link and asynchronously pushed to the visualization front end for display. If an abnormal execution of the target sub-script package is detected, a reverse cleanup command is triggered based on a preset strategy to roll back the deployed intermediate resources.

[0017] A second aspect of this disclosure provides a Kubernetes-based service deployment system, comprising: The receiving module receives deployment instructions for the target solution. The deployment instructions carry a coordination script package, which includes a coordination orchestration file, a global configuration file, and multiple sub-script packages. The parsing module parses the overall orchestration file, determines the execution timing logic between multiple sub-script packages, and extracts the target configuration parameters corresponding to each sub-script package from the global configuration file. The scheduling module, according to the execution sequence logic, schedules each sub-script package sequentially. For the currently scheduled target sub-script package, it executes the following sub-steps: Read the sub-script package description file within the target sub-script package, and generate instantiation deployment parameters based on the target configuration parameters and the local parameters provided by the sub-script package; Parse the instruction definition file within the target sub-script package and identify multiple defined extended instructions; Execute extended instructions based on instantiation deployment parameters, and complete container deployment, database initialization and configuration distribution for the corresponding business service by issuing atomic operation instructions to the target Kubernetes cluster.

[0018] The Kubernetes-based service deployment method and system proposed in this disclosure have the following advantages: By receiving deployment instructions for the target solution, which carry a coordination script package, the system describes the overall deployment structure of the target solution. This includes a coordination orchestration file describing the overall orchestration relationship of each sub-deployment unit, a global configuration file defining globally common target configuration parameters, and multiple sub-script packages describing the deployment logic of each business service or middleware. The coordination orchestration file is parsed to determine the execution sequence logic between the multiple sub-script packages, and the target configuration parameters corresponding to each sub-script package are extracted from the global configuration file. Each sub-script package is scheduled sequentially according to the execution sequence logic. For the currently scheduled target sub-script package, its sub-script package description file is read, and instantiated deployment parameters are generated based on the target configuration parameters and the package's own local parameters. The instruction definition file is parsed to identify the defined extended instructions, and the extended instructions are executed according to the instantiated deployment parameters. Atomic operation instructions are issued to the target Kubernetes cluster to complete the container deployment, database initialization, and configuration distribution of the corresponding business service. Using this implementation method, the complex target solution deployment process can be abstracted into a unified orchestration and scheduling execution process based on the coordination script package, effectively improving the service deployment efficiency based on Kubernetes in complex business scenarios.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0020] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0021] Figure 1 A flowchart illustrating the Kubernetes-based service deployment method provided by this disclosure embodiment is shown.

[0022] Figure 2 This diagram illustrates the directory structure of the sub-script package provided in the embodiments of this disclosure.

[0023] Figure 3 This illustration shows a schematic diagram of the internal logic structure of the development instruction file (startup.dol) provided in this embodiment.

[0024] Figure 4 This diagram illustrates the overall directory structure of the overall planning script package provided in this embodiment.

[0025] Figure 5 A flowchart illustrating a service deployment method that introduces a pre-import mechanism, as provided in another embodiment of this disclosure, is shown.

[0026] Figure 6 A flowchart illustrating the deployment environment selection and parameter configuration provided by another embodiment of this disclosure is shown.

[0027] Figures 7-11 A schematic diagram of interface changes (including import, environment selection, configuration and execution interfaces) of the service deployment platform provided in the embodiments of this disclosure during the operation of a service deployment method.

[0028] Figure 12 This document presents a module structure diagram of a Kubernetes-based service deployment system provided in this embodiment. Detailed Implementation

[0029] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0030] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the invention or its application or use.

[0031] Techniques, methods, and apparatus known to those skilled in the art may not be discussed in detail, but where appropriate, they should be considered part of the specification. In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0032] Figure 1 This flowchart illustrates a Kubernetes-based service deployment method according to an embodiment of the present disclosure. The execution entity of this Kubernetes-based service deployment method is a service deployment platform. This Kubernetes-based service deployment method is used to automatically deploy a target solution containing multiple business services, databases, and configuration resources, thereby improving overall deployment efficiency and reducing the complexity of manual configuration. Figure 1 As shown, this Kubernetes-based service deployment method includes, but is not limited to, the following steps: Step 110: Receive deployment instructions for the target solution. The deployment instructions carry a coordination script package, which includes a coordination orchestration file, a global configuration file, and multiple sub-script packages. Step 120: Parse the overall orchestration file, determine the execution timing logic between multiple sub-script packages, and extract the target configuration parameters corresponding to each sub-script package from the global configuration file; Step 130: According to the execution sequence logic, schedule each sub-script package in sequence. For the currently scheduled sub-script package, execute the following sub-steps: Step 131: Read the sub-script package description file within the sub-script package, and generate instantiation deployment parameters based on the target configuration parameters and the local parameters provided by the sub-script package; Step 132: Parse the instruction definition file within the sub-script package and identify the multiple defined extended instructions; Step 133: Execute extended instructions based on the instantiation deployment parameters. By issuing atomic operation instructions to the target Kubernetes cluster, complete the container deployment, database initialization, and configuration distribution of the corresponding business service.

[0033] In this embodiment, the overall deployment structure of the target solution is described by the overall orchestration file, which includes an overall orchestration file describing the overall orchestration relationship of each sub-deployment unit, a global configuration file defining globally common target configuration parameters, and multiple sub-script packages describing the deployment logic of each business service or middleware. The target configuration parameters can be shared among the sub-script packages during execution.

[0034] Using this implementation method, the deployment process of complex target solutions is abstracted into a unified orchestration and scheduling execution process based on the overall planning script package, avoiding the inefficiency and error-proneness caused by manually configuring Kubernetes resources one by one, and effectively improving the service deployment efficiency based on Kubernetes in complex business scenarios.

[0035] In some implementations, Figure 1 In step 120 shown, the deployment command is usually triggered by the operator through a visual deployment management interface to start the automated delivery process of the business system corresponding to a target solution.

[0036] For example, a target solution may include a user authentication microservice, a data processing component, a distributed database, and a log auditing module. Developers pre-package these heterogeneous components into a standardized coordination script package. When deployment personnel select the target Kubernetes cluster in the deployment management interface, upload the package, and click "Execute Deployment," the service deployment platform receives the deployment instruction carrying the coordination script package.

[0037] In this implementation, the overall planning script package is not just a collection of files, but also a logical encapsulated entity. It highly abstracts the originally fragmented Kubernetes resource configuration files (such as YAML files), initialization SQL sub-script packages, and environment dependencies.

[0038] The overall orchestration file declares the topological relationships between the sub-deployment units corresponding to each sub-script package (such as declaring that the database starts before the application service), realizing the leap from "single-point resource configuration" to "business process control". The global configuration file stores common parameters shared across services (such as image repository address, external access domain name, storage class name, etc.), ensuring that each business component can reference consistent environment variables during deployment.

[0039] As decoupled and reusable execution units, each sub-script package encapsulates the atomic deployment logic of specific business components (such as container startup parameters, health check paths, and specific database initialization instructions).

[0040] In this embodiment, each sub-script package is organized using a predefined sub-script package architecture to describe the service deployment logic based on Kubernetes. A sub-script package is a logically complete deployment unit, containing various files and folder structures describing deployment information, deployment steps, and deployment resources, such as... Figure 2 As shown, it specifically includes the following components: The dolphin.yaml file is a metadata sub-script package description file used to record the basic attribute information of the current sub-script package, including the name, version number, developer information, etc. The service deployment platform can use this to identify the identity and version of the sub-script package for management and version control.

[0041] The `startup.dol` file is a sub-script package description file that describes the specific deployment steps of the sub-script package. The sub-script package description file describes the operation instructions for each step according to a predefined syntax, instructing the deployment system to perform the actions sequentially when scheduling the current target sub-script package.

[0042] The `values.yaml` file defines the parameter information for each business service during service deployment. Default values ​​can be specified for these parameters. Before deployment, users can modify the contents of the `values.yaml` file through the service deployment platform to update the deployment parameters; if the file is empty, the default configuration preset within the sub-script package will be used.

[0043] The `modules` folder stores other sub-script packages exported by the service deployment platform, which can be called or reused by the current target sub-script package during deployment. If this folder is empty, it will not affect the parsing and execution of the target sub-script package.

[0044] The `image` folder stores the container image files required during deployment, supporting image loading and distribution during deployment. If the `image` folder is empty, the service deployment platform can obtain image resources from a remote image repository.

[0045] The `config` folder stores business configuration files migrated from the unified configuration platform. These configuration files are in JSON format, and their filenames match the deployment name. During service deployment, they can be converted into native Kubernetes storage objects and mounted.

[0046] The `clog` folder stores log rule files exported from the unified logging platform. These files are stored in JSON format, and the filenames match the deployment names. When deploying log operation commands, the system can generate log collection configurations based on these rule files.

[0047] The readme.md file explains how to use the sub-script package, deployment precautions, and applicable scenarios, making it easier for users to understand and use.

[0048] Through the above sub-script package architecture design, the service deployment platform can uniformly encapsulate deployment metadata, deployment steps, configuration parameters and deployment resources, and realize the standardized and automated deployment of complex business services on the Kubernetes platform.

[0049] In one implementation, such as Figure 3 As shown, developers implement specific service deployment logic by editing the startup.dol file in the simplified version. The startup.dol file uses predefined syntax to describe each service deployment operation. Each command corresponds to an operation type, and the service deployment platform parses and executes the corresponding actions based on the commands. The specific commands and their functions are as follows: (1) Service deployment (INSTALL command) The INSTALL command instructs the service deployment platform to deploy the specified business service in the target Kubernetes cluster. The service deployment platform then completes the containerized deployment of the service based on the image, parameters, and topology configured in the sub-script package.

[0050] (2) Service deletion (DEL command)

[0051] The DEL command instructs the service deployment platform to delete the target service and its associated containers, storage, and configuration resources to take the service offline or update it.

[0052] (3) Run command (RUN command)

[0053] The RUN command executes shell commands within a specified container, which can be used to perform initialization sub-script packages, debugging operations, or execute specific business logic.

[0054] (4) Database operations (EXEC command)

[0055] The EXEC command is used to perform database-related operations, including creating database accounts and passwords for MySQL, TiDB, etc., executing SQL sub-script packages, and completing database account configuration and data initialization. The service deployment platform can create a management container within the target Kubernetes cluster and mount the corresponding SQL file to execute operations.

[0056] (5) Resource request (HTTP command)

[0057] HTTP commands are used to execute HTTP requests such as POST, GET, and PATCH to upload or retrieve external resources, or to call business system interfaces to automate operations.

[0058] (6) Data import (import command)

[0059] The import command imports data (such as departments, users, roles, etc.) into the corresponding RBAC (role-based access control) platform to initialize permissions and resource information.

[0060] (7) Importing log templates (clog command)

[0061] The clog command is used to import the log templates for value-added services into the logging system within the Kubernetes cluster, which is then used to configure the business log collection rules.

[0062] (8) Kubernetes cluster operations (KUBECTL commands)

[0063] The KUBECTL command allows you to directly execute native Kubernetes commands, enabling you to create, modify, query, or adjust cluster resources, such as Pod management and service updates.

[0064] (9) Copy files (DCOPY command)

[0065] The DCOPY command can be used to copy specified files to a preset path within the target container, enabling the distribution and deployment of configuration files or resource files.

[0066] (10) Mount storage (nfs command)

[0067] The NFS command is used to mount NFS storage, which mounts the target storage resource to a predefined directory of the container for persistent storage or shared data access.

[0068] By combining and executing the above commands, developers can fully describe the deployment process of a sub-script package in the startup.dol file. The service deployment platform parses and executes these commands to achieve automated deployment, configuration, and initialization of complex business services on the Kubernetes platform.

[0069] In this embodiment, the coordination script package serves as the delivery entity of the target solution, and it integrates a coordination script and multiple sub-script packages. The coordination script package contains a coordination orchestration file, which carries the logical instructions of the coordination script.

[0070] Specifically, the orchestration file provides a top-level control entry point for the target solution, used to integrate, sort, and schedule multiple sub-script packages provided by various underlying R&D teams. The service deployment platform parses the logical instructions in the orchestration file to construct the dependency topology between the sub-script packages, thereby enabling the sequential execution and one-click deployment of multiple sub-script packages. Using this embodiment, users can complete the deployment and initialization process of complex business applications involving multiple services and dependencies without manually executing each sub-script package, significantly simplifying the deployment process and improving the level of system automation.

[0071] like Figure 4 As shown, the overall planning script package contains the following: The sub-scripts folder contains sub-script packages corresponding to each service. Each sub-script package contains its own instruction definition file (such as startup.dol), sub-script package description file (such as dolphin.yaml), local configuration file (such as values.yaml), etc., which are used to describe and execute the deployment process of a single service.

[0072] The overall planning script file (such as startup.dol in the root directory) describes the execution order and dependencies of each sub-script package. The service deployment platform parses the scheduling order according to this file and executes the sub-script packages in sequence to achieve collaborative deployment of multiple services.

[0073] A global configuration file (such as values.yaml in the root directory) is used to store global parameters for the overall planning script package. Global parameters can be passed to each sub-script package, overriding or supplementing the local parameters of the sub-script package itself, thus achieving unified management of global configuration.

[0074] The description file for the sub-script package of the overall planning script (such as dolphin.yaml in the root directory): is used to record the basic information of the overall planning script package, such as the scheme name, version number, developer information and description information.

[0075] The image folder is an optional folder used to store the image files required for deployment, mainly including the dependent images that are missing in the sub-script packages.

[0076] The readme.md file is a documentation file that provides instructions on how to use the management script package, the steps involved, and any precautions.

[0077] In the implementation, after receiving the deployment request, the service deployment platform first parses the top-level overall planning script file in the root directory and generates an execution order list of each sub-script package; Based on the global parameters in the global configuration file, the local parameters of each sub-script package are instantiated to generate complete deployment parameters; The sub-script packages are scheduled sequentially to execute various commands defined within them, including service deployment, database initialization, log configuration, and resource mounting. Through status monitoring and log collection mechanisms, the execution status of each sub-script package is fed back in real time, ensuring that the entire deployment process is controllable and reliable.

[0078] Through the above implementation methods, the overall planning script package of this embodiment can realize centralized management and one-click deployment of multiple sub-script packages, thereby improving the deployment efficiency and maintainability of complex business solutions under the Kubernetes platform.

[0079] In one implementation, upon receiving a deployment instruction for the target solution, the coordination script package further performs at least one of the following preprocessing actions: The compressed orchestration script package is decompressed, and the integrity of the orchestration files, global configuration files, and multiple sub-script packages is verified according to the preset directory schema. For example, it verifies the existence of the orchestration entry file and whether the corresponding sub-script package directory structure conforms to the specifications, thereby avoiding deployment interruptions due to missing files.

[0080] Obtain the target environment parameters configured by the user (such as target cluster identifier, namespace, and storage domain information). Associate and map these target environment parameters with the configuration items in the coordination script package to determine the physical boundaries for subsequent atomic operation commands.

[0081] The system reads key-value pairs from the global configuration file and builds a global parameter pool in memory. This global parameter pool will serve as the source of raw configuration data for subsequent instantiation and deployment, and supports secondary fine-tuning by users through form rendering to generate the final target configuration parameters used for execution.

[0082] Through the above steps, the initialization transformation from the "static offline package" of the overall planning script package to the "dynamic deployment task" is completed, providing a structured data foundation for subsequent logical parsing and time-series scheduling.

[0083] In this embodiment of the disclosure, in order to accurately describe the dependencies between multiple sub-script packages and form executable execution sequence logic, this embodiment further explains the parsing process of the overall orchestration file in step 120 above.

[0084] In some implementations, parsing the overall coordination document includes: The pre-defined Domain Specific Language (DSL) parser is used to perform semantic analysis on the orchestration files and construct a deployment logic topology diagram. Based on the deployment logic topology diagram, the prerequisite dependencies between each sub-script package are identified, and the execution timing logic is generated using the topology sorting algorithm. During the parsing and orchestration of the file, a resource status table is created. This table is used to map the Pod lifecycle status, database connection handle, and configuration file mount path of each sub-script package in real time, so as to dynamically constrain and verify the execution timing logic during the execution of the sub-script package scheduling.

[0085] In this implementation, the orchestration file is described using a deployment-oriented DSL, which declares the logical identifiers, dependencies, and execution constraints of each sub-script package. The DSL parser converts the syntactic structure in the orchestration file into internally processable semantic units, thereby constructing a deployment logical topology diagram reflecting the deployment relationships of each sub-script package.

[0086] The deployment logic topology graph uses sub-script packages as nodes and the dependencies between sub-script packages as directed edges to represent the sequential constraints of each sub-script package during deployment. This deployment logic topology graph clearly defines which sub-script packages must be scheduled only after all other sub-script packages have completed execution.

[0087] Furthermore, after constructing the deployment logic topology graph, the prerequisite dependencies between each sub-script package are identified based on this graph. A topology sorting algorithm is then used to sort the deployment logic topology graph, thereby generating execution timing logic to guide deployment. This execution timing logic indicates the scheduling order of each sub-script package during deployment to avoid deployment failures due to unmet dependencies.

[0088] The resource status table described above is used to uniformly record and map the status of key resources involved in the deployment process. This includes the Pod lifecycle status, database connection handle, and configuration file mount path for each sub-script package. The Pod lifecycle status reflects the running status of the container instance triggered by the corresponding sub-script package in the Kubernetes cluster, the database connection handle identifies the connection context established during database initialization, and the configuration file mount path indicates the mount location of the configuration resource within the container.

[0089] In this way, during the subsequent scheduling and execution of sub-script packages, the execution timing logic is dynamically constrained and verified based on the resource status table. That is, before scheduling a sub-script package, it is determined whether its corresponding prerequisites have been satisfied by the resource status table, thereby ensuring that the deployment process is executed stably in the expected logical order.

[0090] Through the above method, this implementation method achieves automatic parsing and execution order control of complex planning script package dependencies without relying on manual intervention, providing a reliable execution foundation for subsequent Kubernetes service deployment based on sub-script packages.

[0091] In this embodiment, step 120 involves parsing the overall orchestration file to generate execution sequence logic to guide deployment. Based on this, to improve overall deployment efficiency while ensuring the correct deployment order, this embodiment continues with step 130, scheduling each sub-script package sequentially according to the execution sequence logic.

[0092] In one implementation, each sub-script package is sequentially scheduled as an asynchronous execution process based on a state machine, including: Upon receiving the deployment confirmation instruction (which is an execution confirmation of the deployment instruction in step 110), the deployment task is submitted to the asynchronous job queue, and a task processing identifier is returned. Each sub-script package is scheduled according to the execution timing logic to complete the pipeline operation from image acquisition, storage volume creation, database initialization to application Pod pull; The deployment is considered complete when all Pods corresponding to the business service reach the Ready state and the service discovery endpoint has been registered, by monitoring the Pod status through the probe interface.

[0093] In this implementation, an asynchronous job queue is used to uniformly manage the queuing, execution, and status updates of multiple deployment tasks, thereby preventing deployment operations from blocking the user interface thread. After a deployment task is successfully submitted to the asynchronous job queue, a task processing identifier corresponding to that deployment task is returned for subsequent queries of deployment progress and execution results.

[0094] After the deployment task enters the execution phase, multiple sub-script packages are scheduled according to the execution sequence logic obtained from the aforementioned analysis. The scheduling process selects the currently executable sub-script packages one by one according to the execution sequence logic and incorporates them into the execution node of the current deployment state machine. The state machine is used to describe the state transition process of the sub-script packages from "pending execution", "in execution" to "execution completed", to ensure that the execution order of each sub-script package is consistent with the dependency constraints.

[0095] The process involves several steps: image acquisition prepares the corresponding container runtime image for the target business service; storage volume creation provides persistent storage resources for the business service; database initialization establishes the required database structure and initial data for the business service; and application Pod pulling creates and starts container instances in the Kubernetes cluster to host the business service. These operations are executed sequentially according to a pre-defined pipeline sequence, forming a complete deployment process.

[0096] In this implementation, the probe interface is used to periodically obtain the running status information of the Pods corresponding to the business service. When it is detected that all Pods corresponding to the business service have reached the Ready state and the Endpoint in the service discovery mechanism has been registered, it is determined that the current deployment task has been completed, and the deployment result is updated in the status record of the deployment task.

[0097] Through the above methods, this implementation method achieves an efficient service deployment process based on asynchronous state machines while ensuring the correct deployment order and dependencies.

[0098] In this embodiment, to further improve the controllability and observability of the deployment process, the above-mentioned pipeline operation is further described. In some embodiments, the above-mentioned pipeline operation further includes: pre-executing image pulling or distribution on the target node according to the image list; starting a background observer process to obtain the deployment progress by monitoring resource status changes of the target Kubernetes cluster.

[0099] The image manifest lists all container images required for the current deployment task. By pre-pulling or distributing images, the waiting time during the subsequent Pod startup phase can be reduced, thereby improving the overall service deployment efficiency. The background observer process continuously monitors resource status changes in the target Kubernetes cluster, including Pod status changes, storage resource binding status, and service endpoint registration status. By monitoring these resource status changes, deployment progress information is obtained in real time and associated with the deployment tasks in the aforementioned asynchronous job queue. This implementation achieves real-time monitoring and progress feedback of the service deployment process, ensuring clear and traceable status feedback even during asynchronous execution.

[0100] In this embodiment of the disclosure, each sub-script package is scheduled sequentially to complete the final deployment of the business service. Specifically, during step 131, the sub-script package description file describes the business deployment type, required resource types, and configurable parameter items corresponding to the sub-script package, including at least parameter definition information, parameter scope, and default values.

[0101] After reading the sub-script package description file, instantiated deployment parameters are generated based on the target configuration parameters and the sub-script package's own local parameters. The target configuration parameters are a global set of parameters generated in the previous steps, combining deployment environment parameters and user configuration operations. Local parameters are parameters that only apply to the current sub-script package and describe its unique deployment requirements. By merging and prioritizing the target configuration parameters and local parameters, instantiated deployment parameters corresponding one-to-one with the current sub-script package are generated, enabling the same sub-script package to generate differentiated deployment instances in different deployment environments or with different solutions.

[0102] During step 132, the instruction definition file, which describes specific deployment behaviors, declares various extended instructions using predefined syntax. During the parsing of the instruction definition file, the sub-script package content undergoes syntax scanning and instruction recognition to identify the multiple extended instructions defined within. Extended instructions identify the types of deployment operations that require unified scheduling and execution; they include at least one or more of database operation instructions, log operation instructions, and configuration operation instructions. By parsing extended instructions from the instruction definition file, the semantics of the sub-script package and its specific execution logic are decoupled, allowing the instruction definition file to describe deployment intent only, while the specific execution method is uniformly controlled by the service deployment platform.

[0103] Finally, step 133 is executed until all sub-script packages have been scheduled and deployed. Atomic operation instructions are the smallest unit of deployment operation, used to drive the Kubernetes cluster to complete specific resource operations. Through atomic operation instructions, the system performs one or more of the following operations: creating or updating container resources corresponding to the business service to complete the container deployment of the business service; triggering the database initialization process to complete the creation of the database instance or data initialization; and converting business configuration parameters into Kubernetes native resource objects and distributing them to complete the configuration distribution operation.

[0104] By using the above method, sub-script packages are used as the execution unit, and the description of sub-script packages, parameter generation and Kubernetes atomic operation delivery process are organically combined to achieve automated deployment of complex business services in the target Kubernetes cluster.

[0105] In this embodiment of the disclosure, after parsing the instruction definition file within the sub-script package in step 133 above, multiple extended instructions are identified. For different types of extended instructions, the system executes corresponding atomic operations according to a preset instruction processing strategy.

[0106] In one scenario, if a database operation command is detected, a management container is created within the target Kubernetes cluster and an SQL file is mounted. The built-in driver is then used to execute the SQL operation to initialize the database instance. The management container is a temporary, control-type container that hosts the database driver and establishes a connection with the target database instance. During the creation of the management container, a pre-configured SQL file from a sub-script package is mounted to a specified path within the management container. Subsequently, the database driver built into the management container parses and executes the SQL file to complete the database initialization operation.

[0107] In another scenario, if a log operation command is detected, the log collection rules are encapsulated as a Sidecar container configuration and injected into the target service Pod. The Sidecar container acts as an auxiliary container, running concurrently with the target service Pod to collect log data from the service container. By injecting the Sidecar container configuration into the template of the target service Pod, the service has log collection capabilities from startup, thus achieving synchronous execution of log rules and the service deployment process.

[0108] In some cases, if a configuration operation command is detected, the business configuration file in the coordination script package is converted into a Kubernetes native storage object, or container environment variables are generated based on the target configuration parameters, and then mounted to the container's default path. Kubernetes native storage objects include at least one of ConfigMap or Secret, used to manage configuration data in a native Kubernetes manner. Subsequently, the native storage object or environment variables are injected into the container's default path through the mount operation, enabling the business container to read and use the corresponding configuration content during startup or runtime.

[0109] Through the above methods, this implementation method achieves unified scheduling and execution of multiple types of deployment operations based on extended instructions, enabling database initialization, log configuration, and business parameter configuration to be completed collaboratively with the container deployment process.

[0110] In this embodiment, after completing the container deployment of the corresponding business service, the deployment session state associated with the coordination script package is maintained. In response to fine-tuning operations for the deployed business service, the native storage object or container environment variables are updated in a targeted manner to trigger hot configuration changes for the target business service. By maintaining the deployment session state, it is possible to continue responding to configuration adjustment requests for the deployed business service after deployment is complete. The aforementioned targeted update operation is used to modify only the target configuration item without affecting other deployed resources, thereby triggering hot configuration changes for the business service.

[0111] In this embodiment, the process of sequentially scheduling each sub-script package also includes a real-time monitoring and exception rollback mechanism for the execution of the sub-script packages. During the execution of the sub-script packages, a bidirectional communication link is established to maintain a connection with the execution environment for transmitting control commands and status feedback information.

[0112] Specifically, the system continuously captures the output data stream generated by the sub-script packages (including standard output information, standard error information, and execution status indicators), and asynchronously pushes it to the visualization front-end for display after structured processing. Simultaneously, it monitors for anomalies during the execution of the sub-script packages. When an anomaly is detected (such as returned error codes, resource creation failure, or timeout), a reverse cleanup command is triggered according to a preset strategy.

[0113] The reverse cleanup command is used to roll back deployed intermediate resources. Based on the resource creation order and dependencies recorded in the deployment session state, cleanup operations are performed sequentially in the reverse order of the deployment process to avoid resource residue or dependency conflicts. Through this method, this implementation transparently displays the execution process of the sub-script package while ensuring effective rollback in case of anomalies, thereby improving the stability and controllability of service deployment.

[0114] Figure 5 A flowchart illustrating another embodiment of the Kubernetes-based service deployment method provided in this disclosure is shown below. Figure 5 As shown, this method includes, but is not limited to, the following steps: Step 510: Display the script package import interface through the deployment management interface, and receive the overall planning script package uploaded by the user based on the script package import interface; Step 520: Receive deployment instructions for the target solution. The deployment instructions carry a coordination script package, which includes a coordination orchestration file, a global configuration file, and multiple sub-script packages. Step 530: Parse the overall orchestration file, determine the execution sequence logic between multiple sub-script packages, and extract the target configuration parameters corresponding to each sub-script package from the global configuration file; Step 540: According to the execution sequence logic, schedule each sub-script package in sequence. For the currently scheduled target sub-script package, execute the following sub-steps: Step 541: Read the sub-script package description file in the target sub-script package, and generate instantiation deployment parameters based on the target configuration parameters and the local parameters provided by the target sub-script package; Step 542: Parse the instruction definition file within the target sub-script package and identify the multiple defined extended instructions; Step 543: Execute extended instructions based on the instantiation deployment parameters. By issuing atomic operation instructions to the target Kubernetes cluster, complete the container deployment, database initialization, and configuration distribution of the corresponding business service.

[0115] In this implementation, a pre-import mechanism for the orchestration script package is introduced before receiving deployment instructions for the target solution. The deployment management interface can be a web-based management page or other human-computer interaction interface, which serves as the entry point for configuration and operation related to service deployment. The script package import interface is used to receive the orchestration script package uploaded by the user. The orchestration script package is a collection of resources that encapsulates the deployment logic of the target solution, and includes an orchestration file, a global configuration file, and multiple sub-script packages.

[0116] After the user uploads the coordination script package via the script package import interface, the service deployment platform stores and registers the coordination script package, placing it in a pending deployment state. Until a deployment instruction for the target solution is received, the coordination script package exists only as an optional deployment resource and does not trigger actual Kubernetes cluster operations.

[0117] When a deployment instruction for the target solution is received, the service deployment platform identifies the corresponding coordination script package from the uploaded and registered coordination script packages and proceeds to the subsequent sub-script package parsing and deployment execution process. This method decouples the advance import of the coordination script package from the triggering of deployment instructions, facilitating centralized management and reuse of deployment content by users.

[0118] In this embodiment of the disclosure, in order to clarify the target deployment environment before deployment execution and to enable configurable processing of deployment parameters, further steps are provided before receiving deployment instructions for the target solution. Figure 6 The deployment environment selection and parameter configuration process is shown below.

[0119] Step 610: Display the list of available physical resources through the interactive interface. The physical resource list reflects the set of resources in the current service deployment platform that can be used to host Kubernetes service deployments. It can include different Kubernetes clusters, available namespaces in the clusters, and corresponding deployment domain information.

[0120] Step 620: When a user makes a selection operation in the physical resource list, parse the selection operation for the physical resource list and obtain the target deployment environment parameters. The target deployment environment parameters include at least the target cluster identifier, namespace, and deployment domain information. The target deployment environment parameters are used to determine the target of the atomic operation command.

[0121] Step 630: Parse the global configuration file in the previously uploaded coordination script package, extract the parameters to be configured, and visualize the parameters based on a predefined template. The parameters to be configured are common deployment parameters shared among multiple sub-script packages, which may include service port, image version, database connection information, etc.

[0122] Step 640: Upon receiving a modification operation for the rendering parameters, update the parameters to be configured based on the modification operation, and generate target configuration parameters based on the updated parameters to be configured and the target deployment environment parameters. The target configuration parameters, as a unified set of parameters, are referenced in subsequent sub-script package scheduling and extended instruction execution to ensure that deployment behavior remains consistent with the selected deployment environment and user configuration.

[0123] By using the above methods, the deployment environment is clearly defined and the deployment parameters are uniformly configured before the formal deployment, providing a clear and controllable parameter foundation for subsequent automated sub-script package scheduling and Kubernetes atomic operation distribution.

[0124] The following describes one implementation of the service deployment method, using the deployment management interface provided by the service deployment platform.

[0125] User login service deployment platform, enter Figure 7 The deployment management page, as shown, displays "Drag the file here, or click upload," allowing users to upload coordination script packages. After importing, the service deployment platform verifies the uploaded coordination script package and prepares the resource information required for subsequent scheduling and execution. For the directory structure of sub-script packages and coordination script packages, please refer to the previous content; it will not be repeated here.

[0126] After importing the overall planning script package, the service deployment platform automatically redirects to... Figure 8 The storage management module interface shown here is for users to prepare for deployment: Displays a list of available Kubernetes clusters, such as v263x-h10612.

[0127] The system displays the storage identifier, such as storage1, and the specific storage item, such as demo-nfs. When the user clicks on a specific storage item (e.g., demo-nfs), the service deployment platform is accessed. Figure 9 The deployment package interface shown prepares you for the next deployment step. This step is used to confirm the target deployment environment and ensure that the storage resources required for the deployment are available.

[0128] In the deployment package interface, users can configure global parameters: Basic information is displayed, including solution version, target cluster name, and deployment namespace.

[0129] Parameter configuration interface: The interface displays the parameters of sub-script packages and global parameters of the overall planning script package in the local configuration file (such as values.yaml). Users can modify the required parameters of each sub-script package in this interface.

[0130] Operation options: The bottom right corner of the interface provides "Confirm Deployment" and "Cancel" buttons.

[0131] If the user clicks "Confirm Deployment," the service deployment platform will generate deployment parameters for each sub-script package and schedule them according to the execution logic. If the user clicks "Cancel," the deployment operation will be abandoned. This step enables visual configuration of the overall planning script package and its sub-script package parameters, and applies the configuration to subsequent execution processes.

[0132] After the user clicks "Confirm Deployment", the service deployment platform will redirect to... Figure 10 The execution interface displayed the message: "Deploying, please wait." The service deployment platform executes the deployment according to the following logic: Sub-script package scheduling: According to the execution timing logic defined in the overall orchestration file, each sub-script package is scheduled in sequence.

[0133] Instantiated deployment parameters: Combine global parameters and local parameters provided by the sub-script package to generate instantiated deployment parameters.

[0134] Extended instruction execution: Parses extended instructions defined in the instruction definition file (such as startup.dol) within the sub-script package, including: service deployment (INSTALL), service deletion (DEL), database operation (EXEC), run command (RUN), resource request (HTTP), data import (import), log template import (clog), K8S command (KUBECTL), file copy (DCOPY), mount storage (nfs), etc.

[0135] Atomic operation command issuance: Atomic operation commands are issued to the target Kubernetes cluster based on the instantiation deployment parameters to complete operations such as container deployment, database initialization, configuration file mounting, and log rule injection.

[0136] Status monitoring: The status of Pods is monitored in real time through probe interfaces or background observer processes. When all business service corresponding Pods reach the Ready state and the service discovery endpoint has been registered, the deployment is considered complete.

[0137] After deployment is complete, the service deployment platform will automatically redirect to... Figure 11 The log inspection interface shown displays the execution logs of the deployment process, including the execution status, results, and exception information for each sub-script package. Users can view this in real time. Output data stream: Capture the output data stream during the execution of the sub-script package through a bidirectional communication link and push it asynchronously to the visualization front end for display.

[0138] Exception handling: If an exception is detected in the execution of a sub-script package, the system can trigger a reverse cleanup command according to a preset strategy to roll back the deployed intermediate resources.

[0139] The above implementation method enables one-click deployment of Kubernetes services via a web-based interface, integrating the traditionally cumbersome manual deployment process into a unified script package execution flow. Specific benefits include: automated and one-click deployment, simplified operation, support for rapid deployment of multi-service and multi-dependency business solutions, significantly improved deployment efficiency, and a lower skill threshold for on-site operators. Furthermore, the deployment process is monitorable and rollbackable, improving deployment reliability and maintainability. Additionally, visualized deployment parameter configuration ensures environmental consistency and parameter accuracy.

[0140] Figure 12 This invention discloses a module structure diagram of a Kubernetes-based service deployment system, which is used as a service deployment platform and includes a receiving module 1110, a parsing module 1120, and a scheduling module 1130 for automating the deployment of a target solution.

[0141] In this embodiment, the receiving module 1110 is used to receive a deployment instruction for the target solution. The deployment instruction carries a coordination script package, which includes a coordination orchestration file, a global configuration file, and multiple sub-script packages. During runtime, the receiving module 1110 first receives upload or import operations of the coordination script package through the deployment management interface. Subsequently, upon detecting a deployment instruction trigger signal, it generates and receives a deployment instruction carrying the coordination script package. This deployment instruction marks the formal start of the target solution deployment process.

[0142] In this embodiment, the parsing module 1120 is connected to the receiving module 1110 and is used to parse the orchestration file, determine the execution timing logic between multiple sub-script packages, and extract the target configuration parameters corresponding to each sub-script package from the global configuration file. Upon receiving the deployment instruction, the parsing module 1120 first loads the orchestration file, uses a preset parser to perform semantic analysis on the file content, constructs an internal data structure reflecting the dependencies between sub-script packages, and thus determines the execution timing logic. Simultaneously, the parsing module reads the global configuration file, extracts the shared parameters defined therein as the target configuration parameters for each sub-script package, and stores them in a parameter pool in memory.

[0143] In this embodiment, the scheduling module 1130 is connected to the parsing module 1120 and is used to schedule each sub-script package sequentially according to the execution timing logic. For the currently scheduled target sub-script package, the scheduling module 1130 performs the following sub-steps: First, the sub-script package description file within the target sub-script package is read, and instantiation deployment parameters are generated based on the target configuration parameters obtained from the parsing module 1120 and the local parameters inherent in the sub-script package.

[0144] Secondly, the instruction definition file within the target sub-script package is parsed to identify the multiple extended instructions defined therein. Extended instructions are predefined operation types used to extend functionality beyond the basic container deployment.

[0145] Finally, based on the instantiation deployment parameters, extended instructions are executed. By issuing atomic operation instructions to the target Kubernetes cluster, the container deployment, database initialization, and configuration distribution of the corresponding business service are completed. The scheduling module 1130 implements the issuance of atomic operations through the interaction interface with the Kubernetes API, ensuring the atomicity and consistency of the operations.

[0146] Through the collaborative work of the receiving module 1110, parsing module 1120 and scheduling module 1130, the service deployment system of this embodiment realizes the complete process of receiving the overall planning script package and automatically deploying the business service.

[0147] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

Claims

1. A service deployment method based on Kubernetes, characterized in that, include: Receive a deployment instruction for a target solution, the deployment instruction carrying a coordination script package, the coordination script package including a coordination orchestration file, a global configuration file and multiple sub-script packages; The overall orchestration file is parsed to determine the execution timing logic between the multiple sub-script packages, and the target configuration parameters corresponding to each sub-script package are extracted from the global configuration file. According to the execution timing logic, each of the sub-script packages is scheduled sequentially. For the currently scheduled target sub-script package, the following sub-steps are executed: Read the sub-script package description file within the target sub-script package, and generate instantiation deployment parameters based on the target configuration parameters and the local parameters inherent in the sub-script package; Parse the instruction definition file within the target sub-script package to identify multiple defined extended instructions; The extended instructions are executed according to the instantiation deployment parameters. By issuing atomic operation instructions to the target Kubernetes cluster, the container deployment, database initialization, and configuration distribution of the corresponding business service are completed.

2. The service deployment method based on Kubernetes according to claim 1, characterized in that, The Kubernetes-based service deployment method also includes: Before receiving deployment instructions for the target solution, the deployment management interface displays a script package import interface, and the user-uploaded coordination script package is received based on the script package import interface until the deployment instructions for the target solution are received.

3. The service deployment method based on Kubernetes according to claim 2, characterized in that, The Kubernetes-based service deployment method also includes: Before receiving deployment instructions for the target solution, a list of available physical resources is displayed through an interactive interface; The selection operation for the physical resource list is parsed to obtain the target deployment environment parameters. The target deployment environment parameters include at least the target cluster identifier, namespace, and deployment domain information. The target deployment environment parameters are used to determine the target of the atomic operation command. The global configuration file in the overall planning script package is parsed to extract the parameters to be configured, and the parameters to be configured are visualized and rendered based on a predefined template. Based on the modification operation on the rendering parameters, the parameters to be configured are updated, and the target configuration parameters are generated based on the updated parameters to be configured and the target deployment environment parameters.

4. The service deployment method based on Kubernetes according to claim 1, characterized in that, The parsing of the overall planning and arrangement document includes: The overall arrangement file is semantically analyzed using a preset domain-specific language parser to construct a deployment logic topology diagram; Based on the deployment logic topology diagram, the prerequisite dependencies between each of the sub-script packages are identified, and the execution timing logic is generated using a topology sorting algorithm. During the parsing of the overall orchestration file, a resource status table is created. The resource status table is used to map the Pod lifecycle status, database connection handle, and configuration file mount path corresponding to each sub-script package in real time, so as to perform dynamic constraint verification on the execution timing logic during the execution of the sub-script package scheduling.

5. The service deployment method based on Kubernetes according to claim 1, characterized in that, The sequential scheduling of each of the sub-script packages is configured as an asynchronous execution process based on a state machine, including: Upon receiving the deployment confirmation instruction, the deployment task is submitted to the asynchronous job queue, and a task processing identifier is returned. According to the execution timing logic, each of the sub-script packages is scheduled to complete the pipeline operation from image acquisition, storage volume creation, database initialization to application Pod pull; The deployment is considered complete when all Pods corresponding to the business service reach the Ready state and the service discovery endpoint has been registered, by monitoring the Pod status through the probe interface.

6. The service deployment method based on Kubernetes according to claim 5, characterized in that, The assembly line operation also includes: Based on the image list, perform image fetching or distribution on the target node in advance; Start a background observer process to monitor resource status changes in the target Kubernetes cluster and obtain deployment progress.

7. The service deployment method based on Kubernetes according to claim 1, characterized in that, The step of executing the extended instructions according to the instantiation deployment parameters includes: If a database operation command is detected, a management container is created within the target Kubernetes cluster and an SQL file is mounted. The built-in driver is used to execute the SQL operation to complete the initialization of the database instance. If a log operation command is detected, the log collection rules are encapsulated into a Sidecar container configuration and injected into the target business Pod; If a configuration operation instruction is detected, the business configuration file in the coordination script package is converted into a Kubernetes native storage object, or a container environment variable is generated according to the target configuration parameters, and the mounting operation is performed to the container's preset path.

8. The service deployment method based on Kubernetes according to claim 7, characterized in that, After completing the container deployment of the corresponding business service, the Kubernetes-based service deployment method further includes: Maintain the deployment session state associated with the overall planning script package, respond to fine-tuning operations for deployed business services, and update the native storage object or container environment variables in a targeted manner to trigger the hot-applying configuration of the target business service.

9. The service deployment method based on Kubernetes according to claim 1, characterized in that, During the sequential scheduling of each of the sub-script packages, the Kubernetes-based service deployment method further includes: The output data stream during the execution of the target sub-script package is captured through a bidirectional communication link and asynchronously pushed to the visualization front end for display. If an execution error is detected in the target sub-script package, a reverse cleanup command is triggered based on a preset strategy to roll back the deployed intermediate resources.

10. A service deployment system based on Kubernetes, characterized in that, include: The receiving module receives a deployment instruction for the target solution. The deployment instruction carries a coordination script package, which includes a coordination orchestration file, a global configuration file, and multiple sub-script packages. The parsing module parses the overall orchestration file, determines the execution timing logic between the multiple sub-script packages, and extracts the target configuration parameters corresponding to each sub-script package from the global configuration file. The scheduling module, according to the execution timing logic, sequentially schedules each of the sub-script packages, and for the currently scheduled target sub-script package, executes the following sub-steps: Read the sub-script package description file within the target sub-script package, and generate instantiation deployment parameters based on the target configuration parameters and the local parameters inherent in the sub-script package; Parse the instruction definition file within the target sub-script package to identify multiple defined extended instructions; The extended instructions are executed according to the instantiation deployment parameters. By issuing atomic operation instructions to the target Kubernetes cluster, the container deployment, database initialization, and configuration distribution of the corresponding business service are completed.

Images