Kubernetes cluster resource dynamic management method, system and device and storage medium

Abstract

The invention relates to the technical field of Kubernetes clusters, and particularly provides a Kubernetes cluster resource dynamic management method, system and device and a storage medium, and the method comprises the steps: monitoring hardware resources of a cluster physical node; monitoring load data of the cluster, and generating a predicted load based on the load data; dynamically adjusting the resource quota of the namespace or creating a new namespace according to the pre-configuration rule and the hardware resource; based on the predicted load and namespace, the number of container group copies is automatically expanded through HPA. According to the invention, the resource management efficiency and timeliness are improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of Kubernetes clusters, and specifically relates to a hairstyle recommendation method, system, device, and storage medium based on big data. Background Art

[0002] In the current cloud computing era, with the rapid development of cloud computing technology, especially the wide application of container technology, more and more industries and enterprises choose to migrate their business systems to the cloud platform for deployment and operation. The cloud platform, with its advantages such as high availability, elastic scalability, and cost-effectiveness, has become an important driving force for promoting business innovation and technological upgrading.

[0003] However, after the business goes to the cloud, how to efficiently and dynamically manage Kubernetes cluster resources has become an urgent need for operation and maintenance and development personnel. Although traditional command-line tools are powerful, they have the problem of high usage thresholds, which is an important challenge for ordinary operation and maintenance and development personnel. Summary of the Invention

[0004] In view of the above deficiencies of the prior art, the present invention provides a method, system, device, and storage medium for dynamically managing Kubernetes cluster resources to solve the above technical problems.

[0005] In a first aspect, the present invention provides a method for dynamically managing Kubernetes cluster resources, including: Monitoring the hardware resources of the cluster physical nodes; Monitoring the load data of the cluster and generating a predicted load based on the load data; Dynamically adjusting the resource quota of the namespace or creating a new namespace according to pre-configured rules and hardware resources; Automatically scaling the number of container group replicas through HPA based on the predicted load and the namespace.

[0006] In an optional embodiment, the method further includes: Converting the hardware resources of the cluster into computing units recognizable by the container group, and the computing units form a dynamic resource pool; Establishing a mapping relationship between the container group and the computing unit according to the computing units allocated to the container group; Establishing an access control topology of user information, container group, and computing unit according to the user information corresponding to the container group.

[0007] In an optional embodiment, converting the hardware resources of the cluster into computing units recognizable by the container group, and the computing units form a dynamic resource pool, includes: Obtaining the original hardware information through the cluster interface, where the original hardware information includes the hardware model and manufacturer information; Pre-define the number of equivalent computing units corresponding to the hardware model and manufacturer information; According to the original hardware information and the defined number of computing units, recursively decompose the physical resources into computing units by using the binary tree splitting strategy; Add logical labels to the nodes according to the computing units corresponding to the nodes, and the logical labels mark the number of computing units and the type of computing units included in the nodes.

[0008] In an optional embodiment, monitor the load data of the cluster and generate a predicted load based on the load data, including: Regularly monitor the load data of each container group and arrange the load data as load time-series data according to the monitoring time; Input the load time-series data into a pre-trained LSTM model to obtain the predicted load of the corresponding container group.

[0009] In an optional embodiment, dynamically adjust the resource quota of the namespace or create a new namespace according to pre-configured rules and hardware resources, including: Determine the resource requirements according to the predicted load; When the resource requirements can be met by the remaining capacity of the cluster, adjust the resource quota of the existing namespace according to the pre-configured rules and hardware resources; When the resource requirements exceed the remaining capacity of the cluster or forced isolation is required, create a new namespace.

[0010] In an optional embodiment, the pre-configured rules include: For multiple resource types, set the input value range [min, max] constraint logic, where max = the total corresponding resources of all authorized nodes; the default value of the container group includes min = 1, max = the maximum capacity of a single node and < the namespace upper limit.

[0011] In an optional embodiment, automatically expand the number of container group replicas through HPA based on the predicted load and the namespace, including: Calculate the optimal number of replicas of the container group:

[0012] Where X is the number of computing units allocated to the namespace, Y(t) is the real-time number of computing units of the cluster, Z(t) is the predicted load, is the hard limit weight, is the real-time resource weight, is the historical load weight.

[0013] In a second aspect, the present invention provides a Kubernetes cluster resource dynamic management system, including: A monitoring module for monitoring the hardware resources of the cluster physical nodes; A prediction module for monitoring the load data of the cluster and generating a predicted load based on the load data; A configuration module for dynamically adjusting the resource quota of the namespace or creating a new namespace according to pre-configured rules and hardware resources; An adjustment module for automatically scaling the number of replicas of the container group through HPA based on the predicted load and the namespace.

[0014] In a third aspect, a device is provided, including: A memory for storing the Kubernetes cluster resource dynamic management program; A processor for implementing the steps of the Kubernetes cluster resource dynamic management method provided in the first aspect when executing the Kubernetes cluster resource dynamic management program.

[0015] In a fourth aspect, a computer-readable storage medium is provided, on which a Kubernetes cluster resource dynamic management program is stored. When the Kubernetes cluster resource dynamic management program is executed by a processor, the steps of the Kubernetes cluster resource dynamic management method provided in the first aspect are implemented.

[0016] The beneficial effects of the present invention are as follows. The Kubernetes cluster resource dynamic management method, system, device and storage medium provided by the present invention monitor the hardware resources in real time, predict the load, actively generate new namespaces, and adjust the resource quantities of each container group in the cluster based on the new namespaces. The entire resource management process does not require manual operation, and the resource adjustment operation is actively triggered by the predicted load value, improving the resource management efficiency and timeliness.

[0017] In addition, the design principle of the present invention is reliable, the structure is simple, and it has a very wide application prospect. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative efforts.

[0019] Figure 1 is a schematic flowchart of the method according to an embodiment of the present invention.

[0020] Figure 2 is another schematic flowchart of the method according to an embodiment of the present invention.

[0021] Figure 3 It is a schematic block diagram of a system according to an embodiment of the present invention.

[0022] Figure 4 It is a schematic structural diagram of a device provided by an embodiment of the present invention. Detailed implementation manners

[0023] In order to enable those skilled in the art of the present technology to better understand the technical solutions in the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the technical field to which the present invention belongs. The terms used in the specification of the present invention herein are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0025] The following explains the key terms that appear in the present invention.

[0026] Kubernetes (abbreviated as K8s) is an open-source container orchestration platform for automating the deployment, scaling, and management of containerized applications. A Kubernetes cluster consists of two types of nodes: the control plane and worker nodes, which work together to achieve high availability and elasticity of applications.

[0027] 1. Control plane (Master node) Function: The "brain" of the cluster, responsible for global decision-making and coordination.

[0028] Core components: API Server: The entry of the cluster, receiving user instructions and communicating with other components.

[0029] etcd: A distributed key-value store that saves all configuration and status data of the cluster.

[0030] Controller Manager: Monitors the cluster status to ensure that the system runs as expected (such as fault repair, replica count maintenance).

[0031] Scheduler: Assigns newly created Pods to appropriate worker nodes.

[0032] 2. Worker Nodes ‌Function‌: Container that runs user applications.

[0033] ‌Core Components‌: ‌Kubelet‌: Communicates with the Control Plane and manages the Pod lifecycle on the node.

[0034] ‌kube-proxy‌: Maintains node network rules and implements service discovery and load balancing.

[0035] Container runtime: Such as Docker and containerd, responsible for pulling images and running containers.

[0036] 3. Pod: The smallest deployment unit A Pod contains one or more containers (such as a main container + a sidecar container), sharing network and storage resources.

[0037] Analogy: A Pod is like a "work group" where containers are members that collaborate to complete tasks.

[0038] The Kubernetes cluster resource dynamic management method provided in the embodiment of the present invention is executed by a computer device. Accordingly, the Kubernetes cluster resource dynamic management system runs in the computer device.

[0039] Figure 1 is a schematic flow chart of a method according to an embodiment of the present invention. Figure 1 The execution entity can be a Kubernetes cluster resource dynamic management system. Depending on different needs, the order of the steps in the flowchart can be changed, and some steps can be omitted.

[0040] like Figure 1 As shown, the method includes: S1. Monitor the hardware resources of the cluster's physical nodes.

[0041] Built-in Linux tools: In Linux, use the top command to view real-time CPU usage, free -m to view memory usage, iostat to monitor disk I / O, and ifconfig or ipaddr to view network interface status. You can also write scheduled scripts, such as cron jobs, to execute these commands at regular intervals and save the output to a log file.

[0042] SNMP protocol: Deploy SNMP agents on physical nodes and send requests through SNMP management stations (such as Nagios and Zabbix) to obtain node hardware resource information, such as CPU utilization, memory usage, and disk space.

[0043] Hardware monitoring interface: For server-level hardware, the IPMI (Intelligent Platform Management Interface) protocol can be utilized, and hardware sensor data, including temperature, fan speed, etc., can be obtained through IPMI tools (such as ipmitool).

[0044] Store the collected hardware resource data in a time series database, such as Prometheus, InfluxDB, etc. These databases are specifically designed to handle time series data and support efficient storage and query.

[0045] S2. Monitor the load data of the cluster and generate a predicted load based on the load data.

[0046] Load data monitoring: Container orchestration platform: If Kubernetes is used as the container orchestration platform, the load data of Pods and Nodes in the cluster, including CPU usage, memory usage, network traffic, etc., can be collected through Kube-state-metrics and Node-exporter.

[0047] Application monitoring: Integrate a monitoring client (such as the Prometheus client library) in the application to collect application-specific load metrics, such as request response time, throughput, etc.

[0048] Log analysis: Collect and analyze application logs through the ELK Stack (Elasticsearch, Logstash, Kibana) or the EFK Stack (Elasticsearch, Fluentd, Kibana), and extract load-related information from them, such as error rate, business transaction volume, etc.

[0049] Predicted load generation: Machine learning algorithms: Use machine learning algorithms such as ARIMA (Autoregressive Integrated Moving Average Model) and LSTM (Long Short-Term Memory Network) to train historical load data. Divide the historical load data into a training set and a test set, use the training set to train the model, and then use the test set to evaluate the accuracy of the model.

[0050] Model training and tuning: Implement machine learning models using Python's machine learning libraries (such as Scikit - learn, TensorFlow, PyTorch). Improve the prediction accuracy of the model by adjusting the hyperparameters of the model (such as learning rate, number of hidden layers, etc.).

[0051] Real-time prediction: Deploy the trained model to the production environment, receive the latest load data in real time, and use the model to generate a predicted load.

[0052] S3. Dynamically adjust the resource quota of the namespace or create a new namespace according to the preconfigured rules and hardware resources.

[0053] Definition of preconfigured rules: Configuration file: Use a configuration file in YAML or JSON format to define the rules, such as setting different namespace resource quota policies according to different time periods, hardware resource utilization, and predicted load.

[0054] Rule engine: Use a rule engine (such as Drools) to implement complex rule logic and dynamically adjust the resource quota of the namespace according to hardware resources and predicted load.

[0055] Resource quota adjustment: Kubernetes API: Use the Kubernetes API client (such as the kubernetes-client library in Python) to dynamically adjust the resource quota of the namespace according to the preconfigured rules and hardware resource information, such as CPU requests and limits, memory requests and limits, etc.

[0056] Autoscaling policy: Implement an autoscaling policy. When hardware resources are sufficient and the predicted load increases, increase the resource quota of the namespace; when hardware resources are tight and the predicted load decreases, decrease the resource quota of the namespace.

[0057] New namespace creation: Resource assessment: Evaluate whether a new namespace needs to be created based on hardware resources and predicted load. If the existing namespace cannot meet the requirements of the predicted load and hardware resources permit, create a new namespace.

[0058] Namespace creation: Use the Kubernetes API to create a new namespace and allocate an initial resource quota to the new namespace according to the preconfigured rules.

[0059] S4. Automatically scale the number of replicas of the container group based on the predicted load and namespace through HPA.

[0060] HPA configuration: Metric definition: In Kubernetes, use the HorizontalPodAutoscaler (HPA) resource object to define the metrics for automatic scaling, such as CPU utilization, memory utilization, custom metrics (such as the request response time of the application), etc.

[0061] Target value setting: Set a target value for each metric. When the actual metric value exceeds or is lower than the target value, HPA will automatically adjust the number of replicas of the container group.

[0062] Automatically expand the number of replicas in the container group: HPA Controller: Kubernetes' HPA controller regularly monitors the metric values and automatically adjusts the number of replicas in the container group based on the comparison between the metric values and the target values. When the predicted load increases, HPA increases the number of replicas in the container group to meet the load demand; when the predicted load decreases, HPA decreases the number of replicas in the container group to save resources.

[0063] Replica number adjustment strategy: The adjustment strategy of HPA can be set, such as the maximum and minimum number of replicas for adjustment, the adjustment time interval, etc., to avoid frequent expansion and contraction operations.

[0064] Adjust the resource limits of containers: Dynamic resource allocation: In addition to adjusting the number of replicas in the container group, the resource limits of containers (such as CPU limits, memory limits) can also be dynamically adjusted according to the predicted load and the resource quotas of the namespace. The Kubernetes API can be used to update the resource requests and limit fields of the containers.

[0065] Resource optimization: By dynamically adjusting the resource limits of containers, ensure that the containers can reasonably utilize the resources of the namespace while meeting the load demand, and improve resource utilization.

[0066] Currently, the static configuration method of Kubernetes cluster resources cannot meet the high-concurrency load scenario, so build a dynamic resource pool: 1. Convert the hardware resources of the cluster into computing units recognizable by the container group, and these computing units form a dynamic resource pool; Hardware information collection: Collect detailed hardware information from the cluster nodes, including parameters such as CPU model, number of cores, frequency, GPU manufacturer, video memory capacity and number of CUDA cores, memory type, capacity and bandwidth.

[0067] Equivalent computing power calculation: Define a unified computing power formula according to the hardware type and manufacturer characteristics. For example: CPU equivalent unit: Number of cores × main frequency (GHz) × manufacturer coefficient (such as 1.2 times for Intel).

[0068] GPU equivalent unit: Video memory capacity (GB) × number of CUDA cores × manufacturer coefficient (such as 1.5 times for NVIDIA).

[0069] Memory equivalent unit: Capacity (GB) × bandwidth (MHz) × type coefficient (such as 1.0 times for DDR4).

[0070] The total node resources are split layer by layer in a binary tree structure. Each time, the resources are evenly divided into left and right parts until no further splitting is possible. The final leaf nodes represent the smallest allocable combinations of computing units.

[0071] According to the types and quantities of computing units included in the node, identification labels are added to the node. For example, if a node contains 32-core CPUs, 1 GPU, and 128 GB of memory, the label is "cpu=32;gpu=1;mem=128GB".

[0072] 2. Based on the computing units allocated to the container group, establish the mapping relationship between the container group and the computing units.

[0073] Each container group is dynamically bound to the corresponding physical node resources according to the requested equivalent number of computing units. For example, if a container group requests 2 CPU units and 0.5 GPU units, the system will allocate a matching combination of computing units from the available resources. Maintain a mapping table to record the correspondence between the container group and the computing units, including the requested quantity, the actual allocated quantity, and the hardware affinity rules.

[0074] Combining resource availability, node priority, and network latency, calculate the adaptation scores for scheduling the container group to each node. For example, the higher the adaptation score of a node with more sufficient available resources, lower node load, and smaller network latency. Monitor the resource pressure of the cluster. When it is detected that the resource utilization rate of a node exceeds the threshold (such as 85%), trigger the migration of the container group and re-allocate the computing units to balance the load.

[0075] 3. Based on the user information corresponding to the container group, establish the access control topology of the user information, container group, and computing units.

[0076] Define the access permissions to the computing units according to the user roles (such as administrator, developer) and the affiliated projects. For example, a certain user is only allowed to use computing units of GPU type A100. Real-time verify whether the user requests comply with constraints such as resource quotas, hardware types, and time windows. For example, limit a project to only use 50% of the computing resources during non-working hours.

[0077] Through the combination of namespaces and labels, ensure that the use of computing units by different users or projects does not interfere with each other. For example, create an independent namespace for financial services and only associate encrypted GPU computing units. Record all resource allocation, release, and permission change operations, including the operator, time, target resources, and execution results, for compliance review and fault tracing.

[0078] In an embodiment of the present invention, based on step S1, a possible embodiment will be given below to non-restrictively elaborate on its specific implementation scheme.

[0079] Method for obtaining node resource configuration information: Node CPU capacity: status.capacity.cpu; Node memory capacity: status.capacity.memory; Number of GPU cards on the node: status.capacity["nvidia.com / gpu"]; Allocatable capacity of node storage: status.allocatable["ephemeral-storage"]; Node pod capacity: status.capacity.pods.

[0080] In an embodiment of the present invention, based on step S2, a possible embodiment will be given below to non-restrictively elaborate on its specific implementation.

[0081] S201. Regularly monitor the load data of each container group and arrange the load data as load time-series data according to the monitoring time.

[0082] If Kubernetes is used as the container orchestration platform, Kube-state-metrics and Node-exporter can be used to collect the load data of container groups (Pods). Kube-state-metrics can provide status information about Kubernetes resource objects (such as Pods, Deployments, etc.), while Node-exporter is used to collect node-level system metrics.

[0083] Prometheus is an open-source monitoring and alerting tool that can be seamlessly integrated with Kubernetes. By deploying Prometheus and related Exporters in the Kubernetes cluster, the load data of container groups, such as CPU usage, memory usage, network traffic, etc., can be collected regularly.

[0084] Determine the appropriate data collection frequency according to actual requirements and system performance. For example, for a system with high real-time requirements, it can be set to collect once per minute; for a system with low real-time requirements, it can be collected once every 5 minutes or 10 minutes. Use the scrape_interval parameter of Prometheus to configure the data collection frequency.

[0085] Store the collected load data in a time series database, such as the storage of Prometheus itself or InfluxDB. These databases are specifically designed to handle time series data and support efficient storage and querying. In Prometheus, data is stored in the form of timestamps and metric values, facilitating subsequent chronological arrangement.

[0086] Query the load data of each container group from the time series database and sort it according to the monitoring time to form load time series data. The query function of the database can be used to achieve sorting. For example, use the range function and sort operation in Prometheus.

[0087] S202. Input the load time series data into the pre-trained LSTM model to obtain the predicted load of the corresponding container group.

[0088] Perform normalization processing on the load time series data. Common methods include Min-Max normalization and Z-Score normalization. Normalization can scale the data to a fixed range, which helps to improve the training effect and convergence speed of the LSTM model.

[0089] Divide the load time series data into input sequences and target sequences. For example, select the data of the first n time steps as the input and the data of the next time step as the target. The sequence division can be implemented using the numpy library in Python.

[0090] Load the pre-trained LSTM model. Deep learning frameworks (such as TensorFlow, PyTorch) can be used to save and load the model.

[0091] Input the preprocessed load time series data into the LSTM model to obtain the predicted load of the corresponding container group.

[0092] LSTM (Long Short-Term Memory network) is a special type of Recurrent Neural Network (RNN) that can handle long-term dependencies in sequential data. When processing load time series data, the LSTM model learns the patterns and trends in the data based on the input historical load data. The model updates its internal state (i.e., memory cell) through multiple time steps of input, enabling it to capture long-term dependency information in the data. During prediction, the model outputs the predicted load value for the next time step based on the current input sequence and internal state. By continuously inputting new input sequences into the model, continuous prediction of future loads can be achieved.

[0093] In an embodiment of the present invention, based on step S3, a possible embodiment will be given below to non-restrictively elaborate on its specific implementation.

[0094] S301. Determine resource requirements based on predicted load.

[0095] Record the correspondence between historical load and actual resource consumption, and build a feature library. Use polynomial regression or neural network to fit the load-resource relationship curve.

[0096] Determine resource requirements based on the load-resource relationship curve and the predicted load.

[0097] S302. When the resource requirements can be met by the remaining capacity of the cluster, adjust the existing namespace resource quota according to the preconfigured rules and hardware resources.

[0098] The preconfigured rules include: CPU: The input value must be within 1 - the sum of the CPU capacities status.capacity.cpu of all authorized nodes; Default CPU of the container group: The input value must be within 1 - the maximum value of the CPU capacities status.capacity.cpu of all authorized nodes, and less than the maximum namespace CPU value above; Memory: The input value must be within 1 - the sum of the memory capacities status.capacity.memory of all authorized nodes; Default memory of the container group: The input value must be within 1 - the maximum value of the memory capacities status.capacity.memory of all authorized nodes, and less than the maximum namespace memory value above; Storage: The input value must be within 1 - the sum of the storage capacities status.allocatable["ephemeral-storage"] of all authorized nodes; Number of volumes: The input value must be within 1 - the number of all authorized nodes * 23; Number of container groups: The input value must be within 1 - the sum of status.capacity.pods of all authorized nodes; GPU cards: The input value must be within 1 - the sum of status.capacity["nvidia.com / gpu"] of all authorized nodes.

[0099] Among them: Not entering means no limit; Dynamically adjust the resource quota of the namespace or create a new namespace according to the preconfigured rules and hardware resources.

[0100] This rule system realizes precise control of resource allocation through a two-layer constraint model (node physical capacity + namespace quota), effectively balancing the resource utilization rate and system stability requirements.

[0101] S303. When the resource requirements exceed the remaining capacity of the cluster or forced isolation is required, create a new namespace.

[0102] If the existing namespace has reached the hard quota limit (such as the total resources of physical nodes), quota expansion is prohibited, and a new namespace must be created.

[0103] In an embodiment of the present invention, based on step S4, a possible embodiment will be given below to non - restrictively elaborate on its specific implementation.

[0104] Calculate the optimal number of replicas of the container group:

[0105] Where X is the number of computing units allocated to the namespace, Y(t) is the real - time number of computing units in the cluster, Z(t) is the predicted load, is the hard - limit weight, is the real - time resource weight, is the historical load weight.

[0106] Expand the number of replicas of the corresponding container group to the optimal number of replicas.

[0107] In Kubernetes, configure the HorizontalPodAutoscaler (HPA) resource object, define the metrics (such as CPU usage rate, memory usage rate, etc.) and target values for automatic scaling. The HPA controller in Kubernetes will regularly monitor the metric values and automatically adjust the number of replicas of the container group according to the comparison result between the metric values and the target values. When the calculated optimal number of replicas is different from the current number of replicas, HPA will automatically adjust. At the same time, the resource limits of the container can also be adjusted by adjusting the target value of HPA or the resource request and limit fields. HPA monitors specific metrics (such as CPU usage rate) of the container group and compares them with the preset target values. When the metric value exceeds or is lower than the target value, HPA will automatically adjust the number of replicas of the container group to ensure that the resource usage of the container group can meet the load requirements and avoid waste of resources. After calculating the optimal number of replicas, HPA will dynamically adjust the number of replicas according to this result and the current monitoring metric situation to achieve the optimal configuration. At the same time, by adjusting the relevant parameters of HPA, the resource limits of the container can also be dynamically adjusted to further optimize resource utilization.

[0108] In an example, create and edit the application instance / workload, and dynamically adjust the number of replicas of the container group and the maximum coordinates of the container quota according to the comparison between the namespace quota and the allocable resources of the node.

[0109] 1) Method for obtaining allocable resources of the node: Number of pods allocatable by the node: allocatedResources.podCapacity - allocatedResources.allocatedPods; CPU requests allocatable by the node: allocatedResources.cpuCapacity - allocatedResources.cpuRequests; CPU limits allocatable by the node: allocatedResources.cpuCapacity - allocatedResources.cpuLimits; Memory requests allocatable by the node: allocatedResources.memoryCapacity - allocatedResources.memoryRequests; Memory limits allocatable by the node: allocatedResources.memoryCapacity - allocatedResources.memoryLimits; Number of GPU cards allocatable by the node: status.allocatable["nvidia.com / gpu"].

[0110] 2) Dynamically set the number of workload replicas and resource quotas when publishing the workload: CPU requests: Compare the CPU quota of the namespace with the maximum CPU allocatable by the nodes with permissions, and take the smaller value of the two. If the namespace is not configured with a CPU quota, set it to the maximum CPU allocatable by the nodes with permissions; CPU limits: The maximum value is the same as the CPU requests, and it is linked to the CPU requests. When setting the CPU requests, set the same CPU limits at the same time. The CPU limits can be changed to be greater than the CPU requests; Memory requests: Compare the memory quota of the namespace with the maximum memory allocatable by the nodes with permissions, and take the smaller value of the two. If the namespace is not configured with a memory quota, set it to the maximum memory allocatable by the nodes with permissions; Memory limits: The maximum value is the same as the memory requests, and it is linked to the memory requests. When setting the memory requests, set the same memory limits at the same time. The memory limits can be changed to be greater than the memory requests; GPU limits: Compare the GPU quota of the namespace with the maximum GPU allocatable by the nodes with permissions, and take the smaller value of the two. If the namespace is not configured with a GPU quota, set it to the maximum GPU allocatable by the nodes with permissions.

[0111] When nodes are added or removed from the cluster, dynamically update the namespace resource quotas. For example, after a node is removed, prompt "Dynamically update the resource quotas of [XXXX1, XXXX2] namespaces after the node removal is completed!"

[0112] Please refer to Figure 2 , in a specific embodiment, it specifically includes the following steps: Namespace resource management module: When creating or editing a namespace, dynamically set the namespace resource quotas and limits according to the cluster node resource capacity.

[0113] 1) Node resource configuration information acquisition method: Node CPU capacity: status.capacity.cpu; Node memory capacity: status.capacity.memory; Number of node GPU cards: status.capacity["nvidia.com / gpu"]; Allocatable capacity of node storage: status.allocatable["ephemeral-storage"]; Node pod capacity: status.capacity.pods.

[0114] 2) Namespace quota configuration: CPU: The input value must be between 1 and the sum of the CPU capacities status.capacity.cpu of all authorized nodes; Default CPU of container group: The input value must be between 1 and the maximum value of the CPU capacities status.capacity.cpu of all authorized nodes, and less than the maximum namespace CPU value above; Memory: The input value must be between 1 and the sum of the memory capacities status.capacity.memory of all authorized nodes; Default memory of container group: The input value must be between 1 and the maximum value of the memory capacities status.capacity.memory of all authorized nodes, and less than the maximum namespace memory value above; Storage: The input value must be between 1 and the sum of the storage capacities status.allocatable["ephemeral-storage"] of all authorized nodes; Number of volumes: The input value must be between 1 and the number of all authorized nodes * 23; Number of container groups: The input value must be between 1 and the sum of status.capacity.pods of all authorized nodes; GPU card: The input value must be within the range of 1 to the sum of the status.capacity["nvidia.com / gpu"] of all authorized nodes.

[0115] Workload publishing module: Create and edit application instances / workloads, compare with namespace quotas and node allocable resources, and dynamically adjust the number of container group replicas and the maximum coordinates of container quotas.

[0116] 1) Method for obtaining node allocable resources: Number of pods allocable to the node: allocatedResources.podCapacity - allocatedResources.allocatedPods; CPU requests allocable to the node: allocatedResources.cpuCapacity - allocatedResources.cpuRequests; CPU limits allocable to the node: allocatedResources.cpuCapacity - allocatedResources.cpuLimits; Memory requests allocable to the node: allocatedResources.memoryCapacity - allocatedResources.memoryRequests; Memory limits allocable to the node: allocatedResources.memoryCapacity - allocatedResources.memoryLimits; Number of GPU cards allocable to the node: status.allocatable["nvidia.com / gpu"].

[0117] 2) Dynamically set the number of workload replicas and resource quotas when publishing the workload: Number of replicas: Compare the namespace container group count quota with the sum of the number of pods allocable to authorized nodes, and take the smaller of the two values; If the namespace has set default CPU and default memory for the container group, automatically set the CPU and memory requests to the default values.

[0118] CPU requests: Compare the namespace CPU quota with the maximum CPU allocable to authorized nodes, and take the smaller of the two values. If the namespace has not configured the CPU quota, set it to the maximum CPU allocable to authorized nodes; CPU Limit: The maximum coordinate value is the same as the CPU request and is linked to the CPU request. When setting the CPU request, set the same CPU limit at the same time. The CPU limit can be changed to be greater than the CPU request value; Memory Request: Compare the memory quota of the namespace with the maximum allocable memory of the (authorized nodes), and take the smaller value of the two. If the namespace does not configure a memory quota, set it to the maximum allocable memory of the authorized nodes; Memory Limit: The maximum coordinate value is the same as the memory request and is linked to the memory request. When setting the memory request, set the same memory limit at the same time. The memory limit can be changed to be greater than the memory request value; GPU Limit: Compare the GPU quota of the namespace with the maximum allocable GPU of the (authorized nodes), and take the smaller value of the two. If the namespace does not configure a GPU quota, set it to the maximum allocable GPU of the authorized nodes.

[0119] Resource Dynamic Synchronization Module: When nodes are added or removed from the cluster, dynamically update the namespace resource quotas. For example, after a node is removed, prompt "After the node is removed, dynamically update the resource quotas of the [XXXX1, XXXX2] namespaces!"

[0120] In another embodiment of the present invention, a method for dynamically managing Kubernetes cluster resources is provided, including: Step 1: Hardware resource monitoring and dynamic resource pool construction. Collection of cluster node hardware information: Obtain the hardware information of all physical nodes through the Kubernetes API, including CPU model (such as Intel Xeon 8358), GPU manufacturer (such as NVIDIA A100), memory type (DDR4), and storage capacity (such as 1TB NVMe SSD).

[0121] Definition of equivalent computing units: CPU unit: Number of cores × Frequency (GHz) × Manufacturer coefficient (Intel = 1.2, AMD = 1.0).

[0122] GPU unit: Video memory (GB) × Number of CUDA cores × Manufacturer coefficient (NVIDIA = 1.5).

[0123] Binary tree splitting strategy: Recursively decompose the node resources according to a binary tree (for example, if the total CPU of a node is 32 cores, it is first split into a left subtree of 16 cores and a right subtree of 16 cores until the leaf nodes are 1-core units).

[0124] Logical label marking: Add a label compute-unit: cpu = 32, gpu = 2, mem = 128GB to the node to identify the types and quantities of computing units it contains.

[0125] Step 2: Load Prediction and Resource Requirement Calculation. Load Time-Series Data Collection: Collect the CPU usage rate, memory occupancy, and network IO of each container group every 15 seconds and store them in InfluxDB. The data structure is as follows: Timestamp: 2023-09-20T14:30:00; Pod ID: pod-abc-123; CPU (%): 68.7; Memory (GB): 4.1.

[0126] Processing by LSTM Prediction Model: Model Input: Load data for the past 60 time steps (15 minutes), normalized to the interval [0, 1].

[0127] Prediction Output: Future 5-minute load value Z(t), which is inverse-normalized and converted into physical resource requirements (e.g., predicted CPU requirement is 8 cores).

[0128] Step 3: Dynamic Namespace Adjustment.

[0129] Calculation of Resource Margin: The real-time available resources Y(t) of the cluster = total resources - allocated resources (e.g., total CPU cores are 100, 60 are used, then Y(t) = 40).

[0130] Decision Logic: If Y(t) ≥ Z(t) × 1.2 (buffer coefficient), adjust the existing namespace quota (e.g., increase the CPU quota of namespace A from 20 cores to 30 cores).

[0131] If Y(t) < Z(t) × 0.8 and isolation is required (e.g., in a financial compliance scenario), create a new namespace and bind dedicated node resources.

[0132] Implementation of Pre-Configuration Rules: Input Constraints: Range of CPU Request Values: 1 ≤ input value ≤ total CPU of all nodes (e.g., 100 cores).

[0133] Default Value of Container Group: The maximum value is the smaller of the CPU capacity of a single node (e.g., 32 cores) and the namespace upper limit (e.g., 50 cores).

[0134] Step 4: Elastic Scaling of Container Groups. Calculation of Optimal Replica Count:

[0135] Among them, X is the number of computing units allocated to the namespace, Y(t) is the real-time computing units of the cluster, Z(t) is the predicted load, is the hard limit weight, is the real-time resource weight, Is the historical load weight.

[0136] Calculation result: OptimalReplicas = floor[(50×0.4 + 40×0.3 + 60×0.3) / 1.0] = floor

[50] = 50 replicas.

[0137] HPA policy execution: If the current number of replicas is 30 and OptimalReplicas = 50, increase it step by step by 10% (30 → 33 → 36…). After expansion, lock it for 400 seconds to prevent repeated operations due to metric fluctuations.

[0138] Step 5: Access control and auditing. User-Pod-compute unit mapping: Pods created by user Alice in the namespace finance are only allowed to access GPU compute units with the label security: encrypted.

[0139] Dynamic policy engine: When a user requests GPU resources, verify whether the namespace to which the user belongs has the RBAC permission of gpu-access: true.

[0140] In some embodiments, the Kubernetes cluster resource dynamic management system may include multiple functional modules composed of computer program segments. The computer programs of each program segment in the Kubernetes cluster resource dynamic management system can be stored in the memory of the computer device and executed by at least one processor to execute (see details in Figure 1 description) the functions of Kubernetes cluster resource dynamic management.

[0141] In this embodiment, the Kubernetes cluster resource dynamic management system can be divided into multiple functional modules according to the functions it performs, such as Figure 3 shown. The module referred to in the present invention means a series of computer program segments that can be executed by at least one processor and can complete fixed functions, and are stored in the memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0142] Monitoring module, used to monitor the hardware resources of cluster physical nodes; Prediction module, used to monitor the load data of the cluster and generate predicted load based on the load data; Configuration module, used to dynamically adjust the resource quota of the namespace or create a new namespace according to pre-configured rules and hardware resources; Adjustment module, used to automatically expand the number of replicas of the container group through HPA based on the predicted load and the namespace.

[0143] Figure 4 The Kubernetes cluster resource dynamic management method provided by the embodiments of this application can be applied to devices. Those skilled in the art can understand that the device structure involved in the embodiments of the present invention does not constitute a limitation on the device. The device may include more or fewer components than shown in the figure, or combine some components, or have different component arrangements. In the embodiments of the present invention, the device includes but is not limited to laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown in the figure, their connections and relationships, and their functions are only examples and are not intended to limit the implementation of the embodiments of this application described and / or required herein.

[0144] Among them, the device 400 may include: a processor 410, a memory 420, and a communication unit 430. These components communicate through one or more buses. Those skilled in the art can understand that the structure of the server shown in the figure does not constitute a limitation on the present invention. It can be a bus structure, a star structure, or may include more or fewer components than shown in the figure, or combine some components, or have different component arrangements.

[0145] Among them, the memory 420 can be used to store the execution instructions of the processor 410. The memory 420 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, a magnetic disk, or an optical disk. When the execution instructions in the memory 420 are executed by the processor 410, the device 400 can execute some or all of the steps in the above method embodiments.

[0146] The processor 410 is the control center of the storage device, connecting various parts of the entire electronic device through various interfaces and circuits. By running or executing software programs and / or modules stored in the memory 420, and by invoking the data stored in the memory, it executes various functions of the electronic device and / or processes data. The processor may be composed of an integrated circuit (IC), for example, it may be composed of a single packaged IC, or it may be composed of multiple packaged ICs with the same or different functions connected together. For example, the processor 410 may include only a central processing unit (CPU). In the embodiments of the present invention, the CPU may be a single arithmetic core or may include multiple arithmetic cores.

[0147] The communication unit 430 is used to establish a communication channel so that the storage device can communicate with other devices. It receives user data sent by other devices or sends user data to other devices.

[0148] The present invention also provides a computer storage medium. Among them, the computer storage medium can store a program, and when the program is executed, it may include some or all of the steps in the various embodiments provided by the present invention. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), etc.

[0149] Those skilled in the art can clearly understand that the technology in the embodiments of the present invention can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solutions in the embodiments of the present invention, 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 a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc., which can store program codes, and includes several instructions to enable a computer device (which may be a personal computer, a server, or a second device, a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0150] For the same or similar parts among the various embodiments in this specification, reference can be made to each other. In particular, for the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the descriptions in the method embodiments.

[0151] In several embodiments provided by the present invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the division of the modules is only a logical function division. In actual implementation, there may be other division methods. For example, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling, direct coupling, or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of the system or module can be in electrical, mechanical, or other forms.

[0152] The modules described as separate components may or may not be physically separated. The components displayed as modules may or may not be physical modules, that is, they can be located in one place or distributed to multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0153] In addition, in each embodiment of the present invention, the functional modules can be integrated in a processing module, or each module can exist physically alone, or two or more modules can be integrated in one module.

[0154] Although the present invention has been described in detail by referring to the accompanying drawings and in combination with the preferred embodiments, the present invention is not limited thereto. Without departing from the spirit and essence of the present invention, those of ordinary skill in the art can make various equivalent modifications or substitutions to the embodiments of the present invention, and these modifications or substitutions should be within the scope of the present invention. / Any person skilled in the art within the technical scope disclosed by the present invention can easily think of changes or substitutions, which should be covered within the protection scope of the present invention.

Claims

1. A method for dynamically managing Kubernetes cluster resources, characterized in that including: monitoring the hardware resources of the cluster physical nodes; monitoring the load data of the cluster and generating a predicted load based on the load data; dynamically adjusting the resource quota of the namespace or creating a new namespace according to preconfigured rules and hardware resources; automatically scaling the number of container group replicas through HPA based on the predicted load and the namespace.

2. The method according to claim 1, wherein The method further includes: converting the hardware resources of the cluster into computing units recognizable by the container group, and the computing units form a dynamic resource pool; establishing a mapping relationship between the container group and the computing unit according to the computing units allocated to the container group; establishing an access control topology of user information, container group, and computing unit according to the user information corresponding to the container group.

3. The method according to claim 2, characterized in that, Converting the hardware resources of the cluster into computing units recognizable by the container group, and the computing units form a dynamic resource pool, including: obtaining the original hardware information through the cluster interface, where the original hardware information includes the hardware model and manufacturer information; predefining the equivalent number of computing units corresponding to the hardware model and manufacturer information; recursively decomposing the physical resources into computing units by using the binary tree segmentation strategy according to the original hardware information and the defined number of computing units; adding a logical label to the node according to the computing units corresponding to the node, and the logical label marks the number and type of computing units included in the node.

4. The method according to claim 1, wherein Monitoring the load data of the cluster and generating a predicted load based on the load data, including: regularly monitoring the load data of each container group and arranging the load data in chronological order of monitoring as load time series data; inputting the load time series data into a pre-trained LSTM model to obtain the predicted load of the corresponding container group.

5. The method according to claim 1, wherein Dynamically adjusting the resource quota of the namespace or creating a new namespace according to preconfigured rules and hardware resources, including: determining the resource requirements according to the predicted load; when the resource requirements can be met by the remaining capacity of the cluster, adjusting the resource quota of the existing namespace according to the preconfigured rules and hardware resources; when the resource requirements exceed the remaining capacity of the cluster or forced isolation is required, creating a new namespace.

6. The method according to claim 5, characterized in that, The preconfigured rules include: for multiple resource types, setting the input value range [min, max] constraint logic, where max = the sum of the corresponding resources of all authorized nodes; the default value of the container group includes min = 1, max = the maximum capacity of a single node and < the namespace upper limit.

7. The method according to claim 1, characterized in that Automatically scaling the number of container group replicas through HPA based on the predicted load and the namespace, including: calculating the optimal number of replicas of the container group: Among them, X is the number of computing units allocated by the namespace, Y(t) is the number of real-time computing units in the cluster, and Z(t) is the predicted load. is the hard limit weight. is the real-time resource weight. is the historical load weight.

8. A dynamic management system for Kubernetes cluster resources, characterized in that, including: a monitoring module for monitoring the hardware resources of the cluster physical nodes; a prediction module for monitoring the load data of the cluster and generating a predicted load based on the load data; a configuration module for dynamically adjusting the resource quota of the namespace or creating a new namespace according to preconfigured rules and hardware resources; an adjustment module for automatically scaling the number of container group replicas through HPA based on the predicted load and the namespace.

9. A device, characterized in that, including: a memory for storing the Kubernetes cluster resource dynamic management program; A processor for implementing the steps of the Kubernetes cluster resource dynamic management method according to any one of claims 1-7 when executing the Kubernetes cluster resource dynamic management program.

10. A computer-readable storage medium storing a computer program, characterized in that, The readable storage medium stores a Kubernetes cluster resource dynamic management program, and when the Kubernetes cluster resource dynamic management program is executed by a processor, it implements the steps of the Kubernetes cluster resource dynamic management method according to any one of claims 1-7.

Images