Method, device and medium for automatic deployment of server cluster

Abstract

Embodiments of the present application disclose a kind of automatic deployment method, device, equipment and medium of server cluster, wherein, the method is understood user intent by utilizing large language model and generates preliminary scheme, then through rule engine, high availability compliance verification is forced, architecture design error is eliminated from the source, in deployment stage, system generates customization task in combination with environment fingerprint, and through execution monitoring and intelligent diagnosis self-healing mechanism based on large model, various unexpected errors that appear in deployment process are dynamically handled, unattended self-healing deployment is realized, finally, the high availability of cluster is demonstrated through automated destructive testing, to ensure the quality of delivery result.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of server deployment, and in particular to an automated deployment method, apparatus, device, and medium for server clusters. Background Technology

[0002] With the widespread adoption of containerization technology, Kubernetes has become the de facto standard in container orchestration. In production environments, to ensure business continuity and service reliability, highly available Kubernetes clusters are typically deployed. Deploying a highly available cluster involves the coordinated work of multiple complex components, including but not limited to load balancers, the setup and quorum configuration of a distributed key-value store cluster, certificate management, network plugin configuration, and the deployment and coordination of multiple control plane nodes. This process is fraught with steps and complex configurations, demanding a high level of expertise and experience from operations and maintenance personnel.

[0003] Static script-based automated deployment tools are currently the mainstream automated deployment method in the industry. Their core principle is that operations personnel pre-write fixed configuration scripts, clearly defining each step of the deployment process, parameters, and dependencies. During deployment, the tool executes these pre-defined instructions sequentially on the target server according to the order defined in the script.

[0004] This solution lacks environmental adaptability and dynamic error correction capabilities. Its script logic is static and pre-defined; if the actual environment of the target server differs from the script's pre-defined "standard environment," the execution process will be interrupted due to an error. At this point, manual intervention is required to log into the server, troubleshoot the error, manually repair the environment, and then rerun the deployment script. This entire process is not only inefficient but also heavily reliant on human experience, making it prone to deployment failures or leaving configuration vulnerabilities due to operational errors, thus failing to achieve true unattended automation. Summary of the Invention

[0005] In view of this, embodiments of this application provide at least one method, apparatus, device, and medium for the automated deployment of server clusters.

[0006] The technical solution of this application embodiment is implemented as follows: On one hand, embodiments of this application provide an automated deployment method for a server cluster, the method comprising: The system receives natural language text input from the user to describe the cluster deployment requirements, performs intent parsing on the natural language text to generate an initial topology architecture, and inputs the initial topology architecture into a preset rule engine for high availability compliance verification to obtain a structured topology file that conforms to preset high availability standards. The system environment fingerprint of the target server cluster is collected by a distributed execution agent, and the structured topology file and the system environment fingerprint are input into the large language model to generate an atomic deployment task queue for each node in the target server cluster. The distributed execution agent is controlled to execute deployment instructions step by step on each node in the target server cluster according to the atomic deployment task queue, and the standard output stream, standard error stream and exit code are captured in real time during the execution of any deployment instruction; When the exit code indicating execution failure is captured, the deployment process of the current node is paused, and the corresponding error log fragment, the current execution instruction, and the system environment fingerprint are assembled into a diagnostic prompt word and input into the large language model to obtain a repair instruction. The repair instruction is inserted at the beginning of the atomic deployment task queue for automated repair, and the original deployment instruction is re-executed after successful repair. After all deployment commands have been executed successfully, a destructive test is performed on the deployed cluster. This test simulates node failures and detects the drifting of virtual IP addresses and the health status of the cluster, generating a high availability verification report.

[0007] On the other hand, embodiments of this application provide an automated deployment apparatus for a server cluster, the method comprising: The processing module is used to receive natural language text input by the user to describe the cluster deployment requirements, perform intent parsing on the natural language text to generate an initial topology architecture, and input the initial topology architecture into a preset rule engine for high availability compliance verification to obtain a structured topology file that conforms to the preset high availability standard. The system environment fingerprint of the target server cluster is collected by a distributed execution agent, and the structured topology file and the system environment fingerprint are input into the large language model to generate an atomic deployment task queue for each node in the target server cluster. The deployment module is used to control the distributed execution agent to execute deployment instructions step by step on each node in the target server cluster according to the atomic deployment task queue, and to capture the standard output stream, standard error stream and exit code in real time during the execution of any of the deployment instructions; When the exit code indicating execution failure is captured, the deployment process of the current node is paused, and the corresponding error log fragment, the current execution instruction, and the system environment fingerprint are assembled into a diagnostic prompt word and input into the large language model to obtain a repair instruction. The repair instruction is inserted at the beginning of the atomic deployment task queue for automated repair, and the original deployment instruction is re-executed after successful repair. After all deployment commands have been executed successfully, a destructive test is performed on the deployed cluster. This test simulates node failures and detects the drifting of virtual IP addresses and the health status of the cluster, generating a high availability verification report.

[0008] In another aspect, embodiments of this application provide a computer device, including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described automated deployment method for server clusters.

[0009] In another aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above-described automated deployment method for server clusters.

[0010] In another aspect, embodiments of this application provide a computer program including computer-readable code. When the computer-readable code is run in a computer device, the processor in the computer device executes some or all of the steps in the automated deployment method for implementing the above-described server cluster.

[0011] In another aspect, embodiments of this application provide a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described automated deployment method for server clusters.

[0012] This application embodiment utilizes a large language model to understand user intent and generate a preliminary solution. Then, a rule engine enforces high availability compliance verification, eliminating architectural design errors from the source. During the deployment phase, the system combines environmental fingerprints to generate customized tasks and dynamically handles various unexpected errors that occur during deployment through execution monitoring and a self-healing mechanism based on a large model. This achieves unattended, self-healing deployment. Finally, automated destructive testing is used to verify the high availability of the cluster and ensure the quality of the delivered results.

[0013] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0014] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0015] Figure 1 A schematic diagram illustrating the implementation process of an automated deployment method for a server cluster provided in this application embodiment; Figure 2 A schematic diagram illustrating the composition of an automated deployment device for a server cluster, provided in an embodiment of this application; Figure 3 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0018] The terms “first / second / third” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first / second / third” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[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 pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0020] This application provides an automated deployment method for a server cluster, which can be executed by the processor of a computer device. The computer device can refer to a server, laptop, tablet, desktop computer, smart TV, set-top box, mobile device (such as a mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device), or other similar computer equipment. Figure 1 This is a schematic diagram illustrating the implementation process of an automated deployment method for a server cluster provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes: Step 101: Receive natural language text input by the user to describe the cluster deployment requirements, perform intent parsing on the natural language text to generate an initial topology architecture, and input the initial topology architecture into a preset rule engine for high availability compliance verification to obtain a structured topology file that conforms to the preset high availability standard.

[0021] In this embodiment, natural language text refers to textual information input by the user using everyday human communication language, describing the requirements of the Kubernetes cluster they wish to build, such as deploying a highly available K8s cluster using 5 machines. The rule engine is a software component that automates judgment and processing based on preset deterministic logical rules. It does not rely on probabilistic models and ensures that the output meets specific hard standards. The structured topology file is a data file organized in a specific format that explicitly defines the roles, network configurations, component relationships, and other architectural information of each node in the cluster.

[0022] First, the system receives natural language text input from the user. Then, it uses a large language model to analyze the text, extracting key entities and understanding the user's deployment goals, thereby generating a preliminary cluster architecture scheme, i.e., the initial topology. Next, the system submits this initial topology to a pre-defined rules engine. The rules engine verifies and corrects the architecture based on built-in high-availability rules. After successful verification, the rules engine outputs a final, structured topology file that conforms to all pre-defined high-availability standards; this file serves as the blueprint for all subsequent deployment operations.

[0023] Step 102: Collect the system environment fingerprint of the target server cluster through the distributed execution agent, and input the structured topology file and the system environment fingerprint into the large language model to generate an atomic deployment task queue for each node in the target server cluster.

[0024] In this embodiment, the target server cluster refers to a group of physical or virtual servers specified by the user and planned for installing Kubernetes. The system environment fingerprint refers to a set of detailed status data about the target server's hardware and software environment collected through automated scripts, such as operating system type and version, kernel version, CPU architecture, memory size, installed software packages, port usage, etc. The atomic deployment task queue is a list of multiple independent, indivisible basic operation instructions arranged in a specific order, with each task explicitly specifying which specific command to execute on which target node.

[0025] The system sends lightweight probe commands to each server in the target server cluster through pre-deployed or connected distributed execution agents. These agents execute the commands and collect detailed environmental information from the servers, summarizing it to form a system environment fingerprint. Subsequently, the system uses the structured topology file generated in step 101 and the collected system environment fingerprint as context information, inputting them together into the large language model. The large language model combines these two pieces of information to understand what architecture to deploy and in what environment, thereby generating a highly customized atomic deployment task queue tailored to the specific differences of the current environment. This task queue meticulously plans every step from system initialization to Kubernetes component installation.

[0026] Step 103: Control the distributed execution agent to execute deployment instructions step by step on each node in the target server cluster according to the atomic deployment task queue, and capture the standard output stream, standard error stream and exit code in real time during the execution of any of the deployment instructions.

[0027] In this embodiment, step-by-step execution means that the system executes deployment instructions one after another in an orderly manner according to the task order defined in the atomic deployment task queue. Only after the previous task is successfully completed will the next task begin execution. The standard output stream is the stream of information normally output during program execution. The standard error stream is the stream of error and warning information output during program execution. The exit code is a numerical code returned to the operating system after program execution, used to indicate the execution result.

[0028] The system controls the distributed execution agent, which begins executing each deployment command on the corresponding nodes of the target server cluster according to the atomic deployment task queue. While running each command, the execution agent simultaneously activates three independent monitoring channels: one channel captures normal output information generated during command execution, another captures error and warning information, and the third retrieves the command's exit code after execution. This three-channel capture mechanism ensures that the system can comprehensively and in real-time perceive the execution status and detailed feedback of each command, providing a complete data foundation for subsequent fault diagnosis.

[0029] Step 104: When the exit code indicating execution failure is captured, the deployment process of the current node is paused, and the corresponding error log fragment, the current execution instruction, and the system environment fingerprint are assembled into a diagnostic prompt word and input into the large language model to obtain a repair instruction. The repair instruction is inserted at the beginning of the atomic deployment task queue for automated repair, and the original deployment instruction is re-executed after successful repair.

[0030] In this embodiment, the diagnostic prompt refers to a carefully crafted piece of text input designed to guide the large language model in fault analysis. It typically includes the error context, the current operational objective, and environmental constraints, and its format is similar to asking a question to an operations expert. The repair instruction refers to one or more executable commands generated by the large language model based on the diagnostic prompt analysis, used to resolve the specific current error.

[0031] When the distributed execution agent detects a non-zero exit code for a deployment command, the system immediately suspends the current deployment process on that node. The system extracts key log fragments reflecting the root cause of the problem from the captured standard error stream and related standard output stream. Then, the system assembles these error log fragments, the content of the currently failed command, and the previously collected system environment fingerprint into a structured diagnostic prompt word according to a preset template. This diagnostic prompt word is input into the large language model, requesting root cause analysis and a solution. After the large language model generates a repair command, the system performs a security check on it and inserts the safe repair command at the front of the node's atomic deployment task queue. The execution agent prioritizes executing this repair command, attempting to automatically repair the environmental problem. After the repair command executes successfully, the system re-executes the original deployment command that failed, thus achieving self-healing of the deployment process.

[0032] Step 105: After all deployment commands have been executed successfully, perform a destructive test on the deployed cluster. Simulate node failures and detect the drifting status of virtual IP addresses and the health status of the cluster to generate a high availability verification report.

[0033] In this application embodiment, destructive testing is a testing method that verifies the fault tolerance and recovery capabilities of a system by actively injecting faults. Virtual IP address migration refers to the process in a high-availability cluster environment where, when the master node fails, the virtual IP address automatically migrates from the failed node to a healthy standby node to ensure uninterrupted service access. The high-availability verification report is a document that summarizes the destructive testing process, observed system behavior, and final verification conclusions.

[0034] After the system confirms that all deployment commands have been successfully executed and the cluster software is installed, it will initiate the verification phase. The system uses a distributed execution agent to perform destructive testing on the deployed cluster. For example, the system will simulate a control plane node failure, sending a command to one of the master nodes to stop critical services or simulating network isolation. Simultaneously and subsequently, the system continuously monitors whether the pre-configured virtual IP addresses have successfully migrated to other healthy nodes within a preset time threshold and continuously polls the cluster's API health status. By analyzing the VIP migration status and the recovery of the overall cluster health status, the system verifies whether the cluster truly possesses high availability capabilities. Finally, the system integrates all test operations, monitoring data, and verification results to generate a detailed high availability verification report.

[0035] This application embodiment utilizes a large language model to understand user intent and generate a preliminary solution. Then, a rule engine enforces high availability compliance verification, eliminating architectural design errors from the source. During the deployment phase, the system combines environmental fingerprints to generate customized tasks and dynamically handles various unexpected errors that occur during deployment through execution monitoring and a self-healing mechanism based on a large model. This achieves unattended, self-healing deployment. Finally, automated destructive testing is used to verify the high availability of the cluster and ensure the quality of the delivered results.

[0036] Optionally, step 101 includes: Step 1011: The semantic extraction unit identifies the target server's Internet protocol address list, cluster version number, and network plugin type from the natural language text as key information.

[0037] In this embodiment, the semantic extraction unit refers to a software functional module in the deployment system. Its core function is to use natural language processing technology to analyze the input unstructured text to identify and extract specific data entities that are meaningful for subsequent processes. An Internet Protocol address list refers to a set of digital tags used to uniquely identify and locate computers or other network devices in a network. In this invention, it specifically refers to the set of server network addresses provided by the user and planned for building a Kubernetes cluster. A cluster version number refers to a specific version identifier of the Kubernetes software distribution that the user expects to deploy. A network plugin type refers to a category of software components used in a Kubernetes cluster to implement container network interconnection and policies, such as Calico or Flannel.

[0038] The deployment system receives natural language text input from the user through the semantic extraction unit in its intent parsing and topology planning module. This unit parses the text, using entity recognition technology to locate and extract the target server's Internet Protocol address list, the desired Kubernetes cluster version number, and the specified container network interface plugin type. This extracted information is stored in a structured manner by the system as crucial information for subsequent steps.

[0039] Step 1012: Input the key information into the large language model to perform topology deduction and obtain the initial topology architecture including node role assignment.

[0040] In this embodiment, the large language model refers to a deep learning model trained on massive amounts of data with a large parameter scale, possessing powerful natural language understanding, generation, and logical reasoning capabilities. Topology deduction refers to the process of generating a scheme of logical relationships and role allocation among components within a system through calculation or reasoning, based on given constraints and objectives. The initial topology architecture refers to the preliminary design scheme for the division of roles among Kubernetes cluster nodes, initially generated by the large language model based on input information.

[0041] The deployment system takes the key information extracted in step 1011 as input and submits it to the external or built-in large language model application interface. The system constructs a prompt, requesting the large language model to plan the node role allocation for a highly available Kubernetes cluster based on the provided number of server addresses, Kubernetes version, and network plugin type. After processing the prompt, the large language model outputs a text description containing the node role allocation suggestions. The system parses this output and formats it into structured initial topology data.

[0042] Step 1013: Input the initial topology architecture into the rule engine. The rule engine verifies the initial topology architecture according to the built-in hard-coded rules, wherein the hard-coded rules include at least a parity verification rule for the number of nodes in the distributed key-value storage system and a minimum value verification rule for the number of nodes in the control plane.

[0043] In this embodiment, the rule engine refers to a deterministic logic processing component in the deployment system, containing a series of predefined, immutable logical judgment rules used to validate and evaluate input data. Hard-coded rules refer to fixed business logic or constraints directly written in the program source code; here, they specifically refer to technical rules that must be followed to ensure Kubernetes high availability. A distributed key-value storage system node refers to an instance of the core component in a Kubernetes high-availability architecture, used for reliably storing all configuration data of the cluster, deployed on an independent node. A control plane node refers to a server running the Kubernetes core management components, responsible for managing the state and workload of the entire cluster.

[0044] The deployment system passes the initial topology data obtained in step 1012 to the rule engine. The rule engine calls its built-in hard-coded rule set to verify the architecture one by one. The verification includes: checking whether the number of nodes in the distributed key-value storage system is odd to ensure that the cluster can reach consensus in the event of a failure; and checking whether the number of control plane nodes reaches a preset minimum value to meet the basic redundancy requirements for high availability. The verification process produces a pass or fail result status.

[0045] Step 1014: When the initial topology does not conform to the hard-coded rules, the rule engine automatically corrects the initial topology and generates the structured topology file containing the node role allocation table, the virtual IP address, and classless inter-domain routing information of the Pod network segment.

[0046] In this embodiment, the structured topology file refers to a configuration file written in a standardized, machine-readable data format, which fully defines the architecture blueprint of the Kubernetes cluster, including detailed information such as the roles of all nodes and network configurations. The node role allocation table is the part of the structured topology file that explicitly lists the correspondence between each server IP address and its role in the Kubernetes cluster. A virtual IP address is a logical IP address that is not fixed to a single physical server but can be transferred between multiple master nodes in a high-availability cluster, providing a unified, highly available entry point for external access to the cluster API. Pod network segment classless inter-domain routing information refers to network configuration information used to define the range of IP addresses that Pods can use in the Kubernetes cluster and their subnetting rules.

[0047] When the rules engine determines in step 1013 that the initial topology does not conform to the hard-coded rules, the deployment system triggers automatic correction logic. The rules engine executes a preset correction algorithm based on the specific rule violated. For example, if the number of nodes in the distributed key-value storage system is even, it automatically adds or removes a node to make it odd. After correction, the system integrates all information to generate a final structured topology file. This file contains complete cluster configuration information, including a node role allocation table, planned virtual IP addresses, and network address ranges allocated to Pods.

[0048] This application's embodiments combine the flexible understanding capabilities of large language models with the deterministic verification capabilities of rule engines, enabling automatic conversion of users' natural language descriptions into detailed deployment architectures that fully comply with the high availability requirements of Kubernetes. This fundamentally eliminates infrastructure design errors caused by human negligence or the "illusion" of large models, ensuring that subsequent deployment processes are built on a correct and stable topology. This is a key prerequisite for achieving fully automated and highly reliable cluster deployment.

[0049] Optionally, step 102 includes: Step 1021: Control the distributed execution agent to connect to all target servers in the target server cluster through the Secure Shell protocol, and send a pre-set lightweight probe script to each target server.

[0050] In this embodiment, the Secure Shell protocol is an encrypted network transmission protocol used to provide secure remote login, command execution, and other network services in insecure networks. A lightweight probe script refers to a pre-written, small-sized, fast-execution, and low-resource-consumption automated script program. The script's function is to collect critical system configuration information of the target server without imposing a significant performance burden or requiring complex configuration changes.

[0051] The system first controls its internal distributed execution agent module. Based on the acquired list of target server IP addresses, this module establishes a network connection with each target server in the list one by one via the Secure Shell protocol. After successfully establishing a secure connection, the system transmits a pre-configured lightweight probe script file to each target server through this connection channel, triggering the script to execute in the target server's local environment.

[0052] Step 1022: Receive the collection results returned by the lightweight detection script. The collection results include the operating system distribution, kernel version, central processing unit architecture, memory size, swap partition enable status, and port usage of each target server. The results are then summarized to form the system environment fingerprint.

[0053] In this embodiment, the collection result refers to the raw data text returned by the lightweight probe script through the standard output stream after execution on the target server, containing various system configuration information of the target server. The system environment fingerprint refers to a structured data set that can uniquely identify and describe the overall hardware and software environment characteristics of the current target server cluster after parsing, organizing, and summarizing the collection results from all target servers.

[0054] The distributed execution agent module continuously monitors the Secure Shell protocol connection channel with each target server, capturing the data stream of collection results returned after the execution of the lightweight probe script. The system parses the received raw text data, extracting key fields such as the operating system distribution, kernel version, CPU architecture, memory size, swap partition status, and port usage of each server. Subsequently, the system aggregates and integrates this structured information extracted from each server to generate a unified, structured data file, known as the system environment fingerprint, which accurately describes the current state of the deployed target environment.

[0055] Step 1023: Combine the structured topology file and the system environment fingerprint into an enhanced prompt word, and input the enhanced prompt word into the large language model.

[0056] In this embodiment, the enhanced prompt word refers to a carefully crafted input text designed to guide the large language model in generating more accurate content that better fits the specific context. In this step, the prompt word integrates the cluster's target architecture planning and actual operating environment information, providing the model with a comprehensive basis for decision-making.

[0057] The system reads the structured topology file generated during the planning phase, which describes the desired cluster architecture. Simultaneously, it reads the system environment fingerprint file generated during the probing phase, which describes the actual server environment. Following a predefined template or format, the system combines and concatenates the contents of these two files to form an enhanced prompt word containing complete contextual information. Subsequently, the system calls the large language model service via an application programming interface (API) and sends the constructed enhanced prompt word as input to the large language model.

[0058] Step 1024: Receive the ordered atomic deployment task queues for different target servers returned by the large language model. Each atomic task in the atomic deployment task queue contains at least a task identifier, a target node identifier, and a command line instruction to be executed.

[0059] In this embodiment, an atomic deployment task queue refers to a list composed of multiple minimum execution units arranged in a specific order. Each minimum execution unit is an indivisible, independent operation step. A task identifier is a number or string used to uniquely identify each atomic task in the queue. A target node identifier is information specifying on which target server the atomic task needs to be executed, typically the server's IP address or hostname.

[0060] The system waits for and receives a response from the large language model after processing the enhanced prompt words. This response is a structured queue of atomic deployment tasks. The system parses this queue to confirm that it contains multiple atomic tasks ordered by execution logic. Each atomic task is a structure that explicitly contains a task identifier for management and tracking, a target node identifier for locating the execution position, and the command-line instruction text to be executed on that target node. This queue constitutes the detailed action plan for the subsequent automated deployment execution phase.

[0061] This application embodiment first automatically detects and summarizes the real environment information of the target server to form a system environment fingerprint; then combines this real environment information with the desired cluster topology as an enhanced context input to the large language model; finally, it obtains an ordered atomic deployment instruction sequence generated by the large language model, tailored to the specific environment of each server, realizing the transformation from a static, general deployment scheme to a dynamic, precise deployment scheme that can adapt to the differences in heterogeneous environments.

[0062] Optionally, step 103 includes: Step 1031: Control the distributed execution agent to send the corresponding command line instructions in the atomic deployment task queue to the target node in the target server cluster through the Secure Shell protocol.

[0063] In this embodiment, the Secure Shell protocol is an encrypted network protocol used to provide secure remote login, command execution, and data transmission services over insecure networks. The target node refers to a specific server within the target server cluster that has been assigned a specific role.

[0064] The system controls the distributed execution agent module, which acts as an automated execution entity. This module establishes a secure network connection with a specified target node in the target server cluster via the Secure Shell protocol. Once the connection is established, the system retrieves the sequentially ordered command-line instructions assigned to the target node from a pre-generated atomic deployment task queue. Subsequently, the system sends the first command-line instruction to be executed to the target node's operating system via this secure connection.

[0065] Step 1032: During the execution of the command line instruction, a three-channel capture mechanism is established to independently and in real time capture the standard output stream, the standard error stream, and the exit code.

[0066] In this embodiment, the standard output stream is the normal information output channel generated during program execution. The standard error stream is the error and diagnostic information output channel generated during program execution. The exit code is an integer value returned to the operating system after program execution, used to indicate the execution result.

[0067] When the target node's operating system executes the received command-line instructions, the system establishes a three-channel capture mechanism through the distributed execution agent module. This mechanism independently and in real-time monitors three key data streams of the instruction execution process: first, it captures regular log information printed to the standard output stream; second, it captures error or warning information printed to the standard error stream; and third, it captures the exit code returned by the operating system after instruction execution. Data from these three channels is collected synchronously and transmitted back to the system for subsequent analysis.

[0068] Step 1033: Determine the execution status of the current instruction based on the value of the exit code. If the value of the exit code is zero, mark the current atomic task as successfully executed and remove it from the atomic deployment task queue.

[0069] In the embodiments of this application, an atomic task refers to an indivisible, basic operational unit in the deployment process, such as installing a specific software package or executing a configuration command.

[0070] Upon receiving the exit code from the target node, the system immediately parses it. The system determines the success of the task based on predefined rules: if the exit code is zero, the system considers the atomic task corresponding to the command-line instruction to have been successfully executed. Subsequently, the system updates the task status, marking the atomic task as "successful" in the internal state machine and removing it from the atomic deployment task queue allocated to the target node. The system then proceeds to process the next atomic task in that queue.

[0071] Step 1034: If the value of the exit code is non-zero, it is determined that the current instruction execution has failed, the subsequent task execution flow for the current target node is suspended, and the fault diagnosis process is triggered.

[0072] In the embodiments of this application, the fault diagnosis process is a series of automated analysis, reasoning and repair steps designed to identify the root cause of execution failure and generate a solution.

[0073] After parsing the exit code, if its value is non-zero, the system determines that the current command-line instruction has failed and its corresponding atomic task has not been completed. The system immediately takes control measures: First, it suspends the execution of all subsequent atomic tasks for the target node where the failure occurred to prevent further system state chaos that might result from continuing execution in the erroneous state. Simultaneously, the system packages the failure event, the captured standard error stream content, the standard output stream content, and related environmental context information as input parameters to trigger and initiate an independent fault diagnosis and self-healing process.

[0074] This application's embodiments reliably distribute instructions through a secure protocol and comprehensively capture execution feedback using a three-channel mechanism. By accurately parsing exit codes, the system can instantly and accurately determine the execution result of each atomic task. For successful tasks, the system orderly advances the deployment process; for failed tasks, the system can immediately interrupt subsequent operations at the current node to prevent error accumulation and automatically transfer the problem to the diagnostic and repair stage. This series of steps ensures the controllability and observability of the deployment process, providing precise input and the necessary execution control foundation for subsequent intelligent analysis-based fault self-healing.

[0075] Optionally, step 104 includes: Step 1041: The captured raw error log is segmented using a log cleaner to extract the error log fragment containing the location of the error and its context.

[0076] In this embodiment, the log cleaner is a software module whose function is to process and analyze raw, unprocessed error log data. Raw error logs refer to a stream of text information automatically generated during system or program execution that records errors or abnormal events.

[0077] The system uses a log cleaner module to process raw error log data captured from the execution environment. This module first locates the core location of the error, and then, according to preset rules, extracts an error log segment from the raw log containing the location of the error and its surrounding context. This process aims to remove irrelevant and redundant information, retaining only the core log content valuable for diagnosing the problem.

[0078] Step 1042: Fill the error log fragment, the currently executed instruction, and the system environment fingerprint into the preset operation and maintenance diagnosis template to generate the diagnosis prompt words.

[0079] In this embodiment, the operation and maintenance diagnosis template is a predefined text structure or framework that includes fixed prompts and variable placeholders to guide the large language model in fault diagnosis. The diagnostic prompts are structured text generated based on the template and specific context, used to clearly describe the fault scenario and diagnostic request to the large language model.

[0080] The system uses the error log fragment extracted in step 1041, the currently executed instruction that triggered the error log, and the system environment fingerprint representing the target server's system status as variable data to fill the corresponding placeholder positions in the preset operation and maintenance diagnostic template. Through this filling operation, the system generates a complete diagnostic prompt word with rich contextual information, which accurately describes the current fault phenomenon, triggering operation, and operating environment.

[0081] Step 1043: Input the diagnostic prompts into the large language model and receive the original repair suggestions returned by the large language model.

[0082] In this embodiment, the system takes the diagnostic prompts generated in step 1042 as input and calls the large language model service through the application programming interface. The large language model analyzes and infers from the diagnostic prompts, generating a text response containing potential repair steps or commands, i.e., the original repair suggestion. The system then receives and captures this original repair suggestion text returned by the large language model.

[0083] Step 1044: Perform regular expression matching on the original repair suggestion using a security filter to block instructions containing high-risk operations, and use the instructions that pass the verification as the repair instructions.

[0084] In this embodiment, the security filter is a software module whose function is to scan and verify text instructions using a predefined set of rules to identify and block operations that may harm the system. Regular expression matching is a string search and matching technique based on regular expression patterns, used to accurately identify specific patterns in text. High-risk operations refer to instructions that may delete critical data, corrupt system configurations, or cause service interruptions, such as forcibly deleting the root directory or formatting a disk.

[0085] The system performs a security check on the original repair suggestions received in step 1043 using a security filter module. This module uses a series of predefined regular expression patterns to scan the text content of the original repair suggestions to identify whether they contain command patterns marked as high-risk operations. If a high-risk pattern is matched, the system blocks the repair suggestion to prevent it from being executed subsequently. Only repair suggestions that do not trigger any high-risk pattern matching are confirmed by the system as valid repair instructions.

[0086] Step 1045: Dynamically insert the repair instruction into the front of the atomic deployment task queue, control the distributed execution agent to execute the repair instruction first, and after the repair instruction is successfully executed, put the original deployment instruction back into the head of the atomic deployment task queue for retry execution.

[0087] In this embodiment, the atomic deployment task queue is a data structure that stores deployment tasks to be executed sequentially, where each task represents an indivisible basic operation instruction. The distributed execution agent is a software agent program responsible for actually executing these task instructions on a remote target server.

[0088] The system dynamically inserts the repair instruction that passed the security check, generated in step 1044, at the front of the currently processing atomic deployment task queue. The system then controls the distributed execution agent to prioritize the execution of this newly inserted repair instruction. After the distributed execution agent reports that the repair instruction has been executed successfully, the system puts the original deployment instruction that caused the error back into the head of the atomic deployment task queue so that it can be retried in the repaired environment.

[0089] This application's embodiments generate repair solutions by leveraging the reasoning capabilities of large language models, and automatically implement repairs and task retries after security filtering. This effectively solves the problems of traditional automated scripts stopping upon encountering errors and relying on manual intervention, significantly improving the robustness, automation level, and deployment success rate of complex system deployment processes, and achieving self-healing capabilities in the deployment process.

[0090] Optionally, step 105 includes: Step 1051: Obtain access credentials for the deployed cluster, and record the first physical node where the virtual IP address is currently located using the access credentials.

[0091] In this embodiment, access credentials refer to authentication information used for secure access to and operation of the Kubernetes cluster, typically including certificates, tokens, or kubeconfig configuration files. A virtual IP address is a logically defined IP address in the network that is not bound to a single physical network interface card (NIC), used to provide a unified, mobile service access point in a high-availability cluster. The first physical node refers to the server or virtual machine to which the virtual IP address is initially bound during verification testing.

[0092] The system first obtains administrator-level access credentials for the deployed Kubernetes cluster by invoking keys, certificates, or configuration files generated or configured during cluster deployment. Then, using these credentials, the system executes specific network probes or cluster status query commands, such as querying the load balancer status or checking the IP binding of a specific network interface, to determine and record which physical node the virtual IP address is currently bound to. This node is marked as the first physical node. This record serves as the initial reference point for subsequent verification operations.

[0093] Step 1052: Inject a fault instruction into the first physical node through the distributed execution agent. The fault instruction includes at least a command to stop critical service processes or a command to simulate network disconnection.

[0094] In this embodiment, the distributed execution agent is a lightweight service or daemon deployed on the target physical node. It receives instructions from the control center and executes them locally, while simultaneously feeding back the execution results and system status to the control center. Fault instructions are a series of predefined or dynamically generated operation commands designed to simulate server fault states.

[0095] The system sends fault injection commands to the first physical node recorded in step 1051 through its pre-deployed distributed execution agent on the target node. These commands are distributed via a secure remote execution channel. The specific content of the fault commands is designed to simulate common faults, including but not limited to: stopping the core service processes of Kubernetes, or simulating network isolation between the node and other cluster nodes by configuring firewall rules or disconnecting network interfaces. This step aims to proactively create a controllable fault environment.

[0096] Step 1053: After injecting the fault instruction, continuously poll the health interface of the application programming interface server at preset time intervals, and monitor whether the virtual IP address drifts and binds to the second physical node within a preset failover time threshold.

[0097] In this embodiment, the application programming interface server in a Kubernetes cluster refers to the kube-apiserver component. It serves as the gateway for all internal and external communication within the cluster, and its health status directly represents the availability of the cluster control plane. Polling refers to the process by which the system repeatedly sends requests to the target and checks the response at fixed, periodic time intervals. The failover time threshold is a preset upper limit used to measure whether the time required from a failure to service recovery meets high availability standards.

[0098] The system initiates a monitoring process immediately after the fault command takes effect. It continuously sends HTTP requests to the health check endpoint of the Kubernetes cluster's API Server at preset, short intervals. Simultaneously, the system monitors the network layer in parallel, detecting changes in the binding status of virtual IP addresses by continuously sending ARP requests or checking the network interface configurations of other physical nodes. The system continues these operations and timed checks to ensure that the virtual IP address successfully unbinds from the failed first physical node and rebinds to a healthy second physical node within a preset failover time threshold.

[0099] Step 1054: After the virtual IP address is successfully migrated, restart the first physical node and verify its ability to rejoin the cluster as a slave node, and generate the high availability verification report based on the failover time and node reentry status.

[0100] In this embodiment, "slave node" refers to a node that is not in a master role. After a failed node recovers, it typically rejoins the cluster as a regular worker node or a backup control plane node. A high availability verification report is a structured document or data record that summarizes the verification test process, results, and key metrics.

[0101] Once the system detects that the virtual IP address has successfully migrated to the second physical node, it sends service restart and node recovery commands to the previously failed first physical node via the distributed execution agent. The system then observes the node's startup logs and verifies whether it can successfully reconnect to the cluster and whether its status has returned to "Ready" in the `kubectl get nodes` command. Finally, the system integrates data from the entire test cycle, including the total time from fault injection to successful virtual IP migration and the final status of the failed node rejoining the cluster, to generate a detailed high availability verification report. This report is used to objectively assess the high availability level of the cluster.

[0102] The embodiments of this application not only simulate real-world failures to test the cluster's automatic failover capabilities, but also verify the recovery and reentry capabilities of failed nodes. This ensures that the delivered cluster possesses engineering-verifiable high availability and resilience, rather than simply completing software installation. This reduces the cost and subjective errors of manual verification, providing an objective and quantifiable guarantee for the cluster's reliability.

[0103] Optionally, before step 101, the method further includes: performing an environment pre-scan on the target server cluster. The environment pre-scan includes at least checking whether the swap partitions of all target servers are disabled, checking the occupancy of key ports, and checking the kernel version that is compatible with the preset standard. The results of the environment pre-scan are used as part of the system environment fingerprint.

[0104] In this embodiment, the target server cluster refers to a set of physical or virtual servers specified by the user for deploying a Kubernetes high-availability cluster. Environment pre-scanning is a probe operation automatically performed by the system before deployment, designed to collect hardware, software, and network configuration information of the target servers to assess whether they meet deployment requirements. A swap partition is an area used by the operating system to temporarily store some memory data on disk when physical memory is insufficient. In Kubernetes deployments, it is usually required to disable swap partitions to ensure the normal operation of components such as kubelet and avoid performance instability. Critical ports refer to the network port numbers required for communication between Kubernetes cluster components and related dependent services. Port occupancy status refers to whether these ports are being listened to by other processes or services, potentially leading to conflicts. Preset standard specifications refer to the minimum or recommended kernel version range required for different Kubernetes versions and operating system distributions, stored internally by the system. The kernel version is the version number of the operating system kernel, and its compatibility directly affects the stability of Kubernetes and container runtime. The system environment fingerprint is a structured data set that uniquely identifies and describes the current hardware and software environment state of the target server cluster, used for generating subsequent differentiated deployment tasks.

[0105] The system connects to each server in the target server cluster via SSH or gRPC. A predefined lightweight probe script runs on the target server, collecting basic information including operating system distribution, kernel version, CPU architecture, memory size, disk space, and network interface status. The system then aggregates the collected raw data to generate a preliminary environment status report.

[0106] Execute specific commands on each target server. Parse the command output to determine if the swap partition is active. The system records the check results for each server in an environment status report.

[0107] Based on a predefined list of ports, network probe commands are executed on each target server. The system analyzes the command output to identify the process IDs and program names listening on these ports. The system records port usage details in an environment status report.

[0108] On each target server, execute the command to obtain the currently running kernel version number. The system queries internally preset standard specifications and compares the obtained kernel version with the standard's specified compatible version range. The system records the comparison results in the environment status report.

[0109] The environment status report generated during the environment pre-scanning step is structured. The system integrates data such as exchange partition status, port usage details, and kernel version compatibility results into a unified JSON format document. This document is marked as the system environment fingerprint and stored in the system's shared state storage for subsequent use by the environment awareness and command generation modules.

[0110] The embodiments of this application can comprehensively and automatically detect the underlying environment status of the target server cluster before deployment begins. This provides a key data foundation for generating accurate deployment instructions for specific environments, avoiding deployment failures due to environment incompatibility, thereby improving the automation, success rate and reliability of the entire Kubernetes high availability cluster deployment process.

[0111] Based on the foregoing embodiments, this application provides an automated deployment device for a server cluster. The device includes various units and modules included in each unit, which can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0112] Figure 2 This is a schematic diagram of the composition structure of an automated deployment device for a server cluster provided in an embodiment of this application, as shown below. Figure 2 As shown, the automated deployment device 20 for the server cluster includes: The processing module 201 is used to receive natural language text input by the user to describe the cluster deployment requirements, perform intent parsing on the natural language text to generate an initial topology architecture, and input the initial topology architecture into a preset rule engine for high availability compliance verification to obtain a structured topology file that conforms to the preset high availability standard. The system environment fingerprint of the target server cluster is collected by a distributed execution agent, and the structured topology file and the system environment fingerprint are input into the large language model to generate an atomic deployment task queue for each node in the target server cluster. The deployment module 202 is used to control the distributed execution agent to execute deployment instructions step by step on each node in the target server cluster according to the atomic deployment task queue, and to capture the standard output stream, standard error stream and exit code in real time during the execution of any of the deployment instructions; When the exit code indicating execution failure is captured, the deployment process of the current node is paused, and the corresponding error log fragment, the current execution instruction, and the system environment fingerprint are assembled into a diagnostic prompt word and input into the large language model to obtain a repair instruction. The repair instruction is inserted at the beginning of the atomic deployment task queue for automated repair, and the original deployment instruction is re-executed after successful repair. After all deployment commands have been executed successfully, a destructive test is performed on the deployed cluster. This test simulates node failures and detects the drifting of virtual IP addresses and the health status of the cluster, generating a high availability verification report.

[0113] Optionally, the processing module 201 is further configured to: The semantic extraction unit identifies the target server's Internet protocol address list, cluster version number, and network plugin type as key information from the natural language text. The key information is input into the large language model to perform topology deduction, resulting in the initial topology architecture including node role assignments; The initial topology is input into the rule engine, which verifies the initial topology according to built-in hard-coded rules, wherein the hard-coded rules include at least a parity check rule for the number of nodes in the distributed key-value storage system and a minimum check rule for the number of nodes in the control plane. When the initial topology does not conform to the hard-coded rules, the rule engine automatically corrects the initial topology and generates a structured topology file containing a node role allocation table, the virtual IP address, and classless inter-domain routing information for Pod network segments.

[0114] Optionally, the processing module 201 is further configured to: The distributed execution agent is controlled to connect to all target servers in the target server cluster via the Secure Shell protocol, and to send a pre-configured lightweight probe script to each target server; The system receives the collection results returned by the lightweight detection script. The collection results include the operating system distribution, kernel version, central processing unit architecture, memory size, swap partition enable status, and port usage of each target server. These results are then summarized to form the system environment fingerprint. The structured topology file and the system environment fingerprint are combined into an enhanced prompt word, and the enhanced prompt word is input into the large language model; The system receives ordered queues of atomic deployment tasks for different target servers returned by the large language model. Each atomic task in the atomic deployment task queue contains at least a task identifier, a target node identifier, and a command line instruction to be executed.

[0115] Optionally, the deployment module 202 is further configured to: The distributed execution agent is controlled to send the corresponding command-line instructions in the atomic deployment task queue to the target nodes in the target server cluster via the Secure Shell protocol. During the execution of the command line instructions, a three-channel capture mechanism is established to independently and in real time capture the standard output stream, the standard error stream, and the exit code; The execution status of the current instruction is determined based on the value of the exit code. If the value of the exit code is zero, the current atomic task is marked as successfully executed and removed from the atomic deployment task queue. If the exit code is non-zero, the current instruction execution is determined to have failed, the subsequent task execution flow for the current target node is suspended, and the fault diagnosis process is triggered.

[0116] Optionally, the deployment module 202 is further configured to: The log cleaner extracts fragments of the captured raw error logs, including the location of the error and its context. The error log fragment, the currently executed instruction, and the system environment fingerprint are filled into a preset operation and maintenance diagnosis template to generate the diagnosis prompt words; Input the diagnostic prompts into the large language model and receive the original repair suggestions returned by the large language model; The original repair suggestions are subjected to regular expression matching by a security filter to block instructions containing high-risk operations, and the instructions that pass the verification are used as the repair instructions. The repair instruction is dynamically inserted at the front of the atomic deployment task queue, and the distributed execution agent is controlled to execute the repair instruction first. After the repair instruction is successfully executed, the original deployment instruction is put back into the head of the atomic deployment task queue for retry execution.

[0117] Optionally, the deployment module 202 is further configured to: Obtain access credentials for the deployed cluster, and record the first physical node where the virtual IP address is currently located using the access credentials; The distributed execution agent injects fault instructions into the first physical node, and the fault instructions include at least instructions to stop critical service processes or simulate network disconnection. After the fault command is injected, the health interface of the application programming interface server is continuously polled at preset time intervals, and the virtual IP address is monitored to see if it drifts and binds to the second physical node within a preset failover time threshold. After the virtual IP address is successfully migrated, the first physical node is restarted and its ability to rejoin the cluster as a slave node is verified. The high availability verification report is generated based on the failover time and the node re-entry status.

[0118] Optionally, the processing module 201 is further configured to: An environment pre-scan is performed on the target server cluster. The environment pre-scan includes at least checking whether the swap partitions of all target servers are disabled, checking the occupancy of key ports, and checking the kernel version that is compatible with the preset standard. The results of the environment pre-scan are used as part of the system environment fingerprint.

[0119] This application embodiment utilizes a large language model to understand user intent and generate a preliminary solution. Then, a rule engine enforces high availability compliance verification, eliminating architectural design errors from the source. During the deployment phase, the system combines environmental fingerprints to generate customized tasks and dynamically handles various unexpected errors that occur during deployment through execution monitoring and a self-healing mechanism based on a large model. This achieves unattended, self-healing deployment. Finally, automated destructive testing is used to verify the high availability of the cluster and ensure the quality of the delivered results.

[0120] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this application can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0121] It should be noted that, in the embodiments of this application, if the above-described automated deployment method for server clusters is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0122] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0123] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0124] This application provides a computer program including computer-readable code, wherein when the computer-readable code is executed in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0125] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0126] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0127] It should be noted that, Figure 3 This is a schematic diagram of a hardware entity of a computer device in an embodiment of this application, such as... Figure 3 As shown, the hardware entity of the computer device 700 includes: one or more processors 701, a communication interface 702, and a memory 703, wherein: Processor 701 typically controls the overall operation of computer device 700.

[0128] Communication interface 702 enables computer devices to communicate with other terminals or servers over a network.

[0129] The memory 703 is configured to store instructions and applications executable by the processor 701, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 701 and various modules in the computer device 700. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 701, the communication interface 702, and the memory 703 can be performed via bus 704. Only one processor is shown in the figure; each processor 700 includes one or more cores.

[0130] It should be noted that the computer device may include multiple processors 701, and each processor 701 can interact with each other through aggregated communication methods such as all-to-all, all-gather, or all-reduce. The processors 701 may be central processing units (CPUs), graphics processing units (GPUs), embedded neural network processing units (NPUs), tensor processing units (TPUs), data processing units (DPUs), accelerated processing units (APUs), floating-point processing units (FPUs), or application-specific integrated circuits (ASICs). The processors may also be single-core or multi-core processors. The processor may consist of a CPU and hardware chips. The hardware chips may be ASICs, PLDs, or combinations thereof. The PLDs may be complex programmable logic devices (CPLDs), FPGAs, generic array logic (GALs), or any combination thereof. The processor can also be implemented using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs).

[0131] The communication interface 702 can be a wired interface or a wireless interface, used to communicate with other modules or devices. The wired interface can be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface can be a cellular network interface or a wireless LAN interface, etc.

[0132] Memory 703 can be non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 703 can also be volatile memory, which can be random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synclink dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM), direct rambus DRAM (DRDRAM), and rambus DRAM.

[0133] The 704 bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc.

[0134] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0135] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0136] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0137] 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. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0138] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0139] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0140] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0141] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. An automated deployment method for a server cluster, characterized in that, The method includes: The system receives natural language text input from the user to describe the cluster deployment requirements, performs intent parsing on the natural language text to generate an initial topology architecture, and inputs the initial topology architecture into a preset rule engine for high availability compliance verification to obtain a structured topology file that conforms to preset high availability standards. The system environment fingerprint of the target server cluster is collected by a distributed execution agent, and the structured topology file and the system environment fingerprint are input into the large language model to generate an atomic deployment task queue for each node in the target server cluster. The distributed execution agent is controlled to execute deployment instructions step by step on each node in the target server cluster according to the atomic deployment task queue, and the standard output stream, standard error stream and exit code are captured in real time during the execution of any deployment instruction; When the exit code indicating execution failure is captured, the deployment process of the current node is paused, and the corresponding error log fragment, the current execution instruction, and the system environment fingerprint are assembled into a diagnostic prompt word and input into the large language model to obtain a repair instruction. The repair instruction is inserted at the beginning of the atomic deployment task queue for automated repair, and the original deployment instruction is re-executed after successful repair. After all deployment commands have been executed successfully, a destructive test is performed on the deployed cluster. This test simulates node failures and detects the drifting of virtual IP addresses and the health status of the cluster, generating a high availability verification report.

2. The method according to claim 1, characterized in that, The process involves receiving natural language text input from the user to describe cluster deployment requirements, parsing the natural language text to generate an initial topology, and inputting the initial topology into a preset rule engine for high availability compliance verification to obtain a structured topology file that conforms to preset high availability standards, including: The semantic extraction unit identifies the target server's Internet protocol address list, cluster version number, and network plugin type as key information from the natural language text. The key information is input into the large language model to perform topology deduction, resulting in the initial topology architecture including node role assignments; The initial topology is input into the rule engine, which verifies the initial topology according to built-in hard-coded rules, wherein the hard-coded rules include at least a parity check rule for the number of nodes in the distributed key-value storage system and a minimum check rule for the number of nodes in the control plane. When the initial topology does not conform to the hard-coded rules, the rule engine automatically corrects the initial topology and generates a structured topology file containing a node role allocation table, the virtual IP address, and classless inter-domain routing information for Pod network segments.

3. The method according to claim 1, characterized in that, The process involves collecting the system environment fingerprint of the target server cluster through a distributed execution agent, and inputting the structured topology file and the system environment fingerprint into a large language model to generate an atomic deployment task queue for each node in the target server cluster, including: The distributed execution agent is controlled to connect to all target servers in the target server cluster via the Secure Shell protocol, and to send a pre-configured lightweight probe script to each target server; The system receives the collection results returned by the lightweight detection script. The collection results include the operating system distribution, kernel version, central processing unit architecture, memory size, swap partition enable status, and port usage of each target server. These results are then summarized to form the system environment fingerprint. The structured topology file and the system environment fingerprint are combined into an enhanced prompt word, and the enhanced prompt word is input into the large language model; The system receives ordered queues of atomic deployment tasks for different target servers returned by the large language model. Each atomic task in the atomic deployment task queue contains at least a task identifier, a target node identifier, and a command line instruction to be executed.

4. The method according to claim 1, characterized in that, The control of the distributed execution agent to execute deployment instructions step-by-step on each node in the target server cluster according to the atomic deployment task queue, and to capture the standard output stream, standard error stream, and exit code in real time during the execution of any deployment instruction, including: The distributed execution agent is controlled to send the corresponding command-line instructions in the atomic deployment task queue to the target nodes in the target server cluster via the Secure Shell protocol. During the execution of the command line instructions, a three-channel capture mechanism is established to independently and in real time capture the standard output stream, the standard error stream, and the exit code; The execution status of the current instruction is determined based on the value of the exit code. If the value of the exit code is zero, the current atomic task is marked as successfully executed and removed from the atomic deployment task queue. If the exit code is non-zero, the current instruction execution is determined to have failed, the subsequent task execution flow for the current target node is suspended, and the fault diagnosis process is triggered.

5. The method according to claim 1, characterized in that, When the exit code indicating execution failure is captured, the deployment process of the current node is paused. The corresponding error log fragment, the currently executed instruction, and the system environment fingerprint are assembled into a diagnostic prompt word and input into the large language model to obtain a repair instruction. The repair instruction is inserted at the beginning of the atomic deployment task queue for automated repair. After successful repair, the original deployment instruction is re-executed, including: The log cleaner extracts fragments of the captured raw error logs, including the location of the error and its context. The error log fragment, the currently executed instruction, and the system environment fingerprint are filled into a preset operation and maintenance diagnosis template to generate the diagnosis prompt words; Input the diagnostic prompts into the large language model and receive the original repair suggestions returned by the large language model; The original repair suggestions are subjected to regular expression matching by a security filter to block instructions containing high-risk operations, and the instructions that pass the verification are used as the repair instructions. The repair instruction is dynamically inserted at the front of the atomic deployment task queue, and the distributed execution agent is controlled to execute the repair instruction first. After the repair instruction is successfully executed, the original deployment instruction is put back into the head of the atomic deployment task queue for retry execution.

6. The method according to claim 1, characterized in that, After all deployment commands have been successfully executed, a destructive test is performed on the deployed cluster. This involves simulating node failures and detecting virtual IP address drift and cluster health status, generating a high availability verification report, including: Obtain access credentials for the deployed cluster, and record the first physical node where the virtual IP address is currently located using the access credentials; The distributed execution agent injects fault instructions into the first physical node, and the fault instructions include at least instructions to stop critical service processes or simulate network disconnection. After the fault command is injected, the health interface of the application programming interface server is continuously polled at preset time intervals, and the virtual IP address is monitored to see if it drifts and binds to the second physical node within a preset failover time threshold. After the virtual IP address is successfully migrated, the first physical node is restarted and its ability to rejoin the cluster as a slave node is verified. The high availability verification report is generated based on the failover time and the node re-entry status.

7. The method according to claim 1, characterized in that, Before receiving the user-input natural language text describing the cluster deployment requirements, the method further includes: An environment pre-scan is performed on the target server cluster. The environment pre-scan includes at least checking whether the swap partitions of all target servers are disabled, checking the occupancy of key ports, and checking the kernel version that is compatible with the preset standard. The results of the environment pre-scan are used as part of the system environment fingerprint.

8. An automated deployment device for a server cluster, characterized in that, The device includes: The processing module is used to receive natural language text input by the user to describe the cluster deployment requirements, perform intent parsing on the natural language text to generate an initial topology architecture, and input the initial topology architecture into a preset rule engine for high availability compliance verification to obtain a structured topology file that conforms to the preset high availability standard. The system environment fingerprint of the target server cluster is collected by a distributed execution agent, and the structured topology file and the system environment fingerprint are input into the large language model to generate an atomic deployment task queue for each node in the target server cluster. The deployment module is used to control the distributed execution agent to execute deployment instructions step by step on each node in the target server cluster according to the atomic deployment task queue, and to capture the standard output stream, standard error stream and exit code in real time during the execution of any of the deployment instructions; When the exit code indicating execution failure is captured, the deployment process of the current node is paused, and the corresponding error log fragment, the current execution instruction, and the system environment fingerprint are assembled into a diagnostic prompt word and input into the large language model to obtain a repair instruction. The repair instruction is inserted at the beginning of the atomic deployment task queue for automated repair, and the original deployment instruction is re-executed after successful repair. After all deployment commands have been executed successfully, a destructive test is performed on the deployed cluster. This test simulates node failures and detects the drifting of virtual IP addresses and the health status of the cluster, generating a high availability verification report.

9. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the automated deployment method of the server cluster according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps in the automated deployment method of the server cluster according to any one of claims 1 to 7.

Images