CN116069460A - 基于监控体系的Kubernetes容器资源动态调度方法 - Google Patents
基于监控体系的Kubernetes容器资源动态调度方法 Download PDFInfo
- Publication number
- CN116069460A CN116069460A CN202211513323.1A CN202211513323A CN116069460A CN 116069460 A CN116069460 A CN 116069460A CN 202211513323 A CN202211513323 A CN 202211513323A CN 116069460 A CN116069460 A CN 116069460A
- Authority
- CN
- China
- Prior art keywords
- node
- resource
- cluster
- scheduling
- monitoring system
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
- G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5083—Techniques for rebalancing the load in a distributed system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Quality & Reliability (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明公开了基于监控体系的Kubernetes容器资源动态调度方法包括:设计三种触发动态资源调度的方式;构建监控体系以监控集群节点的资源利用率;通过计算公式计算各调度节点得分;将调度的pod与得分最高的worker节点进行绑定,完成最终的调度。本发明提供的基于监控体系的Kubernetes容器资源动态调度方法无需遍历所有节点进而提升资源调度效率,资源均衡度好;且在现有的资源调度算法研究基础上,加入了除CPU、内存和磁盘外的网络利用率和速率,并实现了自定义调度器来应用改进的资源调度算法,降低了CPU使用率,显著提升了性能,能更好应对复杂场景资源调度。
Description
技术领域
本发明涉及资源调度技术领域,具体为基于监控体系的Kubernetes容器资源动态调度方法。
背景技术
目前,在以Docker为代表的容器化技术加持下,基于容器化技术的大规模应用的开发和部署已经成为主流。Kubernetes最初源于谷歌内部的Borg,提供了面向应用的容器集群部署和管理系统。Kubernetes的目标旨在消除编排物理/虚拟计算,网络和存储基础设施的负担,并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes已是Docker容器生态系统中应用最广泛的编排系统。Kubernetes的核心功能是资源调度,优秀合理的资源调度技术可以显著提高其计算与存储资源的利用效率,为企业节约软硬件成本。
现有Kubernetes调度器仅仅实现了对Pod的静态调度。即使在第一次调度后使得集群负载均衡,可是随着系统的长时间运行,Pod或节点可能会进行添加或删除,进而导致集群节点资源的使用变化,同样也会产生集群负载不均衡的现象,使得部分节点过载,甚至宕机。
发明内容
本部分的目的在于概述本发明的实施例的一些方面以及简要介绍一些较佳实施例。在本部分以及本申请的说明书摘要和发明名称中可能会做些简化或省略以避免使本部分、说明书摘要和发明名称的目的模糊,而这种简化或省略不能用于限制本发明的范围。
鉴于上述存在的问题,提出了本发明。
因此,本发明解决的技术问题是:现有的Kubernetes调度器仅仅实现了对Pod的静态调度,忽略了节点的资源利用率是随时变化的,无法解决集群负载不平衡的问题。
为解决上述技术问题,本发明提供如下技术方案:基于监控体系的Kubernetes容器资源动态调度方法,包括,
设计三种触发动态资源调度的方式;
构建监控体系以监控集群节点的资源利用率;
通过计算公式计算各调度节点得分;
将调度的pod与得分最高的worker节点进行绑定,完成最终的调度。
作为本发明所述的基于监控体系的Kubernetes容器资源动态调度方法的一种优选方案,其中:所述三种触发动态资源调度方式分别为定时触发、定期触发、临界触发;
所述定时触发定时触发指的是为集群创建一个定时器,在定时时间来临时触发资源调度过程;
所述定期触发指的是针对长时间运行的服务设置每隔一段时间就进行一次资源调度,这一固定的时间由用户自定义设置,需要根据集群具体情况合理地设置此时长;若过长则可能导致动态调度机制长时间不执行进而导致集群负载不均衡,若设置过短则导致调度器频繁地运行,影响集群性能。
所述临界触发节点负载超阈值触发是指为每个节点设置一个阈值,若节点超过指定阈值的时间大于指定的时间则触发资源调度。
作为本发明所述的基于监控体系的Kubernetes容器资源动态调度方法的一种优选方案,其中:所述监控体系包括,
以DaemonSet方式在Kubernetes集群的每一个Node上都部署一个节点监控数据采集器Node-Exporter,在Master节点部署PrometheusServer来采集和存储节点的资源使用信息,PrometheusServer负责定时向每个节点的Node-Exporter采集节点监控周期的资源使用情况。
作为本发明所述的基于监控体系的Kubernetes容器资源动态调度方法的一种优选方案,其中:所述DaemonSet,可保证每个节点上只有一个Pod,
当node加入集群时创建pod;
当node离开集群时回收pod;
当删除DaemonSet时,其创建的所有pod也被删除,DaemonSet中的pod覆盖整个集群。
作为本发明所述的基于监控体系的Kubernetes容器资源动态调度方法的一种优选方案,其中:所述Master指的是集群控制节点,在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制,Kubernetes98%的所有控制命令都发给它,它负责具体的执行过程;
所述node节点为运行容器的实际节点,用于维护运行pod并提供具体应用的运行环境。
作为本发明所述的基于监控体系的Kubernetes容器资源动态调度方法的一种优选方案,其中:所述采集节点监控周期的资源使用情况包括,Prometheus Server接到请求后便将监控数据以JSON格式返回给监控组件,监控组件对数据进行解码,提取对应的节点监控信息,并存储到相应的数据结构,作为资源动态调度的依据。
作为本发明所述的基于监控体系的Kubernetes容器资源动态调度方法的一种优选方案,其中:所述计算公式包括,
L(i)=L(c)+L(m)+L(n)+L(d)
S(i)=n*S(c)S(m)S(n)S(d)
其中,score为调度节点得分,L(i)表示节点负载,S(i)表示节点性能;
L(c)表示CPU利用率,L(m)表示内存利用率,L(n)表示网络利用率,L(d)表示磁盘利用率;
n为CPU核数,S(c)表示CPU频率,S(m)表示内存容量,S(n)表示网络速率,S(d)表示磁盘IO速率;
所述计算公式表示在原有的负载均衡计算上加入网络利用率指标,把CPU、内存、网络、磁盘IO四个维度数据综合考量计算最终得分。
作为本发明所述的基于监控体系的Kubernetes容器资源动态调度方法的一种优选方案,其中:所述将调度的pod与得分最高的worker节点进行绑定包括,
向apiserver发送post请求;
apiserver把创建Pod的信息存储到Etcd中,从集群运行那一刻起,资源调度系统Scheduler就会定时去监控apiserver通过apiserver得到创建Pod的信息,Scheduler采用watch机制,一旦Etcd存储Pod信息成功便会立即通知apiserver,apiserver会立即把Pod创建的消息通知Scheduler,Scheduler发现Pod的属性中DestNode为空时,便会立即触发调度流程进行调度。
作为本发明所述的基于监控体系的Kubernetes容器资源动态调度方法的一种优选方案,其中:所述apiserver能够提供集群管理的REST API接口;提供其他模块之间的数据交互和通信的枢纽,即其他模块通过APIServer查询或修改数据,只有API Server才直接操作etcd。
作为本发明所述的基于监控体系的Kubernetes容器资源动态调度方法的一种优选方案,其中:所述Etcd为分布式key-value存储,用于服务发现、共享配置以及一致性保障,可跟踪并管理集群节点的状态;
所述watch机制为当服务器上某一节点的数据或状态发生变化时收到相应的通知。
本发明的有益效果:本发明提供的基于监控体系的Kubernetes容器资源动态调度方法无需遍历所有节点进而提升资源调度效率,资源均衡度好;且在现有的资源调度算法研究基础上,加入了除CPU、内存和磁盘外的网络利用率和速率,并实现了自定义调度器来应用改进的资源调度算法,降低了CPU使用率,显著提升了性能,能更好应对复杂场景资源调度。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其它的附图。其中:
图1为本发明一个实施例提供的基于监控体系的Kubernetes容器资源动态调度方法的整体流程图;
图2为本发明一个实施例提供的基于监控体系的Kubernetes容器资源动态调度方法的优化项示意图;
图3为本发明一个实施例提供的基于监控体系的Kubernetes容器资源动态调度方法中三种触发机制的运行流程图。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合说明书附图对本发明的具体实施方式做详细的说明,显然所描述的实施例是本发明的一部分实施例,而不是全部实施例。基于本发明中的实施例,本领域普通人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明的保护的范围。
在下面的描述中阐述了很多具体细节以便于充分理解本发明,但是本发明还可以采用其他不同于在此描述的其它方式来实施,本领域技术人员可以在不违背本发明内涵的情况下做类似推广,因此本发明不受下面公开的具体实施例的限制。
其次,此处所称的“一个实施例”或“实施例”是指可包含于本发明至少一个实现方式中的特定特征、结构或特性。在本说明书中不同地方出现的“在一个实施例中”并非均指同一个实施例,也不是单独的或选择性的与其他实施例互相排斥的实施例。
本发明结合示意图进行详细描述,在详述本发明实施例时,为便于说明,表示器件结构的剖面图会不依一般比例作局部放大,而且所述示意图只是示例,其在此不应限制本发明保护的范围。此外,在实际制作中应包含长度、宽度及深度的三维空间尺寸。
同时在本发明的描述中,需要说明的是,术语中的“上、下、内和外”等指示的方位或位置关系为基于附图所示的方位或位置关系,仅是为了便于描述本发明和简化描述,而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作,因此不能理解为对本发明的限制。此外,术语“第一、第二或第三”仅用于描述目的,而不能理解为指示或暗示相对重要性。
本发明中除非另有明确的规定和限定,术语“安装、相连、连接”应做广义理解,例如:可以是固定连接、可拆卸连接或一体式连接;同样可以是机械连接、电连接或直接连接,也可以通过中间媒介间接相连,也可以是两个元件内部的连通。对于本领域的普通技术人员而言,可以具体情况理解上述术语在本发明中的具体含义。
实施例1
参照图1~3,为本发明的一个实施例,提供了基于监控体系的Kubernetes容器资源动态调度方法,包括:
首先设计三种触发动态资源调度的方式;
三种触发动态资源调度方式分别为定时触发、定期触发、临界触发。
定时触发定时触发指的是为集群创建一个定时器,在定时时间来临时触发资源调度过程。
定期触发指的是针对长时间运行的服务设置每隔一段时间就进行一次资源调度。这一固定的时间由用户自定义设置,需要根据集群具体情况合理地设置此时长。若过长则可能导致动态调度机制长时间不执行进而导致集群负载不均衡,若设置过短则导致调度器频繁地运行,影响集群性能。
临界触发节点负载超阈值触发是指为每个节点设置一个阈值,若节点超过指定阈值的时间大于指定的时间则触发资源调度。
其次构建监控体系以监控集群节点的资源利用率;
监控体系包括,以DaemonSet方式在Kubernetes集群的每一个Node上都部署一个节点监控数据采集器Node-Exporter,在Master节点部署PrometheusServer来采集和存储节点的资源使用信息,PrometheusServer负责定时向每个节点的Node-Exporter采集节点监控周期的资源使用情况。
DaemonSet,可保证每个节点上只有一个Pod,当node加入集群时创建pod,当node离开集群时回收pod。如果删除DaemonSet,其创建的所有pod也被删除,DaemonSet中的pod覆盖整个集群。
Master指的是集群控制节点,在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制,Kubernetes98%的所有控制命令都发给它,它负责具体的执行过程。
node节点为运行容器的实际节点,用于维护运行pod并提供具体应用的运行环境。
采集节点监控周期的资源使用情况包括,Prometheus Server接到请求后便将监控数据以JSON格式返回给监控组件,监控组件对数据进行解码,提取对应的节点监控信息,并存储到相应的数据结构,作为资源动态调度的依据。
接着通过计算公式计算各调度节点得分;
计算公式包括,
L(i)=L(c)+L(m)+L(n)+L(d)
S(i)=n*S(c)S(m)S(n)S(d)
其中,score为调度节点得分,L(i)表示节点负载,S(i)表示节点性能;
L(c)表示CPU利用率,L(m)表示内存利用率,L(n)表示网络利用率,L(d)表示磁盘利用率;
n为CPU核数,S(c)表示CPU频率,S(m)表示内存容量,S(n)表示网络速率,S(d)表示磁盘IO速率;
计算公式表示在原有的负载均衡计算上加入网络利用率指标,把CPU、内存、网络、磁盘IO四个维度数据综合考量计算最终得分。
最后将调度的pod与得分最高的worker节点进行绑定,完成最终的调度。
将调度的pod与得分最高的worker节点进行绑定包括,
向apiserver发送post请求;
apiserver把创建Pod的信息存储到Etcd中,从集群运行那一刻起,资源调度系统Scheduler就会定时去监控apiserver通过apiserver得到创建Pod的信息,Scheduler采用watch机制,一旦Etcd存储Pod信息成功便会立即通知apiserver,apiserver会立即把Pod创建的消息通知Scheduler,Scheduler发现Pod的属性中DestNode为空时,便会立即触发调度流程进行调度。
apiserver能够提供集群管理的REST API接口;提供其他模块之间的数据交互和通信的枢纽,即其他模块通过APIServer查询或修改数据,只有API Server才直接操作etcd。
Etcd为分布式key-value存储,用于服务发现、共享配置以及一致性保障,可跟踪并管理集群节点的状态。
watch机制为当服务器上某一节点的数据或状态发生变化时收到相应的通知。
实施例2
本发明的第二个实施例,基于监控体系的Kubernetes容器资源动态调度方法,为了验证本发明的有益效果,通过仿真实验进行科学论证。
本方案的实验环境由在操作系统的服务器上部署的Kubernetes,一台服务器作为Master节点,另外三台服务器作为node子节点构成的集群。
现有Kubernetes调度器仅仅实现了对Pod的静态调度。即使在第一次调度后使得集群负载均衡,可是随着系统的长时间运行,Pod或节点可能会进行添加或删除,进而导致集群节点资源的使用变化,资源均衡度差,同样也会产生集群负载不均衡的现象,使得部分节点过载,CPU使用率过高,甚至宕机。
而本方案采用通过设计三种触发动态资源调度的方式,在预选过程中只选出满足条件的节点个数,而无需轮询所有节点,能够大幅度加快资源调度时间。此外,本方案通过计算公式计算各调度节点得分,在原有的负载均衡计算上加入网络利用率指标,把CPU、内存、网络、磁盘IO四个维度数据综合考量计算最终得分,将调度的pod与得分最高的worker节点进行绑定,完成最终的调度。基于以上方法,能够提升资源调度效率,降低了CPU使用率,从而更好应对复杂场景资源调度。具体步骤为S1~S4。
S1:设计三种触发动态资源调度的方式;
S2:构建监控体系以监控集群节点的资源利用率;
S3:通过计算公式计算各调度节点得分
S4:将调度的pod与得分最高的worker节点进行绑定,完成最终的调度。
具体数据如下表所示。
CPU使用率 | 资源均衡度 | |
本方案 | 13% | 11.79 |
传统方案 | 18% | 5.42 |
应说明的是,以上实施例仅用以说明本发明的技术方案而非限制,尽管参照较佳实施例对本发明进行了详细说明,本领域的普通技术人员应当理解,可以对本发明的技术方案进行修改或者等同替换,而不脱离本发明技术方案的精神和范围,其均应涵盖在本发明的权利要求范围当中。
Claims (10)
1.基于监控体系的Kubernetes容器资源动态调度方法,其特征在于,包括:
设计三种触发动态资源调度的方式;
构建监控体系以监控集群节点的资源利用率;
通过计算公式计算各调度节点得分;
将调度的pod与得分最高的worker节点进行绑定,完成最终的调度。
2.如权利要求1所述的基于监控体系的Kubernetes容器资源动态调度方法,其特征在于:所述三种触发动态资源调度方式分别为定时触发、定期触发、临界触发;
所述定时触发指的是为集群创建一个定时器,在定时时间来临时触发资源调度过程;
所述定期触发指的是针对长时间运行的服务设置每隔一段时间就进行一次资源调度,这一固定的时间由用户自定义设置,需要根据集群具体情况合理地设置此时长,若过长则可能导致动态调度机制长时间不执行进而导致集群负载不均衡,若设置过短则导致调度器频繁地运行,影响集群性能;
所述临界触发节点负载超阈值触发是指为每个节点设置一个阈值,若节点超过指定阈值的时间大于指定的时间则触发资源调度。
3.如权利要求1或2所述的基于监控体系的Kubernetes容器资源动态调度方法,其特征在于:所述监控体系包括,
以DaemonSet方式在Kubernetes集群的每一个Node上都部署一个节点监控数据采集器Node-Exporter,在Master节点部署PrometheusServer来采集和存储节点的资源使用信息,PrometheusServer负责定时向每个节点的Node-Exporter采集节点监控周期的资源使用情况。
4.如权利要求1或3所述的基于监控体系的Kubernetes容器资源动态调度方法,其特征在于:如权利要求1或3所述DaemonSet,可保证每个节点上只有一个Pod,
当node加入集群时创建pod;
当node离开集群时回收pod;
当删除DaemonSet时,其创建的所有pod也被删除,DaemonSet中的pod覆盖整个集群。
5.如权利要求3或4所述的基于监控体系的Kubernetes容器资源动态调度方法,其特征在于:所述Master指的是集群控制节点,在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制,Kubernetes98%的所有控制命令都发给它,它负责具体的执行过程;
所述node节点为运行容器的实际节点,用于维护运行pod并提供具体应用的运行环境。
6.如权利要求1或3所述基于监控体系的Kubernetes容器资源动态调度方法,其特征在于:所述采集节点监控周期的资源使用情况包括,Prometheus Server接到请求后便将监控数据以JSON格式返回给监控组件,监控组件对数据进行解码,提取对应的节点监控信息,并存储到相应的数据结构,作为资源动态调度的依据。
7.如权利要求1所述的基于监控体系的Kubernetes容器资源动态调度方法,其特征在于:所述计算公式包括,
L(i)=L(c)+L(m)+L(n)+L(d)
S(i)=n*S(c)S(m)S(n)S(d)
其中,score为调度节点得分,L(i)表示节点负载,S(i)表示节点性能;
L(c)表示CPU利用率,L(m)表示内存利用率,L(n)表示网络利用率,L(d)表示磁盘利用率;
n为CPU核数,S(c)表示CPU频率,S(m)表示内存容量,S(n)表示网络速率,S(d)表示磁盘IO速率;
所述计算公式表示在原有的负载均衡计算上加入网络利用率指标,把CPU、内存、网络、磁盘IO四个维度数据综合考量计算最终得分。
8.如权利要求1或7所述的基于监控体系的Kubernetes容器资源动态调度方法,其特征在于:所述将调度的pod与得分最高的worker节点进行绑定包括,
向apiserver发送post请求;
apiserver把创建Pod的信息存储到Etcd中,从集群运行那一刻起,资源调度系统Scheduler就会定时去监控apiserver通过apiserver得到创建Pod的信息,Scheduler采用watch机制,一旦Etcd存储Pod信息成功便会立即通知apiserver,apiserver会立即把Pod创建的消息通知Scheduler,Scheduler发现Pod的属性中DestNode为空时,便会立即触发调度流程进行调度。
9.如权利要求8所述的基于监控体系的Kubernetes容器资源动态调度方法,其特征在于:所述apiserver能够提供集群管理的REST API接口;提供其他模块之间的数据交互和通信的枢纽,即其他模块通过APIServer查询或修改数据,只有API Server才直接操作etcd。
10.如权利要求8或9所述的基于监控体系的Kubernetes容器资源动态调度方法,其特征在于:所述Etcd为分布式key-value存储,用于服务发现、共享配置以及一致性保障,可跟踪并管理集群节点的状态;
所述watch机制为当服务器上某一节点的数据或状态发生变化时收到相应的通知。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211513323.1A CN116069460A (zh) | 2022-11-29 | 2022-11-29 | 基于监控体系的Kubernetes容器资源动态调度方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211513323.1A CN116069460A (zh) | 2022-11-29 | 2022-11-29 | 基于监控体系的Kubernetes容器资源动态调度方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116069460A true CN116069460A (zh) | 2023-05-05 |
Family
ID=86173980
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211513323.1A Pending CN116069460A (zh) | 2022-11-29 | 2022-11-29 | 基于监控体系的Kubernetes容器资源动态调度方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116069460A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117729204A (zh) * | 2024-02-06 | 2024-03-19 | 山东大学 | 一种基于监控感知的k8s容器调度方法及系统 |
-
2022
- 2022-11-29 CN CN202211513323.1A patent/CN116069460A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117729204A (zh) * | 2024-02-06 | 2024-03-19 | 山东大学 | 一种基于监控感知的k8s容器调度方法及系统 |
CN117729204B (zh) * | 2024-02-06 | 2024-05-10 | 山东大学 | 一种基于监控感知的k8s容器调度方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110262899B (zh) | 基于Kubernetes集群的监控组件弹性伸缩方法、装置及受控终端 | |
CN106533723B (zh) | 虚拟资源调度方法、装置及系统 | |
CN103152393B (zh) | 一种云计算的计费方法和计费系统 | |
US9015229B1 (en) | Determining placement of user data to optimize resource utilization for distributed systems | |
EP1654648B1 (en) | Hierarchical management of the dynamic allocation of resources in a multi-node system | |
CN103019853A (zh) | 一种作业任务的调度方法和装置 | |
CN103618644A (zh) | 一种基于hadoop集群的分布式监控系统及其方法 | |
CN103024060A (zh) | 一种开放式云计算大规模集群监控系统及方法 | |
WO2017020742A1 (zh) | 负载均衡方法及设备 | |
US8484212B2 (en) | Providing reconstructed data based on stored aggregate data in response to queries for unavailable data | |
CN113067850B (zh) | 一种多云场景下的集群编排系统 | |
CN106027328A (zh) | 一种基于应用容器部署的集群监控的方法及系统 | |
CN102339233A (zh) | 云计算集中管理平台 | |
CN103207920A (zh) | 一种元数据并行采集系统 | |
CN116069460A (zh) | 基于监控体系的Kubernetes容器资源动态调度方法 | |
CN104021029A (zh) | 一种空间信息云计算系统及其实现方法 | |
CN109657005A (zh) | 一种分布式集群系统的数据缓存方法、装置及设备 | |
Zheng et al. | Task scheduling using edge computing system in smart city | |
CN115080341A (zh) | 计算集群及其数据采集方法、设备及存储介质 | |
CN103414784A (zh) | 支持应急模式的云计算资源调度方法 | |
CN108075989B (zh) | 一种基于可扩展协议的负载均衡网络中间件实现方法 | |
CN115988075A (zh) | 一种基于人工鱼群算法的云数据迁移方法及装置 | |
CN105323320B (zh) | 一种内容分发的方法及装置 | |
CN115981802A (zh) | 一种计算系统及相关性能调节方法 | |
CN108196797A (zh) | 一种基于云计算的数据处理系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |