Method for efficiently converting Kubernetes resources to Helm Charts

Abstract

The invention provides a method for efficiently converting Kubernetes resources into Helm Charts, and belongs to the field of cloud computation.The method comprises the steps that on the basis of k8s, business scenes related to cloud native applications are considered, in a selected namespace, arrangement of all assemblies of the cloud native applications is conducted in the modes of graphical dragging, line connection, editing and the like, the modules are exported as templates, and the modules are stored in a database; therefore, automation of partial processes is realized.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing, and in particular to a method for efficiently converting Kubernetes resources into Helm Charts. Background Art

[0002] Moving to the cloud has become an inevitable choice for the sustainable development of enterprises, and the era of fully using cloud services to build software services has arrived. Compared with traditional architectures, cloud-native architectures strip a large number of non-functional features from business code into Iaas and Paas, thereby reducing the technical focus scope of business code developers and enhancing the non-functional capabilities of applications through cloud services.

[0003] When deploying business code on a k8s cluster provided by a cloud provider, manually creating Helm Charts is time-consuming and error-prone, and managing resources across namespaces also has high complexity. To facilitate the migration from the pre-production environment to the production environment, Charts templates can be automatically generated in Kubernetes to simplify the application deployment and management processes and improve DevOps efficiency. Summary of the Invention

[0004] To solve the above technical problems, the present invention provides a method for efficiently converting Kubernetes resources into Helm Charts. Based on k8s, considering business scenarios related to cloud-native applications, in the selected namespace, the components of cloud-native applications are orchestrated through graphical dragging, wiring, editing, etc. and exported as templates, thereby realizing the automation of some processes and simplifying the application deployment and management processes.

[0005] The technical solution of the present invention is as follows:

[0006] A method for efficiently converting Kubernetes resources into Helm Charts is used to automatically package resources (such as Deployment, Service, PersistentVolumeClaim, StorageClass, StatefulSet, CronJob, Ingress, etc.) in the same namespace in a Kubernetes cluster into Charts templates that meet the requirements of Helm 3, aiming to simplify the application deployment and management processes. The method includes: orchestrating the components of cloud-native applications through graphical dragging, wiring, editing, etc. and exporting them as templates.

[0007] Furthermore,

[0008] Automatically package resources in the same namespace in a Kubernetes cluster into Charts templates that meet the requirements of Helm 3.

[0009] Among them, the resources include Deployment, Service, PersistentVolumeClaim, StorageClass, StatefulSet, CronJob, and Ingress.

[0010] Furthermore,

[0011] In the selected namespace, the components of the cloud-native application are orchestrated through graphical dragging, connection, and editing, and then exported as a template.

[0012] The steps include:

[0013] S1, Icon dragging: The resource components in the left menu bar can be dragged into the editor to generate corresponding icons;

[0014] S2, Icon connection: Icons can be connected to indicate their interconnection;

[0015] S3, Double-click to edit: Double-click to pop up the sidebar to edit detailed configuration information;

[0016] S4, Save blueprint: Send a request to the backend, and the backend saves the blueprint to the template repository;

[0017] S5, Undo operation: Undo the previous operation;

[0018] S6, Redo operation: Redo the previous operation;

[0019] S7, Delete blueprint: Delete all blueprints.

[0020] Furthermore,

[0021] An application space contains several applications, including web applications, mysql applications, and redis applications. It can span several namespace environments. An application will be deployed to different environments to generate an application instance. There are several deployments for the application instances in one environment. One deployment corresponds to a stateless workload of Deployment or a stateful workload of StatefulSet. Each deployment can have several releases, and different release strategies can be selected for each release.

[0022] Each release generates a new application instance. On this deployment, the application template or image used is defined. Description of the Drawings

[0023] Figure 1 It is a schematic diagram of the working process of the present invention. Detailed Embodiments

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0025] The present invention provides a method for efficiently converting Kubernetes resources into Helm Charts. In the context of the present invention, an application space (such as a web-APP) can contain multiple applications (web application, mysql application, redis application), which can span multiple namespaces (environments). An application will be deployed to different environments to generate an application instance. An application instance in an environment (web-APP-pre-production environment) has multiple deployments, and each deployment corresponds to a deployment (stateless workload) or a statefulset (stateful workload). Each deployment can have multiple releases, and different release strategies (such as canary release, blue-green release, etc.) can be selected for each release. Each release generates a new application instance. On this deployment, the application template or image used will be defined.

[0026] Figure 1 It is a flowchart of an embodiment of the present invention.

[0027] S1. Icon dragging: The resource components in the left menu bar can be dragged into the editor to generate corresponding icons;

[0028] S2. Icon connection: Icons can be connected to indicate mutual connection;

[0029] Among them, the following relationships exist between components:

[0030] ① Inclusion relationship: Components that can be recognized as being included within the namespace box and the chart box are generated with corresponding inclusion relationships

[0031] ② Association relationship: For example, which container the storage volume and configuration item are mounted to, and which workload the container belongs to, etc.

[0032] ③ Dependency relationship: The dependency relationship between charts, where the deployment first points to the subsequent deployment

[0033] S3. Double-click to edit: Double-click to pop up the sidebar to edit detailed configuration information;

[0034] S4. Save the blueprint: Send a request to the backend, and the backend saves the blueprint to the template repository;

[0035] S5, Undo operation: Undo the previous operation;

[0036] S6, Redo operation: Redo the previous operation;

[0037] S7, Delete blueprint: Delete all blueprints.

[0038] The above are only the preferred embodiments of the present invention, which are only used to illustrate the technical solutions of the present invention and are not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention are all included in the protection scope of the present invention.

Claims

1. A method for efficiently converting Kubernetes resources to Helm Charts, characterized in that: Automatically package resources in the same namespace into a Charts template that meets Helm 3 requirements in the Kubernetes cluster.

2. The method according to claim 1, characterized in that Resources include Deployment, Service, PersistentVolumeClaim, StorageClass, StatefulSet, CronJob, and Ingress.

3. The method according to claim 1 or 2, characterized in that: In the selected namespace, you can orchestrate cloud-native application components by graphically dragging, connecting, and editing, and export them as templates.

4. The method according to claim 1, characterized in that The specific steps include: S1, Icon dragging: The resource components in the left menu bar can be dragged into the editor and the corresponding icons will be generated; S2, Icon connection: Icons can be connected to indicate mutual connection; S3, double-click to edit: double-click to pop up the sidebar to edit detailed configuration information; S4, save blueprint: send a request to the backend, and the backend saves the blueprint to the template repository; S5, undo operation: undo the previous operation; S6, restore operation: restore the previous operation; S7, Delete blueprint: Delete all blueprints.

5. The method according to claim 4, characterized in that An application space contains several applications, including web applications, MySQL applications, and redis applications, and can span several namespace environments.

6. The method according to claim 6, characterized in that: An application will be published to different environments to generate an application instance.

7. The method according to claim 6, characterized in that An application instance in an environment has several deployments. One deployment corresponds to a deployment stateless workload or a statefulset stateful workload. Each deployment can have several releases, and a different release strategy can be selected for each release.

8. The method according to claim 7, characterized in that Each release generates a new application instance. This deployment defines the application template or image to be used.

Images