Kubernetes-based runtime deployment and scaling method for low-code application

Abstract

The present invention provides a Kubernetes-based runtime deployment and scaling method for a low-code application, and belongs to the technical field of code platforms. The method comprises: application runtime image building, runtime container deployment, runtime container image upgrading and runtime container termination; application artifact storage and containerized application deployment; and prometheus monitoring, Alertmanager alerting and application replica count control. With monitoring and alerting mechanisms, the Kubernetes-based runtime deployment and scaling method for a low-code application enables automated scaling and recovery with respect to application runtime, thus achieving efficient utilization of computing resources.

Description

A method for deploying and expanding low-code applications based on Kubernetes Technical Field

[0001] The present invention belongs to the field of code platform applications, and specifically relates to a method for running deployment and expansion of low-code applications based on Kubernetes. Background Art

[0002] After the designer has completed the presentation design, form design, rule design, and permission design of the low-code application, the application can be deployed locally, or locally deployed and run according to the application template. Usually, all applications share one running state. When some applications in the running state use a large amount of peak data or a large throughput, it will affect the use of other deployed applications in the same running state. At this time, it is necessary to add machines to horizontally expand the running state. The result is that some computing resources will be idle after the peak, resulting in a waste of computing resources.

[0003] Summary of the Invention

[0004] In response to the problems in the existing technology, the present invention discloses a method for deploying and expanding the running state of a low-code application based on Kubernetes. In conjunction with the monitoring and alarm mechanism, it can realize the automatic expansion and recovery method of the running state of the application, and can achieve efficient utilization of computing resources.

[0005] In order to achieve the above objectives, the technical solution adopted in this application is: a method for running-state deployment and expansion of low-code applications based on Kubernetes, including: application running-state image construction, running-state container deployment, running-state container image upgrade and running-state container destruction; design state management of application running-state Kubernetes container lifecycle by calling Helm interface through API; after the container is started, deploy the application according to the application product and manage the application lifecycle;

[0006] Application artifact storage and application container deployment: Application artifacts are stored in minio as files, and the database table information in the application artifacts is persisted and rendered on the server.

[0007] Prometheus monitoring, Alertmanager alarms, and application replica count control are configured. Kafka is configured as an alarm receiver. In the running container management service, if the throughput of a running container exceeds the set threshold, Helm is used to upgrade the container and increase or decrease the number of replicas.

[0008] Furthermore, the application runtime image is built, and the runtime is based on Springboot. The runtime basic image openjdk:8-jdk-alpine sets a series of environment variables through ENV; the Spring Boot jar package and startup script start.sh are copied to the image through ADD, the script is started, and the jar package startup item is configured; and the image is built using Dockerfile.

[0009] Furthermore, the running container deployment includes: providing HTTP services based on gin for the lifecycle management of the application running container, realizing the decoupling of the application running container from the application itself, and exposing three interfaces: container installation, container upgrade, and container uninstallation; using the helm go sdk to establish a connection with the Kubernates container, calling the cli.New() interface and the kube_config.yaml configuration file to create a client; creating an action through the action.NewInstall provided by the client, LocateChart loading the local chart package, and finally installing the running container through RunWithContext. Among them, cli is the helm service client, cli.New calls the New interface through the helm client; kube_config: Kubernetes configuration file, used to specify information for connecting to the Kubernetes cluster. LocateChart is a method in the Helm Go SDK used to load the local Chart package. RunWithContext is a method in the Helm Go SDK used to run a function in a specified context environment. This method requires a function and a context object to be passed in.

[0010] Furthermore, the running container image upgrade includes: first establishing a Kubernetes client action through action.NewUpgrade, and then loading the local chart package through LocateChart and client.Run method to update the container image or change the number of copies according to the request content.

[0011] Furthermore, the running container destruction includes: first, creating a Kubernetes client action through action.NewUninstall, then loading the local chart package through LocateChart, and finally uninstalling the running container through client.Run.

[0012] Furthermore, the prometheus monitoring includes a running state integrated monitoring component, which includes three core components: spring-boot-starter-actuator, micrometer-registry-prometheus, and micrometer-core, and performs monitoring.

[0013] Furthermore, the Alertmanager is an important component in the Prometheus ecosystem, mainly used to process alerts generated by Prometheus; the main functions of the Alertmanager include: grouping and merging alerts, routing alerts, deduplication, silencing and suppression, and sending notifications;

[0014] Configure alarm rules. The current alarm is based on the throughput of the current application. When the TPS is greater than 1000, the running CPU and database connection pool resources will cause access pressure on the node, causing other services to become unavailable.

[0015] Modify the Prometheus configuration file to point to the alarm rule file, restart the Prometheus service to make the file take effect, and use Kafka as the alarm receiver to receive alarms.

[0016] Furthermore, the control of the number of application copies is based on configuring Kafka as an alarm receiver, and consuming the alarm in the running container management service, parsing the message, and extracting the alarm indicator. In order to avoid invalid alarms affecting the number of running container copies, the indicator is compared with the configuration indicator. The purpose is to determine whether the throughput of the running container exceeds the threshold; when it is determined that the access threshold is exceeded, the container is upgraded through Helm, increasing the number of copies by one, or decreasing the number of copies by one. When the number of copies is 1, the alarm is ignored, and the alarms for the next 3 minutes are ignored.

[0017] Furthermore, the steps of storing the application product are as follows:

[0018] Step 1: Download and start the MinIO service on each node, use the minio server command, and specify parameters such as the access key and storage path;

[0019] Step 2: On any MinIO node, use the minio server to initialize the cluster.

[0020] Step 3: Create a bucket. Connect to any MinIO node and use the mc tool to create the required bucket. The bucket will be replicated to all nodes in the cluster.

[0021] Furthermore, the containerized deployment process of the application is as follows:

[0022] Process 1: Parse application artifacts and persist applications, menus, forms, processes, dictionaries, rules, and form contents;

[0023] Process 2: Generate the database table structure corresponding to the form;

[0024] Process 3: Parse the process definition, call the process service interface to create the process, and start the process instance.

[0025] Compared with the prior art, the advantages and positive effects of the present invention are:

[0026] The present invention discloses the method steps of application running state image construction, running state container deployment, running state container image upgrade and running state container destruction; application product storage and application containerized deployment; Prometheus monitoring, Alertmanager alarm and application copy number control. Based on the Kubernetes low-code application running state deployment and expansion method, the monitoring and alarm mechanism can realize the automatic expansion and recovery method of the application running state, and realize the efficient utilization of computing resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0028] FIG1 is a process diagram of the operational life cycle of the present invention;

[0029] FIG2 is a schematic diagram showing the contents of the application product of the present invention. DETAILED DESCRIPTION

[0030] In order to more clearly understand the above-mentioned objects, features and advantages of the present invention, the present invention is further described below in conjunction with the accompanying drawings and embodiments. It should be noted that the embodiments of the present application and the features therein can be combined with each other without conflict.

[0031] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention may also be implemented in other ways than those described herein. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0032] Explanation of terms:

[0033] Running state lifecycle: Running state is the basis for application operation. Running state is also an application. Its main functions are to parse application artifacts, persist application structure, parse processes, create process forces, create database table structures for forms, execute form rules, etc. Its lifecycle is roughly divided into three stages: running state image construction, running state containerized deployment, dynamic container upgrade, and container uninstallation.

[0034] In Example 1, as shown in Figures 1 and 2, the present application provides a method for deploying and expanding a low-code application in a running state based on Kubernetes, including:

[0035] Build a runtime image based on Spring Boot. The runtime image openjdk:8-jdk-alpine sets a series of environment variables through ENV. Copy the Spring Boot jar package and startup script start.sh to the image through ADD, start the script, and configure the jar package startup items. Use Dockerfile to build the image.

[0036] Deploy running containers and manage the lifecycle of running application containers. GIN-based HTTP services are provided to decouple running application containers from the application itself, exposing three interfaces: container installation, container upgrade, and container uninstallation. The helm go SDK is used to establish a connection with the Kubernetes container. A client is created by calling the cli.New() interface and the kube_config.yaml configuration file. An action is created using the action.NewInstall provided by the client, and the local chart package is loaded using LocateChart. Finally, the running container is installed using RunWithContext.

[0037] Upgrading a running container image is similar to installing a container. You first need to create a Kubernetes client action using action.NewUpgrade. Then, you load the local chart package using LocateChart and use the client.Run method to update the container image or change the number of replicas based on the requested content.

[0038] To destroy the running container, first use action.NewUninstall to create a Kubernetes client action, then use LocateChart to load the local chart package, and finally use client.Run to uninstall the running container.

[0039] The running state integrated monitoring components include three core components: spring-boot-starter-actuator, micrometer-registry-prometheus, and micrometer-core.

[0040] Alertmanager is an important component in the Prometheus ecosystem, mainly used to handle alerts generated by Prometheus. The main functions of Alertmanager include: grouping and merging alerts, routing alerts, deduplication, silencing and suppression, and notification sending.

[0041] Configure alarm rules. The current alarm is based on the throughput of the current application. When the TPS is greater than 1000, the running CPU and database connection pool resources will cause access pressure on the node, causing other services to become unavailable.

[0042] Modify the Prometheus configuration file to point to the alarm rule file, restart the Prometheus service to make the file take effect, and use Kafka as the alarm receiver to receive alarms;

[0043] Kafka is configured as an alarm receiver. The running container management service consumes the alarm, parses the message, and extracts the alarm indicator. To prevent invalid alarms from affecting the number of running container replicas, the indicator is compared with the configured indicator. The purpose is to determine whether the running container throughput exceeds the threshold. If it is determined that the access threshold is exceeded, the container is upgraded through Helm to increase or decrease the number of replicas. If the number of replicas is 1, the alarm is ignored and the alarms for the next 3 minutes are ignored.

[0044] 1. Build the application runtime image. The runtime is based on Springboot. The runtime basic image openjdk:8-jdk-alpine sets a series of environment variables through ENV, including Nacos, default database and other configurations. Copy the Spring Boot jar package and the startup script start.sh to the image through ADD, expose the 9015 port to the service in the container through EXPOSE-, and start the execution of the startup script through ENTRYPOINT-entry. The startup script start.sh is similar to the traditional Springboot project startup script. Configure the jar package startup items such as maximum heap, minimum heap, Spring activeprofile, nacos configuration center, nacos service registration and discovery address, dynamic data source, etc.

[0045] Use Dockerfile to build an image, which can be done through the docker build command;

[0046] docker build-t web-runtime-image: 1.0;

[0047] Use the docker tag command to add the domain name prefix of the private warehouse to the image;

[0048] docker tag web-runtime-image:1.0private.registry.com / web-runtime-image:1.0;

[0049] Use the docker login command to log in to the private warehouse;

[0050] docker login private.registry.com;

[0051] Use the docker push command to push the image to a private repository;

[0052] docker push private.registry.com / web-runtime-image:1.0.

[0053] 2. Runtime container deployment, Helm can help manage Kubernetes applications -

[0054] Helm Charts can define, install, and upgrade complex Kubernetes applications. Chart packages are easy to create, version, share, and distribute. A chart is a collection of files that describes a set of related Kubernetes resources. A single chart might be used to deploy a simple application.

[0055] Create a chart template through helm create and define the chart name and version in chart.yml;

[0056] helm create web-runtime-chart;

[0057] Edit deployment.yml to define the Deployment's name, label, and other metadata using metadata. spec.replicas defines the number of replicas, which can be configured using .Values. This article defaults to 1, but you can adjust it based on your business needs. Customize metadata selector to select Pods by label. Modify template to define the Pod template for the application's running state. spec.containers defines containers, specifying configurations such as the image, port, and health check.

[0058] Edit service.yml to define the basic information of the running service, including: defining the service entry for the deployed application. The service provides a unified entry to access the application's Pod; exposing the service port. The deployed application container port can be exposed through the service to provide external access; load balancing and traffic routing. The service can match a group of Pods through the label selector and distribute the traffic load balancing to these Pods; setting the access policy. You can define the clusterIP type or externalIPs of the service to control the accessible scope of the service.

[0059] This article uses GIN to provide HTTP services for the lifecycle management of application runtime containers. This decouples application runtime containerization from the application itself and exposes three interfaces: container installation, container upgrade, and container uninstallation. This article uses the Helm Go SDK to establish a connection to a Kubernetes container, creating a client by calling the cli.New() interface and the kube_config.yaml configuration file.

[0060] Create an action through action.NewInstall provided by the client, then load the local chart package through LocateChart, and finally install it for the running container through RunWithContext.

[0061] 3. Upgrading the running container image is similar to installing the container. You first need to create a Kubernetes client action through action.NewUpgrade. Then, load the local chart package through LocateChart and use the client.Run method to update the container image or change the number of replicas based on the requested content.

[0062] 4. To destroy the running container, first use action.NewUninstall to create a Kubernetes client action, then use LocateChart to load the local chart package, and finally use client.Run to uninstall the running container.

[0063] Application artifacts include content, which mainly includes document descriptions of the application itself, including menus, forms, processes, rules, permissions, and other data. The specific content is as follows:

[0064] (1) Application artifacts contain basic application information, including application name, version, description, status, icon, creator, creation time, etc.

[0065] (2) Application menu, menu name, level, content, creator, and creation time.

[0066] (3) Form information includes form type, form status, description, creator, creation time, etc.

[0067] (4) Form rules: the linkage between forms and other forms or the external database, and the method of interacting with third-party APIs, mainly including the form ID pointing to the form, rule content, creator, and creation time.

[0068] (5) Form content, form ID, content, creator, creation time, where content is the front-end display of the form content expressed in JSON, and the running front-end renders according to the content;

[0069] (6) The materialized information table includes the field name, field type, field description, default value, sorting, component code, whether it is the primary key, whether to create an index, whether it is one, whether it is allowed to be empty, and options after the form is materialized.

[0070] (7) Flow table definition, including form ID, content, creator, and creation time.

[0071] (8) Form data access permission control, including role ID, form ID pointing to the form, creator, and creation time.

[0072] All of the above content is stored in json files.

[0073] Application product storage: Application products are stored in minio as files. For high availability, this article deploys Minio in a distributed manner on four nodes. The steps are as follows:

[0074] Step 1: Download and start the MinIO service on each node, use the minio server command, and specify parameters such as the access key and storage path.

[0075] Step 2: On any MinIO node, use the minio server to initialize the cluster.

[0076] Step 3: Create a bucket. Connect to any MinIO node and use the mc tool to create the required bucket. The bucket will be replicated to all nodes in the cluster.

[0077] Application container deployment. The application container deployment process is to persist and render the application, menus, forms, processes, dictionaries, rules, form content, and database table information after form materialization on the server. The main process is as follows:

[0078] Process 1: Parse application artifacts and persist applications, menus, forms, processes, dictionaries, rules, and form contents.

[0079] Process 2: Generate the database table structure corresponding to the form.

[0080] Process 3: Parse the process definition, call the process service interface to create the process, and start the process instance.

[0081] Monitoring, alarming, multi-replication, Prometheus monitoring, and runtime integrated monitoring components include three core components: spring-boot-starter-actuator, micrometer-registry-prometheus, and micrometer-core. These three components are used for monitoring indicator tracking, collection, and exposure, respectively.

[0082] Expose monitoring indicators and change the indicator access path to " / manage". The main purpose of changing the path is to avoid some malicious attacks. The path can be customized according to the characteristics of your own business.

[0083] management:

[0084] endpoints:

[0085] web:

[0086] exposure:

[0087] include:"*"

[0088] base-path:" / manage"

[0089] To install Prometheus, download the binary installation package and install it. However, since the early configuration requires frequent restarts of the Prometheus service, it is recommended to set a system startup item for it in the / etc / systemd / system directory;

[0090] [Unit]

[0091] Description=Prometheus Monitoring

[0092] Documentation=https: / / prometheus.io / docs / introduction / overview /

[0093] After=network-online.target

[0094] [Service]

[0095] User=prometheus

[0096] Restart=on-failure

[0097] ExecStart= / path / to / prometheus\

[0098] --config.file= / path / to / prometheus.yml\

[0099] --storage.tsdb.path= / path / to / prometheus / data

[0100] [Install]

[0101] WantedBy=multi-user.target

[0102] Alertmanager alarm, Alertmanager is an important component in the Prometheus ecosystem, mainly used to handle alerts generated by Prometheus. The main functions of Alertmanager include: grouping and merging alerts, routing alerts, deduplication, silencing and suppression, and notification sending.

[0103] Configure alarm rules. In this embodiment, the alarm is based on the throughput of the current application. When the TPS is greater than 1000, the running CPU and database connection pool resources will cause access pressure on the node, causing other services to become unavailable.

[0104] Modify the Prometheus configuration file to point to the alarm rule file and restart the Prometheus service for the file to take effect.

[0105] Use Kafka as an alarm receiver to receive alarms.

[0106] To control the number of application replicas, Kafka is configured as the alarm receiver in the Alertmanager alarm. At the same time, the alarm is consumed in the running container management service, the message is parsed, and the alarm indicator is extracted. To prevent invalid alarms from affecting the number of running container replicas, the indicator is compared with the configured indicator. The purpose is to determine whether the running container throughput exceeds the threshold.

[0107] When it is determined that the access threshold is exceeded, the container is upgraded through Helm to increase or decrease the number of replicas. When the number of replicas is 1, the alarm is ignored and the alarms for the next 3 minutes are ignored. The access threshold is set by the system management based on infrastructure conditions.

[0108] This article discloses a Kubernetes-based application runtime deployment method. Combined with monitoring and alarm mechanisms, it can realize the automated expansion and recovery of application runtimes, and achieve efficient utilization of computing resources.

[0109] In embodiment 2, the present invention provides a device for running deployment and expansion of a Kubernetes low-code application, comprising:

[0110] The application runtime image building module uses Springboot as the foundation. The runtime base image, openjdk:8-jdk-alpine, sets a series of environment variables through ENV. The Spring Boot jar package and startup script, start.sh, are copied to the image through ADD. The script is started and the jar package startup items are configured. The image is built using Dockerfile.

[0111] The running container deployment module includes: providing HTTP services to the outside world based on GIN for the lifecycle management of the application running container, decoupling the application running container from the application itself, and exposing three interfaces: container installation, container upgrade, and container uninstallation. It also uses the helm go sdk to establish a connection with the Kubernetes container, calls the cli.New() interface and the kube_config.yaml configuration file to create a client, creates an action through the action.NewInstall provided by the client, loads the local chart package through LocateChart, and finally installs the running container through RunWithContext.

[0112] The runtime container image upgrade module, similar to container installation, requires first creating a Kubernetes client action through action.NewUpgrade. Then, using the LocateChart method to load the local chart package and client.Run, updates the container image or changes the number of replicas based on the requested content.

[0113] The running container destruction module first creates a Kubernetes client action through action.NewUninstall, then loads the local chart package through LocateChart, and finally uninstalls the running container through client.Run.

[0114] The specific settings of the above-mentioned application running state image construction module, running state container deployment module, running state container image upgrade module and running state container destruction module correspond to the method of Example 1.

[0115] Embodiment 3, a computer-readable storage medium includes a stored program, wherein when the program is running, the device where the computer-readable storage medium is located is controlled to execute the method of embodiment 1.

[0116] In a fourth embodiment, the present invention provides an electronic device, comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the electronic device is triggered to execute the method of the first embodiment;

[0117] The electronic device may include a processor, a memory, and a communication unit. These components communicate via one or more buses. Those skilled in the art will appreciate that the structure of the electronic device does not limit the embodiments of the present invention; it may be a bus structure, a star structure, or a combination of certain components or a different arrangement of components.

[0118] The communication unit is configured to establish a communication channel so that the electronic device can communicate with other devices, receive user data sent by other devices, or send user data to other devices.

[0119] The processor is the control center of the electronic device, which uses various interfaces and lines to connect the various parts of the entire electronic device, and executes various functions of the electronic device and / or processes data by running or executing software programs and / or modules stored in the memory, and calling data stored in the memory. The processor can be composed of an integrated circuit (IC), for example, it can be composed of a single packaged IC, or it can be composed of multiple packaged ICs with the same or different functions. For example, the processor can only include a central processing unit (CPU). In an embodiment of the present invention, the CPU can be a single computing core or multiple computing cores.

[0120] The memory is used to store the execution instructions of the processor. The memory can be implemented by any type of volatile or non-volatile storage device or a combination of them, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0121] When the execution instructions in the memory are executed by the processor, the electronic device is enabled to execute part or all of the steps of embodiment 1.

[0122] The above description is merely a preferred embodiment of the present invention and does not limit the present invention in any other form. Any technician familiar with the present invention may use the technical content disclosed above to change or modify it into an equivalent embodiment with equivalent changes for application in other fields. However, any simple modification, equivalent change and modification made to the above embodiment based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of protection of the technical solution of the present invention.

Claims

1. A method for deploying and expanding low-code applications in running state based on Kubernetes, characterized in that: include: Application running image construction, running container deployment, running container image upgrade and running container destruction; In the design state, the Helm interface is called through the API to manage the life cycle of the Kubernetes container in the running state of the application. After the Kubernetes container is started, the application is deployed according to the application artifacts and the application life cycle is managed. Application artifact storage and application container deployment: Application artifacts are stored in minio as files, and the database table information in the application artifacts is persisted and rendered on the server. Prometheus monitoring, Alertmanager alarms, and application replica count control are configured. Kafka is configured as an alarm receiver. In the running container management service, if the throughput of a running container exceeds the set threshold, Helm is used to upgrade the container and increase or decrease the number of replicas. The prometheus monitoring includes a running state integrated monitoring component, which includes three core components: spring-boot-starter-actuator, micrometer-registry-prometheus, and micrometer-core, and performs monitoring; The Alertmanager alarm is an important component in the Prometheus ecosystem, mainly used to process the alarms generated by Prometheus. The main functions of the Alertmanager alarm include: grouping and merging alarms, routing alarms, deduplication, silencing and suppressing, and sending notifications. Configure alarm rules. The current alarm is based on the throughput of the current application. When the TPS is greater than 1000, the running CPU and database connection pool resources will cause access pressure on the node, causing other services to become unavailable. Modify the Prometheus configuration file to point to the alarm rule file, restart the Prometheus service to make the file take effect, and use Kafka as the alarm receiver to receive alarms; The application replica number control is based on configuring Kafka as an alarm receiver. At the same time, the alarm is consumed in the running container management service, the message is parsed, and the alarm indicator is extracted. In order to prevent invalid alarms from affecting the number of running container replicas, the indicator is compared with the configuration indicator. Its purpose is to determine whether the running container throughput exceeds the threshold; when it is determined that the access threshold is exceeded, the container is upgraded through Helm to increase or decrease the number of replicas. When the number of replicas is 1, the alarm is ignored.

2. A method for deploying and expanding low-code applications in a running state based on Kubernetes according to claim 1, characterized in that: The application runtime image is built, and the runtime is based on Springboot. The runtime basic image openjdk:8-jdk-alpine sets a series of environment variables through ENV; the Spring Boot jar package and startup script start.sh are copied to the image through ADD, the script is started, and the jar package startup items are configured; and the image is built using Dockerfile.

3. A method for deploying and expanding low-code applications in a running state based on Kubernetes according to claim 1, characterized in that: The running container deployment includes: providing HTTP services based on GIN for the lifecycle management of the application running container, decoupling the application running container from the application itself, and exposing three interfaces: container installation, container upgrade, and container uninstallation; using the helm go sdk to establish a connection with the Kubernetes container, calling the cli.New() interface and the kube_config.yaml configuration file to create a client; creating an action through the action.NewInstall provided by the client, loading the local chart package through LocateChart, and finally installing the running container through RunWithContext.

4. A method for deploying and expanding low-code applications in a running state based on Kubernetes according to claim 1, characterized in that: The running container image upgrade includes: first establishing a Kubernetes client action through action.NewUpgrade, then loading the local chart package through LocateChart and using the client.Run method to update the container image or change the number of copies according to the request content.

5. A method for deploying and expanding low-code applications in running state based on Kubernetes according to claim 1, characterized in that: The running container destruction includes: first, creating a Kubernetes client action through action.NewUninstall, then loading the local chart package through LocateChart, and finally uninstalling the running container through client.Run.

6. A method for deploying and expanding low-code applications in a running state based on Kubernetes according to claim 1, characterized in that: The steps for storing the application product are as follows: Step 1: Download and start the MinIO service on each node, use the minio server command, and specify the access key and storage path parameters; Step 2: On any MinIO node, use the minio server to initialize the cluster. Step 3: Create a bucket, connect to any MinIO node, and use the mc tool to create the required bucket; Buckets are replicated to all nodes in the cluster.

7. A method for deploying and expanding low-code applications in running state based on Kubernetes according to claim 1, characterized in that: The containerized deployment process of the application is as follows: Process 1: Parse application artifacts and persist applications, menus, forms, processes, dictionaries, rules, and form contents; Process 2: Generate the database table structure corresponding to the form; Process 3: Parse the process definition, call the process service interface to create the process, and start the process instance.

Images