Pluggable Kubernetes cluster deployment method, medium and device

Abstract

The invention discloses a pluggable Kubernetes cluster deployment method, a medium and equipment, and solves the problems of rigid deployment process, serious component coupling and low fault recovery efficiency in the prior art. The method comprises the following steps: receiving user module label combination and node resource information through a visual interface, and carrying out structured storage as a deployment context object; after the object is analyzed, a dependent support module is automatically identified and added, a cluster architecture mode is dynamically determined based on the number of Master nodes, and a DAG of a deployment task is constructed; module deployment is executed according to the DAG sequence, and only the fault module and downstream dependency thereof are retrying when failure occurs. According to the method, plug and play of the component is realized through label driving, a deployment process is dynamically arranged based on DAG, intelligent framework cutting is supported, accurate fault isolation and local recovery are realized, time consumption of component switching and resource occupation are greatly reduced, and deployment flexibility and operation and maintenance reliability are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and specifically to a pluggable Kubernetes cluster deployment method, medium, and device. Background Technology

[0002] Kubernetes is a portable, scalable, open-source platform for managing containerized workloads and services, and is the current standard for container orchestration. Public clouds can flexibly provide infrastructure such as servers, virtualized networks, and disks, and many enterprises in the market build their own Kubernetes clusters based on public cloud IaaS (Infrastructure as a Service).

[0003] When deploying a Kubernetes cluster, current mainstream solutions (such as Chinese patent CN113645071B) collect server information and generate a fixed deployment template through a graphical interface. Their deployment process is linear and cannot dynamically adjust module combinations or dependencies according to user needs. For example, when a user selects a distributed storage component (such as GlusterFS), existing technologies require manual modification of the deployment script to add dependent modules (such as the Heketi management service).

[0004] Furthermore, traditional deployment solutions tightly bind core components (such as load balancers and storage systems) to the cluster architecture, requiring the entire deployment logic to be restructured when components are replaced. For example, when switching from a cloud vendor's load balancer (such as AWS ELB) to an open-source solution (such as HAProxy), the configuration template needs to be rewritten and compatibility verified, which can take several hours. Summary of the Invention

[0005] In view of the above problems, the present invention provides a pluggable Kubernetes cluster deployment technical solution to solve the problems of rigid Kubernetes cluster deployment process, severe component coupling and low fault recovery efficiency.

[0006] To address the aforementioned issues, in a first aspect, this application provides a pluggable Kubernetes cluster deployment method, the method comprising:

[0007] S1: Receive the module tag combination selected by the user and the node resource information input by the user through a visual interface. The module tag combination includes architecture mode tag, storage method tag, load balancing tag and optional service tag. The node resource information includes the host IP address, node role group and node tag of each node.

[0008] S2: The module tag combination and node resource information are structured and stored as a deployment context object. The deployment context object includes module enable status flags, module configuration parameters, and node resource constraints.

[0009] S3: Parse the deployment context object and perform the following operations:

[0010] S31: Automatically identify and add supporting modules necessary for implementing the user selection function based on a predefined module dependency graph. The supporting modules are basic nodes that the current user has not selected but have a strong dependency relationship with the user selection module.

[0011] S32: Based on the number of Master nodes in the node role grouping information, determine the cluster architecture mode through preset architecture decision rules, and add the core component modules corresponding to the determined architecture mode to the deployment context object;

[0012] S33: Construct a directed acyclic graph of deployment tasks, where nodes in the directed acyclic graph represent the smallest executable deployment unit, and edges represent dependencies between modules;

[0013] S34: Determine the deployment order of each module according to the directed acyclic graph, specifically including: obtaining the container images required by each module, downloading the dependency resource files and configuration templates corresponding to each module, and distributing the parameters in the obtained container images, resource files and configuration templates to the corresponding target nodes that meet the node resource constraints.

[0014] S4: Execute module deployment according to the deployment order described;

[0015] S5: When module deployment fails, perform the following operations:

[0016] S51: Identify the failed module by module identifier Tag, and determine the affected downstream module according to the dependency relationship of the directed acyclic graph;

[0017] S52: The redeployment process is triggered only for the failed module and its downstream modules.

[0018] Furthermore, the architecture pattern labels include single Master node architecture, multi-Master node architecture, and multi-Master and Worker node architecture;

[0019] The storage method labels include NFS storage, GlusterFS storage, and cloud storage;

[0020] The load balancing tags include HAProxy, Keepalived, Cloud ELB, and Disabled Load Balancing;

[0021] The optional service tags include Prometheus monitoring service, Harbor mirror repository service, and EFK log service.

[0022] Furthermore, the support module includes basic service components and a set of high-availability components;

[0023] Step S32 includes:

[0024] When the number of Master nodes in the node resource information is 1 and the number of Worker nodes is 0, it is determined to be a single Master node architecture, and basic service components are deployed.

[0025] When the number of Master nodes is greater than 3, it is determined to be a multi-Master node architecture or a multi-Master and Worker node architecture, and a high-availability component set is deployed. The high-availability component set includes any one or more of the core control plane component, distributed storage component, and load balancing component.

[0026] When a Worker node exists, a preset scheduling strategy template is matched based on the node label.

[0027] Furthermore, the structured processing of the deployment context object in step S2 includes:

[0028] Parse the optional service tags in the module tag combination to generate a module enable status flag;

[0029] When the enabled status of the module is marked as disabled, the module and its supporting modules with strong dependencies are removed from the directed acyclic graph.

[0030] Furthermore, step S52 includes:

[0031] S521: Load the original deployment context from persistent storage;

[0032] S522: Update the following fields in the deployment context object based on the failed module identifier tag:

[0033] Reset the enabled status flag of the failed module to pending deployment;

[0034] Clear the historical execution state of this module and its downstream modules;

[0035] S523: Regenerate a new topology based on the updated deployment context object, containing only the failed module and its downstream dependencies, wherein the new topology is an updated directed acyclic graph;

[0036] S524: Perform local deployment retries based on the new topology, including:

[0037] S5241: Lock the deployment status of successfully deployed modules;

[0038] S5242: Only refactor the task chain of the failed module and its downstream dependent modules.

[0039] Furthermore, prior to step S524, the method further includes:

[0040] S53: Real-time recording of context snapshot information of failed modules, the context snapshot information including module identifier Tag, target node IP, execution stage status and error status code;

[0041] S54: Push the context snapshot information to the visualization interface via the WebSocket channel;

[0042] S55: Receive a retry command triggered by the user through a visual interface, the retry command being used to trigger step S524.

[0043] Furthermore, the method also includes:

[0044] Real-time snapshot information of the module's context is collected through the Ansible callback plugin;

[0045] The collected context snapshot information is stored in a structured manner according to the module dimension to form a deployment log knowledge graph;

[0046] The log stream is pushed to the visualization interface in real time via a WebSocket channel;

[0047] In response to a log query request, the system returns an execution history containing the following:

[0048] Module deployment timeline;

[0049] Error codes and automated repair suggestions;

[0050] The dependencies between modules in the current directed acyclic graph.

[0051] Furthermore, step S4 includes:

[0052] S41: Perform a pre-check operation on a unit of minimum executable deployment. The pre-check operation includes: checking the integrity of the storage path of the module installation package, verifying the network connectivity of the target node, and scanning the service port occupancy status.

[0053] S42: When any pre-check item fails, immediately interrupt the current module deployment process and generate a diagnostic report containing the type of failed check item and error details.

[0054] In a second aspect, the present invention also provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the method described in the first aspect.

[0055] In a third aspect, the present invention also provides an electronic device including a memory and a processor, the memory being used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method described in the first aspect.

[0056] Unlike existing technologies, the above solution provides a pluggable Kubernetes cluster deployment method, medium, and device, addressing the problems of rigid deployment processes, severe component coupling, and low fault recovery efficiency in existing technologies. The method includes: receiving user module tag combinations and node resource information through a visual interface, and storing them in a structured manner as a deployment context object; parsing this object, automatically identifying and adding dependent supporting modules, dynamically determining the cluster architecture mode based on the number of Master nodes, and constructing a DAG for deployment tasks; executing module deployment according to the DAG order, and retrying only the failed module and its downstream dependencies in case of failure. This invention achieves plug-and-play components through tag-driven architecture (such as load balancing and flexible storage system replacement), dynamically orchestrates the deployment process based on DAG, supports intelligent architecture pruning (such as automatic degradation in single-node mode), and achieves precise fault isolation and partial recovery, greatly reducing component switching time and resource consumption, and significantly improving deployment flexibility and operational reliability.

[0057] The above description of the invention is merely an overview of the technical solution of the present invention. In order to enable those skilled in the art to better understand the technical solution of the present invention and to implement it based on the description and drawings, and to make the above-mentioned objectives and other objectives, features and advantages of the present invention easier to understand, the following description is provided in conjunction with the specific embodiments and drawings of the present invention. Attached Figure Description

[0058] The accompanying drawings are only used to illustrate the principles, implementation methods, applications, features, and effects of specific embodiments of the present invention and other related contents, and should not be considered as limitations on the present invention.

[0059] In the accompanying drawings of the instruction manual:

[0060] Figure 1 A flowchart illustrating a pluggable Kubernetes cluster deployment method according to a first exemplary embodiment of the present invention;

[0061] Figure 2 A flowchart illustrating a pluggable Kubernetes cluster deployment method according to a second exemplary embodiment of the present invention;

[0062] Figure 3 A flowchart illustrating a pluggable Kubernetes cluster deployment method according to a third exemplary embodiment of the present invention;

[0063] Figure 4 A flowchart illustrating a pluggable Kubernetes cluster deployment method according to a fourth exemplary embodiment of the present invention;

[0064] Figure 5 A flowchart illustrating a pluggable Kubernetes cluster deployment method according to a fifth exemplary embodiment of the present invention;

[0065] Figure 6 A flowchart illustrating a pluggable Kubernetes cluster deployment method according to a sixth exemplary embodiment of the present invention;

[0066] Figure 7 A flowchart illustrating a pluggable Kubernetes cluster deployment method according to a sixth exemplary embodiment of the present invention;

[0067] Figure 8 A flowchart illustrating a pluggable Kubernetes cluster deployment method according to the eighth exemplary embodiment of the present invention;

[0068] Figure 9 A flowchart illustrating a pluggable Kubernetes cluster deployment method according to a ninth exemplary embodiment of the present invention;

[0069] Figure 10 This is a schematic diagram of the modules of the electronic device involved in the present invention;

[0070] The reference numerals used in the above figures are explained as follows:

[0071] 10. Electronic devices;

[0072] 101. Processor;

[0073] 102. Storage medium. Detailed Implementation

[0074] To illustrate the possible application scenarios, technical principles, implementable specific solutions, and achievable objectives and effects of this invention in detail, the following description, in conjunction with the listed specific embodiments and accompanying drawings, provides a detailed explanation. The embodiments described herein are merely illustrative of the technical solutions of this invention and are therefore intended only as examples, not as limiting the scope of protection of this invention.

[0075] In this document, the term "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The term "embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment, nor does it specifically limit its independence or connection with other embodiments. In principle, in this invention, as long as there are no technical contradictions or conflicts, the technical features mentioned in each embodiment can be combined in any way to form corresponding implementable technical solutions.

[0076] Unless otherwise defined, the technical terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains; the use of related terms herein is merely for the purpose of describing particular embodiments and is not intended to limit the invention.

[0077] In the description of this invention, the term "and / or" is used to describe the logical relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A exists, B exists, and A and B exist simultaneously. Additionally, the character " / " generally indicates that the preceding and following objects have an "or" logical relationship.

[0078] In this invention, terms such as “first” and “second” are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any actual quantity, hierarchy, or order between these entities or operations.

[0079] Without further limitations, the use of terms such as “comprising,” “including,” “having,” or other similar open-ended expressions in this invention is intended to cover non-exclusive inclusion, which does not exclude the presence of additional elements in a process, method, or product that includes the stated elements, such that a process, method, or product that includes a list of elements may include not only those defined elements but also other elements not expressly listed, or elements inherent to such a process, method, or product.

[0080] In this invention, expressions such as "greater than", "less than", and "exceeding" are understood to exclude the stated number; expressions such as "above", "below", and "within" are understood to include the stated number. Furthermore, in the description of the embodiments of this invention, "multiple" means two or more (including two), and similar expressions related to "multiple" are also understood in this way, such as "multiple groups" and "multiple times", unless otherwise explicitly specified.

[0081] In the first aspect, such as Figure 1 As shown, this application provides a pluggable Kubernetes cluster deployment method, the method comprising:

[0082] S1: Receives the user-selected module tag combination and the node resource information input by the user through a visual interface.

[0083] In step S1, the module tag combination refers to the set of function identifiers selected by the user based on deployment requirements, used to define the function combination for cluster deployment. This includes architecture mode tags, storage method tags, load balancing tags, and optional service tags.

[0084] The node resource information describes the hardware and role information of the target node, including the host IP address (node ​​network identifier), node role group (such as Master node, Worker node), and node tag (attribute marker used for scheduling policy matching).

[0085] A graphical interface provides a user-friendly module selection screen, allowing users to intuitively choose module tags such as architecture mode, storage method, load balancing, and optional services, and fill in resource information such as node IP, role group, and node tags. The interface verifies the validity of input in real time (e.g., IP format, role appropriateness) to ensure the validity of the input information.

[0086] S2: The module tag combination and node resource information are structured and stored as a deployment context object.

[0087] In step S2, the deployment context object refers to a standardized data carrier formed by structuring the combination of module tags and node resource information input by the user. It includes module enable status flags (whether the module participates in deployment), module configuration parameters (specific parameters for module operation), and node resource constraints (hardware limitations for deployment).

[0088] The system parses the combination of module tags selected by the user and generates the enable status flags for each module (e.g., "Prometheus monitoring service" is marked as "enabled" or "disabled"); extracts key fields from node resource information and converts them into node resource constraints (e.g., "Number of Master nodes ≥ 1"); integrates module configuration parameters (e.g., Harbor domain name, load balancer IP) to form a unified deployment context object and persists it for storage, serving as the core basis for subsequent deployment processes.

[0089] S3: Parse the deployment context object and perform the following steps S31-S34.

[0090] like Figure 2 As shown, step S3 includes the following steps:

[0091] S31: Automatically identify and add supporting modules necessary for implementing the user selection function based on the predefined module dependency graph. The supporting modules are basic nodes that the current user has not selected but have a strong dependency relationship with the user selection module.

[0092] In step S31, the system has a built-in predefined module dependency graph (such as "registry image repository" depending on "Docker"). By parsing the module tags in the deployment context object, it automatically identifies and adds necessary supporting modules that the user has not selected, ensuring a closed loop for deployment functionality.

[0093] S32: Based on the number of Master nodes in the node role grouping information, determine the cluster architecture mode through preset architecture decision rules, and add the core component modules corresponding to the determined architecture mode to the deployment context object.

[0094] In step S32, based on the number of Master nodes in the node resource information, the cluster architecture mode is automatically determined by matching the preset architecture decision rules (such as "if the number of Master nodes = 1 and there are no Worker nodes, the corresponding architecture can be configured as a single Master node architecture") and the corresponding core component modules (such as the basic service components of the single-node architecture and the high availability components of the multi-node architecture) are added to the deployment context.

[0095] S33: Construct a directed acyclic graph of deployment tasks.

[0096] In step S33, a directed acyclic graph (DAG) refers to a topological structure constructed with the smallest executable deployment unit as nodes and the dependencies between modules as directed edges, used to clarify the execution order and dependency constraints of deployment tasks. The smallest executable deployment unit refers to an independent execution unit after the deployment module is broken down, such as "pulling the image" or "installing dependencies," which has independent pre-checking and execution logic.

[0097] Using the smallest executable deployment unit as the basic unit, a directed acyclic graph is constructed based on the dependencies between modules (e.g., "docker" needs to be deployed before "registry") to clarify the execution order of each unit and avoid dependency conflicts.

[0098] The deployment system breaks down the deployment process into the smallest granularity atomic modules (i.e., the smallest executable deployment unit). Each atomic module has independence and an "enabled" attribute, supporting on-demand combination. Atomic modules include prepare-os (system initialization, must be started), registry (image repository, enabled when selected by the user), LB (load balancing, enabled when selected by the user), storage units (NFS, GlusterFS, enabled when selected by the user), and Prometheus (monitoring, enabled when selected, automatically inserted into the deployment chain after plugging and unplugging). Each atomic module contains independent pre-check and install phases, ensuring the controllability of the deployment process.

[0099] The system supports dynamic grouping. Users can download a pre-set Excel spreadsheet and fill in the node IPs and their role information (such as master, worker, load balancer, registry, etc.). After the user uploads the Excel file, the system automatically parses the node information and categorizes each node into its corresponding role group, achieving an automatic "node → group" binding process and avoiding the tedious manual editing of the host list. For example, if a node in the Excel file is marked with role=master, the system automatically assigns it to the k8s_master host group for subsequent deployment task execution.

[0100] S34: Determine the deployment order of each module based on the directed acyclic graph.

[0101] like Figure 3 As shown, step S34 specifically includes:

[0102] S341: Obtain the container images required by each module;

[0103] S342: Download the dependency resource files and configuration templates corresponding to each module;

[0104] S343: Distribute the acquired container image, resource files, and parameters from the configuration template to the corresponding target nodes that meet the node resource constraints.

[0105] The topology sorting based on DAG determines the deployment order of modules; the container images required by each module are pulled from the image repository simultaneously, and dependent resource files (such as configuration scripts and installation packages) and configuration templates are downloaded. Resources are then accurately distributed to target nodes according to node resource constraints (such as role grouping and hardware configuration).

[0106] S4: Execute module deployment according to the deployment order.

[0107] In step S4, the task scripts of each module are called sequentially according to the deployment order determined by the DAG, and pre-checks (such as dependency package integrity and network connectivity) and installation operations are performed, while the execution status is recorded in real time.

[0108] After a user selects modules, the system generates a minimal dependency deployment plan based on the selected tag combinations. This means only the modules the user needs are installed, while unselected modules are automatically skipped. During deployment plan generation, the system constructs a DAG (Directed Acyclic Graph) based on the dependencies between components, automatically sorting the deployment order to avoid the user having to manually consider the execution order. The core advantages of DAG include: ensuring ordered dependency execution, automatically resolving preconditions between components; dynamically pruning unselected modules, greatly compressing the deployment scope; and supporting parallel execution of modules, significantly improving deployment efficiency.

[0109] The deployment task scheduling engine uses a Directed Acyclic Graph (DAG) as its execution flow and supports control mechanisms such as task retries, failure skipping, and breakpoint resumption to ensure the flexibility and reliability of the deployment process. For example, if the user does not select the lb_app module, its dependency paths and tasks will not be included in the DAG; if only a single Master + cloud ELB deployment is selected, the system will automatically exclude the built-in load balancer, forming a minimal executable deployment chain.

[0110] S5: When module deployment fails, execute steps S51-S52.

[0111] like Figure 4 As shown, step S5 includes:

[0112] S51: Identify the failed module by module identifier Tag, and determine the affected downstream module according to the dependency relationship of the directed acyclic graph;

[0113] S52: The redeployment process is triggered only for the failed module and its downstream modules.

[0114] In step S51, the failed module is accurately located by the module identifier tag (e.g., “registry-1.0”), and the affected downstream modules are traced based on the DAG dependency relationship (e.g., the failure of “registry” affects “k8s” and “prometheus”).

[0115] In step S52, the retry process is triggered only for the failed module and its downstream modules, while the deployment status of the successful modules remains unchanged. Accurate recovery is achieved by reconstructing the local DAG.

[0116] In highly modular and pluggable deployment systems, to ensure the system can execute securely under any combination of paths, the deployment system constructs a module-level error backtracking mechanism, including:

[0117] Module-level context information tracking: Each task is automatically accompanied by metadata, including module name (Tag), task name, host, and timestamp, enabling full-link tracking of the deployment process.

[0118] Real-time status synchronization: Abnormal tasks are pushed to the front end via WebSocket, and failure information, failed modules, and failed hosts are displayed in real time, so that users can intuitively grasp the deployment status.

[0119] Task dependency chain storage: The system automatically generates a directed dependency graph (DAG) before deployment to determine whether to block downstream modules after a module fails, thus enabling flexible control that only suspends the affected module after a failure, while other modules continue to be deployed.

[0120] Module-level retry logic (precise recovery): After a deployment failure, the system allows users to reselect only the failed module (such as Prometheus) on the front end. The system reconstructs the task chain based on the failure tag and only schedules the execution of that module. The tasks and resources of the successful modules remain unchanged, avoiding a full redeployment.

[0121] The error reporting and backtracking mechanism achieves module-level error granularity and can also achieve precise task-level location, solving the shortcomings of traditional systems that can only achieve script-level error reporting and are difficult to trace modules.

[0122] The above solution enables "pluggable" control of the deployment process, allowing users to flexibly customize cluster functions through tag combinations, thus solving the rigidity problem of traditional template-based deployments. Relying on auto-completion and dynamic architecture decision-making reduces manual configuration costs and avoids deployment failures due to dependency omissions or architecture misjudgments. DAG task orchestration ensures a reasonable deployment order and precise resource distribution matching node constraints, improving deployment efficiency. A module-level partial retry mechanism avoids full redeployment, effectively shortening fault recovery time and significantly improving deployment reliability.

[0123] In some embodiments, the architecture pattern label defines the combination of Kubernetes cluster control nodes and worker nodes, and determines the core architecture of the cluster, including single master node architecture, multi-master node architecture, and multi-master and worker node architecture.

[0124] The storage method label specifies the technical method used to store cluster data, which affects data persistence and access performance, including NFS storage, GlusterFS storage, and cloud storage;

[0125] The load balancing label is used to select the implementation method of cluster traffic distribution and high availability guarantee. It is suitable for the reliability requirements of multi-node architecture, including HAProxy, Keepalived, cloud ELB, and disabling load balancing.

[0126] The optional service tags are extended services that provide cluster operation and maintenance assistance functions. They can be deployed on demand to meet needs such as monitoring and image management, including Prometheus monitoring service, Harbor image repository service, and EFK log service.

[0127] The system displays a list of tags in the visual interface according to four dimensions: "Architecture Pattern", "Storage Method", "Load Balancing", and "Optional Services". Each dimension provides specific optional values:

[0128] The architecture pattern tags include single Master node architecture (only 1 control node, suitable for test environment), multi-Master node architecture (multiple control nodes, no worker nodes, suitable for lightweight control scenarios), and multi-Master and worker node architecture (multiple control nodes + multiple worker nodes, suitable for production environment).

[0129] Storage method tags include NFS storage (Network File System, suitable for small and medium-sized clusters), GlusterFS storage (Distributed File System, suitable for large-scale clusters), and cloud storage (such as AWS EBS and Alibaba Cloud OSS, suitable for cloud environment deployment).

[0130] Load balancing tags include HAProxy (open source load balancer), Keepalived (high availability component, used in conjunction with HAProxy to achieve master-slave switching), Cloud ELB (load balancing service provided by cloud vendors), and Disable load balancing (no load balancing is needed in single-node architectures).

[0131] Optional service tags include Prometheus monitoring service (time-series data monitoring), Harbor image repository service (private image management), and EFK log service (log collection and analysis).

[0132] After users select the corresponding tags through the visual interface, the system automatically associates the corresponding configuration items with the tags (e.g., after selecting "HAProxy+Keepalived", the load balancing IP configuration box is displayed), realizing the linkage configuration of tags and parameters.

[0133] The above solution covers the core requirements of cluster deployment, allowing users to combine tags as needed to meet the demands of various scenarios such as multi-cloud deployment, single-machine testing, and elastic scaling. The linkage between tags and configuration items reduces parameter configuration complexity and lowers the barrier to entry for users. Standardized tag definitions provide clear input for subsequent dependency resolution and architecture decisions, ensuring the traceability of deployment logic.

[0134] In some embodiments, the support module is a set of basic components used to ensure the normal operation of the user-selected module, including basic service components and a set of high-availability components. The basic service components include core control plane components required for a single-node architecture (such as a single instance of kube-apiserver and kube-controller-manager); the high-availability component set includes redundant core control plane components required for a multi-node architecture (such as multi-instance kube-apiserver), distributed storage components (such as distributed etcd), and load balancing components (such as HAProxy+Keepalived).

[0135] Step S32 includes:

[0136] When the number of Master nodes in the node resource information is 1 and the number of Worker nodes is 0, it is determined to be a single Master node architecture, and basic service components are deployed.

[0137] When the number of Master nodes is greater than 3, it is determined to be a multi-Master node architecture or a multi-Master and Worker node architecture, and a high-availability component set is deployed. The high-availability component set includes any one or more of the core control plane component, distributed storage component, and load balancing component.

[0138] When a Worker node exists, a preset scheduling policy template is matched based on the node label. The scheduling policy template includes task allocation rules preset based on the node label, such as "nodes with the 'storage' label are given priority for deploying storage components".

[0139] Specifically, the system parses the Master node count and Worker node existence information from the node resource information, and the determination process is as follows:

[0140] When the number of Master nodes is 1 and the number of Worker nodes is 0, it is determined to be a single Master node architecture, and basic service components are automatically deployed, skipping high availability components.

[0141] When the number of Master nodes is ≥3, it is determined to be a multi-Master node architecture or a multi-Master and Worker node architecture, and a high-availability component set is automatically deployed to ensure control plane redundancy.

[0142] When a Worker node exists, extract the node tags (such as "gpu=true" and "storage=true"), match them with the pre-set scheduling strategy template (such as "gpu nodes should prioritize the deployment of AI task-related components"), and optimize the component deployment location.

[0143] The above solution is based on an automated node resource decision-making architecture, avoiding errors caused by manual architecture selection and improving deployment accuracy. Support modules are deployed on demand, reducing resource waste in single-node architectures while ensuring high availability in multi-node architectures. Matching node tags with scheduling strategies enables intelligent component deployment, improving resource utilization.

[0144] In some embodiments, the structured processing of the deployment context object in step S2 includes:

[0145] Parse the optional service tags in the module tag combination to generate a module enable status flag;

[0146] When the enabled status of the module is marked as disabled, the module and its supporting modules with strong dependencies are removed from the directed acyclic graph.

[0147] In this embodiment, the module enable status flag is a binary flag (enabled / disabled) used to identify whether a module participates in deployment, generated based on the user's selection of optional service tags. A strong dependency refers to a dependency between modules where "the target module cannot run without this module" (e.g., "Prometheus" depends on "kube-state-metrics").

[0148] The working principle of the dynamic module pruning logic is as follows:

[0149] The system parses the optional service tags in the module tag combination (e.g., if the user has not selected "Prometheus Monitoring Service") and generates an "Enabled" status mark for the corresponding module. Based on a predefined module dependency graph, it identifies supporting modules that have strong dependencies on the disabled modules (e.g., if "Prometheus" is disabled, "kube-state-metrics" also does not need to be enabled). When constructing the deployment task DAG, it automatically removes nodes and related edges of the disabled module and its strongly dependent supporting modules, ensuring that the DAG only contains the deployment units actually needed by the user.

[0150] The above solutions enable dynamic simplification of the deployment process, preventing unused modules from consuming resources and effectively shortening deployment time. Automatic removal of strongly dependent modules ensures consistent deployment logic and avoids conflicts or errors caused by residual unused modules. Structured processing ensures the traceability of module enabling / disabling logic, improving the controllability of the deployment process.

[0151] In some embodiments, such as Figure 5 As shown, step S52 includes:

[0152] S521: Load the raw deployment context from persistent storage.

[0153] In step S521, the original deployment context refers to the deployment context object persistently stored before the deployment failure, which contains complete information such as the module's enabled status and configuration parameters before the failure. Specifically, the original deployment context object before the deployment failure can be read from persistent storage (such as a database or local file) to ensure that the basic configuration for retry is consistent with the original deployment.

[0154] S522: Update the following fields in the deployment context object based on the failed module identifier tag:

[0155] Reset the enabled status flag of the failed module to pending deployment;

[0156] Clear the historical execution state of this module and its downstream modules.

[0157] When implementing step S522, the enabled status of the failed module can be reset to "pending deployment" based on the failed module identifier Tag; the historical execution status (such as "completed" or "in execution") of the failed module and its downstream modules can be cleared and marked as "not executed" to ensure that the retry process is triggered again.

[0158] S523: Regenerate a new topology based on the updated deployment context object, containing only the failed module and its downstream dependencies, wherein the new topology is the updated directed acyclic graph.

[0159] In step S523, the new topology refers to a DAG that only contains the failed module and its downstream dependent modules, used for local retry processes. Based on the updated deployment context object, the dependencies between the failed module and its downstream modules are re-parsed to generate a new DAG containing only these modules, removing unaffected modules.

[0160] S524: Perform a local retry based on the new topology.

[0161] like Figure 6 As shown, step S524 includes:

[0162] S5241: Lock the deployment status of successfully executed modules (e.g., keep "prepare-os" and "docker" as "complete") to avoid duplicate execution.

[0163] S5242: Only refactor the task chain of the failed module and its downstream dependent modules.

[0164] In step S5242, the task chain refers to the complete execution path in the DAG from the failed module to the downstream module, such as "registry→k8s→prometheus", and the deployment is executed according to the new DAG order.

[0165] The above solution avoids the full deployment process from being repeated through partial retries, effectively shortening fault recovery time and significantly improving deployment efficiency. Precise updates of context fields and topology reconstruction ensure accurate retry logic, preventing impact on the state of successfully deployed modules. Locking the state of successfully deployed modules ensures deployment resource consistency, reducing resource waste or configuration conflicts caused by repeated operations.

[0166] In some embodiments, prior to step S524, the method further includes:

[0167] S53: Real-time recording of context snapshot information of failed modules.

[0168] In step S53, the snapshot information below refers to a data snapshot recording the key states when the module deployment fails, including the module identifier Tag (unique identifier), the target node IP (execution node), the execution stage status (such as "install stage"), and the error status code (failure type identifier).

[0169] When a module deployment fails, the system automatically captures and records context snapshot information, including the module identifier, execution node, stage, and error code at the moment of failure (e.g., "registry installation failed, error code 1001: image pull timed out").

[0170] S54: Push the context snapshot information to the visualization interface via the WebSocket channel.

[0171] In step S54, the WebSocket channel refers to a full-duplex communication protocol channel used for real-time data transmission between the front-end interface and the back-end system, supporting instant push notifications of deployment status. Context snapshot information is pushed to the front-end visualization interface in real time via the WebSocket channel, with failed modules highlighted in red and error details displayed.

[0172] S55: Receive a retry command triggered by the user through a visual interface, the retry command being used to trigger step S524.

[0173] In step S55, the retry command refers to the redeployment command triggered by the user through the front-end interface, which is used to initiate the partial retry process of the failed module. After viewing the failure information in the interface, the user can trigger the retry command by clicking the "Retry" button. After receiving the command, the system initiates the partial retry process in S524.

[0174] The above solution uses real-time context snapshots to record and push deployment status, enabling users to intuitively grasp fault details and lowering the barrier to troubleshooting. WebSocket real-time communication ensures no-delay feedback of fault information, improving the transparency of the deployment process. User-triggered retry commands combine manual intervention with automated processes, increasing the flexibility of fault handling.

[0175] In some embodiments, such as Figure 7 As shown, the method further includes:

[0176] Step S701: Collect the module's context snapshot information in real time through the Ansible callback plugin.

[0177] In step S701, the Ansible callback plugin refers to an extension component developed based on the Ansible automation tool framework, used to capture and process events (such as task start, success, and failure) during task execution. By customizing the Ansible callback plugin, it listens to the entire lifecycle events of the module deployment and collects context snapshot information such as module identifier tag, target node, execution time, status, and error information in real time.

[0178] Step S702: The collected context snapshot information is stored in a structured manner according to the module dimension to form a deployment log knowledge graph.

[0179] In step S702, the deployment log knowledge graph refers to a set of deployment logs that are structured and stored according to the module dimension. It contains associated data such as module execution time, status, and error information, forming a traceable log network. The collected log information is structured and stored according to the module dimension (e.g., classified by "registry" or "prometheus"), and the module dependencies are associated with the execution timeline to form the deployment log knowledge graph.

[0180] Step S703: Push the log stream to the visualization interface in real time via the WebSocket channel.

[0181] In step S703, the log stream refers to the sequence of log data generated in real time during module execution, which is pushed to the front end in chronological order. The structured log stream is pushed to the front-end interface in real time via a WebSocket channel, supporting filtering and viewing by module, node, time, and other dimensions.

[0182] Step S704: Respond to the log query request and return the execution history containing the following: module deployment timeline (execution time points of each stage), error codes and automated repair suggestions (such as "Error code 1001 suggests checking the network connectivity of the image repository"), and the dependencies of each module in the current directed acyclic graph.

[0183] In this application, logs for all module execution are categorized at the module tag level and pushed to a web interface via WebSocket, allowing users to view information such as module name, execution stage, status (success / failure), and log summary. The system is implemented by inheriting from Ansible CallbackBase, packaging the task tag, host, time, and status into a message and sending it to WebSocket. When module insertion or removal fails, logs can be traced back to the corresponding module, facilitating single-module retries and repairs.

[0184] The system supports timeline tracing, recording the timing information of the entire process from configuration to deployment. It also supports JSON export and one-click debugging assistance. When responding to log query requests, it returns the module deployment timeline, error codes and automatic repair suggestions, as well as the dependencies of each module in the current directed acyclic graph, helping users quickly troubleshoot problems.

[0185] The above solution achieves end-to-end traceability of the deployment process through module-level log collection and knowledge graph construction, reducing fault location time from hours to seconds. Real-time log push and multi-dimensional queries improve operational efficiency and support precise location of single-module issues. Associating error codes with repair suggestions lowers the technical threshold and helps users quickly resolve deployment failures.

[0186] In some embodiments, such as Figure 8 As shown, step S4 includes:

[0187] S41: Perform a pre-check operation on a unit of minimum executable deployment. The pre-check operation includes: checking the integrity of the storage path of the module installation package, verifying the network connectivity of the target node, and scanning the service port occupancy status.

[0188] S42: When any pre-check item fails, immediately interrupt the current module deployment process and generate a diagnostic report containing the type of failed check item and error details.

[0189] In step S41, the pre-check operation refers to the environment verification step performed before module installation, which is used to confirm whether the deployment conditions are met and to avoid installation failure due to environmental issues.

[0190] Pre-checks are triggered at the smallest executable deployment unit before the installation steps, and specifically include:

[0191] Module installation package storage path integrity check: Verify that the required installation package (such as " / opt / k8s / packages / kubelet.tar.gz") exists on the target node, and ensure that the file is not missing or corrupted.

[0192] Target node network connectivity verification: Test the network connectivity between the node and the image repository and other nodes (e.g., ping, telnet port) to ensure normal communication.

[0193] Service port occupancy status scan: Check whether the ports required by the module (such as port 6443 of kube-apiserver) are occupied to avoid port conflicts.

[0194] In step S42, the diagnostic report refers to the structured report generated when the pre-check fails, which includes the type of failed check item (such as "network connectivity") and error details (such as "node 192.168.1.10 port 6443 is not working").

[0195] If any pre-check fails, the current module deployment process is immediately interrupted, a diagnostic report containing the type of failed check, error details, and scope of impact is generated, and pushed to the front-end interface via WebSocket. The pre-check is then retried after the user fixes the issue.

[0196] In this embodiment, the execution flow of each module is divided into a pre-check phase (verification phase) and an install phase (execution phase). Enabled modules will first execute the pre-check phase to verify the prerequisites for the install phase. For example, before executing `join master`, it will first verify whether the current host has a issued CA certificate to determine if the current node is usable. Through a transactional execution mechanism, enabled modules have a complete execution structure, ensuring environment and dependency verification before deployment and reducing the risk of deployment failure.

[0197] The above solution proactively identifies environmental issues through a pre-check mechanism, effectively reducing the probability of deployment failures and improving deployment reliability. Structured diagnostic reports clearly identify the causes of failures, helping users quickly locate and fix environmental problems. Pre-checks are performed at the smallest unit level to ensure accurate problem localization, preventing single-node issues from impacting the overall deployment process.

[0198] like Figure 9 As shown, the specific implementation process of the present invention is as follows:

[0199] Module Selection and Configuration: Users can access the module selection interface through the web visualization interface, check the "Multi-Master and Worker Node Architecture", "GlusterFS Storage", "HAProxy+Keepalived Load Balancing", and "Prometheus Monitoring Service" tabs, fill in the IPs of 3 Master nodes, 5 Worker nodes and node labels (such as labeling Worker nodes with "storage=true"), and configure the Harbor domain name "harbor.example.com" and the load balancing IP "192.168.1.100".

[0200] Deployment context generation: The system parses the user selection, generates module enable status flags (Prometheus=enabled, HAProxy=enabled, etc.), extracts node resource constraints (Master=3, Worker=5), integrates configuration parameters to form a deployment context object and stores it.

[0201] Dependency resolution and architecture decision-making: The system automatically adds supporting modules such as "Docker" and "kube-state-metrics" based on the dependency graph; since the number of Master nodes is 3, it is determined to be a multi-Master and Worker node architecture, and a high availability component set (distributed etcd, HAProxy components) is added; the storage component scheduling template is matched according to the "storage=true" tag of the Worker node.

[0202] DAG Construction and Resource Distribution: The constructed DAG is as follows:

[0203] The process involves preparing os→docker→glusterfs→haproxy→k8s-master→registry→k8s-worker→prometheus, pulling the corresponding image from the image repository, downloading the configuration template and replacing parameters (such as the load balancer IP), and then distributing it to the target nodes.

[0204] Deployment execution and pre-checks: Execution is performed in DAG order. Each module first performs a pre-check (e.g., glusterfs checks the storage path, haproxy checks the port). After the pre-checks pass, the installation is executed.

[0205] Example of troubleshooting: If the "registry" module installation fails (error code: image pull timeout), the system records a context snapshot (Tag=registry, node=192.168.1.10, stage=install) and pushes it to the front end via WebSocket; after the user views the logs and repairs the network, they click "Retry"; the system loads the original context, updates the status of registry and downstream modules (k8s-worker, prometheus) to "pending deployment", reconstructs a new DAG (registry→k8s-worker→prometheus), locks the status of successfully installed modules, and performs a partial retry.

[0206] Log tracing and querying: During deployment, the Ansible callback plugin collects logs in real time and stores them as a knowledge graph categorized by module; users can query the timeline, error code explanations, and dependencies of the "prometheus" module to assist in troubleshooting.

[0207] This invention achieves the following breakthroughs in the field of Kubernetes cluster deployment through a modular deployment architecture and a tag-based control mechanism:

[0208] (1) Improved deployment efficiency: The modular grouping strategy significantly reduces deployment time, Excel batch node management shortens the configuration time from the original 3 days to 30 minutes, and the tagging engine supports concurrent deployment, effectively improving resource utilization.

[0209] (2) Major breakthrough in operation and maintenance accuracy: The atomic module design greatly reduces the scope of fault impact and transforms the traditional full cluster rollback into module-level repair; the real-time log system compresses the fault location time to within 10 seconds, which can eliminate most configuration error risks in a timely and rapid manner.

[0210] (3) Significantly enhanced flexibility and reliability: Pluggable tag combinations support customized deployment in multiple scenarios; automatic completion and dynamic architecture decision-making reduce manual intervention; local retry mechanism greatly improves fault recovery efficiency and ensures stable and controllable deployment process.

[0211] In a second aspect, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the pluggable Kubernetes cluster deployment method as described in the first aspect of the present invention.

[0212] The computer-readable storage medium may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.

[0213] The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD ROM); the magnetic surface memory may be a disk storage device or a magnetic tape storage device.

[0214] The volatile memory may be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synclink dynamic random access memory (SLDRAM), and direct memory bus random access memory (DRRAM). The computer-readable storage media described in the embodiments of the present invention are intended to include these and any other suitable types of memory.

[0215] like Figure 10 As shown, in a third aspect, the present invention provides an electronic device 10, including a processor 101 and a storage medium 102, wherein a computer program is stored on the storage medium, and the computer program, when executed by the processor, implements the pluggable Kubernetes cluster deployment method as described in the first aspect of the present invention.

[0216] In some embodiments, the processor may be implemented by software, hardware, firmware, or a combination thereof, and may be a circuit, one or more of an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field-programmable gate array (FPGA), a central processing unit (CPU), a controller, a microcontroller, or a microprocessor, thereby enabling the processor to perform some or all of the steps or any combination of the steps in the pluggable Kubernetes cluster deployment method described in the various embodiments of this application.

[0217] Finally, it should be noted that although the above embodiments have been described in the description and drawings of this invention, this should not limit the scope of patent protection of this invention. Any technical solutions that are based on the essential concept of this invention, utilize the content described in the description and drawings of this invention to make equivalent structural or procedural substitutions or modifications, as well as the direct or indirect application of the technical solutions of the above embodiments to other related technical fields, are all included within the scope of patent protection of this invention.

Claims

1. A method for deploying a pluggable Kubernetes cluster, characterized in that, The method includes: S1: Receive the module tag combination selected by the user and the node resource information input by the user through a visual interface. The module tag combination includes architecture mode tag, storage method tag, load balancing tag and optional service tag. The node resource information includes the host IP address, node role group and node tag of each node. S2: The module tag combination and node resource information are structured and stored as a deployment context object. The deployment context object includes module enable status flags, module configuration parameters, and node resource constraints. S3: Parse the deployment context object and perform the following operations: S31: Automatically identify and add supporting modules necessary for implementing the user selection function based on a predefined module dependency graph. The supporting modules are basic nodes that the current user has not selected but have a strong dependency relationship with the user selection module. S32: Based on the number of Master nodes in the node role grouping information, determine the cluster architecture mode through preset architecture decision rules, and add the core component modules corresponding to the determined architecture mode to the deployment context object; S33: Construct a directed acyclic graph of deployment tasks, where nodes in the directed acyclic graph represent the smallest executable deployment unit, and edges represent dependencies between modules; S34: Determine the deployment order of each module according to the directed acyclic graph, specifically including: obtaining the container images required by each module, downloading the dependency resource files and configuration templates corresponding to each module, and distributing the parameters in the obtained container images, resource files and configuration templates to the corresponding target nodes that meet the node resource constraints. S4: Execute module deployment according to the deployment order described; S5: When module deployment fails, perform the following operations: S51: Identify the failed module by module identifier Tag, and determine the affected downstream module according to the dependency relationship of the directed acyclic graph; S52: The redeployment process is triggered only for the failed module and its downstream modules.

2. The pluggable Kubernetes cluster deployment method as described in claim 1, characterized in that: The architecture pattern labels include single Master node architecture, multi-Master node architecture, and multi-Master and Worker node architecture; The storage method labels include NFS storage, GlusterFS storage, and cloud storage; The load balancing tags include HAProxy, Keepalived, Cloud ELB, and Disabled Load Balancing; The optional service tags include Prometheus monitoring service, Harbor mirror repository service, and EFK log service.

3. The pluggable Kubernetes cluster deployment method as described in claim 2, characterized in that, The support module includes basic service components and a set of high-availability components; Step S32 includes: When the number of Master nodes in the node resource information is 1 and the number of Worker nodes is 0, it is determined to be a single Master node architecture, and basic service components are deployed. When the number of Master nodes is greater than 3, it is determined to be a multi-Master node architecture or a multi-Master and Worker node architecture, and a high-availability component set is deployed. The high-availability component set includes any one or more of the core control plane component, distributed storage component, and load balancing component. When a Worker node exists, a preset scheduling strategy template is matched based on the node label.

4. The pluggable Kubernetes cluster deployment method as described in claim 1, characterized in that, The structured processing of the deployment context object in step S2 includes: Parse the optional service tags in the module tag combination to generate a module enable status flag; When the enabled status of the module is marked as disabled, the module and its supporting modules with strong dependencies are removed from the directed acyclic graph.

5. The pluggable Kubernetes cluster deployment method as described in claim 1, characterized in that, Step S52 includes: S521: Load the original deployment context from persistent storage; S522: Update the following fields in the deployment context object based on the failed module identifier tag: Reset the enabled status flag of the failed module to pending deployment; Clear the historical execution state of this module and its downstream modules; S523: Regenerate a new topology based on the updated deployment context object, containing only the failed module and its downstream dependencies, wherein the new topology is an updated directed acyclic graph; S524: Perform local deployment retries based on the new topology, including: S5241: Lock the deployment status of successfully deployed modules; S5242: Only refactor the task chain of the failed module and its downstream dependent modules.

6. The pluggable Kubernetes cluster deployment method as described in claim 5, characterized in that, Prior to step S524, the method further includes: S53: Real-time recording of context snapshot information of failed modules, the context snapshot information including module identifier Tag, target node IP, execution stage status and error status code; S54: Push the context snapshot information to the visualization interface via the WebSocket channel; S55: Receive a retry command triggered by the user through a visual interface, the retry command being used to trigger step S524.

7. The pluggable Kubernetes cluster deployment method as described in claim 6, characterized in that, The method further includes: Real-time snapshot information of the module's context is collected through the Ansible callback plugin; The collected context snapshot information is stored in a structured manner according to the module dimension to form a deployment log knowledge graph; The log stream is pushed to the visualization interface in real time via a WebSocket channel; In response to a log query request, the system returns an execution history containing the following: Module deployment timeline; Error codes and automated repair suggestions; The dependencies between modules in the current directed acyclic graph.

8. The pluggable Kubernetes cluster deployment method as described in claim 7, characterized in that, Step S4 includes: S41: Perform a pre-check operation on a unit of minimum executable deployment. The pre-check operation includes: checking the integrity of the storage path of the module installation package, verifying the network connectivity of the target node, and scanning the service port occupancy status. S42: When any pre-check item fails, immediately interrupt the current module deployment process and generate a diagnostic report containing the type of failed check item and error details.

9. A computer-readable storage medium storing computer program instructions thereon, characterized in that, The computer program instructions, when executed by a processor, implement the method as described in any one of claims 1 to 8.

10. An electronic device comprising a memory and a processor, characterized in that, The memory is used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method as described in any one of claims 1 to 8.

Images