Data updating method, device and equipment for stock pod in kubernetes and medium

Abstract

The application provides a data updating method and device for a stock pod in Kubernetes, equipment and medium. The method controls the VPA component through in-place upgrade of the controller, and when the VPA component listens to the data updating event of the target pod, the current configuration parameter of the target pod stored in the resource database is determined according to the data updating information of the target pod. Thus, the consistency of the pod running resource and the storage resource can be determined to ensure effective data updating of the current configuration parameter of the target pod. The resource recommended value is used to replace the current configuration parameter of the target pod to realize in-place upgrade of the resource database without the need of reconstructing the stock pod, and the pod container business is not affected. Thus, the dynamic adjustment convenience of the container resource configuration is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, device and medium for updating data of existing Pods in Kubernetes. Background Technology

[0002] Compared to the complex deployment and weak migration capabilities of traditional virtual machines, an increasing number of applications and middleware are choosing Kubernetes as their deployment and operation platform. In an environment that emphasizes cost reduction and efficiency improvement, how to efficiently utilize resources has become a current research topic.

[0003] In some scenarios, it's frequently observed that business requests for container resources (CPU, memory) are unreasonable. On one hand, businesses may blindly set quotas for containers that are too high for actual needs in an attempt to improve performance, resulting in resource waste and preventing nodes from scheduling more new containers. On the other hand, sudden surges in traffic may occur, but insufficient container resources can lead to performance bottlenecks or OutOfMemory errors, causing frequent restarts and service unavailability. However, it's practically difficult to determine a configuration that both meets business needs and conserves resources during the container configuration phase.

[0004] For resource allocation, existing technologies are based on VPA (Vertical Pod Autoscaler) solutions. This solution calculates recommended resource values ​​based on historical resource usage and automatically adjusts Pod resource quotas. However, while existing technologies can achieve the above functions, they evict existing Pods, causing container restarts and thus impacting business operations.

[0005] To address the issue of dynamically adjusting container resource configurations, existing technologies typically involve evictping and rebuilding existing Pods. This rebuilding process requires rescheduling, network allocation for Sanbox containers, disk mounting, and image pulling, which impacts service recovery time and the lifecycle of other containers within the same Pod. While the Container Runtime Interface (CRI) defines methods for modifying container resources without rebuilding the Pod, the API Server (which provides the cluster's external communication interface) restricts modifications to container resources in existing Pods. Therefore, current technologies directly implement resource restrictions through the CRI or by modifying the cgroups file corresponding to the container on the node. However, this approach fails to reflect the updated values ​​in the Pod's configuration, leading to inconsistencies between the actual configuration and the displayed data. Alternatively, modifying the Kubernetes source code could achieve the same functionality, but this would tightly couple the code, require developers to have a deep understanding of the source code, and is not only difficult to implement and carries significant potential risks, but also hinders future version upgrades.

[0006] Therefore, how to solve the problem of poor convenience in dynamically adjusting container resource configuration has become an urgent technical issue. Summary of the Invention

[0007] This application provides a method, apparatus, device, and storage medium for updating data in existing Pods in Kubernetes, aiming to improve the convenience of dynamic adjustment of container resource configuration.

[0008] Firstly, this application provides a method for updating data in existing Pods in Kubernetes, the method comprising:

[0009] When the in-situ upgrade controller detects a data update event of a target Pod in the pre-configured VPA component, it obtains the data update information of the target Pod, wherein the data update data includes the resource recommendation value and current data storage information of the target Pod;

[0010] Based on the current data storage information, determine the current configuration parameters of the target Pod stored in the resource database;

[0011] Based on the resource recommendation values, the current configuration parameters are overwritten to complete the data update for the target Pod.

[0012] Secondly, this application also provides a data update device for existing Pods in Kubernetes, the data update device for existing Pods in Kubernetes comprising:

[0013] The data update information acquisition module is used to acquire the data update information of the target Pod when the in-situ upgrade controller detects a data update event of the target Pod in the pre-configured VPA component. The data update data includes the resource recommendation value and current data storage information of the target Pod.

[0014] The current configuration parameter determination module is used to determine the current configuration parameters of the target Pod stored in the resource database based on the current data storage information.

[0015] The data update module is used to overwrite the current configuration parameters based on the resource recommendation value to complete the data update of the target Pod.

[0016] Thirdly, this application also provides a computer device, the computer device including a processor, a memory, and a computer program stored in the memory and executable by the processor, wherein when the computer program is executed by the processor, it implements the steps of the data update method for existing Pods in Kubernetes as described above.

[0017] Fourthly, this application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the above-described method for updating data of existing Pods in Kubernetes.

[0018] This application provides a method, apparatus, device, and storage medium for updating data of existing Pods in Kubernetes. The method includes, when the in-place upgrade controller detects a data update event of a target Pod in a pre-configured VPA component, obtaining the data update information of the target Pod, wherein the data update data includes the recommended resource values ​​and current data storage information of the target Pod; determining the current configuration parameters of the target Pod stored in a resource database based on the current data storage information; and overwriting the current configuration parameters based on the recommended resource values ​​to complete the data update of the target Pod. Through this method, this application monitors the VPA component by the in-place upgrade controller, and when a data update event of a target Pod is detected in the VPA component, determines the current configuration parameters of the target Pod stored in the resource database based on the data update information of the target Pod. This avoids interference from multiple version information, ensures the consistency of Pod running resources and storage resources, and ensures effective data updates to the current configuration parameters of the target Pod. Overwriting the current configuration parameters of the target Pod with the recommended resource values ​​achieves in-place upgrades to the resource database without rebuilding the existing Pod, thus not affecting the container services within the Pod. This improves the convenience of dynamically adjusting container resource configurations. Attached Figure Description

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

[0020] Figure 1 A flowchart illustrating the first embodiment of a data update method for existing Pods in Kubernetes provided in this application;

[0021] Figure 2 A flowchart illustrating the second embodiment of the data update method for existing Pods in Kubernetes provided in this application;

[0022] Figure 3A flowchart illustrating the third embodiment of the data update method for existing Pods in Kubernetes provided in this application;

[0023] Figure 4 This application provides a schematic diagram illustrating the structure and data interaction of each component in a method for updating data of existing Pods in Kubernetes.

[0024] Figure 5 This is a schematic diagram of the structure of a first embodiment of a data update device for existing Pods in Kubernetes provided in this application;

[0025] Figure 6 This is a schematic block diagram of the structure of a computer device provided in an embodiment of this application.

[0026] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0027] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0029] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0030] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of a method for updating data of existing Pods in Kubernetes provided in this application.

[0031] like Figure 1 As shown, the data update method for existing Pods in this Kubernetes system includes steps S101 to S103.

[0032] S101. When the in-situ upgrade controller detects a data update event of a target Pod in the pre-configured VPA component, it obtains the data update information of the target Pod, wherein the data update data includes the resource recommendation value and current data storage information of the target Pod.

[0033] In one embodiment, the in-situ upgrade controller is developed in the mode of a controller operator, follows the Kubernetes specification, and achieves interface with VPA and etcd.

[0034] In one embodiment, the update-inplace controller is primarily responsible for monitoring changes to custom objects in the VPA and maintaining the associated existing Pod data in etcd. If there is an update to the recommended values, and the Pod's container configuration values ​​are outside the new recommended range, the resource configuration of that Pod in etcd will be modified to the recommended values.

[0035] Optionally, both the VPA component and the in-situ upgrade controller can be deployed via Deploymnet, starting in a master-election mode with multiple replicas, ensuring both high availability and concurrency control. Plugin templates can be created using Helmcharts for easy installation and uninstallation. Additionally, the values.yaml file can be configured to simplify the setup process.

[0036] In a Kubernetes cluster, a Pod is the foundation for all business applications and the smallest unit of management in Kubernetes. It's a combination of one or more containers. These containers share storage, network, namespaces, and rules for how they run. Within a Pod, all containers are scheduled and run in the same shared context. For a specific application, a Pod is its logical host, containing multiple application containers related to its business logic.

[0037] In one embodiment, an event filter is added to the startup manager of the controller to add only modification events of VPA custom objects (i.e. target Pods) to the tuning queue; in the tuning method, an informer is used to listen for and cache VPA custom objects (i.e. target Pods), and when a new update event needs to be processed, the target Pod and its data update information are retrieved from the cache.

[0038] In one embodiment, the current data storage information includes the data name, data storage address, and current data version number of the current configuration parameters.

[0039] In one embodiment, when configuring a VPA component, there is generally a one-to-one correspondence between the VPA component and the listening object (i.e., the target Pod). That is, one VPA component listens to the resource data of one Pod, and the basis for establishing this correspondence is the Pod's configuration parameters (such as the Pod's name, ID, and data version number). After configuring the VPA component, the VPA component itself only listens to the data of the target Pod and does not perform any data modification operations on the target Pod. Instead, it relies on the in-place upgrade controller to perform these operations. Therefore, after the VPA component is configured, the data update information of the target Pod is synchronously sent to the in-place upgrade controller and cached on the in-place upgrade controller, so that the in-place upgrade controller can uniformly manage each VPA component and Pod.

[0040] Furthermore, after obtaining the data update information of the target Pod, it is determined whether the target Pod's spec.updatePolicy.updateMode is Initial or Off. If not, no processing is performed and the result is returned directly. If it is, it is then determined whether there is a mapped load application that can be elastically scaled up or down, whether there is a recommended value, etc., to handle different situations. If there is a mapped load application, the selector of the load is obtained according to the load mapped by the VPA, and all Pods associated with that load are obtained.

[0041] S102. Based on the current data storage information, determine the current configuration parameters of the target Pod stored in the resource database;

[0042] In one embodiment, an Informer can be used to monitor and cache Pods within the cluster. To avoid directly accessing etcd through the APIServer, the ResourceVersion value for the query condition is specified as 0, causing it to retrieve data from the APIServer's cache. After retrieving all load-related Pods from the cache, Pods in the deletion state are filtered out. For all surviving Pods, the recommended value is used to update the Pod data in etcd.

[0043] The APIServer is a crucial management API layer in Kubernetes. It provides RESTful API access endpoints and persists data to the etcd server. In a Kubernetes cluster, the APIServer acts as the entry point for interaction. It not only interacts with etcd (other components do not directly manipulate etcd, only the APIServer does this) but also provides a unified API call entry point to the outside world.

[0044] Furthermore, such as Figure 2 As shown, step S102 specifically includes:

[0045] S1021. Based on preset query conditions, access the resource database to obtain the storage data of the target Pod and the storage data version number corresponding to the storage data;

[0046] In one embodiment, the APIServer also contains cached Pod configuration parameters. When the in-place upgrade controller accesses etcd through the APIServer, the returned result may also be the cached Pod configuration parameters in the APIServer. In this case, the queried Pod configuration parameters may not be the latest configuration parameters currently used by the Pod. Therefore, before modifying the configuration parameters of the target Pod, it is necessary to compare the data version number of the configuration parameters to be modified.

[0047] S1022. Compare the stored data version number with the current data version number;

[0048] In one embodiment, the storage data version number is the version number of the configuration data of the Pod stored in etcd. etcd can store all the configuration parameter data used by the Pod and the data version number of each configuration parameter.

[0049] Generally, the configuration parameters currently used by a Pod are consistent with the latest version of the Pod data stored in etcd. Therefore, updating the current configuration parameters of a target Pod is equivalent to updating the latest version of the target Pod data stored in etcd.

[0050] However, the APIServer that etcd uses to communicate with the external environment may also cache configuration data from other versions of the target Pod. When the in-place upgrade controller accesses etcd to query the current configuration parameters of the target Pod, the returned result may also be other version data cached in the APIServer. Updating this data will not affect the current configuration parameters of the target Pod. Therefore, after obtaining the query result, it is necessary to compare the stored data version number with the current data version number to ensure that the updated data object is the current configuration parameter of the target Pod that is currently running.

[0051] S1023. When the stored data version number and the current data version number are consistent, determine that the stored data is the current configuration parameter of the target Pod.

[0052] In one embodiment, when the storage data version number and the current data version number are the same, the storage data corresponding to the storage data version number is the configuration parameter currently being used by the target Pod, that is, the configuration parameter that needs to be modified.

[0053] In one embodiment, if the stored data version number and the current data version number are inconsistent, then the stored data version number is not the configuration parameter currently being used by the target Pod. In this case, the current configuration parameter corresponding to the target Pod is queried from etcd.

[0054] S103. Based on the resource recommendation value, overwrite the current configuration parameters to complete the data update of the target Pod.

[0055] In one embodiment, after retrieving all load-related Pods from the cache, Pods in the deletion state are filtered out. For all surviving Pods, the recommended value is used to update the Pod data in etcd. First, a mutex lock is added, and the Pod data in etcd is queried through etcdClient. The ResourceVersion of the data is compared with the PodResourceVersion in the cache to ensure that the latest version in etcd is being updated. Then, the recommended value is overwritten with the original Pod data, and the update is completed in etcd. Finally, the lock is released to complete the data update.

[0056] A mutex is a simple locking method to control access to shared resources. A mutex has only two states: locked and unlocked. Locking a mutex is an atomic operation, meaning the operating system (or pthread library) guarantees that if one thread locks a mutex, no other thread can successfully lock it at the same time; if one thread locks a mutex, no other thread can lock it until it unlocks it; if one thread has already locked a mutex and a second thread attempts to lock it, the second thread will be suspended (not occupying any CPU resources) until the first thread unlocks the mutex, at which point the second thread will be awakened and continue execution, locking the mutex again.

[0057] Furthermore, the system obtains each Pod in the cluster and the VPA component corresponding to each Pod; when the in-situ upgrade controller detects at least two data update events triggered by the VPA components for the corresponding Pods, it caches each data update event sequentially according to the order of occurrence of the data update events based on the message queue; when the in-situ upgrade controller obtains the data update event of the target Pod from the message queue, it reads the data update information corresponding to the target Pod from the preset data cache.

[0058] In one embodiment, a cluster includes multiple Pods, and each Pod can monitor resource data through a VPA component. Therefore, when multiple Pods are running simultaneously in the cluster, multiple VPA components can be created to monitor the resource data of each Pod. Consequently, the configuration parameters of multiple Pods may need to be adjusted, that is, multiple VPA components may trigger data update events for the Pods at the same time. In this case, to ensure the orderly updating of Pod data, the data update events of each Pod can be stored in a message queue according to the triggering order of each data update event. The message queue is used to manage the data update events, and the in-place upgrade controller can pull the data update events in the message queue and perform data update operations on each Pod in sequence.

[0059] A message queue is a first-in, first-out (FIFO) queue-like data structure, essentially an internal linked list within the system kernel. Messages are inserted sequentially into the queue; the sending process adds a message to the end of the queue, and the receiving process reads a message from the head. Multiple processes can simultaneously send messages to a message queue and simultaneously receive messages from a message queue. The sending process pushes the message to the tail of the queue, and the receiving process reads the message from the head of the queue; once a message is read, it is removed from the queue.

[0060] This embodiment provides a method for updating data of existing Pods in Kubernetes. This method monitors the VPA component through an in-situ upgrade controller. When a data update event of a target Pod is detected in the VPA component, the current configuration parameters of the target Pod stored in the resource database are determined based on the data update information of the target Pod. This avoids interference from multiple version information, ensures the consistency of Pod running resources and storage resources, and ensures that the current configuration parameters of the target Pod are effectively updated. The recommended resource values ​​are overridden with the current configuration parameters of the target Pod, realizing an in-situ upgrade of the resource database without rebuilding the existing Pod and without affecting the container services within the Pod. This improves the convenience of dynamically adjusting container resource configuration.

[0061] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating the third embodiment of the data update method for existing Pods in Kubernetes provided in this application.

[0062] In this embodiment, based on the above... Figure 1 In the illustrated embodiment, the method further includes:

[0063] S201. Obtain the configuration information of the target Pod, wherein the configuration information includes the data name, data version number, and data storage address of the target Pod;

[0064] In one embodiment, when configuring a VPA component, the VPA component and the listening object (i.e., the target Pod) are generally in one-to-one correspondence. That is, one VPA component listens to the resource data of one Pod, and the basis for establishing the correspondence is based on the Pod's configuration parameters (such as the Pod's name, number, and data version number).

[0065] S202. Based on the configuration information, configure the VPA component, wherein the VPA component is used to monitor the resource data of the target Pod.

[0066] VPA stands for VerticalPodAutoscaler, which automatically adjusts CPU and memory request values ​​based on container resource usage. This allows for appropriate scheduling on nodes to provide suitable resources for each Pod. It can both shrink overly resource-demanding containers and increase capacity as needed based on their usage.

[0067] In one embodiment, such as Figure 4 As shown, the VPA components include VPARecommender, VPAupdater, and VPAAdmissionController.

[0068] VPARecommender is primarily responsible for retrieving historical usage data from storage databases such as Prometheus (within or outside the cluster), using relevant algorithms to calculate more reasonable recommendation values ​​and recommendation ranges, and updating them to VPA's custom objects.

[0069] VPAupdater is responsible for listening to custom objects in VPA and evicting Pods. If the container configuration in the Pod is higher or lower than the recommended range, the Pod will be evicted. This step usually leads to the deletion and reconstruction of existing Pods. Therefore, in this solution, the updater will not perform the eviction action through parameter configuration.

[0070] When a new Pod is created, VPAAdmissionController is responsible for checking whether the VPA custom object in the cache has already calculated the recommended value for the Pod and whether the current container configuration is outside the recommended range. If so, the recommended value is overwritten to replace the original Pod's resource configuration.

[0071] For example, the VPA component configuration process may include: creating a template in Helmchart format for the three parts of the VPA component and related information such as CRD, webhook, RBAC, and certificate; mapping key configuration items such as container startup parameters, image repository, image name, and version as variables to the chart's values.yaml file; specifying default values ​​for the above variables in the values.yaml file, for example, to query historical container resource usage, configuring "---storage=prometheus" and "---prometheus-address=http: / / prometheus.default.svc.cluster.local:9090" to specify querying Prometheus and its address, configuring "--min-replicas=2" to evict only loads with more than two replicas; when creating a custom VPA object, configuring spec.updatePolicy.updateMode to Initial or Off to only provide recommended values ​​and not evict Pods.

[0072] Furthermore, after configuring the VPA component based on the current data storage information, the method further includes: obtaining historical resource data of the target Pod, wherein the historical resource data includes resource data of the target Pod within a preset historical period; calculating the recommended resource value and data monitoring threshold range corresponding to the target Pod based on the historical resource data; and sending the recommended resource value and the data monitoring threshold range to the in-situ upgrade controller so that the in-situ upgrade controller can monitor whether the VPA component has a data update event for the target Pod.

[0073] In one embodiment, the VPA component calculates the current recommended resource value and the data monitoring threshold range based on the historical resource data of the target Pod, and uses the data monitoring threshold range as the basis for monitoring the resource data of the target Pod.

[0074] For example, historical resource data can be selected based on the calculation requirements of the resource recommendation value and the data monitoring threshold range. For instance, historical resource data for seven days can be selected, and the average value of the seven-day historical resource data can be calculated as the resource recommendation value. Meanwhile, the lowest and highest resource data values ​​for the seven days can be selected, and the average of the lowest resource data values ​​for the seven days can be calculated as the lowest value of the data monitoring threshold range. The average of the highest resource data values ​​for the seven days can be calculated as the highest value of the data monitoring threshold range.

[0075] In one embodiment, the resource recommendation value and data monitoring threshold range can also be formulated according to specific needs. For example, if historical resource data shows that the load of the target Pod differs significantly between the weekend and the weekday, then the corresponding resource recommendation value and data monitoring threshold range can be calculated for the weekday and weekend respectively.

[0076] Furthermore, based on the VPA component, the current resource data of the target Pod is monitored; when the current resource data exceeds the data monitoring threshold range, a data update event of the target Pod is triggered.

[0077] In one embodiment, after the VPA component is configured, the current resource data of the target Pod can be monitored in real time through the VPA component. When the current resource data of the target Pod exceeds the data monitoring threshold range, that is, it is less than the minimum value of the data monitoring threshold range or greater than the maximum value of the data monitoring threshold range, the data update event of the target Pod can be triggered.

[0078] In one embodiment, the detection that the current resource data of the target Pod exceeds the data monitoring threshold range may be occasional. Therefore, the duration or frequency of exceeding the threshold range can be set. A timer starts when the current resource data of the target Pod is detected to exceed the data monitoring threshold range. When the timer reaches a preset duration, a data update event for the target Pod is triggered; or, a data update event for the target Pod is triggered when the number of times the current resource data of the target Pod is detected to exceed the data monitoring threshold range reaches a preset frequency.

[0079] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a first embodiment of a data update device for existing Pods in Kubernetes provided in this application. This data update device for existing Pods in Kubernetes is used to execute the aforementioned data update method for existing Pods in Kubernetes. The data update device for existing Pods in Kubernetes can be configured in a server.

[0080] like Figure 5 As shown, the data update device 300 for existing Pods in this Kubernetes system includes: a data update information acquisition module 301, a current configuration parameter determination module 302, and a data update module 303.

[0081] The data update information acquisition module 301 is used to acquire the data update information of the target Pod when the in-situ upgrade controller detects a data update event of the target Pod in the pre-configured VPA component. The data update data includes the resource recommendation value and current data storage information of the target Pod.

[0082] The current configuration parameter determination module 302 is used to determine the current configuration parameters of the target Pod stored in the resource database based on the current data storage information.

[0083] The data update module 303 is used to overwrite the current configuration parameters based on the resource recommendation value to complete the data update of the target Pod.

[0084] In one embodiment, the data update device 300 for existing Pods in Kubernetes further includes a VPA component configuration module, used to obtain the configuration information of the target Pod, wherein the configuration information includes the data name, data version number, and data storage address of the target Pod; and to configure the VPA component based on the configuration information, wherein the VPA component is used to monitor the resource data of the target Pod.

[0085] In one embodiment, the VPA component configuration module is further configured to obtain historical resource data of the target Pod, wherein the historical resource data includes resource data of the target Pod within a preset historical period; calculate the recommended resource value and data monitoring threshold range corresponding to the target Pod based on the historical resource data; and send the recommended resource value and the data monitoring threshold range to the in-situ upgrade controller so that the in-situ upgrade controller can monitor whether the VPA component has a data update event for the target Pod.

[0086] In one embodiment, the data update device 300 for existing Pods in Kubernetes further includes a data monitoring module, which is used to monitor the current resource data of the target Pod based on the VPA component; and to trigger a data update event for the target Pod when the current resource data exceeds the data monitoring threshold range.

[0087] In one embodiment, the current data storage information includes the data name, data storage address, and current data version number of the current configuration parameters.

[0088] In one embodiment, the current configuration parameter determination module 302 is further configured to access the resource database based on preset query conditions, obtain the storage data of the target Pod and the storage data version number corresponding to the storage data; compare the storage data version number with the current data version number; and determine the storage data as the current configuration parameter of the target Pod when the storage data version number and the current data version number are consistent.

[0089] In one embodiment, the data update information acquisition module 301 is further configured to acquire each Pod in the cluster and the VPA component corresponding to each Pod; when the in-situ upgrade controller detects at least two VPA components triggering data update events for the corresponding Pods, it caches each data update event sequentially according to the order of occurrence of the data update events based on the message queue; when the in-situ upgrade controller acquires the data update event of the target Pod from the message queue, it reads the data update information corresponding to the target Pod from a preset data cache.

[0090] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the device and each module described above can be referred to the corresponding process in the aforementioned embodiment of the data update method for existing Pods in Kubernetes, and will not be repeated here.

[0091] The apparatus provided in the above embodiments can be implemented as a computer program, which can be used in, for example... Figure 6 It runs on the computer device shown.

[0092] Please see Figure 6 , Figure 6 This is a schematic block diagram illustrating the structure of a computer device according to an embodiment of this application. The computer device may be a server.

[0093] See Figure 6 The computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0094] Non-volatile storage media can store operating systems and computer programs. These computer programs include program instructions that, when executed, cause the processor to perform any data update method for existing Pods in Kubernetes.

[0095] The processor provides computing and control capabilities, supporting the operation of the entire computer device.

[0096] Internal memory provides an environment for running computer programs in non-volatile storage media. When these computer programs are executed by the processor, the processor can perform any data update method for existing Pods in Kubernetes.

[0097] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 6The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0098] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0099] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps:

[0100] When the in-situ upgrade controller detects a data update event of a target Pod in the pre-configured VPA component, it obtains the data update information of the target Pod, wherein the data update data includes the resource recommendation value and current data storage information of the target Pod;

[0101] Based on the current data storage information, determine the current configuration parameters of the target Pod stored in the resource database;

[0102] Based on the resource recommendation values, the current configuration parameters are overwritten to complete the data update for the target Pod.

[0103] In one embodiment, the processor is configured to run a computer program stored in memory and may also perform the following steps:

[0104] Obtain the configuration information of the target Pod, wherein the configuration information includes the data name, data version number, and data storage address of the target Pod;

[0105] Based on the configuration information, the VPA component is configured, wherein the VPA component is used to monitor the resource data of the target Pod.

[0106] In one embodiment, after configuring the VPA component based on the current data storage information, the processor is further configured to implement:

[0107] Obtain historical resource data of the target Pod, wherein the historical resource data includes resource data of the target Pod within a preset historical period;

[0108] Based on the historical resource data, the resource recommendation value and data monitoring threshold range corresponding to the target Pod are calculated;

[0109] The recommended resource value and the data monitoring threshold range are sent to the in-place upgrade controller so that the in-place upgrade controller can listen for data update events of the target Pod in the VPA component.

[0110] In one embodiment, after implementing the calculation of the resource recommendation value and data monitoring threshold range corresponding to the target Pod based on the historical resource data, the processor is further configured to implement:

[0111] Based on the VPA component, monitor the current resource data of the target Pod;

[0112] When the current resource data exceeds the data monitoring threshold range, a data update event is triggered for the target Pod.

[0113] In one embodiment, the current data storage information includes the data name, data storage address, and current data version number of the current configuration parameters.

[0114] In one embodiment, when the processor determines the current configuration parameters of the target Pod stored in the resource database based on the current data storage information, it is configured to:

[0115] Based on preset query conditions, access the resource database to obtain the storage data of the target Pod and the storage data version number corresponding to the storage data;

[0116] Compare the stored data version number with the current data version number;

[0117] When the stored data version number and the current data version number are the same, the stored data is determined to be the current configuration parameters of the target Pod.

[0118] In one embodiment, when the processor acquires the data update information of the target Pod after the in-situ upgrade controller detects a data update event of a target Pod in a pre-configured VPA component, it is configured to:

[0119] Obtain each Pod in the cluster and the VPA component corresponding to each Pod;

[0120] When the in-situ upgrade controller detects at least two data update events triggered by the VPA components for the corresponding Pods, it caches each data update event sequentially according to the order in which the data update events occur, based on a message queue.

[0121] When the in-situ upgrade controller obtains the data update event of the target Pod from the message queue, it reads the data update information corresponding to the target Pod from the preset data cache.

[0122] The embodiments of this application also provide a computer-readable storage medium storing a computer program, the computer program including program instructions, and the processor executing the program instructions to implement any of the data update methods for existing Pods in Kubernetes provided in the embodiments of this application.

[0123] The computer-readable storage medium may be an internal storage unit of the computer device described in the foregoing embodiments, such as the hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, SmartMediaCard (SMC), SecureDigital (SD) card, or FlashCard equipped on the computer device.

[0124] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for updating data in existing Pods in Kubernetes, characterized in that, The method includes: When the in-situ upgrade controller detects a data update event of a target Pod in a pre-configured VPA component, it obtains the data update information of the target Pod, wherein the data update information includes the resource recommendation value and current data storage information of the target Pod; Based on the current data storage information, determine the current configuration parameters of the target Pod stored in the resource database; Based on the resource recommendation value, the current configuration parameters are overwritten to complete the data update of the target Pod; Obtain each Pod in the cluster and the VPA component corresponding to each Pod; When the in-situ upgrade controller detects at least two data update events triggered by the VPA components for the corresponding Pods, it caches each data update event sequentially according to the order in which the data update events occur, based on a message queue. When the in-situ upgrade controller obtains the data update event of the target Pod from the message queue, it reads the data update information corresponding to the target Pod from the preset data cache; The current data storage information includes the data name, data storage address, and current data version number of the current configuration parameters; The step of determining the current configuration parameters of the target Pod stored in the resource database based on the current data storage information includes: Based on preset query conditions, access the resource database to obtain the storage data of the target Pod and the storage data version number corresponding to the storage data; Compare the stored data version number with the current data version number; When the stored data version number and the current data version number are the same, the stored data is determined to be the current configuration parameters of the target Pod.

2. The method for updating data of existing Pods in Kubernetes according to claim 1, characterized in that, The method further includes: Obtain the configuration information of the target Pod, wherein the configuration information includes the data name, data version number, and data storage address of the target Pod; Based on the configuration information, the VPA component is configured, wherein the VPA component is used to monitor the resource data of the target Pod.

3. The method for updating data of existing Pods in Kubernetes according to claim 2, characterized in that, After configuring the VPA component based on the current data storage information, the process further includes: Obtain historical resource data of the target Pod, wherein the historical resource data includes resource data of the target Pod within a preset historical period; Based on the historical resource data, the resource recommendation value and data monitoring threshold range corresponding to the target Pod are calculated; The recommended resource value and the data monitoring threshold range are sent to the in-place upgrade controller so that the in-place upgrade controller can listen for data update events of the target Pod in the VPA component.

4. The method for updating data of existing Pods in Kubernetes according to claim 3, characterized in that, After calculating the recommended resource value and data monitoring threshold range for the target Pod based on the historical resource data, the method further includes: Based on the VPA component, monitor the current resource data of the target Pod; When the current resource data exceeds the data monitoring threshold range, a data update event is triggered for the target Pod.

5. A data update device for existing Pods in Kubernetes, characterized in that, The data update mechanism for existing Pods in Kubernetes includes: The data update information acquisition module is used to acquire the data update information of the target Pod when the in-situ upgrade controller detects a data update event of the target Pod in the pre-configured VPA component. The data update information includes the resource recommendation value and current data storage information of the target Pod. The current configuration parameter determination module is used to determine the current configuration parameters of the target Pod stored in the resource database based on the current data storage information. The data update module is used to overwrite the current configuration parameters based on the resource recommendation value to complete the data update of the target Pod; The data update information acquisition module is further configured to: Obtain each Pod in the cluster and the VPA component corresponding to each Pod; When the in-situ upgrade controller detects at least two data update events triggered by the VPA components for the corresponding Pods, it caches each data update event sequentially according to the order in which the data update events occur, based on a message queue. When the in-situ upgrade controller obtains the data update event of the target Pod from the message queue, it reads the data update information corresponding to the target Pod from the preset data cache; The current data storage information includes the data name, data storage address, and current data version number of the current configuration parameters; The current configuration parameter determination module is also used for: Based on preset query conditions, access the resource database to obtain the storage data of the target Pod and the storage data version number corresponding to the storage data; Compare the stored data version number with the current data version number; When the stored data version number and the current data version number are the same, the stored data is determined to be the current configuration parameters of the target Pod.

6. A computer device, characterized in that, The computer device includes a processor, a memory, and a computer program stored in the memory and executable by the processor, wherein when the computer program is executed by the processor, it implements the steps of the data update method for existing Pods in Kubernetes as claimed in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the data update method for existing Pods in Kubernetes as described in any one of claims 1 to 4.

Images