Configuration management method and system for container arrangement and deployment

Abstract

The invention relates to the technical field of container arrangement, and discloses a configuration management method and system for container arrangement deployment, the method comprises the following steps: creating a container arrangement template, and defining global environment variables by using a preset configuration file in the container arrangement template, the global environment variables comprising public environment variables and private environment variables of micro-services; configuring a preset configuration file based on the container arrangement template, and determining a configuration mapping resource of the global environment variable; obtaining the name and the type of each micro-service to be configured, and determining the mapping relationship between each micro-service and the configuration mapping resource based on the name and the type; and creating a container corresponding to each micro-service, and injecting the associated configuration mapping resource into the corresponding container according to the mapping relationship to complete container deployment. According to the method, redundant configuration of parameters is reduced through centralized configuration management; through one-key deployment optimization, the configuration efficiency is improved, homomorphic extension is realized based on a dynamic configuration reference mechanism, and the compatibility is enhanced.

Description

Technical Field

[0001] The present application relates to the field of container orchestration technology, and in particular to a configuration management method and system for container orchestration deployment. Background Art

[0002] Container technology is currently a popular technology and also the most cutting-edge technology. Docker is an open source application container engine that allows developers to package their applications and dependent packages into a portable container and then publish it to any machine with a popular Linux or Windows operating system. It can also achieve virtualization. Containers use a complete sandbox mechanism and there are no interfaces between them.

[0003] In related technologies, containerized microservice architectures require the deployment of dozens or even hundreds of services, each relying on distinct environment variables and configuration information. However, defining a separate ConfigMap for each service, or injecting configuration information individually through environment variables during deployment, presents the following drawbacks: First, repeated definitions must be made in each service's ConfigMap, resulting in high maintenance costs and prone to errors; second, configurations are fragmented across services, requiring the modification of multiple ConfigMaps one by one when deploying a new environment, which is inefficient; third, adding or modifying common configurations requires simultaneous updates to all related services, lacking a unified management mechanism. Therefore, a configuration management solution for container orchestration deployment is urgently needed to address these drawbacks. Summary of the Invention

[0004] The embodiments of the present application provide a configuration management method and system for container orchestration deployment to solve the technical problems of repeated configuration of environment variables and low maintenance efficiency in container orchestration deployment of multiple microservices in related technologies.

[0005] An embodiment of the present application provides a configuration management method for container orchestration deployment, including: creating a container orchestration template, using a preset configuration file in the container orchestration template to define global environment variables, wherein the global environment variables include public environment variables and private environment variables of microservices; configuring the preset configuration file based on the container orchestration template to determine the configuration mapping resources of the global environment variables; obtaining the name and type of each microservice to be configured, and determining the mapping relationship between each microservice and the configuration mapping resource based on the name and type; creating a container corresponding to each microservice, and injecting the associated configuration mapping resource into the corresponding container according to the mapping relationship to complete the container deployment.

[0006] In one embodiment of the present application, public environment variables and private environment variables in the global environment variables are defined by a preset configuration file; wherein, private environment variables are unique configurations of any microservice, and private environment variables satisfy personalized parameter configurations; public environment variables are common configurations between at least two microservices.

[0007] In one embodiment of the present application, a preset configuration file is configured based on a container orchestration template to determine configuration mapping resources for global environment variables, including: parsing the preset configuration file through a template engine in the container orchestration template, performing structured conversion on the global environment variables in the preset configuration file in combination with key-value pair mapping rules to determine YAML data; filling the YAML data into the template placeholder to generate a configuration mapping resource that complies with the container orchestration specification.

[0008] In one embodiment of the present application, the name and type of each microservice to be configured are obtained, and the mapping relationship between each microservice and the configuration mapping resource is determined based on the name and type, including: obtaining the name and type of each microservice to be configured, and using the name and type corresponding to each microservice as an index identifier; matching according to the index identifier through preset mapping rules to determine the mapping relationship between each microservice and the configuration mapping resource, and the preset mapping rules include public environment variables and private environment variables corresponding to each type of microservice.

[0009] In one embodiment of the present application, a container corresponding to each microservice is created, and the associated configuration mapping resources are injected into the corresponding container according to the mapping relationship to complete the container deployment, including: scanning and reading the key-value pairs in the preset configuration file, determining the configuration mapping resources and performing persistence operations; creating a container corresponding to each microservice, and injecting the associated configuration mapping resources into the container corresponding to each microservice in the form of environment variables according to the mapping relationship; when any container is running, the configured global environment variables are read to complete the container deployment.

[0010] In one embodiment of the present application, it also includes: if a configuration update of one or more arbitrary microservices is detected, or if a configuration environment change of one or more arbitrary microservices is detected, the key-value pairs in the preset configuration file are modified, and the container orchestration installation command is re-run.

[0011] In one embodiment of the present application, after completing the container deployment, it also includes: accessing the network address of the target container where any microservice is located to obtain the status code of the target container; determining the deployment status of the target container according to the status code; if the deployment status of the target container is deployment success, skipping the deployment of the target container; if the deployment status of the target container is deployment failure, modifying the corresponding key-value pair in the preset configuration file, and then redeploying the target container.

[0012] In one embodiment of the present application, after completing the container deployment, it also includes: monitoring the workload ready events of each microservice; wherein the workload ready events are used to determine that the status of the corresponding functions of each microservice is online; counting the total number of workload ready events of each microservice to determine the working status of each microservice.

[0013] In one embodiment of the present application, before determining the configuration mapping resource of the global environment variable, the method further includes: verifying the preset configuration file according to preset verification rules to generate a verification result, wherein the preset verification rules include syntax and format verification, logic verification, permission verification, deployment configuration verification, service configuration verification, and security verification; Generate a verification report based on each verification result, determine the configuration items to be adjusted based on the verification report, and adjust the configuration items to be adjusted until the preset configuration file passes the verification.

[0014] An embodiment of the present application also provides a configuration management system for container orchestration deployment, including: a variable definition module, which creates a container orchestration template and uses a preset configuration file in the container orchestration template to define global environment variables, wherein the global environment variables include public environment variables and private environment variables of microservices; a resource configuration module, which configures the preset configuration file based on the container orchestration template and determines the configuration mapping resources of the global environment variables; a mapping determination module, which is used to obtain the name and type of each microservice to be configured, and determine the mapping relationship between each microservice and the configuration mapping resource based on the name and type; a configuration management module, which is used to create a container corresponding to each microservice, and inject the associated configuration mapping resource into the corresponding container according to the mapping relationship to complete the container deployment.

[0015] In the solution implemented by the configuration management method and system for container orchestration deployment provided above, This application uses preset configuration files to define global environment variables, where global environment variables eliminate redundant definitions of environment variables and reduce the probability of failure due to inconsistent configuration; the preset configuration files are configured based on the container orchestration template to determine the configuration mapping resources of the global environment variables; the YAML configuration is automatically injected into the container through the template engine to define the configuration mapping, reducing manual intervention; at the same time, the centralized management of template files allows configuration changes to be modified in only one place, reducing maintenance costs; the name and type of each microservice to be configured are obtained, and the mapping relationship between each microservice and the configuration mapping resource is determined based on the name and type; a container corresponding to each microservice is created, and the associated configuration mapping resource is injected into the corresponding container according to the mapping relationship to complete the container deployment; in this way, the configuration is automatically matched according to the microservice name and type, supporting elastic expansion; the use of centralized configuration management not only ensures consistent configuration of each environment, but also reduces maintenance costs.

[0016] Through standardized configuration, automated generation, and intelligent orchestration, a complete cloud-native microservice deployment system has been built. Centralized configuration management reduces redundant parameter configurations. One-click deployment optimization improves configuration efficiency. At the same time, a dynamic configuration reference mechanism enables homomorphic expansion and enhances compatibility. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] Figure 1 An exemplary flow chart of a configuration management method applicable to container orchestration deployment provided in an embodiment of the present application; Figure 2 A schematic diagram of the configuration management system for container orchestration and deployment provided in an embodiment of the present application; Figure 3 A schematic structural diagram of an electronic device in one embodiment of the present application; Figure 4 Another structural diagram of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0019] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0020] In order to enable those skilled in the art to better understand the improvements of the technical solution provided by the present disclosure, the present disclosure briefly introduces the implementation scenarios and related information of the configuration management method for container orchestration deployment in the related art.

[0021] As mentioned previously, current containerized microservice architectures require the deployment of numerous services, each of which relies on different environment variables to inject configuration information. Traditional approaches define separate configuration mappings for each service or inject configurations one by one during deployment. This results in duplicate configuration definitions, high maintenance costs, inefficient deployment of new environments, and a lack of a unified management mechanism for common configurations. For example, when an e-commerce platform needs to deploy order services, payment services, and inventory services, the common database connection parameters for each service must be repeatedly defined in their respective configurations. Changes to the database address require individual configuration modifications, posing the risk of missing configurations.

[0022] In order to solve the above problems, the inventors found that the defects originated from the decentralized management of configuration information and the lack of a structured processing mechanism. By analyzing the operating principles of container orchestration tools, they realized that the combination of templated configuration and key-value mapping rules can effectively achieve configuration reuse; at the same time, they further discovered that storing public configuration and private configuration separately, and establishing an association between services and configurations through an indexing mechanism, can achieve accurate configuration injection during batch deployment, thus forming a technical idea of ​​centrally managing variables through global environment variables, using template engines to structure configuration conversion, and automatically deploying based on service characteristics.

[0023] In view of this, the embodiment of the present application provides a configuration management method for container orchestration deployment, wherein, please refer to Figure 1 , Figure 1 A flow chart of a configuration management method for container orchestration deployment provided in an embodiment of the present application, the method comprising the following steps: Step S101: Create a container orchestration template and use the preset configuration file in the container orchestration template to define global environment variables, which include public environment variables and private environment variables of microservices. For example, a container orchestration template is created based on Docker or K8s; the preset configuration file refers to a standardized file that uses a key-value pair structure to store environment variables, which can be implemented using a YAML format file containing public configuration segments and private configuration segments. The public configuration segment stores parameters shared by multiple services, and the private configuration segment stores exclusive parameters for a specific service, achieving logical isolation of configuration through a file hierarchy structure.

[0024] For example, public environment variables and private environment variables refer to common parameters shared by multiple microservices (such as database connection address) and customized parameters unique to a single microservice (such as cache size), respectively. They can be distinguished by independent fields or namespaces to avoid configuration conflicts.

[0025] Step S102: configuring a preset configuration file based on the container orchestration template to determine a configuration mapping resource for global environment variables; Step S103: Obtain the name and type of each microservice to be configured, and determine the mapping relationship between each microservice and the configuration mapping resource based on the name and type; Step S104: Create a container corresponding to each microservice, and inject the associated configuration mapping resources into the corresponding container according to the mapping relationship to complete the container deployment.

[0026] A container orchestration template refers to a templated tool used to parse preset configuration files. This can be implemented using Docker's Compose template or Kubernetes' (i.e., K8s) ConfigMap template. The built-in template engine converts the preset configuration files into recognizable structured data. The preset configuration files are YAML files, which are nested key-value pairs. For example, a preset configuration file can be used to define public and private environment variables in the global environment. Private environment variables are unique configurations for any microservice, and they satisfy personalized parameter configurations. Public environment variables are shared configurations between at least two microservices. A configuration map resource is a ConfigMap resource represented by a ConfigMap.YAML file.

[0027] For example, taking the order microservice as an example, first, define the database connection address as a public environment variable in the YAML file, and define the port number of each service as a private environment variable. Secondly, parse the YAML file through the Kubernetes or Docker template engine and convert the variables into ConfigMap resource objects. Thirdly, match the corresponding configuration according to the type of order service and payment service, and inject the Helm Chart of the instruction through the variable. Finally, when executing the deployment, create the service and inject the corresponding configuration to achieve differentiated deployment of different services; when you need to add a logistics service, you only need to add a private configuration segment to the preset configuration file and update the index relationship, without modifying the existing deployment logic.

[0028] In related technologies, when a deployed service cluster includes 50 services, 50 independent ConfigMaps need to be managed, resulting in fragmented and duplicated configurations and insufficient flexibility. However, this application compresses configuration items into a single file through global environment variables and achieves precise matching by mapping service types to configuration segments, significantly reducing the workload of modifying configurations when adding new services. Furthermore, a templated conversion mechanism avoids formatting errors when manually writing YAML files, significantly improving the success rate of configuration deployment.

[0029] Through the above method, this application realizes the centralized management and automated deployment of microservice configuration, eliminating the version inconsistency problem caused by repeated configuration definition; when the public configuration changes, it is only necessary to modify the corresponding fields in the preset configuration file to achieve global update, and the deployment efficiency is doubled; by generating configuration resources through standardized templates, the deployment consistency between different environments is ensured, and the operation and maintenance complexity of the configuration management system is reduced.

[0030] In some embodiments, configuring a preset configuration file based on a container orchestration template to determine a configuration mapping resource for a global environment variable includes: The template engine in the container orchestration template parses the preset configuration file, and performs structural conversion on the global environment variables in the preset configuration file based on the key-value mapping rules to determine the YAML data. Fill the template placeholders with YAML data to generate configuration mapping resources that comply with container orchestration specifications.

[0031] Container orchestration templates refer to framework files used to generate standardized container orchestration configurations. These can be implemented using Docker Compose templates or Kubernetes resource manifest templates. They provide a unified, structured format for configuring mapping resources, preventing syntax errors when manually writing configurations. Template engines, such as Jinja2 or Helm, are tools used to parse templates and dynamically generate configuration files. These engines convert environment variables in pre-set configuration files into recognizable data structures.

[0032] Key-value mapping rules refer to a standardized way of associating environment variable names with configuration values. This can be achieved using a colon-delimited key-value pair format. This converts scattered environment variables into unified structured data, reducing configuration redundancy. YAML data refers to a collection of configuration information that conforms to the YAML syntax specification. Specifically, an indented hierarchical structure is used to express the logical relationships between configuration items. It uses a standardized data format to carry the definitions of public and private environment variables.

[0033] Template placeholders are reserved locations within a container orchestration template for inserting dynamic content. These can be implemented using variable names enclosed in double curly braces. Parsed configuration data is injected into the template through dynamic replacement, generating the final executable configuration resource. Container orchestration specifications refer to the resource configuration format standards defined by the container platform. These can be implemented using Kubernetes ConfigMap or Docker environment variable injection mechanisms to ensure that the generated configuration map resources can be correctly identified and loaded by the target container.

[0034] Specifically, for example, when using Kubernetes, a container orchestration template can be defined as a YAML file containing a ConfigMap resource declaration, where placeholders are used to mark configuration items that need to be dynamically filled. When the template engine parses the preset configuration file, it converts public and private environment variables into structured data based on key-value pair rules. For example, DB_HOST: 192.168.1.100 in the configuration file is converted into a key-value pair mapping relationship. Subsequently, by replacing the placeholders in the template, the converted YAML data is injected into the specified location of the container orchestration template to generate a configuration mapping resource file that conforms to the KubernetesConfigMap specification. In this way, the automatic conversion from the original configuration file to the deployable configuration resource is achieved, avoiding the manual definition of the configuration mapping item by item.

[0035] In related technologies, a separate ConfigMap file is written for each microservice, and the environment variable injection logic is manually maintained during deployment. However, this application uses the template engine's automated parsing and filling mechanism to convert scattered configuration information into standardized container orchestration resources. For example, the common configurations of multiple microservices can be merged into the same ConfigMap while retaining the independence of private configurations. This centralized processing eliminates the need to repeatedly define configuration items and reduces the risk of configuration errors caused by manual modifications.

[0036] Through the above approach, this application achieves automated generation and unified management of configuration resources. For example, when adding a new microservice, one only needs to expand the corresponding environment variable definition in the preset configuration file, and the template engine will automatically convert it into the configuration map resource of the target platform, without having to rewrite the entire ConfigMap file. This significantly reduces the configuration maintenance workload while ensuring the consistency of configuration deployment across different environments, solving the problem of fragmented configuration and low modification efficiency in existing technologies.

[0037] In some embodiments, obtaining the name and type of each microservice to be configured, and determining a mapping relationship between each microservice and a configuration mapping resource based on the name and type includes: Get the name and type of each microservice to be configured, and use the name and type corresponding to each microservice as an index identifier; The mapping relationship between each microservice and the configuration mapping resource is determined by matching according to the index identifier through the preset mapping rules. The preset mapping rules include the public environment variables and private environment variables corresponding to each type of microservice.

[0038] Among them, name and type as index identifiers refer to using the unique identifier of the microservice (for example, the service name) and its category (for example, database service, API (application programming interface) service) as the matching basis. Specifically, key-value pairs or hash table structures can be used for storage to quickly locate the corresponding configuration mapping.

[0039] Preset mapping rules refer to predefined logical relationship tables. For example, they can associate microservices with configuration variables through regular expressions or service type tags. Specifically, the rule set can be stored in JSON or YAML format to ensure that different microservice types automatically match corresponding public and private variables.

[0040] For example, when it is necessary to determine the mapping relationship between each microservice and the configuration mapping resource, first, extract the service name and type information from the microservice registration center or manifest file. For example, a microservice named order-service and of type API, its name is resolved as an index key, and the type is used to match the classification label in the preset rules. The preset mapping rules define that API type services need to inject public variables such as log level and timeout threshold, as well as private variables such as order processing queue name. By matching the index identifier with the rule table, the corresponding environment variable set is automatically filtered out and filled into the specified location of the preset configuration file to form a ConfigMap resource. Finally, the ConfigMap resource is loaded through the envFrom field in the Deployment resource of Kubernetes.

[0041] Traditional methods require writing configuration injection logic for each microservice separately and are unable to automatically associate public variables based on service type. For example, when adding a new microservice, it is necessary to manually check the public configuration dependencies and update all related files. However, this application automatically matches index identifiers with preset rules, allowing microservices of the same type to directly reuse public variable configurations. At the same time, private variables are dynamically bound, reducing manual intervention and configuration redundancy.

[0042] Through the above methods, this application achieves precise matching and automated injection of microservice configurations, solving the configuration errors and inefficiencies caused by manually maintaining multiple ConfigMaps. For example, when deploying dozens of API services of the same type, the same public variables need to be loaded, and only private parameters need to be defined separately for each service, significantly reducing the complexity of configuration management. In addition, the preset mapping rules support dynamic expansion. When adding a new microservice type, only the rule table needs to be updated to synchronize the configuration of all services, avoiding the operation of modifying the deployment one by one.

[0043] In some embodiments, creating a container corresponding to each microservice and injecting the associated configuration mapping resources into the corresponding container according to the mapping relationship to complete container deployment includes: Execute the container orchestration installation command to start the deployment process, scan and read the key-value pairs in the preset configuration file, determine the configuration mapping resources and perform persistence operations; create a container corresponding to each microservice, and inject the associated configuration mapping resources into the container corresponding to each microservice in the form of environment variables according to the mapping relationship; when any container is running, read the configured global environment variables to complete the container deployment.

[0044] It's important to note that all service configuration items should be organized and maintained in the ConfigMap.YAML file. If multiple services share configuration (MySQL connection information), use the same variable name (such as MySQL_HOST) to ensure configuration consistency. In the Helm Values.YAML file, the ConfigMap field maintains the key-value pairs of specific configurations, which will be parsed into the Kubernetes ConfigMap resource (configuration mapping resource) during deployment.

[0045] For example, the Helm Install command is used to start the deployment process, and Helm automatically scans the ConfigMap.YAML file in the project. Through the {{with.Values.ConfigMap-}} configuration, Helm reads the key-value pairs of ConfigMap from Values.YAML, generates and creates Kubernetes' ConfigMap resources, and implements persistent storage of the configuration. When Helm scans the deployment.YAML file, it references the created ConfigMap resource through the envFrom field and injects the configuration into the container of each service in the form of environment variables. After completing the configuration injection, Helm defines the created microservice container according to the Deployment. When the container starts, it obtains all configuration environment variables so that the service can read and use these configurations on demand.

[0046] This approach allows for centralized management of global environment variables, avoiding duplicate definitions for repeated fields. It also simplifies the environment variable injection process by dynamically associating ConfigMap with Deployment using Helm template syntax. This ensures that the latest configuration is available in real time during service runtime, improving deployment efficiency and standardizing configuration management.

[0047] In some embodiments, configuration management for container orchestration deployment further includes: If a configuration update of one or more arbitrary microservices is detected, or if a configuration environment change of one or more arbitrary microservices is detected, the key-value pairs in the preset configuration file are modified and the container orchestration installation command is re-run.

[0048] Specifically, a distributed configuration center is used to centrally store microservice configurations and support versioning; microservices subscribe to their own configuration change events through long polling or Server-Sent Events (SSE). When the configuration center detects a configuration update, it pushes a change notification to the subscribed microservices. Define a mapping table between microservices and configuration items. Use scripts to listen to configuration update events, parse the changed configuration items, and update the configuration list of the corresponding microservices in the mapping file. Use Jinja2 or Go Template to dynamically generate mapping files to avoid manual editing errors. For example, after receiving a configuration update, the microservice dynamically refreshes the configuration through framework-level support (such as Spring Cloud) or a custom Reload mechanism. After the configuration is updated, the health check endpoint is triggered to verify the configuration's effectiveness.

[0049] Through the above approach, closed-loop management of microservice configuration is achieved, significantly improving the agility and reliability of the configuration management system.

[0050] In some embodiments, after the container deployment is completed, the method further includes: Access the network address of the target container where any microservice is located to obtain the status code of the target container; determine the deployment status of the target container based on the status code; If the deployment status of the target container is deployment successful, the deployment of the target container is skipped; if the deployment status of the target container is deployment failed, the corresponding key-value pair in the preset configuration file is modified, and the target container is redeployed.

[0051] The network address refers to the accessible network identifier assigned to the container in the cluster. It can be implemented through the IP address and port combination exposed by the Kubernetes Service or Ingress resource, and is used to establish a communication connection between the external system and the container instance.

[0052] The status code refers to the HTTP response code returned by the container service interface. It can be implemented using a standardized HTTP status code system. For example, 200 indicates normal service, and 503 indicates unavailable service. The status code can be used to quickly determine the running status of the container instance.

[0053] Specifically, after the container instance is started, the network detection mechanism is called to periodically access the network address of the target container and obtain the status code returned by its service interface. For example, an HTTP GET request is sent to the target container via the curl command. If a 200 response is received, the container is determined to have been successfully deployed. If the target container is detected to be in an unready state and a 404 status code is returned, the deployment is determined to have failed, and the configuration injection and startup process for the container is triggered to be re-executed. In this way, through the automated status detection and deployment decision-making mechanism, the repeated deployment of container instances that are already running normally is avoided, while ensuring that abnormal instances are repaired in a timely manner.

[0054] In related technologies, traditional methods rely on manual inspection of container logs or basic status reports from orchestration tools, which are unable to perceive the actual service capabilities of container instances in real time, and easily lead to deployment omissions or waste of resources; this application actively detects the status of container network services and makes decisions based on standardized status codes to achieve accurate judgment and automated processing of deployment status, effectively improving the reliability and execution efficiency of the deployment process.

[0055] Through the above method, this application can automatically identify successfully deployed container instances and skip redundant operations. At the same time, it triggers a rapid reconstruction mechanism for abnormal instances, reducing the risk of deployment failure due to configuration errors or environmental problems, and significantly reducing operation and maintenance complexity and resource consumption.

[0056] In some embodiments, after the container deployment is completed, the method further includes: Monitor the workload readiness events of each microservice. The workload readiness events are used to determine whether the corresponding functions of each microservice are online. Count the total number of workload readiness events for each microservice to determine the working status of each microservice.

[0057] For example, monitor pod readiness conditions through the Kubernetes API or integrate the Prometheus kube_pod_ready_condition metric. Alternatively, define readiness probes in container orchestration templates (such as Helm Charts) with detection logic such as HTTP endpoints, TCP connections, or command execution to monitor the online status of events. Use distributed counters to aggregate the number of readiness events for each microservice. Define the readiness rate formula: Readiness rate = (number of ready instances / expected number of instances) × 100%. Combine this with dynamic thresholds (for example, 95%) to determine service status. Dynamically adjust thresholds based on historical data to avoid misjudgments based on fixed values. Define state transition logic using a rules engine or state machine. When a service reaches "not ready," trigger self-healing actions (such as restarting the pod or rolling back a deployment) or alerts (such as PagerDuty). Display a service status topology map using Grafana, noting abnormal nodes.

[0058] Through the above method, millisecond-level perception of instance-level state changes is achieved, reducing state jitter caused by network partitions or probe misjudgment. At the same time, by quantifying service status, it supports the gradual release of traffic in grayscale releases; dynamic thresholds are used to reduce false alarms triggered by short-term fluctuations.

[0059] In some embodiments, before determining the configuration mapping resource of the global environment variable, the method further includes: Verify the preset configuration file according to the preset verification rules to generate a verification result, wherein the preset verification rules include syntax and format verification, logic verification, permission verification, deployment configuration verification, service configuration verification and security verification; Generate a verification report based on each verification result, determine the configuration items to be adjusted based on the verification report; adjust the preset configuration file according to the configuration items to be adjusted until the verification passes.

[0060] Among them, the preset verification rules refer to a set of standards for multi-dimensional verification of preset configuration files. Specifically, they can be implemented using static code analysis tools or custom verification logic. For example, syntax verification can be performed using YAML Lint, or the format of key configuration items can be matched through regular expressions. Syntax and format verification is used to ensure that the preset configuration files conform to the syntax specifications of the container orchestration tool. Logical verification is used to verify whether the dependencies between configuration items are reasonable. Permission verification is used to check whether the scope of permissions for container access to resources is compliant. Deployment configuration verification is used to verify the validity of parameters such as image versions and resource quotas. Service configuration verification is used to confirm the correctness of settings such as service ports and health check paths. Security verification is used to identify whether sensitive information is encrypted or poses risks.

[0061] Specifically, after determining the preset configuration file, first, call each sub-rule in the preset verification rules to check the contents of the preset configuration file item by item. For example, the syntax and format verification module will parse the YAML structure in the preset configuration file. If an indentation error or missing field is found, a corresponding error entry will be generated; the logic verification module will traverse the variable definitions in the configuration mapping resources to detect whether there are circular references or undeclared variables. All verification results are summarized and a verification report is generated, which lists the type, location and recommended adjustment method of each problem in detail. Based on the verification report, the configuration items to be adjusted are automatically located. For example, the unencrypted database password is marked as a high-risk item, and it is prompted to replace it with a reference in the key management service; the adjusted preset configuration file enters the verification process again until all rules are passed.

[0062] Related technologies lack a systematic verification mechanism after deployment, relying solely on manual inspection or single-dimensional format verification, which makes it difficult to detect configuration errors in a timely manner. For example, naming conflicts between public and private environment variables may not be identified, or resource quotas may exceed the actual capacity of the cluster without being warned. However, this application uses preset multi-level verification rules to cover all aspects of detection, from basic syntax to security policies, effectively avoiding deployment failures or runtime exceptions caused by configuration errors.

[0063] Through the above approach, this application can significantly reduce the risk of deployment interruptions caused by configuration errors and improve the accuracy and reliability of orchestration configuration. For example, when adding a new public environment variable to a microservice, it automatically detects whether the variable conflicts with existing services, thus avoiding communication anomalies between services after deployment. At the same time, the automated verification process reduces manual intervention, thereby improving the configuration management efficiency of large-scale microservice clusters.

[0064] In some implementations, in actual usage scenarios, the development center deployed an application consisting of 30 microservices in a cloud-native environment with low code, involving public middleware such as MySQL and Redis and service-specific configurations.

[0065] The traditional deployment method took five man-days, which involved creating a ConfigMap for each service and maintaining each configuration one by one; manually deploying each service; and modifying each ConfigMap that used the MySQL configuration one by one when the MySQL address changed.

[0066] For example, taking the configuration management method for container orchestration deployment in this application as an example, the deployment takes one man-day, in which all configurations are defined centrally in Values.YAML; Helm Install is executed to generate a full ConfigMap and deploy all services with one click; when the MySQL address changes, only one configuration in Values.YAML needs to be modified; if nearly 100 services of the entire GOS are deployed and maintained using this method, the delivery efficiency will be greatly improved, the manpower investment in deployment and maintenance will be saved, and the cost of troubleshooting caused by configuration errors during deployment will be reduced.

[0067] First, define a global ConfigMap in the Values.YAML (configuration file) of the Helm Chart, which contains environment variables that may be used by all services, covering public middleware configuration and service-specific configuration. By centrally managing all ConfigMaps, for example, only a single Values.YAML file needs to be modified when deploying a new environment, significantly reducing manual intervention and improving deployment efficiency. At the same time, public configuration only needs to be defined once, avoiding repeated modifications. Second, each service automatically references the full ConfigMap through ConfigMapRef (configuration map reference). This dynamic configuration reference mechanism eliminates the need to explicitly declare required variables, and each service uses environment variables as needed. Third, the Values.YAML file is automatically parsed through Helm commands (for example, Helm Install), and configurations are generated and injected, enabling rapid startup and configuration synchronization of dozens of services. One-click deployment optimization supports dynamic service expansion, and new services can inherit the global configuration without additional configuration.

[0068] In one embodiment, a configuration management system for container orchestration deployment is provided, and the configuration management system for container orchestration deployment is used to execute the configuration management method for container orchestration deployment provided in any of the above embodiments. Figure 2 , Figure 2 A structural diagram of a configuration management system for container orchestration deployment provided in an embodiment of the present application, such as Figure 2 As shown, the configuration management system for container orchestration deployment includes a variable definition module 201, a resource configuration module 202, a mapping determination module 203 and a configuration management module 204, wherein: The variable definition module 201 is used to create a container orchestration template and use the preset configuration file in the container orchestration template to define global environment variables, where the global environment variables include the public environment variables and private environment variables of the microservice; The resource configuration module 202 configures the preset configuration file based on the container orchestration template and determines the configuration mapping resources of the global environment variables; A mapping determination module 203 is used to obtain the name and type of each microservice to be configured, and determine the mapping relationship between each microservice and the configuration mapping resource based on the name and type; The configuration management module 204 is used to create a container corresponding to each microservice and inject the associated configuration mapping resources into the corresponding container according to the mapping relationship to complete the container deployment.

[0069] For the specific definition of the configuration management system for container orchestration and deployment, please refer to the definition of the configuration management method for container orchestration and deployment above, which will not be repeated here. The various modules in the above-mentioned configuration management system for container orchestration and deployment can be implemented in whole or in part by software, hardware, and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the electronic device in hardware form, or can be stored in the memory of the electronic device in software form, so that the processor can call and execute the operations corresponding to the above modules.

[0070] In this embodiment, the configuration management system for container orchestration and deployment is essentially equipped with multiple modules to execute the configuration management method for container orchestration and deployment in any of the above embodiments. The specific functions and technical effects can be referred to the above embodiments and will not be repeated here.

[0071] For the specific definition of the vehicle, please refer to the definition of the configuration management method for container orchestration deployment above, which will not be repeated here. The various modules in the above-mentioned vehicle can be implemented in whole or in part by software, hardware, and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the electronic device in hardware form, or can be stored in the memory of the electronic device in software form, so that the processor can call and execute the operations corresponding to the above modules.

[0072] In one embodiment, an electronic device is provided. The electronic device may be a server, and its internal structure diagram may be as follows: Figure 3 As shown. The electronic device includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the electronic device is used to communicate with an external client via a network connection. When the computer program is executed by the processor, the functions or steps on the server side of the above method are implemented.

[0073] In one embodiment, an electronic device is provided. The electronic device may be a client, and its internal structure diagram may be as follows: Figure 4 As shown. The electronic device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the electronic device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, the functions or steps of the client side of the above method are implemented.

[0074] In one embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed: Create a container orchestration template and use the preset configuration file in the container orchestration template to define global environment variables, where the global environment variables include the public environment variables and private environment variables of the microservices; configure the preset configuration file based on the container orchestration template to determine the configuration mapping resources of the global environment variables; obtain the name and type of each microservice to be configured, and determine the mapping relationship between each microservice and the configuration mapping resource based on the name and type; create a container corresponding to each microservice, and inject the associated configuration mapping resource into the corresponding container according to the mapping relationship to complete the container deployment.

[0075] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented: Create a container orchestration template and use the preset configuration file in the container orchestration template to define global environment variables, where the global environment variables include the public environment variables and private environment variables of the microservices; configure the preset configuration file based on the container orchestration template to determine the configuration mapping resources of the global environment variables; obtain the name and type of each microservice to be configured, and determine the mapping relationship between each microservice and the configuration mapping resource based on the name and type; create a container corresponding to each microservice, and inject the associated configuration mapping resource into the corresponding container according to the mapping relationship to complete the container deployment.

[0076] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or electronic device can be referred to the relevant descriptions on the server side and the client side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0077] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. The above-described computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the above-described method embodiments. Any reference to memory, storage, database, or other media used in the various embodiments provided herein may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), direct memory bus RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0078] Those skilled in the art will clearly understand that for the sake of convenience and brevity in description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the above-mentioned device or system can be divided into different functional units or modules to complete all or part of the functions described above.

[0079] The embodiments provided above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments can still be modified, or some of the technical features thereof can be replaced by equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A configuration management method for container orchestration deployment, characterized in that: The method comprises: Create a container orchestration template, and use a preset configuration file in the container orchestration template to define global environment variables, wherein the global environment variables include public environment variables and private environment variables of the microservice; Configuring the preset configuration file based on the container orchestration template to determine the configuration mapping resources of the global environment variables; Obtain the name and type of each microservice to be configured, and determine a mapping relationship between each microservice and the configuration mapping resource based on the name and the type; Create a container corresponding to each microservice, and inject the associated configuration mapping resource into the corresponding container according to the mapping relationship to complete the container deployment.

2. The configuration management method for container orchestration deployment according to claim 1, characterized in that: The public environment variables and the private environment variables in the global environment variables are defined by the preset configuration file; wherein the private environment variables are unique configurations of any of the microservices, and the private environment variables satisfy personalized parameter configurations; the public environment variables are common configurations between at least two of the microservices.

3. The configuration management method for container orchestration deployment according to claim 1, characterized in that: Configuring the preset configuration file based on the container orchestration template to determine the configuration mapping resource of the global environment variable includes: The preset configuration file is parsed by the template engine in the container orchestration template, and the global environment variables in the preset configuration file are structurally converted in combination with the key-value pair mapping rule to determine the YAML data; Fill the template placeholders with the YAML data to generate a configuration mapping resource that complies with the container orchestration specification.

4. The configuration management method for container orchestration deployment according to claim 3, characterized in that: Obtaining the name and type of each microservice to be configured, and determining a mapping relationship between each microservice and the configuration mapping resource based on the name and the type, including: Get the name and type of each microservice to be configured, and use the name and type corresponding to each microservice as an index identifier; The mapping relationship between each of the microservices and the configuration mapping resource is determined by matching according to the index identifier through a preset mapping rule, wherein the preset mapping rule includes public environment variables and private environment variables corresponding to each type of microservice.

5. The configuration management method for container orchestration deployment according to claim 2, characterized in that: Creating a container corresponding to each microservice and injecting the associated configuration mapping resource into the corresponding container according to the mapping relationship to complete the container deployment includes: Scan and read the key-value pairs in the preset configuration file, determine the configuration mapping resources and perform persistence operations; create a container corresponding to each microservice, and inject the associated configuration mapping resources into the container corresponding to each microservice in the form of environment variables according to the mapping relationship; when any of the containers is running, read the configured global environment variables to complete the container deployment.

6. The configuration management method for container orchestration deployment according to claim 2, characterized in that: Also includes: If a configuration update of one or more arbitrary microservices is detected, or if a configuration environment change of one or more arbitrary microservices is detected, the key-value pairs in the preset configuration file are modified, and the container orchestration installation command is re-run.

7. The configuration management method for container orchestration deployment according to any one of claims 1 to 6, characterized in that: After the container deployment is completed, the following steps are also included: Access the network address of the target container where any of the microservices is located to obtain a status code of the target container; and determine the deployment status of the target container according to the status code; If the deployment status of the target container is deployment success, the deployment of the target container is skipped; if the deployment status of the target container is deployment failure, the corresponding key-value pair in the preset configuration file is modified, and the target container is redeployed.

8. The configuration management method for container orchestration deployment according to any one of claims 1 to 6, characterized in that: After the container deployment is completed, the following steps are also included: Monitor workload readiness events of each microservice; wherein the workload readiness events are used to determine whether the status of the corresponding function of each microservice is online; The total number of workload readiness events of each microservice is counted to determine the working status of each microservice.

9. The configuration management method for container orchestration deployment according to any one of claims 1 to 6, characterized in that: Before determining the configuration mapping resource of the global environment variable, the method further includes: Verify the preset configuration file according to preset verification rules to generate a verification result, wherein the preset verification rules include syntax and format verification, logic verification, permission verification, deployment configuration verification, service configuration verification and security verification; A verification report is generated according to the verification result, and configuration items to be adjusted are determined based on the verification report; and configuration adjustments are performed on the configuration items to be adjusted until the verification of the preset configuration file passes.

10. A configuration management system for container orchestration deployment, characterized in that: include: A variable definition module creates a container orchestration template and uses a preset configuration file in the container orchestration template to define global environment variables, wherein the global environment variables include public environment variables and private environment variables of microservices; A resource configuration module configures the preset configuration file based on the container orchestration template and determines the configuration mapping resources of the global environment variables; A mapping determination module is used to obtain the name and type of each microservice to be configured, and determine the mapping relationship between each microservice and the configuration mapping resource based on the name and the type; The configuration management module is used to create a container corresponding to each microservice, and inject the associated configuration mapping resources into the corresponding container according to the mapping relationship to complete the container deployment.

Images