Configuring a thermal loading system, method, device, storage medium and program product

CN121309342BActive Publication Date: 2026-08-28MIGU CO LTD +1
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202511432998.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-09-30
Publication Date
2026-08-28
Estimated Expiration
2045-09-30

AI Technical Summary

Technical Problem

在应用程序部署完成以后,在运行的过程中,往往需要更新配置,目前是在Kubernetes集群的每个应用程序的容器组(POD)中分别增加sidecar容器,通过sidecar容器实现应用程序的配置热加载,但会占用主机资源,从而导致主机资源浪费、资源利用率较低

Benefits of technology

[0030]本申请的至少一个实施例提供一种计算机程序产品,包括计算机程序,所述计算机程序被处理器执行时实现上述所述的方法。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121309342B_ABST
    Figure CN121309342B_ABST
Patent Text Reader

Abstract

The application discloses a configuration hot loading system, method, device, storage medium and computer program product. The system comprises a management application and a plurality of first applications. The management application is configured to publish a first message to a channel of a second cluster when a first condition is met, the first condition comprising that a configuration file content is updated, and the plurality of first applications comprising a first application using the configuration file content. The first message comprises the updated configuration file content and image information of the first application using the configuration file content. Each of the plurality of first applications is configured to subscribe to the first message in the channel published by the management application to the second cluster, determine whether to perform configuration hot loading according to the image information contained in the first message, and perform configuration hot loading according to the updated configuration file content contained in the first message if it is determined to perform configuration hot loading.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to a configuration hot-loading system, method, apparatus, storage medium, and program product. Background Technology

[0002] Among related technologies, Kubernetes is an open-source container orchestration platform that makes it easier to build, deliver, and scale applications by providing powerful container orchestration and automation capabilities. After application deployment, configuration updates are often required during runtime. Currently, this is achieved by adding a sidecar container to each application's container group (POD) within the Kubernetes cluster, enabling hot reloading of application configurations. However, this consumes host resources, leading to wasted host resources and low resource utilization. Summary of the Invention

[0003] In view of this, embodiments of this application aim to provide a configuration hot-loading system, method, apparatus, storage medium, and program product.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a configuration hot-loading system, the system including: a management application and a plurality of first applications, the management application being deployed in a container of a first POD of a first cluster, and each of the first applications being deployed in a container of a second POD of the first cluster;

[0006] The management application is configured to publish a first message to a channel of the second cluster when a first condition is met, the first condition including: the configuration file content is updated, and the plurality of first applications include a first application that uses the configuration file content; the first message includes the updated configuration file content, and the image information of the first application that uses the configuration file content;

[0007] Each of the plurality of first applications is used to subscribe to the first message in the channel published by the management application to the second cluster, and determine whether to perform configuration hot reloading based on the image information contained in the first message. If it is determined to perform configuration hot reloading, configuration hot reloading is performed based on the updated configuration file content contained in the first message.

[0008] Furthermore, according to at least one embodiment of this application, the management application is also used for:

[0009] Start a scheduled task. In each scheduled task cycle after the first scheduled task cycle, retrieve the current configuration file from the first cluster and retrieve the historical configuration file from the second cluster.

[0010] The current configuration file is stored in a first nested hash table, and the historical configuration files are stored in a second nested hash table.

[0011] The first nested hash table is compared with the second nested hash table to obtain the comparison result;

[0012] If the comparison results indicate that the contents of the first nested hash table and the second nested hash table are different, it is determined that the configuration file content has been updated.

[0013] Furthermore, according to at least one embodiment of this application, the management application of the first cluster is also used for:

[0014] In the first scheduled task cycle, an initial configuration file is obtained from the first cluster and stored in the second cluster, wherein the initial configuration file serves as the historical configuration file in the second scheduled task cycle.

[0015] Furthermore, according to at least one embodiment of this application, the management application is also used for:

[0016] After confirming that the configuration file content has been updated, obtain the POD information corresponding to each of the first applications from the first cluster; the POD information includes the mount file of the container of the second POD;

[0017] Based on the POD information, determine whether the plurality of first applications include at least one first application that satisfies a second condition; wherein, the second condition includes the mount file in the POD information corresponding to the first application matching the content of the configuration file;

[0018] If it is determined that at least one first application among the plurality of first applications satisfies the second condition, then it is determined that the plurality of first applications includes a first application that uses the contents of the configuration file.

[0019] Furthermore, according to at least one embodiment of this application, the management application is also used for:

[0020] After determining that the plurality of first applications include a first application that uses the contents of the configuration file, the updated configuration file contents are written into the historical configuration file of the second cluster.

[0021] Furthermore, according to at least one embodiment of this application, the management application is also used for:

[0022] Listen to whether a second message is received from at least one of the plurality of first applications, the second message indicating that configuration hot reloading has failed;

[0023] If the second message is received, an alarm message is generated, which is used to notify the user that hot reloading configuration has failed.

[0024] This application provides a configuration hot-loading method applied to a configuration hot-loading system. The configuration hot-loading system includes a management application and multiple first applications. The management application is deployed in a container of a first POD in a first cluster, and each first application is deployed in a container of a second POD in the first cluster. The method includes:

[0025] When the management application meets a first condition, it publishes a first message to the channel of the second cluster. The first condition includes: the configuration file content is updated, and the plurality of first applications include a first application that uses the configuration file content. The first message includes the updated configuration file content and the image information of the first application that uses the configuration file content.

[0026] Each of the plurality of first applications subscribes to the first message in the channel published by the management application to the second cluster. It determines whether to perform configuration hot reloading based on the image information contained in the first message. If it is determined to perform configuration hot reloading, it performs configuration hot reloading based on the updated configuration file content contained in the first message.

[0027] This application provides an electronic device, including a processor and a memory for storing computer programs that can run on the processor.

[0028] When the processor runs the computer program, it executes the steps of the method described above.

[0029] At least one embodiment of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0030] At least one embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described above.

[0031] The configuration hot-loading system, method, device, storage medium, and computer program product provided in this application embodiment include a management application and multiple first applications. The management application is deployed in a container of a first POD in a first cluster, and each first application is deployed in a container of a second POD in the first cluster. The management application is used to publish a first message to a channel of a second cluster when a first condition is met. The first condition includes: the configuration file content is updated, and the multiple first applications include a first application that uses the configuration file content. The first message includes the updated configuration file content and the image information of the first application that uses the configuration file content. Each of the multiple first applications is used to subscribe to the first message published by the management application to the channel of the second cluster, and determine whether to perform configuration hot-loading based on the image information included in the first message. If configuration hot-loading is determined to be performed, configuration hot-loading is performed based on the updated configuration file content included in the first message.

[0032] By employing the technical solution provided in this application embodiment, a management application is deployed in a PDO (first POD) of the first cluster. Under the condition that the first condition is met, the management application publishes a first message to a channel of the second cluster. In this way, multiple first applications determine whether configuration hot reloading is required to update the configuration based on the first message subscribed to in the channel. Compared with the method of adding a sidecar container to each application's POD in the Kubernetes cluster in related technologies, this application significantly reduces host resource consumption and improves resource utilization efficiency by avoiding the use of sidecar containers. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the structure of the hot-loading system configured in an embodiment of this application;

[0034] Figure 2 This is a schematic diagram of the specific structure of the hot-loading system configured in an embodiment of this application;

[0035] Figure 3 This is a schematic diagram of the working process of the management application in the embodiments of this application. Figure 1 ;

[0036] Figure 4 This is a schematic diagram of the working process of the management application in the embodiments of this application. Figure 2 ;

[0037] Figure 5 This is a schematic diagram illustrating the working process of the first application in this embodiment;

[0038] Figure 6 This is a schematic diagram illustrating the implementation process of the configuration hot-loading method in an embodiment of this application;

[0039] Figure 7 This is a schematic diagram of the composition of the heat-loading device configured in an embodiment of this application;

[0040] Figure 8 This is a schematic diagram of the composition structure of the electronic device according to an embodiment of this application. Detailed Implementation

[0041] Before introducing the technical solutions of the embodiments of this application, the relevant technologies will be introduced first.

[0042] In related technologies, the Kubernetes platform is an open-source container orchestration platform that provides powerful container orchestration and automation capabilities, making it easier to build, deliver, and scale applications, providing a solid foundation for modern cloud-native applications. ConfigMaps or Secrets are resource objects in Kubernetes used to store application configurations in a Kubernetes cluster. These can be environment variables, command-line arguments, and text files. After application deployment, configuration updates are often required during runtime. The typical process involves operations personnel modifying configuration information on the configuration platform and updating the ConfigMap or Secret. A current solution for this is to embed a sidecar container within the application's container group (POD). The configuration directory is added to the sidecar container's synchronous mount. The sidecar container can monitor changes to the ConfigMap or Secret. When a change occurs, the sidecar container reloads the application's configuration file. The sidecar container uses an infinite loop and `fsnotify` to start an event listener, adding the configuration directory to the listener queue. If the listened event is valid, an HTTP request is sent to notify the application to reread the configuration information, thus achieving hot reloading of the application.

[0043] The above solution has the following drawbacks: First, each application's container group (POD) in the Kubernetes cluster requires an additional sidecar container. These sidecar applications consume significant host resources. Given the large number of application PODs in a Kubernetes cluster, adding a sidecar container to each POD results in a substantial waste of host resources. Second, the sidecar container uses an infinite loop `fsnotify` to enable event listening. If too many files or directories are monitored, the sidecar container will also excessively consume host resources, impacting application performance. Third, adding each application's configuration directory to the sidecar container's synchronous mount causes file system redirection and data transfer, increasing memory and CPU consumption, further depleting host resources.

[0044] Based on this, in this embodiment of the application, addressing the issues in related technologies such as the need to add sidecar containers to each application's container group (POD) in a Kubernetes cluster, the added sidecar applications consuming certain host resources, and the impact of using an infinite loop fsnotify to enable event listening on application performance, this embodiment proposes a configuration hot reloading system. The configuration hot reloading system includes a management application and multiple first applications. The management application is deployed in a container of a first POD in the first cluster, and each first application is deployed in a container of a second POD in the first cluster. The management application is used to publish a first message to a channel of the second cluster when a first condition is met. The first condition includes: the configuration file content being updated, and the multiple first applications including a first application using the configuration file content. The first message includes the updated configuration file content and the image information of the first application using the configuration file content. Each of the multiple first applications is used to subscribe to the first message published by the management application to the channel of the second cluster, and determine whether to perform configuration hot reloading based on the image information included in the first message. If configuration hot reloading is determined, configuration hot reloading is performed based on the updated configuration file content included in the first message.

[0045] See Figure 1 , Figure 1 This is a schematic diagram of the structure of the hot-loading system configured in an embodiment of this application, as shown below. Figure 1As shown, the system includes: a management application 11 and a plurality of first applications 12, wherein the management application 11 is deployed in a container of a first POD in a first cluster, and each of the first applications 12 is deployed in a container of a second POD in the first cluster.

[0046] The management application 11 is configured to publish a first message to a channel of the second cluster when a first condition is met, the first condition including: the configuration file content is updated, and the plurality of first applications 12 include a first application 12 that uses the configuration file content; the first message includes the updated configuration file content, and the image information of the first application 12 that uses the configuration file content.

[0047] Each of the plurality of first applications 12 is used to subscribe to the first message in the channel published by the management application to the second cluster, and determine whether to perform configuration hot reloading based on the image information contained in the first message. If it is determined to perform configuration hot reloading, configuration hot reloading is performed based on the updated configuration file content contained in the first message.

[0048] It is understood that the management application 11 can also be described as an intelligent configuration management application. The first application 12 can also be described as an application.

[0049] It is understandable that the first POD can also be described as the first container group, and the second POD can also be described as the second container group.

[0050] It is understandable that the first cluster could refer to a Kubernetes cluster, and the second cluster could refer to a Redis cluster.

[0051] It is understood that the content of the configuration file may refer to the content of the ConfigMap configuration file or the content of the Secret configuration file.

[0052] It is understood that the configuration hot reloading can be understood as dynamically updating the configuration of the first application during runtime without restarting the first application.

[0053] It is understood that the first message may also include the configuration file name corresponding to the updated configuration file content.

[0054] It is understood that the image information may include the image name and version.

[0055] Here, the image information can be determined based on the POD information corresponding to each of the first applications 12 obtained by the management application 11 from the first cluster; wherein, the POD information includes the image information of the first application 12.

[0056] Here, the channel for publishing the first message to the second cluster can refer to constructing a string in a preset format according to the image information such as the image name and version, and the updated configuration file content, and using the preset string as the channel for publishing the first message to the second cluster, i.e., the Redis cluster.

[0057] Here, each of the first applications 12 is specifically configured to: compare the image information included in the first message, such as the image name and version, with the image name and version of the image it uses; if they are the same, it indicates that it is the configuration of the first application 12 itself, and perform hot reloading of the configuration according to the updated configuration file content included in the first message. Otherwise, it indicates that it is not the configuration of the first application 12 itself, and hot reloading of the configuration is not required.

[0058] In practical applications, before the management application 11 publishes the first message to the channel of the second cluster, it is necessary to determine whether the first condition is met. It can first determine whether the configuration file content has been updated, and then determine whether the plurality of first applications 12 include a first application 12 that uses the configuration file content.

[0059] Based on this, in some embodiments, the management application 11 is further configured to:

[0060] Start a scheduled task. In each scheduled task cycle after the first scheduled task cycle, retrieve the current configuration file from the first cluster and retrieve the historical configuration file from the second cluster.

[0061] The current configuration file is stored in a first nested hash table, and the historical configuration files are stored in a second nested hash table.

[0062] The first nested hash table is compared with the second nested hash table to obtain the comparison result;

[0063] If the comparison results indicate that the contents of the first nested hash table and the second nested hash table are different, it is determined that the configuration file content has been updated.

[0064] Here, if the comparison result indicates that the contents of the first nested hash table and the second nested hash table are the same, it is determined that the configuration file content has not been updated. In this case, the first application 12 does not need to perform configuration hot reloading.

[0065] Here, the period of the scheduled task can be preset, for example, set to the default value of 60 seconds.

[0066] Here, the first nested hash table can consist of two nested hash tables, including an outer hash table and an inner hash table, wherein the inner hash table is used to store the contents of the current configuration file.

[0067] Here, the second nested hash table can consist of two nested hash tables, including an outer hash table and an inner hash table, wherein the inner hash table is used to store the contents of historical configuration files.

[0068] Here, the difference between the contents of the first nested hash table and the second nested hash table can be understood as the difference between the contents of the current configuration file stored in the inner hash table of the first nested hash table and the contents of the historical configuration files stored in the inner hash table of the second nested hash table.

[0069] Furthermore, if the comparison result indicates that the contents of the first nested hash table and the second nested hash table are different, it is determined that the configuration file content has been updated, and the content of the current configuration file stored in the inner hash table of the first nested hash table is used as the updated configuration file content.

[0070] In some embodiments, the management application 11 is further configured to:

[0071] In the first scheduled task cycle, an initial configuration file is obtained from the first cluster and stored in the second cluster, wherein the initial configuration file serves as the historical configuration file in the second scheduled task cycle.

[0072] Here, we will take a ConfigMap configuration file as an example to explain the process of determining when the configuration file content has been updated.

[0073] First, during the first scheduled task cycle, the ConfigMap query interface of the first cluster (e.g., a Kubernetes cluster) is invoked to obtain the initial configuration file, i.e., the ConfigMap initial configuration file, and then stored in the second cluster (e.g., Redis). This initial configuration file then serves as the historical configuration file in the second cluster (e.g., Redis) during the second scheduled task cycle.

[0074] Then, in the second scheduled task cycle after the first scheduled task cycle, the ConfigMap query interface of the first cluster, such as the Kubernetes cluster, is called to obtain the current configuration file (the current ConfigMap configuration file) from the first cluster, such as the Kubernetes cluster, and the historical configuration file (the initial ConfigMap configuration file) from the second cluster, Redis.

[0075] Next, the current configuration file is stored in the first nested hash table, and the historical configuration files are stored in the second nested hash table.

[0076] Here, the first nested hash table is represented by Hash table 1. The key of the outer hash table in Hash table 1 is the name of the outer hash table, such as the name of ConfigMap, and the value is the name of the inner hash table. The key of the inner hash table is the name of the configuration file, i.e., the name of the current configuration file, and the value is the content of the configuration file, i.e., the content of the current configuration file.

[0077] Here, the second nested hash table is represented by Hash Table 2. The key of the outer hash table of Hash Table 2 is the name of the outer hash table, such as the name of ConfigMap, and the value is the name of the inner hash table. The key of the inner hash table is the file name, and the value is the content of the historical configuration file.

[0078] Here, if the content of the current configuration file of the first application 12 stored in the inner hash table of the first nested hash table is different from the content of the historical configuration file of the first application 12 stored in the inner hash table of the second nested hash table, then it is determined that the configuration file content has been updated.

[0079] Here, if the content of the current configuration file of the first application 12 stored in the inner hash table of the first nested hash table is the same as the content of the historical configuration file of the first application 12 stored in the inner hash table of the second nested hash table, then it is determined that the configuration file content has not been updated, and the first application 12 does not need to perform configuration hot reloading.

[0080] In practical applications, before the management application 11 publishes the first message to the channel of the second cluster, it is also necessary to determine whether the first condition is met. That is, after determining that the configuration file content has been updated, it is also necessary to determine whether the plurality of first applications 12 include a first application 12 that uses the configuration file content.

[0081] Based on this, in some embodiments, the management application 11 is further configured to:

[0082] After confirming that the configuration file content has been updated, obtain the POD information corresponding to each of the first applications from the first cluster; the POD information includes the mount file of the container of the second POD;

[0083] Based on the POD information, determine whether the plurality of first applications 12 include at least one first application 12 that satisfies the second condition; wherein, the second condition includes that the mount file in the POD information corresponding to the first application 12 matches the content of the configuration file;

[0084] If it is determined that at least one first application 12 among the plurality of first applications 12 satisfies the second condition, then it is determined that the plurality of first applications 12 includes a first application 12 that uses the contents of the configuration file.

[0085] For example, suppose the POD information includes the mount file of the container of the second POD as ConfigMap, and the configuration file content is the ConfigMap configuration file content. Both correspond to ConfigMap, that is, the mount file in the POD information corresponding to the first application matches the configuration file content. Therefore, it is determined that the first application 12 corresponding to the POD information satisfies the second condition.

[0086] For example, suppose the POD information includes the mount file of the container of the second POD as ConfigMap, and the configuration file content is the Secret configuration file content. One corresponds to ConfigMap and the other corresponds to Secret. That is, the mount file in the POD information corresponding to the first application 12 does not match the configuration file content. Therefore, it is determined that the first application 12 corresponding to the POD information does not meet the second condition.

[0087] In some embodiments, the management application 11 is further configured to:

[0088] After determining that one of the plurality of first applications 12 uses the configuration file content, the updated configuration file content is written into the historical configuration file of the second cluster.

[0089] Here, writing the updated configuration file content into the historical configuration file of the second cluster can be understood as replacing the old configuration file content in the historical configuration file with the updated configuration file content.

[0090] In some embodiments, the management application 11 is further configured to:

[0091] Listen to whether a second message is received from at least one of the plurality of first applications 12, the second message indicating that configuration hot reloading has failed;

[0092] If the second message is received, an alarm message is generated, which is used to notify the user that hot reloading configuration has failed.

[0093] The following describes the working process of the management application and multiple first applications in the embodiments of this application with specific examples.

[0094] See Figure 2 , Figure 2 This is a schematic diagram of the specific structure of the hot-loading system configured in an embodiment of this application, as shown below. Figure 2 As shown, the system includes an intelligent configuration management application and multiple configuration hot-reloading applications; wherein, the intelligent configuration management application corresponds to the management application 11 mentioned above, and the intelligent configuration management application is deployed in the container of the first POD of the first cluster, i.e., the Kubernetes cluster; the configuration hot-reloading application corresponds to the first application 12 mentioned above, and the configuration hot-reloading application is deployed in the container of the second POD of the first cluster, i.e., the Kubernetes cluster.

[0095] Here, the intelligent configuration management application is deployed in a POD (Planetary Object) within the first cluster (Kubernetes cluster), and can include two modules: an intelligent management module and an alarm monitoring module. The intelligent management module runs as a scheduled task. Upon startup, in the first scheduled task cycle, it calls the backend interface of the first cluster (Kubernetes cluster) to query the configuration content of the ConfigMap or Secret, and writes the configuration content to the second cluster (Redis cluster). In each subsequent scheduled task cycle, it first queries the configuration content of the ConfigMap or Secret in the first cluster (Kubernetes cluster), i.e., the current configuration file, and then reads the configuration content stored in the second cluster (Redis cluster), i.e., the historical configuration file, comparing the two configuration contents for consistency. If the comparison results are consistent, it indicates that the configuration has not been updated, and the first application does not need to perform configuration hot reloading. If the comparison results are inconsistent, it indicates that the configuration file content has been updated. The next step is to query the POD information in the first cluster (i.e., the Kubernetes cluster) to check whether the first application in each container of the second POD uses the configuration content. If it is not used, it indicates that the first application in the container of the second POD does not need to perform configuration hot reloading. If it is used, the updated configuration file content and the image information of the first application using the configuration file content, such as the image name and version, are published to the channel of the second cluster (i.e., the Redis cluster). The latest configuration content is also written to the historical configuration file of the second cluster (i.e., the Redis cluster), thereby achieving intelligent determination of the application that needs configuration updates. The alarm listening module is responsible for listening to the reporting of configuration hot reloading failure messages (i.e., the second message) of each first application. After receiving the second message, it converts the configuration hot reloading failure message (i.e., the second message) into an alarm message and sends it. The alarm message is used to notify the user that the configuration hot reloading has failed, so that users such as operation and maintenance personnel can handle it in a timely manner.

[0096] The configuration hot-reload module is a module within the application. Each container in the second POD contains an application (or is described as a configuration hot-reload application) that includes this module. This module subscribes to a channel of the second cluster, i.e., the Redis cluster. Upon receiving the first message from this channel, it first checks if the image information (name and version) used by the application matches the image information (name and version) in the first message from the subscribed channel. If they don't match, it means this isn't its own configuration update content and doesn't require configuration hot-reload. If they match, the application reads the updated configuration file content from the first message from the subscribed channel and performs configuration hot-reload. If the application's configuration hot-reload fails, the configuration hot-reload module calls the hot-reload failure reporting interface to report the configuration hot-reload failure message (the second message) to the alarm listening module included in the intelligent configuration management application.

[0097] The working process of the aforementioned intelligent configuration management application is explained below.

[0098] The intelligent management module is a module of the intelligent configuration management application. It is responsible for intelligently monitoring changes in the ConfigMap or Secret configuration of the first cluster, i.e., the Kubernetes cluster, and promptly publishing the updated configuration file content.

[0099] The alarm monitoring module is a module of the intelligent configuration management application. It is responsible for receiving messages of configuration hot reloading failure and promptly notifying operation and maintenance personnel to handle the issue.

[0100] See Figure 3 , Figure 3 This is a schematic diagram illustrating the working process of the management application in an embodiment of this application, such as... Figure 3 As shown, steps 301 to 311 are included:

[0101] Step 301: The intelligent management module in the management application 11 (intelligent configuration management application) runs as a scheduled task. When it starts, it reads the configuration parameters, which mainly include the relevant background query interfaces of the first cluster, i.e., the Kubernetes cluster, including the ConfigMap query interface, Secret query interface, and POD query interface; the period of the scheduled task (default 60 seconds); the access address and password of the second cluster, i.e., the Redis cluster; and the channel name of the second cluster, i.e., the Redis cluster.

[0102] Here, after executing step 301, either step 302 or step 303 is executed.

[0103] Step 302: After the task cycle begins, call the ConfigMap query interface of the first cluster, i.e. the Kubernetes cluster, parse the query results, and store the parsed results in the first nested hash table (represented by Hash Table 1). The key of the outer hash table in Hash Table 1 is the name of the outer hash table, such as the ConfigMap name, and the value is the name of the inner hash table. The key of the inner hash table is the name of the configuration file, i.e. the name of the current configuration file, and the value is the content of the configuration file, i.e. the content of the current configuration file.

[0104] Step 303: After the task cycle begins, call the Secret query interface of the first cluster, i.e. the Kubernetes cluster, parse the query result, and store the parsed result in the first nested Hash table (represented by Hash table 1). The key of the outer hash table of Hash table 1 is the name of the outer hash table, such as the Secret name, and the value is the name of the inner hash table. The key of the inner hash table is the name of the configuration file and the name of the current configuration file, and the value is the content of the configuration file, i.e. the content of the current configuration file.

[0105] Step 304: Determine if the current task cycle is the first scheduled task cycle. If it is the first scheduled task cycle, it means that the intelligent configuration management program has just started and does not need to perform hot reloading of configuration. Proceed to step 310. If it is not the first scheduled task cycle, proceed to the next step, i.e., step 305.

[0106] Step 305: Read the contents of the historical configuration files stored in the second cluster, i.e., the Redis cluster, and store them in the second nested hash table (represented by Hash Table 2). The key of the outer hash table of Hash Table 2 is the name of the outer hash table, such as ConfigMap or Secret name, and the value is the name of the inner hash table. The key of the inner hash table is the file name, and the value is the contents of the historical configuration file.

[0107] Here, for ConfigMap configuration files, Hash table 1 stores the current ConfigMap configuration file, and Hash table 2 stores the historical ConfigMap configuration files.

[0108] Here, for the Secret configuration file, Hash table 1 stores the current Secret configuration file, and Hash table 2 stores the historical Secret configuration files.

[0109] Step 306: Compare Hash Table 1 and Hash Table 2. Loop through the entries where the ConfigMap or Secret name is the same and compare the configuration file content in Hash Table 1 and Hash Table 2 for consistency. If no inconsistent configuration file content is found, proceed to Step 311. If an inconsistent configuration is found, it is determined that the configuration file content has been updated. Execute Step 307 and store the inconsistent configuration content, i.e., the updated configuration file content, in a nested Hash table (Hash Table 3). The key of the outer hash table is the ConfigMap or Secret name, and the value is the name of the inner hash table. The key of the inner hash table is the updated configuration file name, and the value is the updated configuration file content.

[0110] Step 307: Call the POD query interface of the first cluster, i.e. the Kubernetes cluster, to parse the POD information corresponding to each second POD. The POD information includes the name and version of the image of the first application in the container of the second POD, the mount information of the container of the second POD, i.e. the name of the ConfigMap or Secret mount file, and the name of the configuration file.

[0111] Step 308: Based on the mount files included in the POD information, determine whether the first application in the container of the second POD uses the updated configuration file content (i.e., the updated configuration file content in Hash Table 3). Specifically, determine whether any of the multiple first applications contains at least one first application that meets the second condition, where the second condition includes a match between the mount file and the configuration file content. If not, proceed to step 311; if so, it is determined that at least one of the multiple first applications contains at least one first application that meets the second condition, then proceed to the next step, step 309.

[0112] Step 309: Based on the updated configuration file (Hash Table 3), construct a JSON string according to the image name and version of the application using the updated configuration file content, the configuration file name, and the updated configuration file content. Publish the JSON string as the first message to the channel of the second cluster, i.e., the Redis cluster.

[0113] Step 310: Write the updated configuration file content into the historical configuration file of the second cluster (i.e., the Redis cluster) using a hash data type, such as a third nested hash table, to replace the old configuration file content. The key of the outer hash table is the name of the outer hash table, such as ConfigMap or Secret name, and the value is the name of the inner hash table. The key of the inner hash table is the configuration file name, and the value is the updated configuration file content.

[0114] Step 311: This task cycle has ended. Waiting to enter the next task cycle.

[0115] See Figure 4 , Figure 4 This is a schematic diagram illustrating the working process of the management application in an embodiment of this application, such as... Figure 4 As shown, steps 401 to 404 are included:

[0116] Step 401: When the alarm listening module in the management application 11 (intelligent configuration management application) starts, it reads the configuration parameters, mainly the listening port and the alarm sending interface address.

[0117] Step 402: The alarm listening module included in the management application 11 (intelligent configuration management application) enables the listening port, starts listening to the configuration hot reload failure reporting interface, and waits to receive the configuration hot reload failure message sent by the first application, i.e., the second message.

[0118] Step 403: The alarm listening module included in the management application 11 (intelligent configuration management application) receives the configuration hot reload failure report message, i.e., the second message, sent by the first application, parses the configuration hot reload failure message, and converts it according to the alarm message format to obtain the alarm message.

[0119] Step 404: The management application 11 (intelligent configuration management application) calls the alarm sending interface to send an alarm message, which is used to prompt the user that the configuration hot reloading has failed.

[0120] The following explains the working process of the above-described hot-loading application configuration.

[0121] See Figure 5 , Figure 5 This is a schematic diagram of the working process of the first application in this embodiment of the application, as shown below. Figure 5 As shown, steps 501 to 507 are included:

[0122] Step 501: The configuration hot reload module included in each first application 12 (or described as a configuration hot reload application or application) starts to read configuration parameters, mainly including the access address and password of the second cluster, i.e., the Redis cluster, the channel name for subscribing to the second cluster, i.e., the Redis cluster, and the interface address for reporting hot reload failures, etc.

[0123] Here, the configuration hot reloading module is a module that every first application has. It is responsible for subscribing to the channel of the second cluster, i.e., the Redis cluster, reading configuration updates and performing hot reloading, and promptly reporting any failures in hot reloading configuration.

[0124] Step 502: Each first application 12 (or described as a configuration hot-reload application or application) includes a configuration hot-reload module that subscribes to the channel of the second cluster, i.e., the Redis cluster, and waits to receive a first message published by the management application (intelligent configuration management application) on the channel of the second cluster; the first message includes updated configuration file content and the corresponding configuration file name, as well as the image information of the first application using the configuration file content.

[0125] Step 503: Each first application 12 (or described as a configuration hot-load application or application) includes a configuration hot-load module that receives a first message published on the channel, parses the first message, and obtains the content in the first message, which may include the image information of the first application using the configuration file content, such as the image name and version, the configuration file name corresponding to the updated configuration file content, the updated configuration file content, etc.

[0126] If they are different, it means that it is not the application's own configuration and hot reloading of the configuration is not required; if they are the same, it means that it is the application's own configuration, and the updated configuration file content should be written into the configuration file and then hot reloading of the configuration should be performed.

[0127] Step 504: The configuration hot reloading module in each first application 12 (or described as a configuration hot reloading application or application) queries the image name and version of the image used by the first application, and determines whether the image name and version used by itself are the same as the image name and version included in the first message. If they are different, it means that it is not the application's own configuration and configuration hot reloading is not required, and the process ends; if they are the same, it means that it is the application's own configuration, and proceeds to the next step, namely step 505.

[0128] Step 505: The configuration hot reloading module of the first application 12 (or described as a configuration hot reloading application or application) includes writing the updated configuration file content into the configuration file of the first application according to the configuration file name. Then the first application performs hot reloading configuration, that is, the configuration of the first application is updated without restarting the first application.

[0129] Step 506: The configuration hot-loading module included in the first application 12 (or described as a configuration hot-loading application or application) checks whether the configuration hot-loading is successful. If the configuration hot-loading is successful, the process ends; if the hot-loading fails, proceed to the next step, namely step 507.

[0130] Step 507: The configuration hot loading module of the first application 12 (or described as a configuration hot loading application or application) that performs configuration hot loading calls the configuration hot loading failure reporting interface to report the configuration hot loading failure information, i.e., the second message, to the intelligent configuration management application. After receiving the second message, the intelligent configuration management application generates an alarm message, which is used to prompt the user that the configuration hot loading has failed.

[0131] The embodiments of this application have the following technical advantages:

[0132] (1) By deploying a management application in a PDO (first POD) of the first cluster, the management application publishes a first message to the channel of the second cluster when the first condition is met. In this way, multiple first applications determine whether configuration hot reloading is required to update the configuration based on the first message subscribed to in the channel.

[0133] Compared to related technologies that add sidecar containers to each application's container group (POD) in a Kubernetes cluster, this approach eliminates the need to mount sidecar containers to each application's POD. Instead, the application is deployed and managed within a single POD, significantly saving host resources and preventing resource waste. This solves the problem of excessive host resource consumption in related technologies. Specifically, related technologies require adding a sidecar container to each application POD. Given the large number of PODs in a Kubernetes cluster, adding a sidecar container to each POD consumes enormous amounts of host resources, representing a significant waste and increasing the cost of purchasing additional host resources. In this application, managing application deployment only requires a single POD, greatly conserving host resources.

[0134] (2) In related technologies, the use of fsnotify event listening in an infinite loop will consume a lot of host resources and affect the performance of the application if the number of monitored files or directories is too large. In this application, the management application intelligently determines the POD application that needs hot reloading configuration by calling the backend API interface of the first cluster, such as the Kubernetes cluster. It does not need to use fsnotify in an infinite loop to listen for events to determine whether the configuration file or directory has been updated, thus effectively solving the impact on application performance.

[0135] (3) In related technologies, each application's configuration directory is added to the synchronous mount of the sidecar container. Setting the mount directory will cause file system redirection and data transfer, which will increase memory and CPU consumption and occupy certain host resources. In this application, the configuration file content of the first application is stored in a second cluster, such as a Redis cluster. The first application only needs to read from the channel of the subscribed second cluster, such as the Redis cluster, which solves the problem of host resource consumption caused by directory mounting.

[0136] (4) In this application, the management application calls the ConfigMap or Secret backend query interface of the first cluster, such as the Kubernetes cluster, through a scheduled task to obtain the current configuration file. It compares the configuration content in the latest ConfigMap or Secret with the historical configuration content in the second cluster, such as Redis, to determine whether the configuration file content has been updated. It checks the POD information through the backend query interface to see whether the first application in the container of the second POD uses the updated configuration file content. If the first condition is met, it publishes a first message to the second cluster, such as Redis. The first message includes the updated configuration file content and the image information, such as the image name and version, that uses the configuration file content. Each first application in the container of the second POD subscribes to the first message in the channel of the second cluster, such as Redis. After determining that the image information, such as the name and version, included in the first message is its own configuration, it reads the updated configuration file content included in the first message and performs hot reloading, thereby realizing intelligent hot reloading of application configuration.

[0137] (5) In this application, the alarm listening module in the management application is responsible for listening to the configuration hot reloading failure result. It sends alarms in a timely manner for applications that fail to reload, so that operation and maintenance personnel can handle them manually in a timely manner and reduce the impact of hot reloading failure on business.

[0138] See Figure 6 , Figure 6This is a schematic diagram illustrating the implementation flow of the configuration hot-loading method according to an embodiment of this application. It is applied to a configuration hot-loading system, which includes a management application and multiple first applications. The management application is deployed in a container of a first POD in a first cluster, and each first application is deployed in a container of a second POD in the first cluster. Figure 6 As shown, the method includes steps 601 to 602:

[0139] Step 601: When the management application meets the first condition, it publishes the first message to the channel of the second cluster. The first condition includes: the configuration file content is updated, and a first application using the configuration file content is included in a plurality of first applications; the first message includes the updated configuration file content and the image information of the first application using the configuration file content.

[0140] Step 602: Each of the multiple first applications subscribes to the first message published by the management application to the second cluster through the channel. Based on the image information contained in the first message, it is determined whether to perform configuration hot reloading. If it is determined to perform configuration hot reloading, configuration hot reloading is performed based on the updated configuration file content contained in the first message.

[0141] In some embodiments, the method further includes:

[0142] The management application starts a scheduled task. In each scheduled task cycle after the first scheduled task cycle, it retrieves the current configuration file from the first cluster and the historical configuration file from the second cluster. The current configuration file is stored in a first nested hash table, and the historical configuration file is stored in a second nested hash table. The first nested hash table and the second nested hash table are compared to obtain a comparison result. If the comparison result indicates that the contents of the first nested hash table and the second nested hash table are different, it is determined that the configuration file content has been updated.

[0143] In some embodiments, the method further includes:

[0144] The management application retrieves an initial configuration file from the first cluster during the first scheduled task cycle and stores the initial configuration file in the second cluster, wherein the initial configuration file serves as the historical configuration file during the second scheduled task cycle.

[0145] In some embodiments, the method further includes:

[0146] After determining that the configuration file content has been updated, the management application obtains POD information corresponding to each first application from the first cluster; the POD information includes the mount file of the container of the second POD; based on the POD information, it determines whether the plurality of first applications include at least one first application that meets a second condition; wherein, the second condition includes that the mount file in the POD information corresponding to the first application matches the configuration file content; if it is determined that the plurality of first applications include at least one first application that meets the second condition, then it is determined that the plurality of first applications include a first application that uses the configuration file content.

[0147] In some embodiments, the method further includes:

[0148] After determining that one of the plurality of first applications uses the content of the configuration file, the management application writes the updated configuration file content into the historical configuration file of the second cluster.

[0149] In some embodiments, the method further includes:

[0150] The management application listens to see if it receives a second message from at least one of the plurality of first applications, the second message indicating that configuration hot reloading has failed; if the second message is received, an alarm message is generated, the alarm message being used to prompt the user that configuration hot reloading has failed.

[0151] It should be noted that the implementation principles of the management application and multiple primary applications have been described above and will not be repeated here.

[0152] To implement the configuration hot-loading method of this application embodiment, this application embodiment also provides a configuration hot-loading device, which is installed in an electronic device and applied to a configuration hot-loading system. The system includes: a management application and a plurality of first applications. The management application is deployed in a container of a first POD of a first cluster, and each first application is deployed in a container of a second POD of the first cluster. Figure 7 This is a schematic diagram of the composition of the heat-loading device configured in an embodiment of this application, as shown below. Figure 7 As shown, the device includes:

[0153] The first processing module 71 is configured to publish a first message to a channel of the second cluster through a management application when a first condition is met, wherein the first condition includes: the configuration file content is updated, and the plurality of first applications include a first application that uses the configuration file content; the first message includes the updated configuration file content, and the image information of the first application that uses the configuration file content.

[0154] The second processing module 72 is used to subscribe to the first message published by the management application to the second cluster through each of the plurality of first applications, determine whether to perform configuration hot reloading based on the image information contained in the first message, and if it is determined to perform configuration hot reloading, perform configuration hot reloading based on the updated configuration file content contained in the first message.

[0155] In some embodiments, the first processing module 71 is further configured to:

[0156] By starting a scheduled task through the management application, in each scheduled task cycle after the first scheduled task cycle, the current configuration file is obtained from the first cluster, and the historical configuration file is obtained from the second cluster; the current configuration file is stored in a first nested hash table, and the historical configuration file is stored in a second nested hash table; the first nested hash table and the second nested hash table are compared to obtain a comparison result; if the comparison result indicates that the contents of the first nested hash table and the second nested hash table are different, it is determined that the configuration file content has been updated.

[0157] In some embodiments, the first processing module 71 is further configured to:

[0158] The management application retrieves an initial configuration file from the first cluster during the first scheduled task cycle and stores the initial configuration file in the second cluster, wherein the initial configuration file serves as the historical configuration file during the second scheduled task cycle.

[0159] In some embodiments, the first processing module 71 is further configured to:

[0160] After determining that the configuration file content has been updated, the management application obtains POD information corresponding to each first application from the first cluster; the POD information includes the mount file of the container of the second POD; based on the POD information, it is determined whether the plurality of first applications include at least one first application that meets a second condition; wherein, the second condition includes that the mount file in the POD information corresponding to the first application matches the configuration file content; if it is determined that the plurality of first applications include at least one first application that meets the second condition, then it is determined that the plurality of first applications include a first application that uses the configuration file content.

[0161] In some embodiments, the first processing module 71 is further configured to:

[0162] After determining that the plurality of first applications include a first application that uses the configuration file content, the management application writes the updated configuration file content into the historical configuration file of the second cluster.

[0163] In some embodiments, the first processing module 71 is further configured to:

[0164] The management application listens for whether it receives a second message from at least one of the plurality of first applications, the second message indicating that configuration hot reloading has failed; if the second message is received, an alarm message is generated, the alarm message being used to notify the user that configuration hot reloading has failed.

[0165] In practical applications, the first processing module 71 and the second processing module 72 can be implemented by the processor configured in the hot-loading device.

[0166] It should be noted that the configuration hot-loading device provided in the above embodiments is only illustrated by the division of the above program modules. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program modules to complete all or part of the processing described above. In addition, the configuration hot-loading device and the configuration hot-loading method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0167] This application also provides an electronic device, such as... Figure 8 As shown, it includes:

[0168] Communication interface 81 enables information exchange with other devices;

[0169] The processor 82, connected to the communication interface 81, is used to execute the methods provided by one or more technical solutions on the electronic device side when running a computer program. The computer program is stored in the memory 83.

[0170] It should be noted that the specific processing procedures of the processor 82 and the communication interface 81 are detailed in the method embodiment and will not be repeated here.

[0171] Of course, in practical applications, the various components in electronic device 80 are coupled together through bus system 84. It can be understood that bus system 84 is used to realize the connection and communication between these components. In addition to a data bus, bus system 84 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, in... Figure 8 The general labeled all buses as Bus System 84.

[0172] The memory 83 in this embodiment is used to store various types of data to support the operation of the electronic device 80. Examples of such data include any computer program used to operate on the electronic device 80.

[0173] The methods disclosed in the embodiments of this application can be applied to the processor 82, or implemented by the processor 82. The processor 82 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware or by instructions in the form of software in the processor 82. The processor 82 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor 82 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in the memory 83. The processor 82 reads the information in the memory 83 and completes the steps of the aforementioned method in combination with its hardware.

[0174] In an exemplary embodiment, the electronic device 80 may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0175] It is understood that the memory (memory 83) in the embodiments of this application can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0176] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory storing a computer program, which can be executed by the processor 82 of the electronic device 80 to complete the steps described in the aforementioned electronic device-side method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0177] For example, embodiments of this application also provide a computer program product, including a computer program that can be executed by a processor 82 of an electronic device 80 to perform the steps described in any of the foregoing methods.

[0178] It should be noted that terms such as "first" and "second" are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0179] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0180] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application.

Claims

1. A configuration hot-loading system, characterized in that, The system includes: a management application and multiple first applications, wherein the management application is deployed in a container of a first container group (POD) of a first cluster, and each first application is deployed in a container of a second POD of the first cluster. The management application is configured to publish a first message to a channel of the second cluster when a first condition is met, the first condition including: the configuration file content is updated, and the plurality of first applications include a first application that uses the configuration file content; the first message includes the updated configuration file content, and the image information of the first application that uses the configuration file content; Each of the plurality of first applications is used to subscribe to the first message in the channel published by the management application to the second cluster, and determine whether to perform configuration hot reloading based on the image information contained in the first message. If it is determined to perform configuration hot reloading, configuration hot reloading is performed based on the updated configuration file content contained in the first message.

2. The system according to claim 1, characterized in that, The management application is also used for: Start a scheduled task. In each scheduled task cycle after the first scheduled task cycle, retrieve the current configuration file from the first cluster and retrieve the historical configuration file from the second cluster. The current configuration file is stored in a first nested hash table, and the historical configuration files are stored in a second nested hash table. The first nested hash table is compared with the second nested hash table to obtain the comparison result; If the comparison results indicate that the contents of the first nested hash table and the second nested hash table are different, it is determined that the configuration file content has been updated.

3. The system according to claim 2, characterized in that, The management application of the first cluster is also used for: In the first scheduled task cycle, an initial configuration file is obtained from the first cluster and stored in the second cluster, wherein the initial configuration file serves as the historical configuration file in the second scheduled task cycle.

4. The system according to claim 2 or 3, characterized in that, The management application is also used for: After confirming that the configuration file content has been updated, obtain the POD information corresponding to each of the first applications from the first cluster; the POD information includes the mount file of the container of the second POD; Based on the POD information, determine whether the plurality of first applications include at least one first application that satisfies a second condition; wherein, the second condition includes the mount file in the POD information corresponding to the first application matching the content of the configuration file; If it is determined that at least one first application among the plurality of first applications satisfies the second condition, then it is determined that the plurality of first applications includes a first application that uses the contents of the configuration file.

5. The system according to claim 4, characterized in that, The management application is also used for: After determining that the plurality of first applications include a first application that uses the contents of the configuration file, the updated configuration file contents are written into the historical configuration file of the second cluster.

6. The system according to claim 1, characterized in that, The management application is also used for: Listen to whether a second message is received from at least one of the plurality of first applications, the second message indicating that configuration hot reloading has failed; If the second message is received, an alarm message is generated to notify the user that hot reloading configuration has failed.

7. A configuration hot-loading method, characterized in that, The system is used to configure a hot-load system, which includes a management application and multiple first applications. The management application is deployed in a container of a first POD in a first cluster, and each first application is deployed in a container of a second POD in the first cluster. The method includes: When the management application meets a first condition, it publishes a first message to the channel of the second cluster. The first condition includes: the configuration file content is updated, and the plurality of first applications include a first application that uses the configuration file content. The first message includes the updated configuration file content and the image information of the first application that uses the configuration file content. Each of the plurality of first applications subscribes to the first message in the channel published by the management application to the second cluster. It determines whether to perform configuration hot reloading based on the image information contained in the first message. If it is determined to perform configuration hot reloading, it performs configuration hot reloading based on the updated configuration file content contained in the first message.

8. An electronic device, characterized in that, This includes a processor and memory for storing computer programs that can run on the processor. When the processor is used to run the computer program, it performs the steps of the method of claim 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method of claim 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method of claim 7.

Citation Information

Patent Citations

  • File updating method and device

    CN106909411A

  • Network element configuration change method, device and system, electronic equipment and storage medium

    CN115550170A