Postgresql database elastic scaling method based on cloud native platform in k8s environment

Abstract

The application discloses a PostgreSQL database elastic scaling method based on a cloud native platform in a k8s environment, which comprises the following steps: receiving alarm information; calling a corresponding alarm information processing module based on a preset identifier, analyzing the alarm information by using the corresponding alarm information processing module, and executing a corresponding scaling processing strategy according to the type of the alarm information; directly establishing a connection with an apiserver of the k8s environment by using a k8s client module, and adaptively modifying a pg-CustomResource resource scaling value based on the scaling processing strategy; listening to resource changes of all database pg-CustomResource by using a pg-operator module, executing an elastic scaling operation, and updating a state value of the pg-CustomResource according to an elastic scaling execution result. If the operation is completed, the resource changes of the PG database pg-CustomResource are listened to by using a database resource listening module, and whether the automatic elastic scaling task is completed is judged. The method can greatly improve the flexibility of automatic elastic scaling and meet various needs in different scenes.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for elastic scaling of PostgreSQL database based on a cloud-native platform in a Kubernetes environment. Background Technology

[0002] PostgreSQL is one of the world's most advanced open-source relational databases, known for its stability, ease of use, and high performance. However, due to its open-source nature and rich functionality, it requires professional database DBAs for maintenance. In today's big data environment, user demands on databases are increasing daily. When database capacity can no longer meet the high performance requirements of applications, seamless scaling of the database is needed to ensure application reliability. This operation consumes a significant amount of user effort and time. Kubernetes is mature in deploying and scaling stateless applications, but its support for stateful database applications is still relatively limited.

[0003] Currently, there are basically three ways to scale up and down a database. The first is to set up monitoring and alerts, and then manually scale the database up or down when a threshold is reached. This method is inefficient and prone to errors due to its cumbersome operation. The second method is to allocate a large amount of resources to the database, making it difficult for the database to reach the threshold. This method greatly increases the user's costs. The third method is to configure resource threshold monitoring through database tools or platforms, and then scale the database resources up or down when the threshold is reached. However, these database tools or platforms are often not natively compatible with the Kubernetes cloud environment. When used on Kubernetes, they encounter various problems such as network communication difficulties, inability to schedule resources properly, and service discovery anomalies. Moreover, the operation and maintenance of PostgreSQL databases are performed using non-standardized commands, which cannot guarantee the accuracy and idempotency of operation and maintenance. It does not utilize pg-operator for automated, standardized, and efficient database operation and maintenance.

[0004] Kubernetes does not provide components or features for automatically scaling cloud-native applications, and all three methods mentioned above have obvious drawbacks.

[0005] Many cloud-native database platforms use kubectl commands to interact with Kubernetes cloud environments. Logging into the master node to execute commands poses a significant security risk to the entire Kubernetes cloud environment. Furthermore, maintaining Kubernetes resources requires cumbersome code and high performance. Summary of the Invention

[0006] This application provides a method for elastic scaling of PostgreSQL databases based on a cloud-native platform in a Kubernetes environment. It is natively compatible with the Kubernetes environment and can fully utilize the advantages of cloud computing's "resource pooling" to significantly improve the flexibility of automatic elastic scaling and meet various needs in different scenarios. It uses pg-operator to automate the operation and maintenance of the PG database, thereby improving the stability and reliability of the database service.

[0007] This application provides a method for elastic scaling of a PostgreSQL database based on a cloud-native platform in a Kubernetes environment. The cloud-native platform and at least one PostgreSQL (PG) database are deployed in the Kubernetes environment. The cloud-native platform manages the at least one PG database. The elastic scaling method includes:

[0008] Receive alarm information, wherein the alarm information is sent based on monitoring of the at least one PG database and according to a preset alarm rule threshold;

[0009] Based on the preset identifier, the corresponding alarm information processing module is invoked, the alarm information is parsed using the corresponding alarm information processing module, and the corresponding scaling processing strategy is executed according to the type of alarm information.

[0010] Using the Kubernetes client module, a direct connection is established with the Kubernetes environment's API server, and the resource status of the Kubernetes environment is checked based on the scaling policy to adaptively modify the pg-CustomResource resource scaling value.

[0011] Using the pg-operator module, monitor resource changes in all pg-CustomResource databases, perform elastic scaling operations to automate the operation and maintenance of the pg database cluster, and update pg-CustomResource resources after the operation is completed;

[0012] The database resource monitoring module is used to monitor resource changes in the PG database pg-CustomResource and determine whether the automatic elastic scaling task has been completed.

[0013] If completed, the callback alarm handler is used to maintain the database instance status and update the execution results of the auto-scaling task.

[0014] Optionally, based on a preset identifier, the corresponding alarm information processing module can be invoked, including:

[0015] Determine whether the policy contained in the tag in the alarm message is a hardware policy or a cluster policy, and then call the corresponding alarm message processing module.

[0016] Optionally, parsing alarm information using the corresponding alarm information processing module may also include:

[0017] Determine whether the alarm message contains the autoscaling tag; if not, discard the alarm message.

[0018] Based on the category of alarm information, the filtered alarm information is categorized and added to the corresponding alarm information queue. The alarm information categories include processor, memory, and hard disk.

[0019] Using the corresponding alarm processor, retrieve alarm information from the alarm information queue and parse the retrieved alarm information.

[0020] Optionally, the process of parsing alarm information using the corresponding alarm information processing module and executing corresponding scaling processing strategies based on the type of alarm information also includes:

[0021] Using the corresponding alarm information processing module, the alarm information is parsed, the instanceId tag is read, the database instance information of the alarm is obtained, and the database instance status is changed to autoscaling;

[0022] Read the strategy in the strategy tag. If the value is resource, the hardware resource processing strategy is called. If the value is cluster, the cluster scale processing strategy is called.

[0023] Optionally, if the value is "resource", the hardware resource handling strategy to be invoked includes:

[0024] If it's a hardware resource processing strategy, then...

[0025] Call the Kubernetes client module to check the current environment resource status;

[0026] The appropriate elastic scaling coefficient is adapted based on the environmental resource utilization rate during expansion or contraction, and the final elastic scaling value is rounded up to calculate the elastic scaling value based on the resource load.

[0027] Optionally, if the value is "cluster", the cluster-scale processing strategy will be invoked, including:

[0028] If the strategy is cluster-scale processing, then...

[0029] View the current number of cluster nodes, adapt the corresponding elastic scaling factor according to the current number of cluster nodes, and round up the final elastic scaling value to calculate the elastic scaling value based on the cluster size.

[0030] Optionally, adaptively modifying the pg-CustomResource resource scaling value also includes:

[0031] Record elastic scaling change tasks and record task status;

[0032] Find the corresponding database instance's pg-CustomResource based on the instanceId tag, use the calculated elastic scaling value, modify the hardware resource value or cluster size value to request the start of elastic scaling processing.

[0033] Optionally, the pg-operator module can be used to monitor resource changes in all pg-CustomResource databases and perform elastic scaling operations, including:

[0034] The pg-operator module is used to monitor modifications to pg-CustomResource on each database instance, and the database cluster is elastically scaled based on the modified parameters and values; and,

[0035] After processing is complete, modify the status information of pg-CustomResource for the database instance to describe whether the elastic scaling process was successful.

[0036] Optionally, the database resource monitoring module can be used to monitor resource changes in the PG database pg-CustomResource and determine whether the automatic elastic scaling task has been completed, including:

[0037] The database resource monitoring module listens for changes to the status of pg-CustomResource for the database instance, determines the completion status of the elastic scaling task based on the status information, and calls back the alarm handler to modify the database instance status and the elastic scaling task status.

[0038] This application also proposes a cluster device in a Kubernetes environment, characterized in that it includes a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the steps of the aforementioned elastic scaling method for PostgreSQL databases based on a cloud-native platform in a Kubernetes environment.

[0039] The method in this application is natively compatible with the Kubernetes environment, and can fully utilize the advantages of cloud computing's "resource pooling" to significantly improve the flexibility of automatic elastic scaling and meet various needs in different scenarios; it uses pg-operator to automate the operation and maintenance of the pg database, thereby improving the stability and reliability of the database service.

[0040] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0041] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0042] Figure 1 This is the overall technical flow of the elastic stretching method according to the embodiments of this application;

[0043] Figure 2 This is the alarm message processing flow of the elastic scaling method in this application embodiment. Detailed Implementation

[0044] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0045] This application proposes a system for automatically scaling cloud-native PostgreSQL database applications in a Kubernetes environment based on business load. This application uses the CustomResourceDefinitions feature of the Kubernetes platform to abstract PostgreSQL database instances built with HGHAC. In this embodiment, the PG database CustomResource represents the details of a PG database instance. The system used in this application includes a monitoring data acquisition module, a monitoring data storage module, a monitoring alarm push module, an alarm preprocessing module, an alarm processing module, a Kubernetes client module, and a database pg-operator module. This application's method can automatically scale up or down based on the current CPU, memory, and disk resource usage of the PostgreSQL database. The scaling strategy can be based on hardware resources or database instance nodes. Specifically, this application provides a method for elastic scaling of a PostgreSQL database based on a cloud-native platform in a Kubernetes environment. The cloud-native platform and at least one PostgreSQL (PG) database are deployed in the Kubernetes environment. The cloud-native platform manages at least one PG database. Figure 1 As shown, the elastic stretching method of this application embodiment includes the following steps:

[0046] In step S101, alarm information is received on the cloud platform side. This alarm information is sent based on monitoring of the at least one PG database and according to preset alarm rule thresholds. In some specific embodiments, the following modules of the system can be used to complete this step: a monitoring data acquisition module on the database side, based on the HGHAC OpenAPI interface, pod resource information, and database data, to collect monitoring data; a monitoring data storage module, based on the Prometheus core, responsible for storing monitoring data, configuring alarm rule thresholds, and issuing resource load threshold alarms; and a monitoring alarm push module, based on the AlertManager core, responsible for merging alarm information, controlling the alarm information push interval, and receiving the data on the cloud platform side. The monitoring data acquisition module, monitoring data storage module, and monitoring alarm push module are set up on the database side. Multiple databases can share a common set of acquisition, storage, and push mechanisms.

[0047] In step S102, on the cloud platform side, based on a preset identifier, the corresponding alarm information processing module is invoked. This module parses the alarm information and executes the corresponding scaling processing strategy according to the type of alarm information. In some examples, invoking the corresponding alarm information processing module based on the preset identifier includes: determining whether the strategy contained in the label of the alarm information is a hardware strategy or a cluster strategy, and then invoking the corresponding alarm information processing module. For example, an alarm information preprocessing module can be set up to receive alarm information and invoke different elastic scaling alarm processors based on whether the strategy in the label is "resource" or "cluster". In some specific examples, the label contains a set of key-value structure values, specifically: scaling -- true or false, strategy -- resource or cluster, and instanceId -- a UUID.

[0048] In step S103, on the cloud platform side, a connection is directly established with the apiserver of the k8s environment, and the resource status of the k8s environment is checked based on the scaling processing strategy in order to adaptively modify the pg-CustomResource resource scaling value.

[0049] In step S104, the pg-operator module is used to monitor resource changes in all databases pg-CustomResource, perform elastic scaling operations to automate the operation and maintenance of the pg database cluster, and update the pg-CustomResource resources after the operation is completed.

[0050] In step S105, the database resource monitoring module is used to monitor resource changes in the PG database pg-CustomResource and determine whether the automatic elastic scaling task has been completed.

[0051] In step S106, if completed, the callback alarm handler is used to maintain the database instance status and update the execution results of the automatic elastic scaling task.

[0052] The method in this application is natively compatible with the Kubernetes environment, and can fully utilize the advantages of cloud computing's "resource pooling" to significantly improve the flexibility of automatic elastic scaling, meet various needs in different scenarios, and use pg-operator to automate the operation and maintenance of the pg database, thereby improving the stability and reliability of the database service.

[0053] In some examples, parsing alarm information using the corresponding alarm information processing module also includes:

[0054] Determine whether the alarm message contains the autoscaling tag; if not, discard the alarm message.

[0055] Based on the category of alarm information, the filtered alarm information is categorized and added to the corresponding alarm information queue. The alarm information categories include processor, memory, and hard disk.

[0056] Using the corresponding alarm processor, retrieve alarm information from the alarm information queue and parse the retrieved alarm information.

[0057] like Figure 2 As shown, a specific exemplary alarm process includes:

[0058] The alarm receiver in the alarm information preprocessing module of the cloud-native platform receives the alarm information.

[0059] Filter alarm messages for those with the "autoscaling" tag; discard the message if none is found.

[0060] Alarm information is stored in the database and classified into CPU, memory, and disk alarms according to the type tag in the alarm information. Different alarms are pushed to different message queues.

[0061] The cloud-native platform's alarm information processing module is divided into CPU alarm processors, memory alarm processors, and disk alarm processors. Each processor retrieves alarm information from its respective message queue, parses the alarm content, and checks the current environment's resource status through the Kubernetes client module to determine if automatic elastic scaling is allowed. If not, the alarm information record is modified, and the automatic elastic scaling task is terminated. If allowed, the automatic elastic scaling logic is executed, and the alarm information record is modified upon success.

[0062] The method in this application embodiment stores different alarm messages in different message queues based on the type of alarm resource. There are three types of message queues: CPU, memory, and disk. The alarm information processing module includes three alarm information processors for CPU, memory, and disk, respectively. Each processor retrieves alarm messages from its corresponding message queue for processing. In some examples, the method further includes parsing the alarm information using the corresponding alarm information processing module and executing corresponding scaling strategies based on the type of alarm information.

[0063] Using the corresponding alarm information processing module, the alarm information is parsed, the instanceId tag is read, the database instance information of the alarm is obtained, and the database instance status is changed to autoscaling;

[0064] Read the value in the strategy tag. If the value is resource, the hardware resource processing strategy is invoked. If the value is cluster, the cluster size processing strategy is invoked.

[0065] Specifically, the alarm processor retrieves alarm information from the message queue. It parses the alarm content, reads the instanceId tag, obtains the database instance information of the alarm, and modifies the database instance status to autoscaling. It then reads the strategy from the label and calls different automatic elastic scaling strategies based on different values.

[0066] In some embodiments, if the value is "resource", invoking the hardware resource processing strategy includes: if it is a hardware resource processing strategy, calling the Kubernetes client module to check the current environmental resource status; adapting the corresponding elastic scaling coefficient according to the environmental resource utilization rate during expansion or contraction, and rounding the final elastic scaling value up to calculate the elastic scaling value based on the resource load. A specific example is calling the Kubernetes client module to check the current environmental resource status: during expansion, if the environmental resource utilization rate is greater than 90%, the elastic scaling coefficient is 1.1; if the resource utilization rate is greater than 40% but less than 90%, the elastic scaling coefficient is 1.3; and if the resource utilization rate is less than 40%, the elastic scaling coefficient is 1.5. During contraction, if the environmental resource utilization rate is greater than 90%, the elastic scaling coefficient is 1.5; if the resource utilization rate is greater than 40% but less than 90%, the elastic scaling coefficient is 1.3; and if the resource utilization rate is less than 40%, the elastic scaling coefficient is 1.1. The final elastic scaling value is always rounded up, with a minimum elastic scaling value of 1. The automatic elastic scaling coefficient and the final resource scaling value are calculated based on the resource load.

[0067] In some embodiments, if the value is "cluster", the cluster scaling strategy is invoked, including: if it is a cluster scaling strategy, checking the current number of cluster nodes, adapting the corresponding elastic scaling coefficient based on the current number of cluster nodes, and rounding the final elastic scaling value up to calculate the elastic scaling value based on the cluster size. For example, if the current number of cluster nodes is less than 5, the elastic scaling coefficient is 1.5; 5 to 10 nodes, the elastic scaling coefficient is 1.3; and more than 10 nodes, the elastic scaling coefficient is 1.2. After scaling, the final number of cluster nodes is rounded up, with a minimum scaling node count of 1. The automatic elastic scaling coefficient and the number of cluster nodes after scaling are calculated based on the cluster size.

[0068] The method in this application executes different automatic elastic scaling strategies based on the strategy in the label of the database instance resource, according to the configuration. It supports both scaling up and down the hardware resources of the database service and scaling up and down the number of database instance replicas. Moreover, it supports configuring the threshold and duration for which automatic elastic scaling will be triggered when the resource load reaches a certain level, supporting more flexible automatic elastic scaling strategies.

[0069] In some embodiments, adaptively modifying the pg-CustomResource resource scaling value also includes:

[0070] Record the elastic scaling change task and record the task status as processing;

[0071] Locate the corresponding database pg-CustomResource based on the instanceId tag, and modify the hardware resource value or cluster size value therein.

[0072] The system locates the corresponding pg-CustomResource for the database instance based on the instanceId tag. Using the calculated elastic scaling value, it modifies the hardware resource value or cluster size value to initiate elastic scaling processing, thus automating the operation and maintenance of the pg database cluster. Specifically, pg-operator creates hooks on the Kubernetes API server, hooking all operations that modify pg-CustomResource resources. These operations are categorized into add, update, and delete operations. The pg-CustomResource resource data is modeled and maintained in a workqueue. Then, pg-operator retrieves pg-CustomResource resources from the queue in an orderly manner, establishes a direct connection with the Kubernetes API server, and automates the operation and maintenance of the pg database cluster running on the Kubernetes environment based on changes to the pg-CustomResource resources.

[0073] In some examples, you can also configure automatic elastic scaling, for example, the system initializes the following automatic elastic scaling alarm rules:

[0074] CpuHigh rule: CPU usage is greater than 80% for 15 seconds.

[0075] MemoryHigh rule: Memory usage exceeds 80% for 15 seconds.

[0076] DiskHigh rule: Disk usage is greater than 80%;

[0077] CpuLow rule: CPU usage is less than 30% for 15 seconds.

[0078] The MemoryLow rule states that if memory usage is less than 30%, the memory usage period will last for 15 seconds.

[0079] The process is as follows:

[0080] Configure the threshold and duration of the rules.

[0081] Automatic elastic scaling rules are recorded and stored in the database.

[0082] Modify the alarm rule configuration of the monitoring data storage module and reread the rules.

[0083] In some embodiments, the pg-operator module is used to monitor resource changes in all pg-CustomResource databases and perform elastic scaling operations, including:

[0084] The pg-operator module is used to monitor modifications to pg-CustomResource on each database instance, and the database cluster is elastically scaled based on the modified parameters and values; and,

[0085] After processing is complete, modify the status information of pg-CustomResource for the database instance to describe whether the elastic scaling process was successful.

[0086] In this embodiment, Pg-CustomResource utilizes the custom resource extension capabilities of the Kubernetes environment to abstract a PG database cluster instance built with HGHAC. The main contents of the Pg-CustomResource resource relevant to this application include: Replicas: number of cluster nodes; Resources.limits.cpu: CPU resource limit used by the cluster; Resources.limits.memory: memory resource limit used by the cluster; Resources.requests.storage: disk resources used by the cluster; Hghac: HGHAC cluster parameter information; Status.instance: instance status; Status.replicas: number of cluster nodes; Status.readyReplicas: number of nodes currently ready in the cluster.

[0087] In some embodiments, the database resource monitoring module is used to monitor resource changes in the PG database pg-CustomResource and determine whether the automatic elastic scaling task has been completed, including:

[0088] The database resource monitoring module listens for changes to the status of pg-CustomResource for the database instance, determines the completion status of the elastic scaling task based on the status information, and calls back the alarm handler to modify the database instance status and the elastic scaling task status.

[0089] In some specific examples, pg-operator monitors changes to pg-CustomResource and modifies the cluster resource values ​​of the pg database instance in the environment to reflect actual operational status. The database resource monitoring module detects changes to pg-CustomResource and determines whether the auto-scaling task was successful. The database resource monitoring module then calls back to the alarm processing module to modify the alarm records and the database instance status.

[0090] The method described in this application uses the io.fabric8 dependency package in Java to schedule Kubernetes cloud environment resources, ensuring compatibility with the Kubernetes cloud environment.

[0091] This application implements the best practices of manual operation and maintenance of PostgreSQL databases into code, forming the pg-operator module. Using the k8s.io dependency package in Go, it directly schedules Kubernetes cloud environment resources, automatically scaling up or down database hardware resources or database cluster size. This ensures that pg-operator is perfectly compatible with the Kubernetes cloud environment, reduces manual operation and maintenance costs, improves performance, and enhances the stability and reliability of database services.

[0092] This application proposes an automatic elastic scaling solution for PostgreSQL databases based on a cloud-native platform in a Kubernetes environment. The pg-operator, an automated operation and maintenance tool for PostgreSQL databases in a Kubernetes environment, reduces manual operation and maintenance costs and improves performance, stability, and reliability. The method described in this application uses `CustomResourceDefinitions` and `CustomResource` to abstract the resource description of a PostgreSQL database instance, facilitating PostgreSQL database operation and maintenance management.

[0093] All components of the method described in this application are natively compatible with the Kubernetes cloud environment and can communicate directly with the Kubernetes API server without intruding into the cloud environment, ensuring cloud security. Simultaneously, it natively schedules Kubernetes resources without network communication barriers, fully leveraging the advantages of cloud computing's "resource pooling." The method in this application enables PG database instances to automatically scale up or down in terms of hardware resources or elastically scale the cluster size based on business load, improving resource utilization.

[0094] This application also proposes a cluster device in a Kubernetes environment, characterized in that it includes a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the steps of the aforementioned elastic scaling method for PostgreSQL databases based on a cloud-native platform in a Kubernetes environment.

[0095] It should be noted that, in the embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0096] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0097] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0098] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims. All of these forms are within the protection scope of this application.

Claims

1. A method for elastic scaling of a PostgreSQL database based on a cloud-native platform in a Kubernetes environment, characterized in that, The system includes a cloud-native platform and at least one PostgreSQL (PG) database deployed in the Kubernetes environment. The cloud-native platform is used to manage the at least one PG database, and the elastic scaling method includes: Receive alarm information, wherein the alarm information is sent based on monitoring of the at least one PG database and according to a preset alarm rule threshold; Based on the preset identifier, the corresponding alarm information processing module is invoked, the alarm information is parsed using the corresponding alarm information processing module, and the corresponding scaling processing strategy is executed according to the type of alarm information. Using the Kubernetes client module, a direct connection is established with the Kubernetes environment's API server, and the resource status of the Kubernetes environment is checked based on the scaling policy to adaptively modify the pg-CustomResource resource scaling value. Using the pg-operator module, monitor resource changes in all pg-CustomResource databases, perform elastic scaling operations to automate the operation and maintenance of the pg database cluster, and update pg-CustomResource resources after the operation is completed; The database resource monitoring module is used to monitor resource changes in the PG database pg-CustomResource and determine whether the automatic elastic scaling task has been completed. If completed, the callback alarm handler is used to maintain the database instance status and update the execution results of the auto-scaling task.

2. The method for elastic scaling of PostgreSQL database based on a cloud-native platform in a Kubernetes environment as described in claim 1, characterized in that, Based on a preset identifier, the corresponding alarm information processing module is invoked, including: Determine whether the policy contained in the tag in the alarm message is a hardware policy or a cluster policy, and then call the corresponding alarm message processing module.

3. The method for elastic scaling of PostgreSQL database based on a cloud-native platform in a Kubernetes environment as described in claim 2, characterized in that, Using the corresponding alarm information processing module, parsing alarm information also includes: Determine whether the alarm message contains the autoscaling tag; if not, discard the alarm message. Based on the category of alarm information, the filtered alarm information is categorized and added to the corresponding alarm information queue. The alarm information categories include processor, memory, and hard disk. Using the corresponding alarm processor, retrieve alarm information from the alarm information queue and parse the retrieved alarm information.

4. The method for elastic scaling of PostgreSQL database based on a cloud-native platform in a Kubernetes environment as described in claim 2, characterized in that, The process also includes using the corresponding alarm information processing module to parse alarm information and execute corresponding scaling strategies based on the type of alarm information. Using the corresponding alarm information processing module, the alarm information is parsed, the instanceId tag is read, the database instance information of the alarm is obtained, and the database instance status is changed to autoscaling; Read the strategy in the strategy tag. If the value is resource, the hardware resource processing strategy is called. If the value is cluster, the cluster scale processing strategy is called.

5. The method for elastic scaling of PostgreSQL databases based on a cloud-native platform in a Kubernetes environment as described in claim 4, characterized in that, If the value is resource, the hardware resource handling strategy will be invoked, including: If it's a hardware resource processing strategy, then... Call the Kubernetes client module to check the current environment resource status; The appropriate elastic scaling coefficient is adapted based on the environmental resource utilization rate during expansion or contraction, and the final elastic scaling value is rounded up to calculate the elastic scaling value based on the resource load.

6. The method for elastic scaling of PostgreSQL database based on a cloud-native platform in a Kubernetes environment as described in claim 5, characterized in that, If the value is "cluster", then the cluster-scale processing strategy will be invoked, including: If the strategy is cluster-scale processing, then... View the current number of cluster nodes, adapt the corresponding elastic scaling factor according to the current number of cluster nodes, and round up the final elastic scaling value to calculate the elastic scaling value based on the cluster size.

7. The method for elastic scaling of PostgreSQL database based on a cloud-native platform in a Kubernetes environment as described in claim 6, characterized in that, Adaptive modification of pg-CustomResource resource scaling values ​​also includes: Record elastic scaling change tasks and record task status; Find the corresponding database instance's pg-CustomResource based on the instanceId tag, use the calculated elastic scaling value, modify the hardware resource value or cluster size value to request the start of elastic scaling processing.

8. The method for elastic scaling of PostgreSQL database based on a cloud-native platform in a Kubernetes environment as described in claim 7, characterized in that, Using the pg-operator module, monitor resource changes in all pg-CustomResource databases and perform elastic scaling operations, including: The pg-operator module is used to monitor modifications to pg-CustomResource on each database instance, and the database cluster is elastically scaled based on the modified parameters and values; and, After processing is complete, modify the status information of pg-CustomResource for the database instance to describe whether the elastic scaling process was successful.

9. The method for elastic scaling of PostgreSQL database based on a cloud-native platform in a Kubernetes environment as described in claim 8, characterized in that, Using the database resource monitoring module, monitor resource changes in the PG database pg-CustomResource to determine whether the automatic elastic scaling task has been completed, including: The database resource monitoring module listens for changes to the status of pg-CustomResource for the database instance, determines the completion status of the elastic scaling task based on the status information, and calls back the alarm handler to modify the database instance status and the elastic scaling task status.

10. A cluster device in a Kubernetes environment, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program, and the computer program, when executed by the processor, implements the steps of the PostgreSQL database elastic scaling method based on a cloud-native platform in a Kubernetes environment as described in any one of claims 1 to 9.

Images