WO2022016808A1 - 一种kubernetes集群资源动态调整方法及电子设备 - Google Patents

一种kubernetes集群资源动态调整方法及电子设备 Download PDF

Info

Publication number
WO2022016808A1
WO2022016808A1 PCT/CN2020/140019 CN2020140019W WO2022016808A1 WO 2022016808 A1 WO2022016808 A1 WO 2022016808A1 CN 2020140019 W CN2020140019 W CN 2020140019W WO 2022016808 A1 WO2022016808 A1 WO 2022016808A1
Authority
WO
WIPO (PCT)
Prior art keywords
lstm
resource consumption
data
resource
time series
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2020/140019
Other languages
English (en)
French (fr)
Inventor
杨磊
王洋
须成忠
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Institute of Advanced Technology of CAS
Original Assignee
Shenzhen Institute of Advanced Technology of CAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Institute of Advanced Technology of CAS filed Critical Shenzhen Institute of Advanced Technology of CAS
Publication of WO2022016808A1 publication Critical patent/WO2022016808A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/149—Network analysis or design for prediction of maintenance
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/142—Network analysis or design using statistical or mathematical methods
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • the present application belongs to the field of computers, and in particular relates to a method for dynamically adjusting Kubernetes cluster resources and an electronic device.
  • Kubernetes a container cluster management technology that can realize container orchestration and management
  • container orchestration and management a container cluster management technology that can realize container orchestration and management
  • Linux in the cloud era In order to prevent the application from consuming too many resources and thus affecting the performance of other applications and nodes, it is necessary to implement the application resource control and isolation through the resource limitation mechanism of Kubernetes and the Cgroup technology of Docker.
  • it can only be statically deployed through the configuration file, and it is necessary to manually estimate the resource requirements such as Cpu and Memory.
  • the Pod will use up the resources on the node without limit, and there will be resource competition, which will have a huge impact on the stability of the service.
  • the traffic will change regularly, so the resource usage will change accordingly, and the static deployment method will lead to insufficient or redundant resources.
  • VPA is similar to HPA, but it adjusts the resource request value of a single Pod.
  • the industry will also conduct stress tests on the entire link, using the cAdvisor monitoring system integrated in Kubernetes to predict the number of replicas and resources required by the Pod in advance, and use redundancy when the resources cannot be accurately budgeted. way of configuration.
  • the academic community generally obtains the curve of performance changing with resources through experiments, determines an appropriate resource reservation value, and reserves the corresponding resources in advance.
  • the literature [Xu, G., Xu, C.-Z MEER: Online Estimation of Optimal Reservations for Long Lived Containers in In-Memory Cluster Computing.
  • ICDCS 2019 proposes a long-life cycle-oriented container-sensitive memory resource reservation mechanism , allowing containers to run with much less memory than ideal, at the cost of a performance penalty.
  • the literature adopts offline training. After obtaining the model, online prediction is used to obtain the Pod resource limit.
  • VPA vertical expansion
  • API Server the only operation entry for Kubernetes resource objects, other components must operate resource data through the API provided by it
  • Kube-Scheduler is redeployed and cannot be upgraded in place, which obviously does not meet the real-time requirements.
  • the VPN is still in the alpha version and has not been merged into the official Kubernetes release, and HPA and VPA are currently incompatible, so you can only choose one to use, otherwise there will be interference between the two.
  • test data of the old version may not be suitable for the new version, or the same data on different machines, due to different configurations, often show differences in performance, and the effect of dynamic adjustment is not achieved.
  • the present application provides a dynamic adjustment method and electronic device for Kubernetes cluster resources, aiming to solve one of the above technical problems in the prior art at least to a certain extent.
  • a method for dynamic adjustment of Kubernetes cluster resources comprising the following steps:
  • Step a collect historical monitoring indicator data in the application, and obtain resource consumption time series data according to the monitoring indicator data;
  • Step b constructing an LSTM-Kalman filter, and inputting the resource consumption time series data into the LSTM-Kalman for pre-training to obtain a prediction model; wherein, the LSTM-Kalman filter is a Kalman filter transformed by LSTM;
  • the technical solution adopted in the embodiment of the present application further includes: in the step a, the collection of historical monitoring indicator data in the application includes:
  • the collected monitoring indicator data includes CPU utilization and quota, file system read/write utilization and quota, and network packet sending/receiving/discarding rate data. at least one or a combination of more than one;
  • the technical solution adopted in the embodiment of the present application further includes: in the step a, the obtaining the resource consumption time series data according to the monitoring indicator data includes:
  • the time series database is regularly queried to obtain the index data of interest, and the interested index data is cached and sorted to form time series data of resource consumption that can be directly used for prediction.
  • the caching and sorting of the indicator data of interest includes:
  • the constructing the LSTM-Kalman filter includes:
  • X(k) is the system state at time k
  • Z(k) is the observed value at time k
  • W(k) and V(k) represent the process and measurement noise, respectively, and their covariances are Q, respectively
  • R represents the process and measurement noise, respectively, and their covariances are Q, respectively
  • R represents the process and measurement noise, respectively, and their covariances are Q, respectively
  • R represents the process and measurement noise, respectively, and their covariances are Q, respectively
  • R is the function model generated by the LSTM f model
  • the prediction steps are:
  • F represents the Jacobian matrix of f with respect to X(k-1
  • the update steps are:
  • Kg(k) P(k
  • k) X(k
  • Step 100 Data collection and arrangement: firstly, static redundant configuration deployment is performed on the application, and historical monitoring indicator data such as Cpu and Memory of the application under the real load environment are collected;
  • Equations (3) and (4) correspond to the system prediction process, and the predicted value under k state is obtained, and then combined with the measured value Z(t), the optimal estimated value X(k
  • this application transforms the Kalman filter by using LSTM to get rid of the excessive dependence on the dynamic model, so that the model parameters do not need to be given a priori.
  • the specific transformation process is as follows:
  • Equation (11) F represents the Jacobian matrix of f with respect to X(k-1
  • FIG. 3 it is a schematic diagram of the Kalman filter transformed by LSTM.
  • the request value in the configuration file can be taken as X(k-1
  • k-1) obtains the state noise Q(k) at time k through LSTM Q.
  • the Kalman filter is recursively updated through equations (12), (13), and (14).
  • the Kalman filter transformed by LSTM takes into account both prediction and noise filtering, and at the same time gets rid of the excessive dependence on the dynamic model.
  • the model parameters do not need to be given a priori, but can be learned from the data, giving full play to the time series before and after Correlation; and enhanced long-range prediction ability, instead of relying only on the last moment value, the prediction accuracy can be significantly improved.
  • the model evaluation process is specifically as follows: pulling the monitoring indicator data within the time period set by the Metrics Collector through the Controller, and comparing the prediction result of the prediction model with the monitoring indicator data reported from the Metrics Collector, and judging whether it needs to be performed again.
  • Model training If the time consumption value of the set threshold is below the optimal estimated value of the prediction model, the model will not be updated. Otherwise, the new monitoring index data will be used to update the parameters of the prediction model to correct the model.
  • a historical data peak is also backed up in the Controller, which is temporarily used as a container resource limit when the filter is retrained.
  • Step 400 Enter the online prediction execution stage: continuously collect new resource consumption time series data, and input the trained prediction model to predict the resource consumption peak value within a preset time period in the future, and update the value as a resource limit value;
  • Cgroup is a module used to implement resource usage and statistics in the Linux kernel. Docker uses Cgroup to isolate and limit resources. Kubelet acts as a node agent of Kubernetes. All operations on Cgroup are implemented by the internal Container Manager module. Container Manager will pass Cgroups limit the use of resources layer by layer. When the container resource request and limit are specified through configuration files such as yaml, Docker will set the runtime cpu.share, cpu.quota, cpu.period, mem.limit and other indicators for the container, and Executor will modify these indicator files for resource utilization. Update to achieve dynamic Pod resource limit adjustment.
  • the processor, the memory, the input system, and the output system may be connected by a bus or in other ways, and the connection by a bus is taken as an example in FIG. 4 .
  • the memory can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules.
  • the processor executes various functional applications and data processing of the electronic device by running the non-transitory software programs, instructions and modules stored in the memory, that is, the processing method of the above method embodiment is implemented.
  • the memory may include a stored program area and a stored data area, wherein the stored program area can store an operating system and an application program required by at least one function; the stored data area can store data and the like. Additionally, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory may optionally include memory located remotely from the processor, which may be connected to the processing system via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
  • the one or more modules are stored in the memory, and when executed by the one or more processors, perform the following operations of any of the foregoing method embodiments:
  • Step a collect historical monitoring indicator data in the application, and obtain resource consumption time series data according to the monitoring indicator data;
  • the above product can execute the method provided by the embodiments of the present application, and has functional modules and beneficial effects corresponding to the execution method.
  • the above product can execute the method provided by the embodiments of the present application, and has functional modules and beneficial effects corresponding to the execution method.
  • Step b constructing an LSTM-Kalman filter, and inputting the resource consumption time series data into the LSTM-Kalman for pre-training to obtain a prediction model; wherein, the LSTM-Kalman filter is a Kalman filter transformed by LSTM;
  • Step c Collect new resource consumption time series data, input the new resource consumption time series data into the prediction model to predict the resource consumption peak value within a preset time period in the future, and use the resource consumption peak value as a resource limit value for resource consumption. renew.
  • An embodiment of the present application provides a computer program product, the computer program product includes a computer program stored on a non-transitory computer-readable storage medium, the computer program includes program instructions, and when the program instructions are executed by a computer , which causes the computer to do the following:
  • Step c Collect new resource consumption time series data, input the new resource consumption time series data into the prediction model to predict the resource consumption peak value within a preset time period in the future, and use the resource consumption peak value as a resource limit value for resource consumption. renew.
  • the method for dynamic adjustment of Kubernetes cluster resources and the electronic device first perform static redundant configuration deployment on the application, collect historical monitoring indicator data of the application under a real load environment, and perform online pre-training to obtain a more reliable prediction model;
  • the model is iteratively trained until the loss of the model converges or only oscillates within a preset range, then continuously collect new resource consumption time series data and input it into the prediction model to predict the peak resource consumption in a short period of time in the future, and use this value as the resource limit value.
  • Updated to implement dynamic Pod resource limit adjustment Compared with the prior art, the present application at least has the following beneficial effects:
  • the resource is dynamically limited, and the local maximum value is used instead of the global maximum value, which improves the resource utilization rate and has an adaptive effect.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • Pure & Applied Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • Algebra (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请涉及一种Kubernetes集群资源动态调整方法及电子设备。所述方法包括：收集应用中的历史监控指标数据，根据所述监控指标数据得到资源消耗时序数据；构建LSTM-Kalman滤波器，将所述资源消耗时序数据输入所述LSTM-Kalman进行预训练，得到预测模型；收集新的资源消耗时序数据，将所述新的资源消耗时序数据输入所述预测模型中预测未来预设时间段内的资源消耗峰值，将所述资源消耗峰值作为资源限制值进行资源更新。本申请保证了数据的精确性，有效的提高了系统资源利用率，解决了资源碎片问题，同时具备一定的自适应的能力。

Description

一种Kubernetes集群资源动态调整方法及电子设备 技术领域
本申请属于计算机领域，特别涉及一种Kubernetes集群资源动态调整方法及电子设备。
背景技术
随着以Docker为支撑的容器即服务技术兴起，Kubernetes(一种容器集群管理技术，可以实现容器的编排管理)因其强大的容器编排技术受到业界追捧，已然成为容器集群管理的“事实标准”，更是被誉为“云时代的Linux”。为避免应用过多消耗资源，从而影响其他应用及节点性能，需要通过Kubernetes的资源限制机制以及Docker的Cgroup技术实现应用资源控制隔离。通常在部署应用的时候，只能通过配置文件进行静态部署，需要人为的估算Cpu、Memory等资源需求量。显然当预留资源不足会导致容器发生Cputhrottle或者Out of memory kill，影响服务质量，需要新建Pod(是Kubernetes最基本操作单元，包含一个或多个密切相关的业务逻辑容器，是集群调度的最小单位)再次部署。当出现冗余配置时，会使得集群资源利用率低下，影响节点可分配资源，导致其他Pod无法被调度到该节点上。
通常，如果不对Pod进行资源限制，Pod将会无限制的使用完节点上的资源，出现资源竞争，对服务的稳定性产生巨大影响。在实际生产环境中，流 量会发生规律性变化，因此资源使用率随之发生变化，静态部署的方式会带来资源不足或冗余。为了在资源不断波动情况下，能够动态调整资源，开源社区提供HPA(Pod横向自动扩容，https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)、VPA(垂直自动扩容，https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/vertical-pod-autoscaler.md)。HPA的原理是通过Kubernetes的Controller Manager组件运行一个Controller，周期性监听Pod资源使用情况，当高于设定的阈值时，会自动增加Pod的数量，当低于某个阈值时，会自动减少Pod数量，通过调整集群中Pod的数量来动态改变资源。VPA与HPA相似，但是调整的是单个Pod的资源请求值，通过监控组件的数据，计算Pod的资源推荐值，允许在节点上进行适当调度，为每个Pod提供适当资源，当被VPA接管的Pod资源实际消耗值与推荐值相差较大时，会对Pod进行驱逐并重新建立Pod再次部署到集群中，从而达到动态资源改变的目的。
为了服务的稳定性，工业界也会进行全链路的压力测试，利用集成在Kubernetes中的cAdvisor监控系统，提前预判Pod需要的副本数和资源量，在无法准确预算资源时，采用冗余配置的方式。除此之外，学术界一般通过实验得到性能随资源变化的曲线，确定一个合适的资源预留值，提前预留好相应的资源。如文献[Xu,G.,Xu,C.-Z MEER:Online Estimation of Optimal Reservations for Long Lived Containers in In-Memory Cluster Computing.ICDCS 2019]提出一种面向长生命周期的容器敏感内存资源预留机制，允许容器可以在比理想内存少很多的情况下运行，只需付出一定的性能损失代价即可。文献采用离线训练，得到模型后，在线预测获得Pod资源限额。
如上所述，若采用开源社区的HPA或VPA解决方案，对时间,Cpu,Memory,网络资源等敏感的在线或实时计算应用来说，实时性不够。通常部署的应用都是重量级Java框架或者相关技术栈的Web应用，利用HPA进行水平扩容来调整Pod数量，可以在较短时间能增加Pod数量，但是从触发扩容到经过Kube-Scheduler(Kubernetes的集群调度器，负责将Pod调度到合适的节点上)调度到合适的节点再通过Docker client拉取镜像，开启容器开启服务需要较长时间。至于VPA提供的垂直扩容，需要从节点驱逐旧Pod，重新建立满足资源需求的Pod，再通过API Server(Kubernetes资源对象的唯一操作入口，其他组件都必须通过它提供的API来操作资源数据)，Kube-Scheduler重新部署，无法做到原地升级，显然并不满足实时性需求。并且VPN还处于alpha版，并没有合并到官方的Kubernetes release中，而且HPA和VPA目前不兼容，只能选择一个使用，否则两者之间会产生干扰。
对于全链路的离线、在线压测提前预判的方式，或者例如文献[谢文舟,孙艳霞.基于Kubernetes负载特征的资源预测模型研究[J].网络安全技术与应用,2018(04):27-28.]通过在某几种应用类型上大量实验，不断改变资源预留值，测量应用的性能指标，从而建立资源和性能变化曲线，最后折中得到一个资源预留值。然而在生产环境的异构集群中存在成千上万的应用，各种应用版本发布更新频繁，应用链路复杂，各节点物理配置不尽相同。穷举所有应用进行压测找到最优或次优的资源调整方案，开销过大，耗时耗力，并不现实。即便可以，往往旧版本的测试数据可能并不适合新版本，或者相同的数据在不同的机器上，由于配置不同，表现出的性能往往也存在差异性，并且没有做到动态调整的效果。
发明内容
本申请提供了一种Kubernetes集群资源动态调整方法及电子设备，旨在至少在一定程度上解决现有技术中的上述技术问题之一。
为了解决上述问题，本申请提供了如下技术方案：
一种Kubernetes集群资源动态调整方法，包括以下步骤：
步骤a：收集应用中的历史监控指标数据，根据所述监控指标数据得到资源消耗时序数据；
步骤b：构建LSTM-Kalman滤波器，将所述资源消耗时序数据输入所述LSTM-Kalman进行预训练，得到预测模型；其中，所述LSTM-Kalman滤波器为利用LSTM改造后的Kalman滤波器；
步骤c：收集新的资源消耗时序数据，将所述新的资源消耗时序数据输入所述预测模型中预测未来预设时间段内的资源消耗峰值，将所述资源消耗峰值作为资源限制值进行资源更新。
本申请实施例采取的技术方案还包括：所述步骤a中，所述收集应用中的历史监控指标数据包括：
对运行在Pod中的容器进行监控并收集各种监控指标数据；收集的监控指标数据包括cpu利用率及限额、文件系统读/写利用率及限额、网络报文发送/接收/丢弃率数据中的至少一种或一种以上的组合；
将收集到的监控指标数据存入时序数据库。
本申请实施例采取的技术方案还包括：在所述步骤a中，所述根据所述监控指标数据得到资源消耗时序数据包括：
定时查询所述时序数据库得到感兴趣的指标数据，并对所述感兴趣的指标数据进行缓存及整理，形成可以直接用于预测的资源消耗时序数据。
本申请实施例采取的技术方案还包括：所述对所述感兴趣的指标数据进行缓存及整理包括：
使用滑动窗口依次滑动每一条指标数据，并选择窗口中的最大值作为新的数据集。
本申请实施例采取的技术方案还包括：在所述步骤b中，所述构建LSTM-Kalman滤波器包括：
假设观测值是系统状态值的有噪估计，令观测矩阵H＝I：
X(k)＝f(X(k-1))+W(k)，W～N(0,Q)
Z(k)＝X(k)+V(k)，V～N(0,R)
上式中，X(k)为k时刻的系统状态，Z(k)为k时刻的观测值，W(k)和V(k)分别表示过程和测量噪声，它们的协方差分别为Q，R；f为由LSTM f模型生成的函数模型；
预测步骤为：
X(k|k-1)＝f(X(k-1|k-1))
P(k|k-1)＝F P(k-1|k-1)FT+Q(k)
上式中，F代表f关于X(k-1|k-1)的雅可比矩阵，Q(k)由LSTM Q给出；
更新步骤为：
Kg(k)＝P(k|k-1)((P(k|k-1)+R(k))-1
X(k|k)＝X(k|k-1)+Kg(k)(Z(k)–X(k|k-1)
P(k|k)＝(I-Kg(k))P(k|k-1)
上式中，R(k)由LSTM r得到，Z(k)代表k时刻的观测值；
将配置文件中的request值作为X(k-1|k-1)，当前时刻k采集到的指标数据作为观测值Z(k|k)，分别经过所述LSTM f和LSTM r网络得到k时刻的预测值X(k|k-1)和观测噪声R(k)；X(k|k-1)经过LSTM Q得到k时刻的状态噪声Q(k)；利用R(k)、Q(k)、X(k-1|k-1)对所述Kalman滤波器进行递推更新。
本申请实施例采取的技术方案还包括：在所述步骤c中，所述将所述资源消耗时序数据输入所述LSTM-Kalman进行预训练，得到预测模型还包括：
模型评估：利用新的监控指标数据对所述预测模型进行迭代训练，直到所述预测模型损失收敛或只在预设范围内震荡时停止迭代训练。
本申请实施例采取的技术方案还包括：所述模型评估还包括：
获取预设时间段内的新的监控指标数据，将所述预测模型的预测结果与所述新的监控指标数据进行比较，判断是否需要再次进行模型训练：如果大于设定阈值的时间消耗值在所述预测模型的预测结果以下则不再更新模型，反之则使用所述新的监控指标数据更新所述预测模型的参数，对所述预测模型进行修正。
本申请实施例采取的技术方案还包括：在所述步骤c中，所述预测未来预设时间段内的资源消耗峰值还包括：
待所述LSTM f、LSTM r、LSTM Q三个子循环网络损失收敛或者降低到预设阈值，开始执行递推估计，通过度量收集器上报数据给预测模型，所述预测模型对未来预设时间段内的资源消耗峰值进行最优估计，使用最优估计值对Pod中容器资源进行更新操作。
本申请实施例采取的又一技术方案为：一种电子设备，包括：
至少一个处理器；以及
与所述至少一个处理器通信连接的存储器；其中，
所述存储器存储有可被所述一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的Kubernetes集群资源动态调整方法的以下操作：
步骤a：收集应用中的历史监控指标数据，根据所述监控指标数据得到资源消耗时序数据；
步骤b：构建LSTM-Kalman滤波器，将所述资源消耗时序数据输入所述LSTM-Kalman进行预训练，得到预测模型；其中，所述LSTM-Kalman滤波器为利用LSTM改造后的Kalman滤波器；
步骤c：收集新的资源消耗时序数据，将所述新的资源消耗时序数据输入所述预测模型中预测未来预设时间段内的资源消耗峰值，将所述资源消耗峰值作为资源限制值进行资源更新。
相对于现有技术，本申请实施例产生的有益效果在于：本申请实施例的Kubernetes集群资源动态调整方法及电子设备首先对应用进行静态冗余配置部署，收集真实负载环境下应用的历史监控指标数据，在线进行预训练得到较为可靠的预测模型；然后对预测模型进行迭代训练，直到模型损失收敛或只在预设范围内震荡后，不断采集新的资源消耗时序数据输入预测模型中预测未来一小段时间内资源消耗的峰值，将该值作为资源限制值进行更新，实现动态的Pod资源限制调整。相对于现有技术，本申请至少具有以下有益效果：
1、面对流量“洪峰”短时间内可以起到良好的缓冲作用，保证服务的实时性，稳定性；面对流量“低谷”，又可将空闲的资源归还内核，有效的提高了系统资源利用率，解决了资源碎片问题，同时具备一定的自适应的能力。
2、在预测的同时进行滤噪处理，保证数据的精确性。
3、规避了应用版本差异、集群异构性导致模型不适用的问题，无需进行大量的压测试验，建立性能和资源关系曲线。
4、通过预测未来一段时间资源消耗峰值作为资源限制值，对资源进行动态限制，采用局部最大值代替全局最大值的配置思想，提高了资源利用率，起到了自适应的效果。
附图说明
图1是本申请实施例的Kubernetes集群资源动态调整方法的流程图；
图2为本申请实施例的Kubernetes集群资源动态调整系统结构示意图；
图3为经LSTM改造后的Kalman滤波器示意图；
图4是本申请实施例提供的Kubernetes集群资源动态调整方法的硬件设备结构示意图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。
针对现有技术的不足，本申请实施例的Kubernetes集群资源动态调整方法提出一种Kubernetes Pod资源在线预测，动态调整解决方案。整个方案包括数据收集整理、在线同步训练、在线预测执行三个阶段。首先对应用进行静态冗余配置部署，收集真实负载环境下应用的Cpu、Memory等历史数据，在线进行预训练得到较为可靠的预测模型；并对预测模型进行迭代训练，直到模型损失收敛或只在预设范围内震荡，则停止训练，并进入在线预测执行阶段，不断采集新的资源消耗时序数据，并输入预测模型中预测未来一小段时间内资源消耗的峰值，将该值作为资源限制值进行更新，实现动态的Pod资源限制调整。
具体的，请参阅图1，是本申请实施例的Kubernetes集群资源动态调整方法的流程图。本申请实施例的Kubernetes集群资源动态调整方法包括以下步骤：
步骤100：数据收集整理：首先对应用进行静态冗余配置部署，收集真实负载环境下应用的Cpu、Memory等历史监控指标数据；
步骤100中，数据收集整理具体包括：
步骤101：通过集成在Kubelet中的cAdvisor对运行在Pod中的容器进行监控并收集各种监控指标数据；
本步骤中，Kubelet为运行在集群每个节点上的进程，用于处理Master节点下发到本节点的任务并负责管理Pod及Pod中的容器。cAdvisor集成于Kubelet组件内，Kubelet从cAdvisor获取单独的容器使用统计信息，然后通过REST API暴露这些聚合后的Pod资源使用的统计信息。cAdvisor是一个开源的分析容器资源使用率以及性能特性的代理工具，它会自动查找所在节点上 的容器，收集每个容器的相关指标数据。本申请实施例中，cAdvisor收集的指标数据包括cpu利用率及限额、文件系统读/写利用率及限额、网络报文发送/接收/丢弃率等数据中的至少一种或一种以上的组合。具体请一并参阅图2，是本申请实施例的Kubernetes集群资源动态调整系统结构图。
步骤102：通过Prometheus将收集到的各种监控指标数据存入TSDB(时序数据库)；
本步骤中，Prometheus是一个开源的服务监控系统和时序数据库，提供了通用的数据模型和便捷的数据采集、存储和查询接口。Prometheus的核心组件Prometheus Server(普罗米修斯服务器)定期从静态配置的监控目标或基于服务发现机制自动配置的目标中拉取监控指标数据。在本申请实施例中，Prometheus Server通过cAdvisor提供的metrics接口周期性的进行数据抓取操作，然后将抓取的数据以时间序列的方式存储到服务端内存缓存区或持久化到存储设备中。
步骤103：通过自定义组件Metrics Collector(度量收集器)定时从Prometheus中收集感兴趣的监控指标数据做二级缓存，并对监控指标数据进行整理，形成可以直接用于预测的资源消耗时序数据；
本步骤中，自定义组件Metrics Collector通过查询语言PromQL定时查询Prometheus Server的时序数据库得到感兴趣的指标数据，并对指标进行缓存及整理，形成可以直接用于预测的资源消耗时序数据，减轻TSDB的压力，同时也保证时序数据的实时性，便于Kalman滤波器进行模型训练和估计。
本申请实施例中，在对时序数据进行处理时，使用滑动窗口依次滑动每一条数据，并选择窗口中的最大值作为新的数据集，使得滤波器预测出的值在未来一段时间内，资源消耗都不会超过预测值。
步骤200：在线同步训练：构建LSTM-Kalman滤波器，将Metrics Collector收集到的资源消耗时序数据输入LSTM-Kalman滤波器中进行预训练，得到预测模型LSTM-KF；
步骤200中，Kalman滤波器是一个最优化自回归数据处理算法，Kalman利用目标的动态信息，设法去掉噪声的影响，得到一个关于目标最优估计。考虑到系统的振荡，应用间的相互干扰等因素造成采集的数据不准，因此利用Kalman滤波器规避掉这些不稳定因素，得到较好的估计值。同时模型仅仅通过5步递推就可以实现对新值的最优估计，但是现有的Kalman滤波器在实际应用中需要依赖动力学模型。
Kalman的空间状态方程可以使用一个线性随机差分方程描述：
X(k)＝AX(k-1)+W(k)，W～N(0,Q)(1)
Z(k)＝HX(k)+V(k)，V～N(0,R)(2)
式(1)代表状态方程，式(2)代表测量方程。其中X(k)为k时刻的系统状态，Z(k)为k时刻的观测值，A为状态转移矩阵，H为观测矩阵，W(k)和V(k)分别表示过程和测量噪声，假设服从高斯白噪声，它们的协方差分别为Q，R。
现有的Kalman滤波算法如下：
利用系统的当前状态模型预测系统的下一状态；假设系统的当前状态k，基于系统的上一状态预测出当前状态：
X(k|k-1)＝A X(k-1|k-1)(3)
式(3)中，X(k|k-1)是利用上一状态预测的结果，X(k-1|k-1)是上一状态最优的估计。对应于X(k|k-1)的协方差：
P(k|k-1)＝A P(k-1|k-1)AT+Q(4)
式(3)、(4)对应了系统预测过程，得到k状态下的预测值，然后结合测量值Z(t)，得到k状态下的最优估计值X(k|k)：
X(k|k)＝X(k|k-1)+Kg(k)(Z(k)–HX(k|k-1)(5)
式(5)中，Kg为Kalman Gain(增益)：
Kg(k)＝P(k|k-1)HT/((H*P(k|k-1)H’+R)(6)
为了使得滤波器不断迭代递推下去，还需要更新X(k|k)状态下的协方差：
P(k|k)＝(I-Kg(k)H)P(k|k-1)(7)
式(7)中，I是全1的矩阵。当进入k+1状态时，P(k|k)即为式(4)中的P(k|k-1)。
上述算法非常依赖动力学模型，然而对于实际问题，动力学特性并不知道，无法先验的给出状态转移矩阵A和观测矩阵H，以及噪声分也是常常假设服从高斯分布。这些参数的假设存在很多人为主观因素，使得模型和实际数据不能很好的匹配，导致较大的预测误差。
因此，本申请通过使用LSTM对Kalman滤波器进行改造，使其摆脱对动力学模型的过分依赖，使得模型参数不需要先验的给出。具体改造过程如下：
给出新的状态空间方程：
假设观测值是系统状态值的有噪估计，令观测矩阵H＝I：
X(K)＝f(X(k-1))+W(k)，W～N(0,Q)(8)
Z(k)＝X(k)+V(k)，V～N(0,R)(9)
式(9)中，f为由LSTM f模型生成的函数模型。
新的预测步骤为：
X(k|k-1)＝f(X(k-1|k-1))(10)
P(k|k-1)＝F P(k-1|k-1)FT+Q(k)(11)
式(11)中，F代表f关于X(k-1|k-1)的雅可比矩阵，Q(k)由LSTM Q给出。
新的更新步骤为：
Kg(k)＝P(k|k-1)((P(k|k-1)+R(k))-1(12)
X(k|k)＝X(k|k-1)+Kg(k)(Z(k)–X(k|k-1)(13)
P(k|k)＝(I-Kg(k))P(k|k-1)(14)
式(12)、(13)中，R(k)由LSTM r得到，Z(k)代表k时刻的观测值。
如图3所示，为经LSTM改造后的Kalman滤波器示意图。初始化时，可以将配置文件中的request值作为X(k-1|k-1)，当前时刻k采集到的指标数据作为观测值Z(k|k)，分别经过LSTM f和LSTM r网络得到k时刻的预测值X(k|k-1)和观测噪声R(k)。X(k|k-1)经过LSTM Q得到k时刻的状态噪声Q(k)。利用R(k)、Q(k)、X(k-1|k-1)，通过式(12)、(13)、(14)对Kalman滤波器进行递推更新。
基于上述，经过LSTM改造后的Kalman滤波器兼顾预测和滤噪的同时，摆脱了对动力学模型的过分依赖，模型参数不用先验的给出，可以从数据中 学习出来，充分发挥时间序列前后相关性；并且增强了长程预测能力，而不仅仅依赖于上一个时刻值，预测精度可以显著提高。
步骤300：模型评估：利用新的监控指标数据对预测模型进行迭代训练，以对预测模型进行更新修正，直到模型损失收敛或只在预设范围内震荡，得到训练好的预测模型LSTM-KF；
步骤300中，模型评估过程具体为：通过Controller拉取Metrics Collector设定时间段内的监控指标数据，并对预测模型的预测结果和从Metrics Collector上报的监控指标数据进行比较，判断是否需要再次进行模型训练：如果设定阈值的时间消耗值在预测模型的最优估计值以下则不再更新模型，反之则再次使用新的监控指标数据更新预测模型参数，对模型进行修正。Controller中还备份有一个历史数据峰值，以备滤波器再次训练时，临时作为容器资源限制使用。
步骤400：进入在线预测执行阶段：不断收集新的资源消耗时序数据，并输入训练好的预测模型中预测未来预设时间段内的资源消耗峰值，并将该值作为资源限制值进行更新；
步骤400中，待LSTM f、LSTM r、LSTM Q三个子循环网络损失收敛或者降低到预设阈值，开始执行递推估计，Metrics Collector上报数据给预测模型LSTM-KF，预测模型LSTM-KF对接下来一小段时间的资源消耗峰值进行最优估计，Executor直接使用最优估计值对Pod中容器所在的Container Cgroup的限制值进行更新操作。本申请采用最优估计值代表未来一小段时间峰值，即使用局部峰值代替全局峰值，即可避免冗余配置，又可以保证服务的稳定性，提高了资源利用率，起到了自适应的效果。
Cgroup是Linux内核中用于实现资源使用和统计的模块，Docker利用Cgroup进行资源隔离及限制，Kubelet作为Kubernetes的节点代理，所有对Cgroup的操作都是由内部的Container Manager模块实现，Container Manager会通过Cgroup对资源使用层层限制。当通过yaml等配置文件对容器资源请求和限制量指定时，Docker会为容器设置运行时的cpu.share、cpu.quota、cpu.period、mem.limit等指标，Executor通过修改这些指标文件进行资源更新，从而实现动态的Pod资源限制调整。
本申请实施例中，由于各组件之间存在频繁的调用关系，为了部署方便，可以借助Sidecar(一种将应用功能从应用本身剥离出来作为单独进程的方式。做到无侵入的向应用添加多种功能)思想将组件容器化，部署在同一个Pod内，便于运维管理。
图4是本申请实施例提供的Kubernetes集群资源动态调整方法的硬件设备结构示意图。如图4所示，该设备包括一个或多个处理器以及存储器。以一个处理器为例，该设备还可以包括：输入系统和输出系统。
处理器、存储器、输入系统和输出系统可以通过总线或者其他方式连接，图4中以通过总线连接为例。
存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序、非暂态计算机可执行程序以及模块。处理器通过运行存储在存储器中的非暂态软件程序、指令以及模块，从而执行电子设备的各种功能应用以及数据处理，即实现上述方法实施例的处理方法。
存储器可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储数据等。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如 至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施例中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至处理系统。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
输入系统可接收输入的数字或字符信息，以及产生信号输入。输出系统可包括显示屏等显示设备。
所述一个或者多个模块存储在所述存储器中，当被所述一个或者多个处理器执行时，执行上述任一方法实施例的以下操作：
步骤a：收集应用中的历史监控指标数据，根据所述监控指标数据得到资源消耗时序数据；
步骤b：构建LSTM-Kalman滤波器，将所述资源消耗时序数据输入所述LSTM-Kalman进行预训练，得到预测模型；其中，所述LSTM-Kalman滤波器为利用LSTM改造后的Kalman滤波器；
步骤c：收集新的资源消耗时序数据，将所述新的资源消耗时序数据输入所述预测模型中预测未来预设时间段内的资源消耗峰值，将所述资源消耗峰值作为资源限制值进行资源更新。
上述产品可执行本申请实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本申请实施例提供的方法。
本申请实施例提供了一种非暂态(非易失性)计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令可执行以下操作：
步骤a：收集应用中的历史监控指标数据，根据所述监控指标数据得到资源消耗时序数据；
步骤b：构建LSTM-Kalman滤波器，将所述资源消耗时序数据输入所述LSTM-Kalman进行预训练，得到预测模型；其中，所述LSTM-Kalman滤波器为利用LSTM改造后的Kalman滤波器；
步骤c：收集新的资源消耗时序数据，将所述新的资源消耗时序数据输入所述预测模型中预测未来预设时间段内的资源消耗峰值，将所述资源消耗峰值作为资源限制值进行资源更新。
本申请实施例提供了一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行以下操作：
步骤a：收集应用中的历史监控指标数据，根据所述监控指标数据得到资源消耗时序数据；
步骤b：构建LSTM-Kalman滤波器，将所述资源消耗时序数据输入所述LSTM-Kalman进行预训练，得到预测模型；其中，所述LSTM-Kalman滤波器为利用LSTM改造后的Kalman滤波器；
步骤c：收集新的资源消耗时序数据，将所述新的资源消耗时序数据输入所述预测模型中预测未来预设时间段内的资源消耗峰值，将所述资源消耗峰值作为资源限制值进行资源更新。
本申请实施例的Kubernetes集群资源动态调整方法及电子设备首先对应用进行静态冗余配置部署，收集真实负载环境下应用的历史监控指标数据，在线进行预训练得到较为可靠的预测模型；然后对预测模型进行迭代训练，直 到模型损失收敛或只在预设范围内震荡后，不断采集新的资源消耗时序数据输入预测模型中预测未来一小段时间内资源消耗的峰值，将该值作为资源限制值进行更新，实现动态的Pod资源限制调整。相对于现有技术，本申请至少具有以下有益效果：
1、面对流量“洪峰”短时间内可以起到良好的缓冲作用，保证服务的实时性，稳定性；面对流量“低谷”，又可将空闲的资源归还内核，有效的提高了系统资源利用率，解决了资源碎片问题，同时具备一定的自适应的能力。
2、在预测的同时进行滤噪处理，保证数据的精确性。
3、规避了应用版本差异、集群异构性导致模型不适用的问题，无需进行大量的压测试验，建立性能和资源关系曲线。
4、通过预测未来一段时间资源消耗峰值作为资源限制值，对资源进行动态限制，采用局部最大值代替全局最大值的配置思想，提高了资源利用率，起到了自适应的效果。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本申请中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本申请所示的这些实施例，而是要符合与本申请所公开的原理和新颖特点相一致的最宽的范围。

Claims (9)

  1. 一种Kubernetes集群资源动态调整方法，其特征在于，包括以下步骤：
    步骤a：收集应用中的历史监控指标数据，根据所述监控指标数据得到资源消耗时序数据；
    步骤b：构建LSTM-Kalman滤波器，将所述资源消耗时序数据输入所述LSTM-Kalman进行预训练，得到预测模型；其中，所述LSTM-Kalman滤波器为利用LSTM改造后的Kalman滤波器；
    步骤c：收集新的资源消耗时序数据，将所述新的资源消耗时序数据输入所述预测模型中预测未来预设时间段内的资源消耗峰值，将所述资源消耗峰值作为资源限制值进行资源更新。
  2. 根据权利要求1所述的Kubernetes集群资源动态调整方法，其特征在于，所述步骤a中，所述收集应用中的历史监控指标数据包括：
    对运行在Pod中的容器进行监控并收集各种监控指标数据；收集的监控指标数据包括cpu利用率及限额、文件系统读/写利用率及限额、网络报文发送/接收/丢弃率数据中的至少一种或一种以上的组合；
    将收集到的监控指标数据存入时序数据库。
  3. 根据权利要求2所述的Kubernetes集群资源动态调整方法，其特征在于，在所述步骤a中，所述根据所述监控指标数据得到资源消耗时序数据包括：
    定时查询所述时序数据库得到感兴趣的指标数据，并对所述感兴趣的指标数据进行缓存及整理，形成可以直接用于预测的资源消耗时序数据。
  4. 根据权利要求3所述的Kubernetes集群资源动态调整方法，其特征在于，所述对所述感兴趣的指标数据进行缓存及整理包括：
    使用滑动窗口依次滑动每一条指标数据，并选择窗口中的最大值作为新的数据集。
  5. 根据权利要求1所述的Kubernetes集群资源动态调整方法，其特征在于，在所述步骤b中，所述构建LSTM-Kalman滤波器包括：
    假设观测值是系统状态值的有噪估计，令观测矩阵H＝I：
    X(k)＝f(X(k-1))+W(k)，W～N(0,Q)
    Z(k)＝X(k)+V(k)，V～N(0,R)
    上式中，X(k)为k时刻的系统状态，Z(k)为k时刻的观测值，W(k)和V(k)分别表示过程和测量噪声，它们的协方差分别为Q，R；f为由LSTM f模型生成的函数模型；
    预测步骤为：
    X(k|k-1)＝f(X(k-1|k-1))
    P(k|k-1)＝F P(k-1|k-1)FT+Q(k)
    上式中，F代表f关于X(k-1|k-1)的雅可比矩阵，Q(k)由LSTM Q给出；
    更新步骤为：
    Kg(k)＝P(k|k-1)((P(k|k-1)+R(k))-1
    X(k|k)＝X(k|k-1)+Kg(k)(Z(k)–X(k|k-1)
    P(k|k)＝(I-Kg(k))P(k|k-1)
    上式中，R(k)由LSTM r得到，Z(k)代表k时刻的观测值；
    将配置文件中的request值作为X(k-1|k-1)，当前时刻k采集到的指标数据作为观测值Z(k|k)，分别经过所述LSTM f和LSTM r网络得到k时刻的预测值X(k|k-1)和观测噪声R(k)；X(k|k-1)经过LSTM Q得到k时刻的状态噪声Q(k)；利用R(k)、Q(k)、X(k-1|k-1)对所述Kalman滤波器进行递推更新。
  6. 根据权利要求1至5任一项所述的Kubernetes集群资源动态调整方法，其特征在于，在所述步骤c中，所述预将所述资源消耗时序数据输入所述LSTM-Kalman进行预训练，得到预测模型还包括：
    模型评估：利用新的监控指标数据对所述预测模型进行迭代训练，直到所述预测模型损失收敛或只在预设范围内震荡时停止迭代训练。
  7. 根据权利要求6所述的Kubernetes集群资源动态调整方法，其特征在于，所述模型评估还包括：
    获取设定时间段内的新的监控指标数据，将所述预测模型的预测结果与所述新的监控指标数据进行比较，判断是否需要再次进行模型训练：如果大于设定阈值的时间消耗值在所述预测模型的预测结果以下则不再更新模型，反之则使用所述新的的监控指标数据更新所述预测模型的参数，对所述预测模型进行修正。
  8. 根据权利要求5所述的Kubernetes集群资源动态调整方法，其特征在于，在所述步骤c中，所述预测未来预设时间段内的资源消耗峰值还包括：
    待所述LSTM f、LSTM r、LSTM Q三个子循环网络损失收敛或者降低到预设阈值，开始执行递推估计，通过度量收集器上报数据给预测模型，所述预测模型对未来预设时间段内的资源消耗峰值进行最优估计，使用最优估计值对Pod中容器资源进行更新操作。
  9. 一种电子设备，包括：
    至少一个处理器；以及
    与所述至少一个处理器通信连接的存储器；其中，
    所述存储器存储有可被所述一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述1至8任一项所述的Kubernetes集群资源动态调整方法的以下操作：
    步骤a：收集应用中的历史监控指标数据，根据所述监控指标数据得到资源消耗时序数据；
    步骤b：构建LSTM-Kalman滤波器，将所述资源消耗时序数据输入所述LSTM-Kalman进行预训练，得到预测模型；其中，所述LSTM-Kalman滤波器为利用LSTM改造后的Kalman滤波器；
    步骤c：收集新的资源消耗时序数据，将所述新的资源消耗时序数据输入所述预测模型中预测未来预设时间段内的资源消耗峰值，将所述资源消耗峰值作为资源限制值进行资源更新。
PCT/CN2020/140019 2020-07-22 2020-12-28 一种kubernetes集群资源动态调整方法及电子设备 Ceased WO2022016808A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010709708.X 2020-07-22
CN202010709708.XA CN113971066B (zh) 2020-07-22 2020-07-22 一种Kubernetes集群资源动态调整方法及电子设备

Publications (1)

Publication Number Publication Date
WO2022016808A1 true WO2022016808A1 (zh) 2022-01-27

Family

ID=79584799

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/140019 Ceased WO2022016808A1 (zh) 2020-07-22 2020-12-28 一种kubernetes集群资源动态调整方法及电子设备

Country Status (2)

Country Link
CN (1) CN113971066B (zh)
WO (1) WO2022016808A1 (zh)

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114637650A (zh) * 2022-03-11 2022-06-17 电子科技大学 一种基于Kubernetes集群的弹性伸缩方法
CN114722529A (zh) * 2022-03-31 2022-07-08 南通倍佳机械科技有限公司 一种基于人工智能的推杆设备寿命预测方法及系统
CN114780202A (zh) * 2022-03-29 2022-07-22 浪潮云信息技术股份公司 一种函数计算资源池调整方法、装置、设备及介质
CN115168042A (zh) * 2022-07-18 2022-10-11 中国电信股份有限公司 监控集群的管理方法及装置、计算机存储介质、电子设备
CN115168057A (zh) * 2022-09-02 2022-10-11 浙江大华技术股份有限公司 基于k8s集群的资源调度方法及装置
CN115469974A (zh) * 2022-11-03 2022-12-13 成都盛思睿信息技术有限公司 资源受限状态下的Kubernetes Pod弹性扩缩容方法
CN115714692A (zh) * 2022-11-18 2023-02-24 联通(广东)产业互联网有限公司 一种监测网卡的模型训练方法及其应用、系统和电子设备
CN115953738A (zh) * 2023-03-02 2023-04-11 上海燧原科技有限公司 一种图像识别分布式训练的监控方法、装置、设备及介质
CN116010519A (zh) * 2022-12-30 2023-04-25 杭州沃趣科技股份有限公司 一种本地存储目录的iops参数确定方法、设备及介质
CN116089218A (zh) * 2023-02-10 2023-05-09 杭州谐云科技有限公司 基于Kubernetes的历史数据和趋势分析的动态基线告警方法及系统
CN116643844A (zh) * 2023-05-24 2023-08-25 方心科技股份有限公司 面向电力超算云资源自动扩展的智能化管理系统及方法
CN117032950A (zh) * 2023-07-10 2023-11-10 企迈科技有限公司 基于日志的实时数据透传方法及系统
CN117455063A (zh) * 2023-11-09 2024-01-26 河南省地质研究院 基于三维地质模型的矿产资源预测方法、设备以及介质
CN117785446A (zh) * 2023-12-18 2024-03-29 慧之安信息技术股份有限公司 基于弹性资源分配策略的K8s存储资源分配方法和系统
CN117971474A (zh) * 2024-01-30 2024-05-03 新励成教育科技股份有限公司 一种自适应能效及资源动态配置的数据中心口才训练系统
CN118368212A (zh) * 2024-06-19 2024-07-19 中邮消费金融有限公司 基于业务指标的全链路监控系统、方法及存储介质
CN118644524A (zh) * 2024-06-26 2024-09-13 东南大学 一种基于lstm-kf的无人机视角小目标跟踪方法
CN120276828A (zh) * 2025-06-06 2025-07-08 苏州元脑智能科技有限公司 任务调度处理方法及电子设备
CN120353583A (zh) * 2025-04-03 2025-07-22 武汉星火众达信息技术有限公司 一种基于用户的需求和任务优先级的计算资源调度方法
CN120415999A (zh) * 2025-07-02 2025-08-01 广州嘉为科技有限公司 基于Sidecar与Executor的监控探针双层管理方法、系统、设备及介质
CN120492131A (zh) * 2025-07-16 2025-08-15 浙江算力科技有限公司 基于时序图网络资源状态预测的计算任务调度方法及系统
CN121704621A (zh) * 2026-02-11 2026-03-20 福建农业职业技术学院 基于窄带物联网的农业温室环境协同控制方法及系统

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114780170B (zh) * 2022-04-11 2023-07-21 远景智能国际私人投资有限公司 容器资源的配置方法、装置、设备及存储介质
CN115397026B (zh) * 2022-08-25 2025-07-29 中国科学院计算技术研究所 一种接入网系统的资源调度方法
CN116185568A (zh) * 2023-02-01 2023-05-30 杭州朝厚信息科技有限公司 一种容器扩容方法、装置、电子设备及存储介质
CN117197902B (zh) * 2023-11-07 2024-01-30 华南农业大学 一种母猪分娩智能预测系统及方法
WO2024187919A1 (zh) * 2023-12-12 2024-09-19 天翼云科技有限公司 Kubernetes中存量Pod的数据更新方法、装置、设备及介质
CN118152124B (zh) * 2024-03-15 2024-12-06 广东织云科技有限公司 一种基于云计算的数据处理方法及系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108228347A (zh) * 2017-12-21 2018-06-29 上海电机学院 一种任务感知的Docker自适应调度系统
CN108874542A (zh) * 2018-06-07 2018-11-23 桂林电子科技大学 基于神经网络的Kubernetes调度优化方法
CN108920153A (zh) * 2018-05-29 2018-11-30 华南理工大学 一种基于负载预测的Docker容器动态调度方法
US20180349168A1 (en) * 2017-05-30 2018-12-06 Magalix Corporation Systems and methods for managing a cloud computing environment
CN110535894A (zh) * 2018-05-25 2019-12-03 深圳先进技术研究院 一种基于负载反馈的容器资源动态分配方法及其系统
CN111124689A (zh) * 2019-12-31 2020-05-08 中国电子科技集团公司信息科学研究院 一种集群中容器资源动态分配方法
CN112069039A (zh) * 2020-08-28 2020-12-11 苏州浪潮智能科技有限公司 人工智能开发平台的监控预知告警方法、装置及存储介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190095245A1 (en) * 2017-09-22 2019-03-28 CloudHealth Technologies, Inc. System and Method for Apportioning Shared Computer Resources
EP3750060B1 (en) * 2018-02-05 2024-10-09 Telefonaktiebolaget LM Ericsson (publ.) Resource needs prediction in virtualized systems: generic proactive and self-adaptive solution

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180349168A1 (en) * 2017-05-30 2018-12-06 Magalix Corporation Systems and methods for managing a cloud computing environment
CN108228347A (zh) * 2017-12-21 2018-06-29 上海电机学院 一种任务感知的Docker自适应调度系统
CN110535894A (zh) * 2018-05-25 2019-12-03 深圳先进技术研究院 一种基于负载反馈的容器资源动态分配方法及其系统
CN108920153A (zh) * 2018-05-29 2018-11-30 华南理工大学 一种基于负载预测的Docker容器动态调度方法
CN108874542A (zh) * 2018-06-07 2018-11-23 桂林电子科技大学 基于神经网络的Kubernetes调度优化方法
CN111124689A (zh) * 2019-12-31 2020-05-08 中国电子科技集团公司信息科学研究院 一种集群中容器资源动态分配方法
CN112069039A (zh) * 2020-08-28 2020-12-11 苏州浪潮智能科技有限公司 人工智能开发平台的监控预知告警方法、装置及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TIAN YE: "Study on Auto Scaling Framework for Container in Cloud Computing", MASTER THESIS, TIANJIN POLYTECHNIC UNIVERSITY, CN, no. 1, 15 January 2020 (2020-01-15), CN , XP055888217, ISSN: 1674-0246 *

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114637650A (zh) * 2022-03-11 2022-06-17 电子科技大学 一种基于Kubernetes集群的弹性伸缩方法
CN114780202A (zh) * 2022-03-29 2022-07-22 浪潮云信息技术股份公司 一种函数计算资源池调整方法、装置、设备及介质
CN114722529B (zh) * 2022-03-31 2023-08-08 广东精茂健康科技股份有限公司 一种基于人工智能的推杆设备寿命预测方法及系统
CN114722529A (zh) * 2022-03-31 2022-07-08 南通倍佳机械科技有限公司 一种基于人工智能的推杆设备寿命预测方法及系统
CN115168042A (zh) * 2022-07-18 2022-10-11 中国电信股份有限公司 监控集群的管理方法及装置、计算机存储介质、电子设备
CN115168057A (zh) * 2022-09-02 2022-10-11 浙江大华技术股份有限公司 基于k8s集群的资源调度方法及装置
CN115469974A (zh) * 2022-11-03 2022-12-13 成都盛思睿信息技术有限公司 资源受限状态下的Kubernetes Pod弹性扩缩容方法
CN115714692A (zh) * 2022-11-18 2023-02-24 联通(广东)产业互联网有限公司 一种监测网卡的模型训练方法及其应用、系统和电子设备
CN115714692B (zh) * 2022-11-18 2025-06-27 联通(广东)产业互联网有限公司 一种监测网卡的模型训练方法及其应用、系统和电子设备
CN116010519A (zh) * 2022-12-30 2023-04-25 杭州沃趣科技股份有限公司 一种本地存储目录的iops参数确定方法、设备及介质
CN116089218A (zh) * 2023-02-10 2023-05-09 杭州谐云科技有限公司 基于Kubernetes的历史数据和趋势分析的动态基线告警方法及系统
CN115953738A (zh) * 2023-03-02 2023-04-11 上海燧原科技有限公司 一种图像识别分布式训练的监控方法、装置、设备及介质
CN116643844A (zh) * 2023-05-24 2023-08-25 方心科技股份有限公司 面向电力超算云资源自动扩展的智能化管理系统及方法
CN116643844B (zh) * 2023-05-24 2024-02-06 方心科技股份有限公司 面向电力超算云资源自动扩展的智能化管理系统及方法
CN117032950A (zh) * 2023-07-10 2023-11-10 企迈科技有限公司 基于日志的实时数据透传方法及系统
CN117455063A (zh) * 2023-11-09 2024-01-26 河南省地质研究院 基于三维地质模型的矿产资源预测方法、设备以及介质
CN117785446A (zh) * 2023-12-18 2024-03-29 慧之安信息技术股份有限公司 基于弹性资源分配策略的K8s存储资源分配方法和系统
CN117971474A (zh) * 2024-01-30 2024-05-03 新励成教育科技股份有限公司 一种自适应能效及资源动态配置的数据中心口才训练系统
CN118368212A (zh) * 2024-06-19 2024-07-19 中邮消费金融有限公司 基于业务指标的全链路监控系统、方法及存储介质
CN118644524A (zh) * 2024-06-26 2024-09-13 东南大学 一种基于lstm-kf的无人机视角小目标跟踪方法
CN120353583A (zh) * 2025-04-03 2025-07-22 武汉星火众达信息技术有限公司 一种基于用户的需求和任务优先级的计算资源调度方法
CN120353583B (zh) * 2025-04-03 2026-02-13 武汉星火众达信息技术有限公司 一种基于用户的需求和任务优先级的计算资源调度方法
CN120276828A (zh) * 2025-06-06 2025-07-08 苏州元脑智能科技有限公司 任务调度处理方法及电子设备
CN120415999A (zh) * 2025-07-02 2025-08-01 广州嘉为科技有限公司 基于Sidecar与Executor的监控探针双层管理方法、系统、设备及介质
CN120492131A (zh) * 2025-07-16 2025-08-15 浙江算力科技有限公司 基于时序图网络资源状态预测的计算任务调度方法及系统
CN121704621A (zh) * 2026-02-11 2026-03-20 福建农业职业技术学院 基于窄带物联网的农业温室环境协同控制方法及系统

Also Published As

Publication number Publication date
CN113971066B (zh) 2024-11-26
CN113971066A (zh) 2022-01-25

Similar Documents

Publication Publication Date Title
CN113971066B (zh) 一种Kubernetes集群资源动态调整方法及电子设备
CN109271015B (zh) 一种降低大规模分布式机器学习系统能耗的方法
CN110990159B (zh) 一种基于历史数据分析的容器云平台资源配额预测方法
CN102799512A (zh) 一种基于向量自回归的云计算中虚拟机监控方法
CN105893541B (zh) 一种基于混合存储的流式数据自适应持久化方法及系统
CN116225696B (zh) 用于流处理系统的算子并发度调优方法及装置
CN114637650B (zh) 一种基于Kubernetes集群的弹性伸缩方法
CN111385142B (zh) 基于Kubernetes的自适应伸缩web容器的方法
CN111694653A (zh) 计算系统中调整计算算子类型分布的方法、装置及系统
CN112751726A (zh) 一种数据处理方法、装置、电子设备和存储介质
CN120578499A (zh) 基于硬件资源负载与系统运行关系映射预测方法及系统
Zhang et al. Autrascale: an automated and transfer learning solution for streaming system auto-scaling
CN115185683A (zh) 一种基于动态优化模型的云平台流处理资源分配方法
CN120909809B (zh) 基于k8s进行模型训练的方法
CN120803743B (zh) 一种基于奖励累积深度强化学习的Kubernetes微服务最优部署方法、设备及介质
CN120353612B (zh) 异构计算系统及缓存一致性维护方法、装置、设备、介质
Ali et al. Probabilistic normed load monitoring in large scale distributed systems using mobile agents
CN120407183A (zh) 一种用户无感的冷热感知的远程内存交换系统
CN114297026B (zh) 自适应混沌环境的云存储服务超时值优化方法及相关设备
Koch et al. SMiPE: estimating the progress of recurring iterative distributed dataflows
CN115391028A (zh) 资源分配系统、方法及装置
CN120704899B (zh) 基于kubernetes的数据流驱动的高均衡serverless工作流调度方法及系统
US12536172B2 (en) Data query optimization method, electronic device and storage medium
CN119620959B (zh) 用于存储空间的弹性伸缩方法、设备、介质及程序产品
CN121412281B (zh) 基于机器学习的教育教学资源动态分配管理系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20946105

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20946105

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 20946105

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 09/08/2023)

122 Ep: pct application non-entry in european phase

Ref document number: 20946105

Country of ref document: EP

Kind code of ref document: A1