Helm-based method for automatically deploying local volumes in a kubernetes cluster

Abstract

The application discloses a kind of Helm-based kubernetes cluster local volume automation deployment method, belong to the technical field of computer software kubernetes operation and maintenance management, the technical problem that the present application wants to solve is how to realize the quick installation and deployment local volume in kubernetes cluster, it is convenient for operation and maintenance maintenance simultaneously, guarantee storage performance, reduce the threshold of access cloud platform, improve service product performance, the technical scheme for being adopted is as follows: the method is as follows: local volume disk mounting directory is created, and is managed by Ansible;Local volume dependent local disk and directory are initialized by Ansible script, corresponding Ansible script is executed by triggering Ansible command, to realize the automatic deployment installation of local volume disk;In the process of local volume automation deployment, deployment management is carried out by Helm chart package, and the deployment file of local volume is developed according to the development specification of Helm chart package;Using the deployment template of Helm, the customized development of quick is realized.

Description

Technical Field

[0001] This invention relates to the technical field of Kubernetes operation and maintenance management, specifically a method for automated deployment of local volumes in a Kubernetes cluster based on Helm. Background Technology

[0002] Helm is currently the only open-source sub-project in the Kubernetes service orchestration field, serving as a package management tool for Kubernetes applications. Helm supports version management and control of releases through software packaging, greatly simplifying the complexity of Kubernetes application deployment and management.

[0003] In recent years, cloud computing technology has developed rapidly. Faced with a wide variety of cloud solutions, most commonly use the open-source system Kubernetes for automated deployment, scaling, and management of containerized applications. Most Kubernetes clusters are deployed on cloud virtual machines in virtualized environments. Cloud vendors typically provide their own cloud storage services to support these clusters. For a cloud platform product, the diverse persistent storage solutions offered by cloud vendors increase storage access costs and difficulties when building the underlying Kubernetes cluster, requiring extensive adaptation testing. Virtual machine clusters built on Elastic Compute Service (ECS) servers typically have remote data volumes for their storage disks. Building separate remote storage on top of this will undoubtedly lead to performance degradation. For example, building a new distributed storage service like Ceph on an OpenStack virtual machine built on Ceph will result in reduced storage performance, impacting the platform's normal operation and user experience. Therefore, ensuring platform products are compatible with various cloud solutions, enabling convenient deployment, improving storage performance, and guaranteeing user experience has become a critical challenge for many developers.

[0004] The local volumes provided by Kubernetes can solve the storage requirements of services in scenarios with high I / O and high storage performance. Compared with manually configuring local volumes, which is more labor-intensive, complex to configure, and inconvenient to record and maintain for a platform product. Summary of the Invention

[0005] The technical objective of this invention is to provide an automated deployment method for local volumes in a Kubernetes cluster based on Helm, in order to solve the problems of how to quickly install and deploy local volumes to a Kubernetes cluster, while facilitating operation and maintenance, ensuring storage performance, reducing the threshold for accessing cloud platforms, and improving the performance of service products.

[0006] The technical objective of this invention is achieved as follows: an automated deployment method for local volumes in a Kubernetes cluster based on Helm, the method being as follows:

[0007] The local volume disk mount directory is created and managed using Ansible;

[0008] The local disks and directories that the local volume depends on are initialized using Ansible scripts, and the corresponding Ansible scripts are executed by triggering the Ansible command, thereby achieving automated deployment and installation of the local volume disks.

[0009] During the automated deployment of local volumes, deployment management is handled by the Helm chart package, and the deployment files for local volumes are developed in accordance with the Helm chart package development specifications.

[0010] Enable rapid customization by utilizing Helm's deployment templates.

[0011] Preferably, the local volume chart deployment template includes the configMap template, the local volume storage StorageClass template, the local volume template, and the disk directory initialization job template.

[0012] Even better, the customized configMap template is as follows:

[0013] (1) Custom mount custom parameters configMap: The parameter file values.yaml is the parameter configuration document for the entire Helmchart package template. It contains the custom information of the disk and directory of the local volume creation service and configures the specified format into the values.yaml file for Helm template reference parameters. The parameters in values ​​are extracted into the configMap through Helm template syntax.

[0014] (2) Customize Ansible configMap for parsing cluster host information: The purpose of configmap is to define a Python script to parse the hosts file of Kubernetes cluster hosts and generate the Ansible configuration file inventory for managing host information.

[0015] (3) Customize the Ansible task template configMap: Define the Ansible script for creating the disk directory in the configMap, and use the custom mount parameter configMap in (1) to generate the parameter file;

[0016] (4) Custom Ansible execution command configMap: Define the command to be executed by the Ansible task as a shell script for reference in Helm job templates; when executed, reference the file generated by the custom Ansible parsing cluster host information configMap in (2) and the custom Ansible task template configMap in (3), and thus form a complete Ansible task.

[0017] More preferably, the storageClass template for creating local volume storage is as follows:

[0018] StorageClass delays the binding of PVs to PVCs. Specifying the WaitForFirstConsumer mode will delay the binding and preparation of PersistentVolumes until the service Pod using the PersistentVolumeClaim is created.

[0019] PersistentVolume is selected or prepared based on the topology specified by the service Pod scheduling constraints;

[0020] PVCs and PVs are bound together by specifying the same StorageClass.

[0021] More preferably, the local volume template is deployed as follows:

[0022] In Chart, local volume templates are customized for each service. Helm reads all local volume parameter information defined in values.yaml. During deployment, local volumes are dynamically generated based on the local volume templates. The local volume templates define labels for each service. Service pods use label selectors to match labels and bind corresponding PVs to associate them with the corresponding storage disks or directories, providing corresponding storage for services in the platform products. Created PVs are automatically associated with local disk directories. The status of a PV after creation is "available". When a pod is created, it is automatically associated with the PV through PVC, thereby realizing the deployment and installation of local volume and local disk storage.

[0023] More preferably, disk initialization is performed by initializing the job template through the disk directory, as follows:

[0024] The initial creation of disks or directories is achieved by setting up a Kubernetes job, which uses an Ansible Docker image and executes the scripts in the configMap template within the Ansible image's container.

[0025] When Helm runs a chart, it mounts the configuration files in the configmap into the container of the job task.

[0026] According to the configuration in the configMap file, Ansible connects to control the virtual machines of the Kubernetes cluster. It filters the host nodes that need to perform disk and directory initialization tasks through scripts, and completes the disk and directory initialization tasks on the nodes that need to perform them, without requiring manual disk initialization in the virtual machine environment.

[0027] Use Helm commands to check if the deployment was successful and examine the logs in the pod where the job was executed. This will help you check if each virtual machine has been correctly initialized to disk, facilitating error troubleshooting and operations management.

[0028] An electronic device includes: a memory and at least one processor;

[0029] The memory contains computer programs;

[0030] The at least one processor executes the computer program stored in the memory, causing the at least one processor to perform the automated deployment method of local volumes in a Helm-based Kubernetes cluster as described above.

[0031] A computer-readable storage medium storing a computer program that can be executed by a processor to implement the above-described method for automated deployment of local volumes in a Helm-based Kubernetes cluster.

[0032] The Helm-based automated deployment method for local volumes in a Kubernetes cluster has the following advantages:

[0033] (i) This invention enables rapid installation and deployment of local volumes to a Kubernetes cluster, facilitating operation and maintenance, ensuring storage performance, reducing the barrier to accessing cloud platforms, and improving the performance of service products.

[0034] (ii) The Helm Chart package deployed in this invention is customized to customize the local disk storage Persistent Volume required by different services; the local disk resource initialization task on the k8s cluster host mainly solves the problem of dynamically allocating persistent storage in service scenarios where system applications need to store data on different nodes and have high I / O requirements.

[0035] (III) The local volume Helm deployment management of the present invention improves the efficiency of resource allocation management and utilization, and solves problems such as automated deployment of local volumes;

[0036] (iv) This invention completes the automated deployment of local volumes. Combined with Ansible, it enhances the flexibility of automated installation and deployment, while also supporting Helm version management and custom parameter configuration.

[0037] (v) This invention significantly improves the efficiency of local volume deployment and operation and maintenance management, reduces deployment costs, and enables rapid deployment; localized storage reduces the integration costs of platform products, enhances the stability of platform products, and ensures the availability of service products;

[0038] (vi) This invention is organized and deployed using Helm, Ansible, and Python, which can effectively manage local volumes in a Kubernetes cluster, enable fast and efficient installation and deployment, improve storage performance, and provide solutions for automated deployment and maintenance, storage resource allocation, and version management.

[0039] (vii) The architecture of this invention features rapid installation and deployment, easy management, and supports local volume deployment in numerous cloud platform environments based on Kubernetes.

[0040] (viii) This invention combines Helm and Ansible to provide programmable and flexible configuration deployment, while also enabling customized allocation and management of storage resources. Attached Figure Description

[0041] The invention will be further described below with reference to the accompanying drawings.

[0042] Appendix Figure 1 This diagram illustrates the automated deployment method of local volumes in a Helm-based Kubernetes cluster. Detailed Implementation

[0043] The following detailed description of the Helm-based automated deployment method for local volumes in a Kubernetes cluster, with reference to the accompanying drawings and specific embodiments, illustrates the present invention.

[0044] Example 1:

[0045] As attached Figure 1 As shown in the figure, this embodiment provides a method for automated deployment of local volumes in a Kubernetes cluster based on Helm. The method is as follows:

[0046] S1. Create the local volume disk mount directory and manage it using Ansible;

[0047] S2. Initialize the local disks and directories that the local volume depends on using Ansible scripts, and trigger the execution of the corresponding Ansible scripts through Ansible commands to achieve automated deployment and installation of the local volume disks.

[0048] S3. During the automated deployment of local volumes, deployment management is handled by the Helm chart package, and the deployment files for local volumes are developed in accordance with the Helm chart package development specifications.

[0049] S4. Utilize Helm's deployment templates to achieve rapid customized development.

[0050] This embodiment uses Helm for overall installation and deployment orchestration. Helm is a package management tool for Kubernetes applications. Helm supports version management and control of releases through software packaging, greatly simplifying the complexity of Kubernetes application deployment and management. The package format used by Helm is called a chart. A chart is a collection of files describing Kubernetes-related resources. Local volume disk mount directory creation is managed using Ansible. Ansible, as an automation tool, has the following advantages: simplicity (it's a high-level scripting language, not a standard language); no agent installation required (it separates management nodes and remote managed nodes via SSH authentication); and wide applicability, including various operating systems, virtualization systems, and cloud environments.

[0051] The local volume chart deployment template in this embodiment includes a configMap template, a local volume storage StorageClass template, a local volume template, and a disk directory initialization job template.

[0052] The customized configMap template in this embodiment is as follows:

[0053] (1) Custom mount custom parameters configMap: The parameter file values.yaml is the parameter configuration document for the entire Helmchart package template. It contains the custom information of the disk and directory of the local volume creation service and configures the specified format into the values.yaml file for Helm template reference parameters. The parameters in values ​​are extracted into the configMap through Helm template syntax.

[0054] (2) Customize Ansible configMap for parsing cluster host information: The purpose of configmap is to define a Python script to parse the hosts file of Kubernetes cluster hosts and generate the Ansible configuration file inventory for managing host information.

[0055] (3) Customize the Ansible task template configMap: Define the Ansible script for creating the disk directory in the configMap, and use the custom mount parameter configMap in (1) to generate the parameter file;

[0056] (4) Custom Ansible execution command configMap: Define the command to be executed by the Ansible task as a shell script for reference in Helm job templates; when executed, reference the file generated by the custom Ansible parsing cluster host information configMap in (2) and the custom Ansible task template configMap in (3), and thus form a complete Ansible task.

[0057] The specific storageClass template for creating local volume storage in this embodiment is as follows:

[0058] (i) StorageClass is used to delay the binding of PV and PVC correspondence. The WaitForFirstConsumer mode will delay the binding and preparation of PersistentVolume until the service Pod using the PersistentVolumeClaim is created.

[0059] (ii) PersistentVolume is selected or prepared based on the topology specified by the service Pod scheduling constraints;

[0060] (iii) PVC and PV are bound together by specifying the same StorageClass.

[0061] The specific deployment of the local volume template in this embodiment is as follows:

[0062] In Chart, local volume templates are customized for each service. Helm reads all local volume parameter information defined in values.yaml. During deployment, local volumes are dynamically generated based on the local volume templates. The local volume templates define labels for each service. Service pods use label selectors to match labels and bind corresponding PVs to associate them with the corresponding storage disks or directories, providing corresponding storage for services in the platform products. Created PVs are automatically associated with local disk directories. The status of a PV after creation is "available". When a pod is created, it is automatically associated with the PV through PVC, thereby realizing the deployment and installation of local volume and local disk storage.

[0063] A local volume is a statically created persistent storage (PersistentVolume) for Kubernetes cluster pods. It's a storage unit within the cluster that can be pre-provisioned by the administrator using static provisioning. A local volume represents a mounted local storage device, such as a disk, partition, or directory. Local volumes can only be created statically and can be used persistently and portablely without manually scheduling Pods to nodes. The system can understand the node constraints of a volume by viewing its node affinity configuration. Local volumes are based on Kubernetes and have strong cross-platform compatibility. Typically, virtual machines in cloud environments are OpenStack virtual machines based on Ceph storage. Building distributed storage services in such environments can severely impact storage performance and service operation. Deploying local volumes can avoid this problem because they directly use local disks for storage, ensuring storage performance.

[0064] In this embodiment, disk initialization is performed by initializing the job template through the disk directory as follows:

[0065] ① The initial creation of disks or directories is achieved by setting up a Kubernetes job. The job uses the Ansible Docker image and executes the script in the configMap template within the Ansible image container.

[0066] ② When Helm runs a chart, it mounts the configuration files in the configmap into the job's container;

[0067] ③ According to the configuration in the configMap file, Ansible connects to and controls the virtual machines of the Kubernetes cluster. It filters the host nodes that need to perform disk and directory initialization tasks through scripts, and completes the disk and directory initialization tasks on the nodes that need to be executed, without the need for manual disk initialization in the virtual machine environment.

[0068] ④ Use Helm commands to check if the deployment was successful and check the logs in the job task pod to check whether each virtual machine has correctly initialized its disk, which facilitates error troubleshooting and operation and maintenance management.

[0069] This creates a deployment and management tool using Helm, and technologies such as Ansible and Python to automatically initialize local disks and directories. It also allows for the customization of service product PV templates to adapt to different cloud platform environments. This eliminates the limitations imposed by cloud platform storage environments on storage requirements, automates the allocation of storage PVs, improves deployment efficiency, and facilitates version management.

[0070] Example 2:

[0071] This invention also provides an electronic device, including: a memory and a processor;

[0072] The memory stores the instructions executed by the computer.

[0073] The processor executes computer execution instructions stored in the memory, causing the processor to execute the Helm-based automated deployment method for local volumes in a Kubernetes cluster according to any embodiment of the present invention.

[0074] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can be a microprocessor or any conventional processor.

[0075] Memory is used to store computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, at least one application program required for a function, etc.; the data storage area can store data created based on the use of the terminal, etc. In addition, memory can also include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart memory cards (SMC), secure digital cards (SD cards), flash memory cards, at least one disk storage device, flash memory devices, or other volatile solid-state storage devices.

[0076] Example 3:

[0077] This invention also provides a computer-readable storage medium storing multiple instructions, which are loaded by a processor to cause the processor to execute the Helm-based automated deployment method for local volumes in a Kubernetes cluster according to any embodiment of this invention. Specifically, a system or apparatus equipped with a storage medium may be provided, on which software program code implementing the functions of any of the above embodiments is stored, and the computer (or CPU or MPU) of the system or apparatus may read and execute the program code stored in the storage medium.

[0078] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of the present invention.

[0079] Storage media embodiments for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RYM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0080] Furthermore, it should be clear that not only can the program code read by the computer be executed, but also the operating system or other components operating on the computer can be instructed based on the program code to perform some or all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0081] Furthermore, it is understood that the program code read from the storage medium is written to the memory set in the expansion board inserted into the computer or to the memory set in the expansion unit connected to the computer. Then, based on the instructions of the program code, the CPU or other components installed on the expansion board or expansion unit execute some and all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0082] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for automatically deploying local volumes in a Helm-based kubernetes cluster, characterized in that, The method is as follows: The local volume disk mounting directory is created and managed through Ansible; The local volume depends on the local disk and directory, which are initialized through the Ansible script, and the corresponding Ansible script is triggered to execute through the Ansible command, so as to realize the automatic deployment and installation of the local volume disk; In the process of automatic deployment of the local volume, the chart package of Helm is used for deployment management, and the deployment file of the local volume is developed according to the development specification of the chart package of Helm; The deployment template of Helm is used to realize rapid customized development; The chart deployment template of the local volume includes a configMap template, a local volume storage StorageClass template, a local volume template and a disk directory initialization job template; The customized configMap template is as follows: (1) Custom mounting custom parameters configMap: The parameter file values.yaml is a parameter configuration tool for the entire Helm chart package template. The custom information of the disk and directory of the local volume creation service is configured in the values.yaml file in a specified format, which is used to reference parameters in the Helm template. The parameters in the values are extracted to the configMap through the Helm template syntax; (2) Custom Ansible parsing cluster host information configMap: The function of configmap is to define a python script for parsing the hosts information file of the kubernetes cluster, and to generate the configuration file inventory of the Ansible management host information; (3) Custom Ansible task template configMap: The Ansible script for creating the disk directory is defined in the configMap, and the parameter file is generated by referencing the custom mounting custom parameters configMap in (1); (4) Custom Ansible execution command configMap: The command defined for executing the Ansible task is defined as a shell script, which is used for the reference of the job template of Helm; when executed, the files generated by (2) custom Ansible parsing cluster host information configMap and (3) custom Ansible task template configMap are referenced, and then a complete ansible task is formed; The disk initialization through the disk directory initialization job template is as follows: For the initialization creation of the disk or directory, a job of kubernetes is used to realize the initialization creation. The docker image of Ansible is applied in the job, and the script in the configMap template is executed in the container of the Ansible image; When Helm runs the chart, the configuration file in the configmap is mounted to the container of the job task; According to the configuration in the configMap file, Ansible connects the virtual machine of the kubernetes cluster, filters the host node that needs to perform the disk and directory initialization task through the script, and completes the disk and directory initialization task on the node that needs to be executed; Check whether the deployment is successful through the Helm command, and check the log in the job task pod, and then troubleshoot whether each virtual machine correctly performs disk initialization.

2. The method of claim 1, wherein the method further comprises: The storageClass template for creating local volume storage is as follows: StorageClass is used to delay the binding of PV and PVC, and specifies the WaitForFirstConsumer mode to delay the binding and preparation of PersistentVolume until the service Pod using the PersistentVolumeClaim is created; PersistentVolume selects or prepares according to the topology specified by the service Pod scheduling constraint; PVC and PV are bound together by specifying the same StorageClass.

3. The method of claim 1, wherein the method further comprises: The local volume template is deployed as follows: In the Chart, customize the local volume template required by each service, and Helm reads all local volume parameter information defined in values.yaml; during deployment, dynamically generate local volumes according to the local volume template definition; the label of each service is defined in the local volume template, and the pod of the service is bound to the corresponding pv by matching the label through the label selector, to associate the corresponding storage disk or directory, and provide corresponding storage for the services in the platform product; the created pv is automatically associated with the local disk directory, and the state of the pv after creation is available; when the pod is created, it is automatically associated with the pv through the pvc, and then the local volume local disk storage is deployed and installed.

4. An electronic device, comprising: It includes: a memory and at least one processor; wherein the memory has stored thereon a computer program; the at least one processor executes the computer program stored on the memory, so that the at least one processor executes the Helm-based kubernetes cluster local volume automatic deployment method in any one of claims 1 to 3.

5. A computer readable storage medium, characterized in that, The computer readable storage medium has stored therein a computer program, which can be executed by a processor to implement the Helm-based kubernetes cluster local volume automatic deployment method in any one of claims 1 to 3.

Images