A method and system for converting a low-code deployment configuration to a kubernetes standard resource file

Abstract

This invention discloses a method and system for converting low-code deployment configurations to Kubernetes standard resource files, relating to the fields of cloud computing and software engineering technology. When low-code deployment configuration data is received on the low-code operation page, the data is preprocessed to obtain corresponding target field data. Based on a preset low-code rule base, a corresponding intermediate deployment model is generated according to the target field data. The intermediate deployment model is then rendered according to a preset resource file template to obtain the corresponding Kubernetes standard resource file, which is then displayed on the low-code operation page. This solves the technical problem that existing Kubernetes implementations place high technical requirements on users, making it difficult to meet the needs of non-professional users.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing and software engineering technology, and in particular to a method and system for converting low-code deployment configurations to Kubernetes standard resource files. Background Technology

[0002] In recent years, cloud-native technologies have become a core driver of enterprise digital transformation, and Kubernetes, as the de facto standard for container orchestration, is widely used in scenarios such as microservices, DevOps, and serverless. However, Kubernetes resource configuration files (such as YAML / JSON) are typically quite complex, involving numerous API objects (such as Deployment, Service, Ingress, etc.), requiring users to have advanced operational and development capabilities. This complexity hinders the use of Kubernetes by non-professional developers (such as business analysts, novice operations personnel, etc.), thus necessitating a method that lowers the barrier to entry for Kubernetes while ensuring its standardization and scalability. Summary of the Invention

[0003] This invention provides a method and system for converting low-code deployment configurations to Kubernetes standard resource files, solving the technical problem that existing Kubernetes systems have high technical requirements for users and are difficult to meet the needs of non-professional users.

[0004] The first aspect of this invention provides a method for converting low-code deployment configurations to Kubernetes standard resource files, comprising:

[0005] When low-code deployment configuration data is received on the low-code operation page, the low-code deployment configuration data is preprocessed to obtain the corresponding target field data;

[0006] Based on a pre-defined low-code rule base, a corresponding intermediate deployment model is generated according to the target field data;

[0007] The intermediate deployment model is rendered according to the preset resource file template to obtain the corresponding Kubernetes standard resource file and displayed on the low-code operation page.

[0008] Optionally, the step of preprocessing the low-code deployment configuration data to obtain the corresponding target field data includes:

[0009] The low-code deployment configuration data is converted to obtain the corresponding structured data.

[0010] The structured data is then processed to standardize the field format, resulting in the corresponding standardized field data.

[0011] The standardized field data is then filled with default values ​​to obtain the corresponding target field data.

[0012] Optionally, the target field data includes multiple form fields, and the step of generating a corresponding intermediate deployment model based on the target field data according to a preset low-code rule base includes:

[0013] Each of the form fields is destructured to obtain multiple target form fields;

[0014] Each of the target form fields is used to retrieve a preset low-code rule library and match the corresponding low-code native field path;

[0015] When the target form field does not match the low-code native field, a mapping operation is performed on the target form field to obtain the corresponding low-code native field path;

[0016] Each target form field is formatted according to its corresponding low-code native field path to obtain multiple low-code native fields.

[0017] An intermediate deployment model is generated using each of the aforementioned low-code native fields.

[0018] Optionally, the step of destructuring each of the form fields to obtain multiple target form fields includes:

[0019] Determine whether each of the form fields is a composite field;

[0020] If the form field is a composite field, then the form field is split to obtain multiple target form fields;

[0021] If the form field is not a composite field, then the form field is determined as the target form field.

[0022] Optionally, the step of generating an intermediate deployment model using each of the low-code native fields includes:

[0023] Based on the field type of each of the low-code native fields, each of the low-code native fields is injected into a preset initial intermediate deployment model in layers to obtain the corresponding first deployment model;

[0024] The first deployment model is processed by field order normalization to obtain the corresponding second deployment model;

[0025] The second deployment model is then processed by completing default values ​​and cleaning up empty fields to obtain the corresponding third deployment model;

[0026] The third deployment model is semantically validated to obtain the corresponding intermediate deployment model.

[0027] Optionally, the step of performing semantic verification on the third deployment model to obtain the corresponding intermediate deployment model includes:

[0028] Determine whether each model field in the third deployment model meets the preset verification conditions;

[0029] When all the model fields meet the verification conditions, the third deployment model is determined as the intermediate deployment model.

[0030] Optionally, it also includes:

[0031] If the model field does not meet the verification conditions, the model field will be identified as an abnormal field.

[0032] The aforementioned exception fields are used as exception information, and the exception information is displayed on the low-code operation page.

[0033] Optionally, the step of rendering the intermediate deployment model according to a preset resource file template to obtain the corresponding Kubernetes standard resource file and displaying it on the low-code operation page includes:

[0034] The intermediate deployment model is rendered according to the preset resource file template to obtain the corresponding Kubernetes standard resource file;

[0035] Load the Kubernetes standard resource file into the feedback component of the low-code operation page;

[0036] The feedback component is rendered to generate a low-code operation page containing the Kubernetes standard resource files.

[0037] A second aspect of this invention provides a system for converting low-code deployment configurations to Kubernetes standard resource files, comprising:

[0038] The response module is used to preprocess the low-code deployment configuration data when it receives low-code deployment configuration data on the low-code operation page to obtain the corresponding target field data.

[0039] The mapping module is used to generate a corresponding intermediate deployment model based on the target field data, according to a preset low-code rule base.

[0040] The rendering module is used to render the intermediate deployment model according to the preset resource file template, obtain the corresponding Kubernetes standard resource file, and display it on the low-code operation page.

[0041] A third aspect of the present invention provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to perform the steps of the method for converting low-code deployment configuration to Kubernetes standard resource files as described in any of the preceding claims.

[0042] As can be seen from the above technical solutions, the present invention has the following advantages:

[0043] This invention preprocesses low-code deployment configuration data received on the low-code operation page to obtain corresponding target field data. Based on a preset low-code rule base, it generates a corresponding intermediate deployment model according to the target field data. A preset resource file template renders the intermediate deployment model to obtain the corresponding Kubernetes standard resource file, which is then displayed on the low-code operation page. This automatically converts user-input low-code deployment configuration data into Kubernetes standard resource files, reducing the technical requirements for Kubernetes. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is a flowchart illustrating the steps of a method for converting low-code deployment configuration to Kubernetes standard resource files, as provided in Embodiment 1 of the present invention.

[0046] Figure 2 This is a flowchart illustrating the steps of a method for converting low-code deployment configuration to Kubernetes standard resource files, as provided in Embodiment 2 of the present invention.

[0047] Figure 3 This is a structural block diagram of a system for converting low-code deployment configuration to Kubernetes standard resource files, provided in Embodiment 3 of the present invention.

[0048] Figure 4 This is a structural block diagram of an electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

[0049] This invention provides a method and system for converting low-code deployment configurations to Kubernetes standard resource files, which addresses the technical problem that existing Kubernetes systems have high technical requirements for users and are difficult to meet the needs of non-professional users.

[0050] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0051] Please see Figure 1 , Figure 1 This is a flowchart illustrating the steps of a method for converting low-code deployment configuration to Kubernetes standard resource files, as provided in Embodiment 1 of the present invention.

[0052] This invention provides a method for converting low-code deployment configurations to Kubernetes standard resource files, comprising:

[0053] Step 101: When low-code deployment configuration data is received on the low-code operation page, the low-code deployment configuration data is preprocessed to obtain the corresponding target field data.

[0054] Low-code deployment configuration data refers to the form configuration data entered by the user. The form configuration data includes, but is not limited to, application name, namespace, image address, number of replicas, container port, environment variables, resource limits, mounted volumes, service type (ClusterIP, NodePort), Ingress, probes, startup commands, etc.

[0055] The target field data refers to the standardized deployment data obtained after format validation, default value completion, field cleaning and normalization.

[0056] In this embodiment of the invention, when low-code deployment configuration data is received on the low-code operation page, the low-code deployment configuration data is preprocessed (i.e., format validation, default value completion, field cleaning and normalization) to obtain the corresponding target field data.

[0057] Step 102: Based on the preset low-code rule library, generate the corresponding intermediate deployment model according to the target field data.

[0058] The intermediate deployment model refers to a structured data model generated based on target field data and a low-code rule base, which sits between low-code configuration and Kubernetes standard resource files. Its structure is logically aligned with the Kubernetes resource system and contains standardized configuration information for modules such as Deployment, Service, and PVC. It serves as a "bridge" connecting low-code configuration and native Kubernetes resources.

[0059] In an embodiment of the present invention,

[0060] Step 103: Render the intermediate deployment model according to the preset resource file template to obtain the corresponding Kubernetes standard resource file and display it on the low-code operation page.

[0061] Resource file templates refer to pre-built template files that conform to the syntax specifications of Kubernetes standard resource files (YAML format). They contain templates for various Kubernetes resources such as Deployment, Service, ConfigMap, Ingress, and PVC, and have built-in field placeholders, conditional rendering logic, and format specifications. They are the basic carrier for generating standard resource files.

[0062] Kubernetes standard resource files refer to YAML format files that conform to the Kubernetes resource definition specification. They contain resource configuration information (such as Pod scheduling rules, service exposure methods, storage mounting policies, etc.) that can be directly recognized and executed by the Kubernetes cluster. They can be directly applied to cluster deployment through the kubectl command or the Kubernetes API.

[0063] In this embodiment of the invention, the template engine injects the configuration data of each module in the intermediate deployment model into the variable placeholders of the corresponding resource file template according to the field mapping relationship (for example, filling the "image" field value in the model into the placeholder of "spec.template.spec.containers[0].image" in the template, and filling the "replicas" field value into the placeholder of "spec.replicas"). During the data injection process, the template engine will synchronously execute the conditional rendering logic built into the resource file template (such as automatically enabling the Ingress rule-related code block in the template when there is an Ingress configuration in the model, and skipping the code block if there is no Ingress configuration) and the format validation logic (such as validating whether the indentation format and field syntax of the injected YAML file conform to the Kubernetes specification). If the validation finds that the format is abnormal, it will automatically adjust according to the correction rules built into the resource file template (such as completing the missing indentation and correcting the field value format). After completing the data injection and format validation, the template engine generates a complete Kubernetes standard resource file and displays it on the low-code operation page.

[0064] In this embodiment of the invention, when low-code deployment configuration data is received on the low-code operation page, the low-code deployment configuration data is preprocessed to obtain corresponding target field data. Based on a preset low-code rule base, a corresponding intermediate deployment model is generated according to the target field data. A preset resource file template is used to render the intermediate deployment model to obtain the corresponding Kubernetes standard resource file, which is then displayed on the low-code operation page. This automatically converts user-input low-code deployment configuration data into Kubernetes standard resource files, reducing the technical requirements of Kubernetes for users.

[0065] Please see Figure 2 , Figure 2 This is a flowchart illustrating the steps of a method for converting low-code deployment configuration to Kubernetes standard resource files, as provided in Embodiment 2 of the present invention.

[0066] This invention provides a method for converting low-code deployment configurations to Kubernetes standard resource files, comprising:

[0067] Step 201: When low-code deployment configuration data is received on the low-code operation page, the low-code deployment configuration data is preprocessed to obtain the corresponding target field data, which includes multiple form fields.

[0068] Further, step 201 includes the following sub-steps:

[0069] S11. Convert the low-code deployment configuration data to obtain the corresponding structured data.

[0070] In this embodiment of the invention, the low-code deployment configuration data is converted into a structured intermediate data format (such as JSON) while retaining the original data types (strings, numbers, booleans, lists) to obtain the corresponding structured data.

[0071] S12. Standardize the field format of the structured data to obtain the corresponding standardized field data.

[0072] In this embodiment of the invention, the structured data is subjected to field format standardization processing (i.e., string type standardization, numeric type standardization, resource unit standardization, JSON structure standardization, and structured object standardization) to obtain the corresponding standardized field data.

[0073] It's important to note that string type standardization refers to converting non-standard representations of string fields in structured data (such as custom descriptions and redundant characters) into Kubernetes-compliant enumeration values ​​or standard representations, removing redundant content, and ensuring that the field meaning is unique and conforms to K8s field requirements. Numeric type standardization refers to converting non-standard formats of numeric fields in structured data (such as those with unit descriptions or Chinese numerals) into pure numeric formats and validating whether the values ​​conform to the valid range of K8s fields (such as port numbers 0-65535) to ensure that the values ​​are compliant and usable. Resource unit standardization refers to converting non-standard units (such as "core" or "G") of resource fields such as "CPU" and "memory" in structured data into standard units supported by Kubernetes (such as CPU without units, memory "Gi" or "Mi") to ensure that resource configurations can be correctly parsed and allocated by the K8s cluster. JSON structure standardization refers to correcting JSON format fields in structured data that are poorly nested and have inconsistent key names into standard JSON structures with key names conforming to K8s specifications, clear hierarchy, and correct format, avoiding subsequent configuration parsing failures due to JSON format issues. Structured object standardization refers to integrating the scattered standardized fields in structured data into objects with specific levels and relationships (such as "containers" and "ports" objects in K8s) according to the logical relationship between Kubernetes resources, ensuring that the data structure is aligned with the K8s resource definition logic.

[0074] S13. Perform default value completion on the standardized field data to obtain the corresponding target field data.

[0075] Default value completion refers to the process of automatically filling in compliant default values ​​for missing required fields, non-required fields, and related fields in standardized field data based on a preset default value rule library, and verifying the consistency of the configuration logic after completion to ensure that the final data has no missing fields and no logical conflicts.

[0076] In this embodiment of the invention, the standardized field data is processed to complete the default values ​​based on a preset default value rule library to obtain the corresponding target field data.

[0077] It should be noted that the default value rule library refers to a pre-built set of rules that stores the default values ​​of fields related to Kubernetes deployment. It includes basic default values ​​(general default configurations applicable to all scenarios) and scenario-based default values ​​(customized default configurations for different environments such as development, testing, and production). It also has built-in field association logic and conflict reconciliation rules.

[0078] Step 202: Deconstruct each form field to obtain multiple target form fields.

[0079] Further, step 202 includes the following sub-steps:

[0080] S21. Determine whether each form field is a composite field.

[0081] In this embodiment of the invention, it is determined whether each form field is a composite field (e.g., "resource limit" includes CPU and memory).

[0082] S22. If the form field is a composite field, then the form field is split to obtain multiple target form fields.

[0083] In this embodiment of the invention, when a form field is a composite field, the form field is split into multiple target form fields.

[0084] S23. If the form field is not a composite field, then the form field will be determined as the target form field.

[0085] In this embodiment of the invention, when a form field is not a composite field, the form field is determined as the target form field.

[0086] Step 203: Retrieve the preset low-code rule library using each target form field and match the corresponding low-code native field path.

[0087] A low-code rule library refers to a pre-built collection of rules that store deployment configurations for low-code platforms. It includes core components such as field mapping index tables, semantic matching algorithms, and path correction logic, and is used to match target form fields with native low-code field paths.

[0088] Low-code native field paths refer to hierarchical path expressions in Kubernetes (K8s) standard resource files (usually in YAML format) used to locate a specific configuration field. Their structure is fully aligned with the field nesting logic of the resource file, and can accurately describe the position of the field in the K8s resource object hierarchy.

[0089] In this embodiment of the invention, each target form field is used to retrieve the path of each low-code native field in the preset low-code rule library and match the corresponding low-code native field path.

[0090] Step 204: When the target form field does not match the low-code native field, perform a mapping operation on the target form field to obtain the corresponding low-code native field path.

[0091] In this embodiment of the invention, when a target form field does not match a low-code native field, a mapping operation is performed on the target form field to obtain the corresponding low-code native field path. For example, if no corresponding low-code native field is found for the target form field (such as a user-defined extended field), a mapping operation is performed on the target form field based on the default mapping logic to obtain the corresponding low-code native field path (such as mapping to a metadata.annotations custom annotation field).

[0092] Step 205: Convert the format of each target form field according to the corresponding low-code native field path of each target form field to obtain multiple low-code native fields.

[0093] Low-code native fields refer to fields obtained after format conversion of target form fields, whose format is fully adapted to the path requirements of low-code native fields, containing compliant configuration values ​​and correct structure, and can be directly used to assemble structured data for intermediate deployment models.

[0094] In this embodiment of the invention, each target form field is format-converted according to its corresponding low-code native field path to obtain multiple low-code native fields. For example, for a single target form field, the hierarchical structure and field attributes of its corresponding low-code native field path are parsed (e.g., the path "spec.template.spec.containers[0].resources.limits.memory" indicates that the field belongs to the container resource limit level, and the attribute is "memory unit related value"). Then, the preset format conversion rules are matched according to the field attribute (e.g., memory-type fields need to convert user input formats such as "2G" and "512M" to the K8s standard "2Gi" and "512Mi", and port-type fields need to convert the string format "8080" to the integer "8080"). Then, the format conversion operation is performed. If the target form field is an array-type configuration (e.g., "multi-port mapping"), the multiple port data input by the user are split into array elements according to the array identifier in the native field path (e.g., "ports[*]"), and filled into the corresponding array nodes in sequence according to the path hierarchy. If the field involves a key-value pair structure (such as "environment variables"), the user-input "key=value" format data is split into a standard key-value pair structure according to the "name-value" key naming convention corresponding to the native field path (such as "env[0].name" and "env[0].value"). After the conversion, the format of the converted field is further verified to ensure that it completely matches the field type requirements of the low-code native field path (such as the "replicas" path requiring integers, which needs to be confirmed that the converted data is not a string). If there is a mismatch, a secondary correction is triggered (such as forcibly converting the string "3" to the integer 3), and finally the low-code native field corresponding to each target form field is obtained.

[0095] Step 206: Generate an intermediate deployment model using each low-code native field.

[0096] Furthermore, step 206 includes the following sub-steps:

[0097] S31. Based on the field type of each low-code native field, inject each low-code native field into the preset initial intermediate deployment model in layers to obtain the corresponding first deployment model.

[0098] The initial intermediate deployment model refers to a pre-built empty structure or basic structure model that conforms to the Kubernetes resource logic. It contains a hierarchical framework of Kubernetes core resources (such as Deployment and Service) (such as hierarchical nodes such as "spec", "spec.template", and "spec.template.spec"), but does not populate specific configuration values. It is the basic carrier for field injection.

[0099] In this embodiment of the invention, based on the field type of each low-code native field, each low-code native field is injected into a preset initial intermediate deployment model in layers (that is, according to the field type of the low-code native field, the field value is injected into the corresponding level node of the initial intermediate deployment model respectively, and different types of fields adopt an appropriate injection method (such as directly filling basic types and appending elements to array types)) to obtain the corresponding first deployment model.

[0100] It should be noted that the injection methods for different types of fields are as follows: For basic data type fields, the field value is directly filled into the field position of the corresponding level node (e.g., injecting the integer "3" into the "spec.replicas" node). For array type fields, it is first checked whether the target level node already has an array structure. If it exists, the field value is appended to the array as a new element (e.g., appending "port:8080" to the "spec.ports" array). If it does not exist, the array is created and the field value is filled in. For key-value pair type fields, the key-value pair data of the field is injected into the target node according to the "key name matching" principle (e.g., injecting "name:DB_HOST,value:localhost" into the key-value pair node under "spec.template.spec.containers[0].env").

[0101] S32. Perform field order normalization on the first deployment model to obtain the corresponding second deployment model.

[0102] In this embodiment of the invention, the field order of the first deployment model is normalized (i.e., the field order of each level node in the first deployment model is adjusted according to the preset Kubernetes field order specification) to obtain the corresponding second deployment model.

[0103] It should be noted that the Kubernetes field order specification library refers to a pre-built collection that stores standard field sorting rules for different Kubernetes resource types (Deployment, Service, etc.). It is formulated based on the official Kubernetes documentation and deployment best practices, and clarifies the recommended order of fields under each resource model.

[0104] S33. Perform default value completion and empty field cleanup on the second deployment model to obtain the corresponding third deployment model.

[0105] In this embodiment of the invention, the second deployment model is processed by default value completion (i.e., traversing the null and non-mandatory fields of the second deployment model, matching and filling the corresponding default values ​​from the deployment model default value library) and empty field cleanup (i.e., identifying fields in the second deployment model with values ​​of null, empty strings or empty arrays, determining whether they are unnecessary configurations, and deleting unnecessary empty fields) to obtain the corresponding third deployment model.

[0106] It should be noted that the deployment model default value library is a pre-built set of rules that stores the default values ​​of non-mandatory fields for various Kubernetes resource types. It is formulated based on the official Kubernetes recommended configuration and industry deployment practices and is used to automatically fill in compliant values ​​for missing non-mandatory fields in the model.

[0107] S34. Perform semantic verification on the third deployment model to obtain the corresponding intermediate deployment model.

[0108] Furthermore, S34 includes the following sub-steps:

[0109] S341. Determine whether each model field in the third deployment model meets the preset verification conditions.

[0110] Validation conditions refer to the predefined compliance requirements for each model field in the field validation rule base. These are categorized by field type, including numerical range, format specifications, correlation matching, and resource existence, and are the core standards for determining field compliance. For example, the validation condition for the basic field "spec.replicas" is "a non-negative integer not greater than the cluster resource quota limit," the validation condition for the correlation field "spec.selector" is "there is at least one matching label with spec.template.metadata.labels," and the validation condition for the resource dependency field "spec.volumes.persistentVolumeClaim.claimName" is "the corresponding PVC name already exists in the current namespace."

[0111] Model fields refer to the fields in the third-party deployment model.

[0112] S342. When all model fields meet the validation conditions, the third deployment model is determined as the intermediate deployment model.

[0113] In this embodiment of the invention, it is determined whether each model field in the third deployment model meets the preset verification conditions. When all model fields meet the verification conditions, the third deployment model is determined to be an intermediate deployment model through field-level verification.

[0114] S343. When a model field does not meet the validation conditions, the model field is identified as an abnormal field.

[0115] S344. Use each exception field as exception information and display the exception information on the low-code operation page.

[0116] In this embodiment of the invention, when a model field does not meet the verification conditions, the model field is identified as an abnormal field, each abnormal field is used as abnormal information, and the abnormal information is displayed on the low-code operation page to guide the user to correct the low-code deployment configuration data.

[0117] Step 207: Render the intermediate deployment model according to the preset resource file template to obtain the corresponding Kubernetes standard resource file and display it on the low-code operation page.

[0118] Furthermore, step 207 includes the following sub-steps:

[0119] S41. Render the intermediate deployment model according to the preset resource file template to obtain the corresponding Kubernetes standard resource file.

[0120] In this embodiment of the invention, a preset resource file template is used to render the intermediate deployment model to obtain the corresponding Kubernetes standard resource file.

[0121] S42, A feedback component that loads Kubernetes standard resource files into a low-code action page.

[0122] Feedback components refer to functional modules in the low-code platform's user interface used to display and interact with Kubernetes standard resource files. Their core function is to provide feedback to users on the generation results of the resource files.

[0123] S43, Render Feedback Component, generates a low-code operation page containing Kubernetes standard resource files.

[0124] In this embodiment of the invention, Kubernetes standard resource files are loaded into the feedback component of the low-code operation page. The feedback component is rendered to generate a low-code operation page containing the Kubernetes standard resource files, which is then provided to the user for preview, download, or deployment submission.

[0125] It's worth mentioning that the low-code platform's user interface also includes features such as multi-resource file export: packaging and exporting multiple resources as a zip file; rendering history: retaining versions after each rendering, supporting comparison and rollback; and visual deployment: the platform can connect to the Kubernetes API, directly applying YAML to the target cluster.

[0126] In this embodiment of the invention, when low-code deployment configuration data is received on the low-code operation page, the low-code deployment configuration data is preprocessed to obtain corresponding target field data. Based on a preset low-code rule base, a corresponding intermediate deployment model is generated according to the target field data. A preset resource file template is used to render the intermediate deployment model to obtain the corresponding Kubernetes standard resource file, which is then displayed on the low-code operation page. This automatically converts user-input low-code deployment configuration data into Kubernetes standard resource files, reducing the technical requirements of Kubernetes for users.

[0127] Please see Figure 3 , Figure 3 This is a structural block diagram of a system for converting low-code deployment configuration to Kubernetes standard resource files, as provided in Embodiment 3 of the present invention.

[0128] This invention provides a system for converting low-code deployment configurations to Kubernetes standard resource files, comprising:

[0129] The response module 301 is used to preprocess the low-code deployment configuration data when it receives low-code deployment configuration data on the low-code operation page to obtain the corresponding target field data.

[0130] The mapping module 302 is used to generate a corresponding intermediate deployment model based on the target field data according to a preset low-code rule library.

[0131] The rendering module 303 is used to render the intermediate deployment model according to the preset resource file template, obtain the corresponding Kubernetes standard resource file, and display it on the low-code operation page.

[0132] Furthermore, the response module 301 includes:

[0133] The conversion submodule is used to convert the low-code deployment configuration data into the corresponding structured data.

[0134] The field format standardization submodule is used to standardize the field format of structured data to obtain the corresponding standardized field data;

[0135] The default value completion submodule is used to complete the default value of standardized field data to obtain the corresponding target field data.

[0136] Furthermore, the mapping module 302 includes:

[0137] The destructuring submodule is used to destructure each form field to obtain multiple target form fields;

[0138] The mapping submodule is used to retrieve the preset low-code rule library using each target form field and match the corresponding low-code native field path;

[0139] When the target form field does not match the low-code native field, a mapping operation is performed on the target form field to obtain the corresponding low-code native field path;

[0140] Each target form field is formatted according to its corresponding low-code native field path to obtain multiple low-code native fields.

[0141] Build submodules to generate intermediate deployment models using various low-code native fields.

[0142] Furthermore, the submodules are deconstructed, including:

[0143] The first analysis unit is used to determine whether each form field is a composite field;

[0144] The second analysis unit is used to split the form fields into multiple target form fields if the form fields are composite fields.

[0145] The third analysis unit is used to determine the form field as the target form field if the form field is not a composite field.

[0146] Furthermore, sub-modules are constructed, including:

[0147] The first deployment unit is used to inject each low-code native field into a preset initial intermediate deployment model in layers based on the field type of each low-code native field, so as to obtain the corresponding first deployment model.

[0148] The second deployment unit is used to perform field order normalization processing on the first deployment model to obtain the corresponding second deployment model;

[0149] The third deployment unit is used to perform default value completion and empty field cleanup on the second deployment model to obtain the corresponding third deployment model.

[0150] The verification unit is used to perform semantic verification on the third deployment model to obtain the corresponding intermediate deployment model.

[0151] Furthermore, the verification unit includes:

[0152] The first verification subunit is used to determine whether each model field in the third deployment model meets the preset verification conditions.

[0153] When all model fields meet the validation conditions, the third deployment model is determined as the intermediate deployment model.

[0154] Furthermore, the verification unit also includes:

[0155] The second verification subunit is used to identify model fields as abnormal fields when they do not meet the verification conditions.

[0156] Each exception field is used as exception information, and the exception information is displayed on the low-code operation page.

[0157] Furthermore, the rendering module 303 includes:

[0158] The first rendering submodule is used to render the intermediate deployment model according to the preset resource file template to obtain the corresponding Kubernetes standard resource file;

[0159] The feedback submodule is a feedback component used to load Kubernetes standard resource files into the low-code action page;

[0160] The second rendering submodule is used to render the feedback component, generating a low-code operation page containing standard Kubernetes resource files.

[0161] Please see Figure 4 , Figure 4 This is a structural block diagram of an electronic device provided in Embodiment 4 of the present invention.

[0162] An electronic device according to an embodiment of the present invention includes: a memory 401 and a processor 402. The memory 401 stores a computer program. When the computer program is executed by the processor 402, the processor 402 performs a method for converting low-code deployment configuration to Kubernetes standard resource files as described in any of the above embodiments.

[0163] Memory 401 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Memory 401 has storage space 403 for program code 413 for performing any of the method steps described above. For example, storage space 403 for program code may include individual program codes 413 for implementing the various steps in the methods described above. This program code may be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, CDs, memory cards, or floppy disks. The program code may be compressed, for example, in a suitable form. When run by a computing processing device, this code causes the computing processing device to perform the various steps in the methods described above. This program code may be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, CDs, memory cards, or floppy disks. The program code may be compressed, for example, in a suitable form. When this code is run by a computing device, it causes the computing device to perform the steps in the method described above for converting low-code deployment configurations into Kubernetes standard resource files.

[0164] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0165] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0166] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0167] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0168] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or 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 of the various embodiments of the present invention. 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.

[0169] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for converting low-code deployment configurations to Kubernetes standard resource files, characterized in that, include: When low-code deployment configuration data is received on the low-code operation page, the low-code deployment configuration data is preprocessed to obtain the corresponding target field data, including: The low-code deployment configuration data is converted to obtain the corresponding structured data. The structured data is then processed to standardize the field format, resulting in the corresponding standardized field data. The standardized field data is then filled with default values ​​to obtain the corresponding target field data; The target field data includes multiple form fields. Based on a preset low-code rule library, a corresponding intermediate deployment model is generated according to the target field data, including: Each of the form fields is destructured to obtain multiple target form fields; Each target form field is used to retrieve the preset low-code rule library and match the corresponding low-code native field path. The low-code native field path refers to the hierarchical path expression used to locate a specific configuration field in the Kubernetes standard resource file. Its structure is completely aligned with the field nesting logic of the resource file and describes the position of the field in the Kubernetes resource object hierarchy. When the target form field does not match the low-code native field, a mapping operation is performed on the target form field to obtain the corresponding low-code native field path; Each target form field is formatted according to its corresponding low-code native field path to obtain multiple low-code native fields. An intermediate deployment model is generated using each of the aforementioned low-code native fields, including: Based on the field type of each of the low-code native fields, each of the low-code native fields is injected into a preset initial intermediate deployment model in layers to obtain the corresponding first deployment model; The first deployment model is processed by field order normalization to obtain the corresponding second deployment model; The second deployment model is then processed by completing default values ​​and cleaning up empty fields to obtain the corresponding third deployment model; The third deployment model is semantically validated to obtain the corresponding intermediate deployment model; The intermediate deployment model is rendered according to the preset resource file template to obtain the corresponding Kubernetes standard resource file and displayed on the low-code operation page.

2. The method for converting low-code deployment configuration to Kubernetes standard resource files according to claim 1, characterized in that, The step of destructuring each of the form fields to obtain multiple target form fields includes: Determine whether each of the form fields is a composite field; If the form field is a composite field, then the form field is split to obtain multiple target form fields; If the form field is not a composite field, then the form field is determined as the target form field.

3. The method for converting low-code deployment configuration to Kubernetes standard resource files according to claim 1, characterized in that, The step of performing semantic verification on the third deployment model to obtain the corresponding intermediate deployment model includes: Determine whether each model field in the third deployment model meets the preset verification conditions; When all the model fields meet the verification conditions, the third deployment model is determined as the intermediate deployment model.

4. The method for converting low-code deployment configuration to Kubernetes standard resource files according to claim 3, characterized in that, Also includes: If the model field does not meet the verification conditions, the model field will be identified as an abnormal field. The aforementioned exception fields are used as exception information, and the exception information is displayed on the low-code operation page.

5. The method for converting low-code deployment configuration to Kubernetes standard resource files according to claim 1, characterized in that, The step of rendering the intermediate deployment model according to the preset resource file template to obtain the corresponding Kubernetes standard resource file and displaying it on the low-code operation page includes: The intermediate deployment model is rendered according to the preset resource file template to obtain the corresponding Kubernetes standard resource file; Load the Kubernetes standard resource file into the feedback component of the low-code operation page; The feedback component is rendered to generate a low-code operation page containing the Kubernetes standard resource files.

6. A system for converting low-code deployment configurations to Kubernetes standard resource files according to any one of claims 1-5, characterized in that, include: The response module is used to preprocess the low-code deployment configuration data when it receives low-code deployment configuration data on the low-code operation page to obtain the corresponding target field data. The mapping module is used to generate a corresponding intermediate deployment model based on the target field data, according to a preset low-code rule base. The rendering module is used to render the intermediate deployment model according to the preset resource file template, obtain the corresponding Kubernetes standard resource file, and display it on the low-code operation page.

7. An electronic device, characterized in that, The system includes a memory and a processor, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of the method for converting low-code deployment configurations to Kubernetes standard resource files as described in any one of claims 1-5.

Images