Kubernetes cluster deployment method and device and electronic equipment

Abstract

The invention provides a Kubernetes cluster deployment method and device and electronic device.The method comprises the steps that configuration parameters corresponding to the current environment are determined through a three-level parameter coverage mechanism; dynamically rendering the configuration parameters to generate a configuration file; calling a configuration file, and carrying out component deployment by adopting asynchronous parallelization; and determining that the deployment of the Kubernetes cluster is completed under the condition that the deployment of all the components in the Kubernetes cluster is completed. According to the embodiment of the invention, the configuration parameters are directly determined through a three-level parameter coverage mechanism, the configuration parameters are dynamically rendered, the corresponding configuration file is generated, and component deployment is performed by adopting a parallelization strategy based on the configuration file, so that automatic deployment of the Kubernetes cluster is realized, and the error rate is reduced. In addition, the components are deployed in an asynchronous parallelization mode, so that subsequent tasks can be prevented from being blocked, and the deployment efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of cluster configuration, and more specifically, to a Kubernetes cluster deployment method, apparatus, and electronic device. Background Technology

[0002] With the rapid development of cloud computing and containerization technologies, Kubernetes has become the de facto standard for enterprise application orchestration and management. However, most enterprises still rely on manual operation for Kubernetes cluster deployment, which has significant limitations: on the one hand, manual deployment processes are cumbersome and lack standardization, resulting in lengthy deployment cycles; on the other hand, manual operation is highly dependent on experience and proficiency, and is prone to failures due to configuration omissions, incorrect parameter settings, or version compatibility issues, affecting system stability. Summary of the Invention

[0003] In view of this, the purpose of this application is to provide a Kubernetes cluster deployment method, apparatus, and electronic device that can improve the efficiency and accuracy of Kubernetes cluster deployment.

[0004] In a first aspect, embodiments of this application provide a Kubernetes cluster deployment method, including: determining configuration parameters corresponding to the current environment through a three-level parameter coverage mechanism; dynamically rendering the configuration parameters to generate a configuration file; calling the configuration file and deploying components using asynchronous parallelization; and determining that the Kubernetes cluster deployment is complete when all components in the Kubernetes cluster have been deployed.

[0005] In the above implementation process, configuration parameters are directly determined through a three-level parameter coverage mechanism, and the configuration parameters are dynamically rendered to generate corresponding configuration files. Based on the configuration files, a parallel strategy is used for component deployment, achieving automated deployment of the Kubernetes cluster and reducing the error rate. In addition, since component deployment is performed asynchronously and in parallel, subsequent tasks are avoided from being blocked, thereby improving deployment efficiency.

[0006] In one embodiment, determining the configuration parameters corresponding to the current environment through a three-level parameter coverage mechanism includes: determining the priority order of parameter sources; wherein the priority order is: command line input parameters take precedence over environment variable parameters, and environment variable parameters take precedence over preset value parameters; merging the parameter sources according to the priority order to generate a target parameter set; and converting the target parameter set into a set format to obtain the configuration parameters corresponding to the current environment.

[0007] In the above implementation process, by achieving adaptive environment configuration based on the priority order of parameter sources, users only need to adjust key parameters through command-line input to complete deployments for different scenarios, significantly reducing configuration complexity. Furthermore, through a priority merging mechanism, the multi-environment configuration that originally required manual comparison is transformed into an automated process, reducing configuration time and improving configuration efficiency.

[0008] In one embodiment, dynamically rendering the configuration parameters to generate a configuration file includes: creating a Jinja2 template file containing conditional logic; the Jinja2 template file embedding environment judgment conditions and dynamic variable placeholders; passing the configuration parameters to the Jinja2 template file and performing variable substitution; rendering the Jinja2 template file and generating the configuration file based on the rendering result.

[0009] In the above implementation process, by using Jinja2 template files to achieve adaptive environment configuration and real-time dynamic parameter adjustment, the configuration generation is automated and standardized, which can significantly reduce the configuration error rate in mixed scenarios, avoid human error and improve efficiency.

[0010] In one embodiment, calling the configuration file and deploying the component using asynchronous parallelization includes: initializing the etcd cluster in parallel, starting the etcd process in parallel on multiple nodes through Ansible asynchronous tasks; polling the health status of the etcd cluster through a shell script; and starting the component deployment when it is determined that the health status of the etcd cluster meets preset conditions.

[0011] In the above implementation process, starting the etcd process in parallel avoids blocking subsequent tasks, thereby improving deployment efficiency. Furthermore, polling the etcd cluster's health status enables real-time monitoring, enhancing the cluster's reliability and stability, and consequently improving the reliability and stability of the deployment process.

[0012] In one embodiment, before determining the configuration parameters corresponding to the current environment through the three-level parameter coverage mechanism, the method further includes: performing an environment check operation through a Shell script; calling the dmidecode tool to collect hardware information and generate an environment signature code; determining a corresponding optimization scheme based on the environment signature code, adjusting kernel parameters or loading hardware drivers to obtain optimized kernel parameters; wherein, the kernel parameters are configured to determine the current environment.

[0013] In the above implementation process, by collecting hardware information and generating environmental feature codes, and then determining the corresponding optimization scheme based on the environmental feature codes, the accuracy of environmental identification can be improved, thereby enhancing network performance.

[0014] In one embodiment, after calling the configuration file and deploying the component asynchronously and in parallel, the method further includes: determining the operation type based on input parameters and executing an atomic operation matching the operation type; wherein the input parameters include operation parameters; constructing an operation dependency graph and verifying preconditions; verifying operation dependencies through the operation dependency graph; recording breakpoint states in real time during the operation; and implementing fault recovery in the event of an anomaly through an anomaly recording mechanism; wherein the anomaly recording mechanism includes breakpoint recording, CRC checksum verification, and automatic rollback mechanism.

[0015] In the above implementation process, by setting up an operation dependency graph and verifying operation dependencies based on the graph, even complex operations can be executed in an orderly manner, improving component configuration and upgrade efficiency. Furthermore, by employing an exception logging mechanism to enable fault recovery in the event of anomalies, fault recovery time can be reduced promptly, improving system stability and reliability.

[0016] In one embodiment, after calling the configuration file and deploying components asynchronously and in parallel, the method further includes: detecting basic cluster functions by creating a temporary Pod and executing a preset command; calling a cluster monitoring tool to obtain node resource utilization and etcd storage performance; and formatting the test results into an HTML report; wherein the HTML report is a visual report and is configured to provide feedback on whether the deployment of the Kubernetes cluster has met expectations.

[0017] In the above implementation process, verifying the deployment status after component deployment can shorten the deployment cycle, reduce human error, and improve the stability and maintainability of the cluster.

[0018] Secondly, embodiments of this application also provide a Kubernetes cluster deployment apparatus, comprising: a first determining module, configured to determine configuration parameters corresponding to the current environment through a three-level parameter coverage mechanism; a rendering module, configured to dynamically render the configuration parameters and generate a configuration file; a deployment module, configured to call the configuration file and deploy components using asynchronous parallelization; and a second determining module, configured to determine that the Kubernetes cluster deployment is complete when all components in the Kubernetes cluster have been deployed.

[0019] Thirdly, embodiments of this application also provide an electronic device, including: a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the machine-readable instructions are executed by the processor to perform the steps of the method described in the first aspect above, or any possible implementation of the first aspect.

[0020] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the Kubernetes cluster deployment method described in the first aspect or any possible implementation of the first aspect.

[0021] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, specific embodiments are described below in conjunction with the accompanying drawings. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A block diagram of an electronic device provided in an embodiment of this application; Figure 2 A flowchart illustrating the Kubernetes cluster deployment method provided in this application embodiment; Figure 3 This is a schematic diagram of the functional modules of the Kubernetes cluster deployment device provided in the embodiments of this application. Detailed Implementation

[0024] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0025] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] Currently, with the deepening of enterprise digital transformation, containerization technology has become a core cornerstone for building modern application architectures. As the de facto standard in the field of container orchestration, the efficiency and reliability of Kubernetes cluster deployment directly affect the speed of enterprise business iteration and operational costs.

[0027] However, through long-term research, the inventors of this application have found that in the actual production environments of most enterprises, the deployment of Kubernetes clusters still heavily relies on manual operations: the operations and maintenance team needs to manually write YAML configuration files, configure network plugins, storage solutions, and security policies layer by layer, and repeatedly verify component compatibility in multi-node environments. This model has three significant pain points: First, the deployment cycle is lengthy, often taking several days or even weeks from basic environment preparation to cluster service verification, making it difficult to adapt to the needs of rapid business development; second, the complexity of manual configuration leads to a high error rate, according to Gartner statistics, more than 60% of cluster failures are caused by human error; third, as the cluster scale expands to the level of hundreds of nodes, the traditional manual operation and maintenance model faces an exponential increase in configuration complexity, making it difficult to meet the requirements of elastic scaling and continuous delivery in the cloud-native era.

[0028] In view of this, this application proposes a Kubernetes cluster deployment method that directly determines configuration parameters through a three-level parameter overriding mechanism, dynamically renders the configuration parameters to generate corresponding configuration files, and deploys components based on the configuration files using a parallel strategy, thereby achieving automated deployment of the Kubernetes cluster and reducing the error rate. Furthermore, by employing asynchronous parallelization for component deployment, subsequent tasks can be avoided from being blocked, thus improving deployment efficiency.

[0029] To facilitate understanding of this embodiment, the electronic device that performs the Kubernetes cluster deployment method disclosed in this application embodiment will first be described in detail.

[0030] like Figure 1 The diagram shown is a block illustration of an electronic device. The electronic device 100 may include a memory 111 and a processor 113. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device 100. For example, the electronic device 100 may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0031] The aforementioned memory 111 and processor 113 are electrically connected to each other directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected to each other via one or more communication buses or signal lines. The aforementioned processor 113 is used to execute executable modules stored in the memory.

[0032] The memory 111 can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory 111 stores programs, and the processor 113 executes these programs upon receiving execution instructions. The methods executed by the electronic device 100 as defined in any embodiment of this application can be applied to the processor 113, or implemented by the processor 113.

[0033] The aforementioned processor 113 may be an integrated circuit chip with signal processing capabilities. The processor 113 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a digital signal processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor.

[0034] The electronic device 100 in this embodiment can be used to execute various steps in the various methods provided in the embodiments of this application. The implementation process of the Kubernetes cluster deployment method is described in detail below through several embodiments.

[0035] Please see Figure 2 This is a flowchart of the Kubernetes cluster deployment method provided in the embodiments of this application. The following will describe... Figure 2 The specific process shown will be explained in detail.

[0036] Step 201: Determine the configuration parameters corresponding to the current environment through a three-level parameter coverage mechanism.

[0037] This three-level parameter coverage mechanism includes command-line input parameters, environment variable parameters, and preset value parameters. The goal of this mechanism is to dynamically select configuration parameters based on the environment (e.g., development / production / hybrid cloud), prioritizing the use of high-priority parameters.

[0038] In one embodiment, the configuration parameter can be determined by merging command-line input parameters, environment variable parameters, and preset value parameters, and using the merge_vars tool to generate a temporary manifest file.

[0039] This temporary manifest file is used by Ansible. Configuring parameters in this way reduces configuration time from 15 minutes to 30 seconds (a 30-fold improvement), significantly enhancing configuration efficiency.

[0040] Step 202: Dynamically render configuration parameters and generate configuration files.

[0041] This configuration parameter can be rendered using a corresponding conditional template. For example, the Jinja2 template.

[0042] In one embodiment, the configuration file can be modified using the yq tool after it has been generated.

[0043] Understandably, after merging command-line input parameters, environment variable parameters, and preset parameters, the jq tool can be used to overwrite the merged parameters according to priority and generate the final parameter file (i.e., configuration file).

[0044] Step 203: Invoke the configuration file and deploy the component using asynchronous parallelization.

[0045] Asynchronous parallelization here refers to the parallel execution of the etcd process on the etcd node group.

[0046] In one embodiment, the method further includes: asynchronously and in parallel starting the etcd process on the etcd node group, while simultaneously polling the etcd health status via a shell script. If etcd startup times out or fails, etcd is restarted. If the etcd health check passes, the API Server deployment is automatically started, which can greatly shorten deployment time.

[0047] Specifically, if the etcd startup time exceeds a certain threshold, it is determined that the etcd startup has timed out. This etcd startup time threshold can be set to 300 seconds, 500 seconds, 600 seconds, etc. The threshold can be selected based on the actual situation.

[0048] It should be understood that by starting the etcd process asynchronously and in parallel on the etcd node, subsequent tasks can be avoided from being blocked, thus improving the efficiency of component deployment.

[0049] Step 204: Once all components in the Kubernetes cluster have been deployed, confirm that the Kubernetes cluster deployment is complete.

[0050] In one embodiment, after step 204, the method further includes: establishing a unique identifier for the configuration file and comparing the file lists of local and remote nodes. Only changed files are transferred; if the transfer fails, it is retried.

[0051] The unique identifier for the configuration file can be created using the MD5 algorithm.

[0052] For example, you can iterate through all files in a specified directory, calculate their MD5 hash values, and summarize them into a temporary list. The irreversible encryption property of MD5 allows for precise location of file content changes.

[0053] In the above implementation process, configuration parameters are directly determined through a three-level parameter coverage mechanism, and the configuration parameters are dynamically rendered to generate corresponding configuration files. Based on the configuration files, a parallel strategy is used for component deployment, achieving automated deployment of the Kubernetes cluster and reducing the error rate. In addition, since component deployment is performed asynchronously and in parallel, subsequent tasks are avoided from being blocked, thereby improving deployment efficiency.

[0054] In one possible implementation, step 201 includes: determining the priority order of parameter sources; merging parameter sources according to the priority order to generate a target parameter set; and converting the target parameter set into a set format to obtain the configuration parameters corresponding to the current environment.

[0055] The parameter sources can include command-line input parameters, environment variable parameters, and default value parameters. The priority order of these parameter sources is as follows: command-line input parameters take precedence over environment variable parameters, and environment variable parameters take precedence over default value parameters.

[0056] Command-line input parameters here refer to the command parameters entered by the user, which have advantages such as real-time user specification and strong dynamism. Environment variable parameters refer to environment-related configuration parameters (e.g., cloud platform). Preset parameters refer to parameters that are set in advance; they are global default configurations and form the basis of static parameters.

[0057] In one embodiment, parameter sources can be merged in descending order of priority. For example, parameter sources can be merged in the order of command-line input parameters, environment variable parameters, and preset value parameters.

[0058] When merging parameter sources, jq or yq tools can be used for deep merging to ensure that nested objects are correctly covered.

[0059] For example, the specific implementation steps of step 201 can be as follows: Command-line input arguments are parsed using a pass function (e.g., `extra-vars`), converting them into key-value pairs and formatting them as JSON. Then, environment variable arguments are read and converted to JSON. Preset arguments are also read and converted to JSON. Finally, the preset arguments are merged with the environment variable arguments, then merged with the command-line input arguments, and finally converted back to YAML format to generate the final temporary manifest file.

[0060] The parameter source merging process can be as follows; Load default parameters (usually in YAML format) from group_vars / all.yml and read environment variable files. Capture parameters passed from the command line and merge them by priority using a custom script merge_vars.

[0061] Optionally, the setting format can be JSON, YAML, etc., and the setting format can be selected according to the actual situation.

[0062] Among them, yaml2json and json2yaml can achieve mutual conversion between YAML and JSON.

[0063] It should be understood that through step 201 above, adaptive environment configuration can be achieved. Users only need to adjust key parameters by entering parameters through the command line to complete deployments for different scenarios, significantly reducing configuration complexity. In addition, through the priority merging mechanism, the multi-environment configuration that originally required manual comparison is transformed into an automated process, reducing configuration time.

[0064] After obtaining the configuration parameters, Ansible can load them through the ANSIBLE_EXTRA_VARS environment variable. Subsequent tasks (such as template rendering and configuration generation) can then use these configuration parameters, avoiding the need to manually specify multiple parameter sources and simplifying configuration management.

[0065] In the above implementation process, by achieving adaptive environment configuration based on the priority order of parameter sources, users only need to adjust key parameters through command-line input to complete deployments for different scenarios, significantly reducing configuration complexity. Furthermore, through a priority merging mechanism, the multi-environment configuration that originally required manual comparison is transformed into an automated process, reducing configuration time and improving configuration efficiency.

[0066] In one possible implementation, step 202 includes: creating a Jinja2 template file containing conditional logic; passing configuration parameters to the Jinja2 template file and performing variable substitution; rendering the Jinja2 template file and generating a configuration file based on the rendering result.

[0067] The Jinja2 template file contains embedded environment judgment conditions and dynamic variable placeholders.

[0068] The Jinja2 template file can be created as follows: Create a template file with the .j2 extension (e.g., kubeadm-config.j2) in the Ansible role or Playbook directory, and embed Jinja2 conditional logic within it.

[0069] It should be understood that after a Jinja2 template file is created, it is loaded and parsed. Specifically, the Jinja2 template file is loaded via the `templates / kubernetes.yml` path. The Jinja2 template file can be parsed by recognizing the `{{variable_name}}` format.

[0070] The rendering of the Jinja2 template file described above can be achieved as follows: Call the Ansible Template module; load configuration parameters and parse the conditional statements in the Jinja2 template file. Based on the conditional statements, check the value of the `cloud_provider` variable. If it is `aws`, insert the AWS-specific configuration block. If it is not `aws`, skip the AWS-specific configuration. Then, populate the dynamic variables. Variable population can be achieved through placeholder replacement.

[0071] The steps for calling the Ansible Template module include: defining a task in the Playbook, specifying the template source file path and the target generated file path; and passing variable values ​​through the vars parameter, where the variable values ​​come from the three-level overriding mechanism or real-time environment variables.

[0072] In one embodiment, variables can be obtained by loading parameters merged through a three-level overriding mechanism from a temporary manifest file (such as inventory / .runtime.yml); prioritizing command-line input parameters (such as the pod_cidr value passed by --extra-vars); and if the command-line parameters are not defined, falling back to the default values ​​in the environment variable file and the preset value file in turn.

[0073] Optionally, the rendered configuration can be modified via yq. Specifically, real-time parameters can be injected via yq, and POD_CIDR can be passed via environment variables or CLI input to ensure consistency with the parameters in the three-level coverage mechanism.

[0074] The file format of the configuration file mentioned above matches the template type, including but not limited to YAML, JSON, or XML. The file format of this configuration file can be selected according to the actual situation.

[0075] In one embodiment, after generating the configuration file based on the rendering result, the method further includes: pre-verifying the template rendering result using Ansible's --check mode; adding conditional checks in the Shell script to ensure that the target configuration file fields exist; and terminating the deployment process and outputting error logs if the verification fails.

[0076] In the above implementation process, by using Jinja2 template files to achieve adaptive environment configuration and real-time dynamic parameter adjustment, the configuration generation is automated and standardized, which can significantly reduce the configuration error rate in mixed scenarios, avoid human error and improve efficiency.

[0077] In one possible implementation, step 203 includes: initializing the etcd cluster in parallel, starting the etcd process in parallel on multiple nodes via an Ansible asynchronous task; polling the health status of the etcd cluster via a Shell script; and, if the health status of the etcd cluster meets preset conditions, starting component deployment.

[0078] Before initializing the etcd cluster in parallel, the method also includes: defining the etcd node group in the Playbook and setting the task policy to free to allow parallel execution.

[0079] Parallel initialization of an etcd cluster can be achieved as follows: Define an etcd node group in the Ansible Playbook and set the task policy to free to allow parallel execution. Configure Ansible asynchronous task parameters: `yaml async:300 # Timeout 300 seconds poll:0 # Return immediately without waiting for task completion; record the asynchronous task token (e.g., ansible_job_id) for subsequent status queries.`

[0080] In one embodiment, the following script can be executed on the control node to periodically check the health of the etcd endpoints, thereby implementing round-robin health status polling of the etcd cluster.

[0081] For example, the steps of a health check can be as follows: poll the health status of the etcd endpoint using a shell script and use the etcdctl endpoint health command; set up a retry mechanism with a maximum of 10 retries and an interval of 5 seconds between each retrieval; and trigger the API Server deployment task after the health check passes.

[0082] The steps for deploying the components described above can be as follows: deploy the API Server component sequentially to avoid restarting the control plane simultaneously; start the Controller Manager and Scheduler components in sequence; and control the start and stop of the components through the Systemd service management module.

[0083] In the above implementation process, starting the etcd process in parallel avoids blocking subsequent tasks, thereby improving deployment efficiency. Furthermore, polling the etcd cluster's health status enables real-time monitoring, enhancing the cluster's reliability and stability, and consequently improving the reliability and stability of the deployment process.

[0084] In one possible implementation, before step 201, the method further includes: performing an environment check operation via a Shell script; calling the dmidecode tool to collect hardware information and generate an environment signature; determining the corresponding optimization scheme based on the environment signature, adjusting kernel parameters or loading hardware drivers to obtain optimized kernel parameters.

[0085] Among them, the kernel parameter configuration determines the current environment.

[0086] The environment check operation here can include environment pre-check and initialization. This environment check operation can be implemented in the following ways: by executing the environment check operation through a shell script, combined with the Ansible tool to batch distribute configuration modules; or by calling the dmidecode and lshw commands through a shell script to obtain hardware information, and combined with the cloud environment metadata interface to detect the current running environment.

[0087] This shell script can be used to perform operations such as environment checks, hardware fingerprinting, and generating environment signature codes.

[0088] For example, performing environment checks via a shell script can be achieved through the following steps: the shell script obtains the device manufacturer and model information using `dmidecode -s system-manufacturer` and `dmidecode -s system-product-name`; the Ansible tool calls the sysctl module to modify kernel parameters, such as `net.ipv4.ip_forward=1`; and the shell script executes `modprobe br_netfilter` to load the kernel module.

[0089] The aforementioned hardware information may include server manufacturer, model, serial number, UUID, etc., which can be used to generate a unique physical machine identifier (i.e., environmental feature code).

[0090] The environmental identifier here can be used to identify device type, trigger automated operations, etc. The purpose of this environmental identifier can be selected according to the actual situation.

[0091] In one embodiment, the optimization scheme may include: kernel parameter modification, module loading, hardware-level optimization, etc.

[0092] Kernel parameters can be modified in batches using the Ansible+sysctl module. Kernel modules can be loaded via shell scripts.

[0093] It should be understood that corresponding optimization strategies can be matched based on environment signatures. For example, enabling Hugepages on physical machines, disabling swap in cloud environments, and configuring network acceleration in Azure environments using `ethtool -K eth0 tx-checksumming off`. The association between this optimization strategy and the environment signature can be selected based on the actual situation.

[0094] In the above implementation process, by collecting hardware information and generating environmental feature codes, and then determining the corresponding optimization scheme based on the environmental feature codes, the accuracy of environmental identification can be improved, thereby enhancing network performance.

[0095] In one possible implementation, after step 203, the method further includes: determining the operation type based on the input parameters and performing an atomic operation matching the operation type; constructing an operation dependency graph and verifying the preconditions; verifying the operation dependency relationship through the operation dependency graph; recording the breakpoint status in real time during the operation; and realizing fault recovery in the event of an anomaly through an anomaly recording mechanism.

[0096] The input parameters include the operation parameters.

[0097] The operations here include certificate rotation, component upgrades, and configuration changes. Certificate rotation refers to backing up the old certificate to a specified directory, generating a new certificate, and updating the configuration. For example, the old certificate can be backed up to ` / etc / kubernetes / pki / backup`, a new certificate can be generated, and `KubeConfig` can be updated.

[0098] Component upgrade refers to downloading a specified version of the component, restarting the service, and verifying version consistency. Configuration change refers to modifying the configuration file and then verifying the format and content validity.

[0099] In one embodiment, the rules for constructing the operation dependency graph may include: determining the binding relationship between operation nodes and pre-check nodes; and a dynamic dependency loading mechanism based on operation type.

[0100] The aforementioned prerequisites can be achieved by running the check_dependencies.sh script.

[0101] Optionally, the exception logging mechanism may include breakpoint logging, CRC checksum verification, and automatic rollback mechanism. This exception logging mechanism can be selected based on the actual situation.

[0102] The aforementioned atomic operation refers to decomposing operational operations into indivisible atomic steps, so that each step can be executed independently and supports rollback.

[0103] Understandably, when recording breakpoint states, the current state can be written to / var / .k8s-state (e.g., kubelet_install) at the beginning of each phase.

[0104] In one embodiment, if the command returns a non-zero status code, the error is captured and logged. Alternatively, a rollback to the previous normal stage can be performed based on the status file.

[0105] In the above implementation process, by setting up an operation dependency graph and verifying operation dependencies based on the graph, even complex operations can be executed in an orderly manner, improving component configuration and upgrade efficiency. Furthermore, by employing an exception logging mechanism to enable fault recovery in the event of anomalies, fault recovery time can be reduced promptly, improving system stability and reliability.

[0106] In one possible implementation, after step 203, the method further includes: detecting the basic functions of the cluster by creating a temporary Pod and executing a preset command; calling a cluster monitoring tool to obtain node resource utilization and etcd storage performance; and formatting the test results into an HTML report.

[0107] The HTML report is a visual report, configured to provide feedback on whether the Kubernetes cluster deployment has met expectations.

[0108] The node utilization here can be obtained using `kubectl top node`, and the etcd storage performance can be tested using `etcdctl check perf`.

[0109] The aforementioned temporary Pods are used to preset commands to quickly verify the basic functions of the cluster (such as scheduling, network communication, etc.).

[0110] For example, cluster basic function verification can be achieved in the following ways: start short-lifecycle containers using the kubectl run command and execute the echo OK command to verify the Pod scheduling success rate; use kubectl top node to obtain CPU and memory usage in real time, and combine the thresholds to determine the rationality of resource allocation.

[0111] In one embodiment, the HTML report can be generated by converting the raw test data into a time series chart; embedding key indicator compliance status indicators in the HTML report, and marking non-compliant items with a red warning.

[0112] The HTML report is a visual report.

[0113] Understandably, the Kubernetes cluster deployment method in this application embodiment can greatly improve deployment efficiency. Table 1 below compares the deployment efficiency differences between the Kubernetes cluster deployment method in this application embodiment and existing Kubernetes cluster deployment methods.

[0114] Table 1:

[0115] In the above implementation process, verifying the deployment status after component deployment can shorten the deployment cycle, reduce human error, and improve the stability and maintainability of the cluster.

[0116] Based on the same concept, this application also provides a Kubernetes cluster deployment device corresponding to the Kubernetes cluster deployment method. Since the principle of the device in this application is similar to that of the aforementioned Kubernetes cluster deployment method, the implementation of the device in this application can refer to the description in the above method embodiments, and the repeated parts will not be described again.

[0117] Please see Figure 3This is a functional module diagram of the Kubernetes cluster deployment device provided in this application embodiment. Each module in the Kubernetes cluster deployment device in this embodiment is used to execute the steps in the above method embodiments. The Kubernetes cluster deployment device includes a first determining module 301, a rendering module 302, a deployment module 303, and a second determining module 304; wherein, The first determination module 301 is used to determine the configuration parameters corresponding to the current environment through a three-level parameter coverage mechanism.

[0118] The rendering module 302 is used to dynamically render the configuration parameters and generate a configuration file.

[0119] The deployment module 303 is used to call the configuration file and perform component deployment using asynchronous parallelization.

[0120] The second determining module 304 is used to determine that the Kubernetes cluster deployment is complete when all components in the Kubernetes cluster have been deployed.

[0121] In one possible implementation, the first determining module 301 is further configured to: determine the priority order of parameter sources; wherein the priority order is: command line input parameters take precedence over environment variable parameters, and the environment variable parameters take precedence over preset value parameters; merge the parameter sources according to the priority order to generate a target parameter set; and convert the target parameter set into a set format to obtain the configuration parameters corresponding to the current environment.

[0122] In one possible implementation, the rendering module 302 is further configured to: create a Jinja2 template file containing conditional logic; the Jinja2 template file embeds environment judgment conditions and dynamic variable placeholders; pass the configuration parameters to the Jinja2 template file and perform variable substitution; render the Jinja2 template file and generate the configuration file based on the rendering result.

[0123] In one possible implementation, the deployment module 303 is further configured to: initialize the etcd cluster in parallel, start the etcd process in parallel on multiple nodes via Ansible asynchronous tasks; poll the health status of the etcd cluster via a Shell script; and, if the health status of the etcd cluster meets preset conditions, initiate component deployment.

[0124] In one possible implementation, the Kubernetes cluster deployment device further includes: an adjustment module, used to perform environment check operations via a Shell script; call the dmidecode tool to collect hardware information and generate an environment signature code; determine a corresponding optimization scheme based on the environment signature code, adjust kernel parameters or load hardware drivers to obtain optimized kernel parameters; wherein the kernel parameters are configured to determine the current environment.

[0125] In one possible implementation, the Kubernetes cluster deployment device further includes: a recovery module, configured to determine the operation type based on input parameters and execute atomic operations matching the operation type; wherein the input parameters include operation parameters; construct an operation dependency graph and verify preconditions; verify operation dependencies through the operation dependency graph; record breakpoint status in real time during the operation; and achieve fault recovery in the event of an anomaly through an anomaly recording mechanism; wherein the anomaly recording mechanism includes breakpoint recording, CRC checksum verification, and automatic rollback mechanism.

[0126] In one possible implementation, the Kubernetes cluster deployment device further includes: a formatting module, used to detect basic cluster functions by creating temporary Pods and executing preset commands; call cluster monitoring tools to obtain node resource utilization and etcd storage performance; and format the test results into an HTML report; wherein the HTML report is a visual report, and the HTML report is configured to provide feedback on whether the deployment of the Kubernetes cluster has met expectations.

[0127] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the Kubernetes cluster deployment method described in the above method embodiments.

[0128] The computer program product of the Kubernetes cluster deployment method provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the steps of the Kubernetes cluster deployment method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0129] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0130] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0131] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes 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 steps 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), random access memory (RAM), magnetic disks, or optical disks. It should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitation, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0132] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for deploying a Kubernetes cluster, characterized in that, include: The configuration parameters corresponding to the current environment are determined through a three-level parameter coverage mechanism; The configuration parameters are dynamically rendered to generate a configuration file; The configuration file is invoked, and the component is deployed asynchronously and in parallel. The deployment of the Kubernetes cluster is considered complete once all components in the Kubernetes cluster have been deployed.

2. The method according to claim 1, characterized in that, The process of determining the configuration parameters corresponding to the current environment through a three-level parameter coverage mechanism includes: Determine the priority order of parameter sources; wherein the priority order is: command line input parameters take precedence over environment variable parameters, and environment variable parameters take precedence over preset value parameters; The parameter sources are merged according to the priority order to generate the target parameter set; After converting the target parameter set into a set format, the configuration parameters corresponding to the current environment are obtained.

3. The method according to claim 1, characterized in that, The dynamic rendering of the configuration parameters to generate a configuration file includes: Create a Jinja2 template file containing conditional logic; the Jinja2 template file contains embedded environment judgment conditions and dynamic variable placeholders; The configuration parameters are passed to the Jinja2 template file, and variable substitutions are performed. Render the Jinja2 template file and generate the configuration file based on the rendering result.

4. The method according to claim 1, characterized in that, The step of calling the configuration file and deploying components using asynchronous parallelization includes: The etcd cluster is initialized in parallel by starting the etcd process on multiple nodes in parallel through Ansible asynchronous tasks. The health status of the etcd cluster is polled using a shell script; Once the health status of the etcd cluster meets the preset conditions, the component deployment is initiated.

5. The method according to any one of claims 1-4, characterized in that, Before determining the configuration parameters corresponding to the current environment through the three-level parameter coverage mechanism, the method further includes: Perform environment checks via shell scripts; The dmidecode tool is used to collect hardware information and generate an environment signature code. Based on the environmental feature code, a corresponding optimization scheme is determined, kernel parameters are adjusted or hardware drivers are loaded to obtain optimized kernel parameters. The kernel parameters are configured to determine the current environment.

6. The method according to any one of claims 1-4, characterized in that, After invoking the configuration file and deploying the component using asynchronous parallelization, the method further includes: The operation type is determined based on the input parameters, and an atomic operation matching the operation type is executed; wherein, the input parameters include operation parameters; Construct an operation dependency graph and verify the preconditions; The operation dependencies are verified using the operation dependency graph. Record breakpoint status in real time during operation; Fault recovery is achieved in the event of anomalies through an anomaly recording mechanism; wherein, the anomaly recording mechanism includes breakpoint recording, CRC check and automatic rollback mechanism.

7. The method according to any one of claims 1-4, characterized in that, After invoking the configuration file and deploying the component using asynchronous parallelization, the method further includes: Test the basic functions of the cluster by creating a temporary Pod and executing preset commands; Use cluster monitoring tools to obtain node resource utilization and etcd storage performance; Format the test results as an HTML report; The HTML report is a visual report, configured to provide feedback on whether the deployment of the Kubernetes cluster has met expectations.

8. A Kubernetes cluster deployment device, characterized in that, include: The first determination module is used to determine the configuration parameters corresponding to the current environment through a three-level parameter coverage mechanism; The rendering module is used to dynamically render the configuration parameters and generate configuration files; The deployment module is used to call the configuration file and deploy components asynchronously and in parallel. The second determining module is used to determine that the Kubernetes cluster deployment is complete when all components in the Kubernetes cluster have been deployed.

9. An electronic device, characterized in that, include: The processor and memory, wherein the memory stores machine-readable instructions executable by the processor, wherein when the electronic device is running, the machine-readable instructions are executed by the processor to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the method as described in any one of claims 1 to 7.

Images