CN110262899B - 基于Kubernetes集群的监控组件弹性伸缩方法、装置及受控终端 - Google Patents
基于Kubernetes集群的监控组件弹性伸缩方法、装置及受控终端 Download PDFInfo
- Publication number
- CN110262899B CN110262899B CN201910535264.XA CN201910535264A CN110262899B CN 110262899 B CN110262899 B CN 110262899B CN 201910535264 A CN201910535264 A CN 201910535264A CN 110262899 B CN110262899 B CN 110262899B
- Authority
- CN
- China
- Prior art keywords
- monitoring
- monitoring component
- resource configuration
- pod
- recommended resource
- 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.)
- Active
Links
- 238000012544 monitoring process Methods 0.000 title claims abstract description 212
- 238000000034 method Methods 0.000 title claims abstract description 49
- 230000008602 contraction Effects 0.000 claims description 14
- 230000003862 health status Effects 0.000 claims description 4
- 238000012217 deletion Methods 0.000 claims description 3
- 230000037430 deletion Effects 0.000 claims description 3
- 239000000306 component Substances 0.000 description 136
- 102100033121 Transcription factor 21 Human genes 0.000 description 9
- 101710119687 Transcription factor 21 Proteins 0.000 description 9
- 230000006872 improvement Effects 0.000 description 7
- 101100491335 Caenorhabditis elegans mat-2 gene Proteins 0.000 description 5
- 238000007726 management method Methods 0.000 description 5
- 238000004364 calculation method Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 238000013468 resource allocation Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000003247 decreasing effect Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000036541 health Effects 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 230000002411 adverse Effects 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000008358 core component Substances 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000001939 inductive effect Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
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
- 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/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明提供了一种基于Kubernetes集群的监控组件弹性伸缩方法、装置及一种受控终端，属于云计算技术领域。该方法包括：将弹性伸缩容器以边车模式部署至部署监控组件的Pod中；弹性伸缩容器自Metrics监控系统获取当前Kubernetes集群中部署监控组件的Pod所对应的Metrics信息，并根据Metrics信息计算监控组件所对应的推荐资源配置；由弹性伸缩容器配置的伸缩策略对监控组件所关联的推荐资源配置进行修改。本发明可在Kubernetes集群因节点规模及Pod数量发生动态变化是对监控组件所配置的资源进行实时的监控并实现了对监控组件所占用的资源的弹性伸缩配置，提高了对资源调度效率。
Description
技术领域
本发明涉及云计算技术领域，尤其涉及一种基于Kubernetes集群的监控组件弹性伸缩方法、装置及一种受控终端。
背景技术
随着云计算和人工智能的广泛应用，容器技术扮演的角色越来越重要。Docker作为最广泛应用的一种容器技术有效解决了传统虚拟机技术存在的资源利用率低、软件堆栈环境不一致等问题。在云计算环境下，需要大规模部署容器，与之相应的集群管理方案应运而生。Kubernetes作为一种容器集群管理系统的佼佼者，在业界得到广泛应用。
Kubernetes集群提供了Service虚拟服务概念，对应于实际的服务提供者Pod集群，可以使用Replication Controller来实现Service对应一个Pod集群，服务入口对应于Service端口，通过Service负载到Pod集群，同时，利用HPA策略来实现对于Pod集群数量的动态调整，扩容或者缩容。在Kubernetes集群组件与运行中对资源的监控具有重要意义。
在Kubernetes集群中，监控组件是其核心组件之一，其主要功能是针对Kubernetes集群中的各种资源(例如pod、node、deployment等)进行监控，监控项包括CPU、内存、流量、健康状况、磁盘使用率等。监控数据可作为其他组件的基础数据，为其他组件提供决策支持。因此对监控组件的健康状况进行监控就尤为重要。当Kubernetes集群规模或者Pod的数量增长时，监控组件的资源使用量也会同步增长，此时如果无法及时检测到组件的资源需求，并根据资源使用情况进行弹性伸缩，则监控组件可能无法正常工作。
在现有技术中，对Kubernetes集群的监控主要集中在对系统业务型的Pod等资源的监控和弹性伸缩，而对这些资源的弹性伸缩依赖于监控组件提供的监控数据，但是对监控组件的监控及弹性伸缩的效果并不理想，从而导致整个Kubernetes集群的规模或者Pod数量发生变化时，监控组件所占用的资源不合理的问题，并对整个Kubernetes集群的扩容或者缩容造成不利影响。
发明内容
本发明的目的在于揭示一种基于Kubernetes集群的监控组件弹性伸缩方法，用以解决目前Kubernetes集群中监控组件占用资源的实时监控及对监控组件所占用资源的弹性伸缩配置，以适用Kubernetes集群因节点规模及Pod数量发生动态变化对监控组件对资源的实时且合理配置的需求；同时，基于相同发明思想，本发明还揭示了一种基于Kubernetes集群的监控组件弹性伸缩装置及一种受控终端。
为实现上述第一个发明目的，本发明首先揭示了一种基于Kubernetes集群的监控组件弹性伸缩方法，包括以下步骤：
S1、将弹性伸缩容器以边车模式部署至部署监控组件的Pod中；
S2、弹性伸缩容器自Metrics监控系统获取当前Kubernetes集群中部署监控组件的Pod所对应的Metrics信息，并根据Metrics信息计算监控组件所对应的推荐资源配置；
S3、由弹性伸缩容器配置的伸缩策略对监控组件所关联的推荐资源配置进行修改。
作为本发明的进一步改进，所述步骤S2中的Metrics监控系统为Prometheus监控系统、Zabbix监控系统或者时序数据库监控系统；所述Metrics监控系统部署于Kubernetes集群中的API server或者ETCD组件。
作为本发明的进一步改进，步骤S2中根据Metrics信息计算监控组件所对应的推荐资源配置后，还包括：
动态调整推荐资源配置的操作，所述动态调整推荐资源配置的操作基于第一动态调整策略及第二动态调整策略确定；
所述第一动态调整策略由Kubernetes集群在初始状态中Pod数量与初始状态中监控组件所对应的推荐资源配置的对应关系予以确定；
所述第二动态调整策略由Kubernetes集群在当前状态中Pod数量与当前状态中监控组件所对应的推荐资源配置的对应关系予以确定；
作为本发明的进一步改进，所述推荐资源配置由处理器Metrics信息、内存Metrics信息、流量Metrics信息、带宽Metrics信息、磁盘使用率Metrics信息或者健康状况Metrics信息中的一种或者几种配置项共同描述。
作为本发明的进一步改进，所述监控组件包括：Metrics-server container监控组件、kube-state-metrics container监控组件或者heapster container监控组件，并以容器形式部署于Pod中。
作为本发明的进一步改进，所述步骤S2还包括：计算监控组件的历史平均推荐资源配置，并将监控组件的当前推荐资源配置与历史平均推荐资源配置进行比较，
并仅在监控组件的当前推荐资源配置与历史平均推荐资源配置之间的偏差超过阈值T时，对监控组件的当前推荐资源配置进行修改；
所述阈值T为1～10％。
作为本发明的进一步改进，所述步骤S3中对监控组件所关联的推荐资源配置进行修改后，还包括：
弹性伸缩容器发起进行弹性伸缩调度申请，通知Kubernetes集群中的资源管理器在Kubernetes集群中匹配出与修改后的推荐资源配置相适配的Pod。
作为本发明的进一步改进，所述步骤S3中，弹性伸缩容器发起进行弹性伸缩调度申请后还包括：
通过Kubernetes集群中的资源管理器对执行弹性伸缩前所对应的Pod执行删除操作。
基于上述第一个发明的相同发明思想，本发明还揭示了一种基于Kubernetes集群的监控组件弹性伸缩装置，包括：
部署于Pod中的监控组件，以边车模式部署至部件监控组件的Pod中的弹性伸缩容器，以及Metrics监控系统；
其中，
弹性伸缩容器自Metrics监控系统获取当前Kubernetes集群中部署监控组件的Pod所对应的Metrics信息，并根据Metrics信息计算监控组件所对应的推荐资源配置；
由弹性伸缩容器配置的伸缩策略对监控组件所关联的推荐资源配置进行修改。
最后，发明还揭示了一种受控终端，包括：
处理器；
用于存储处理器的执行指令的存储器；
其中，所述处理器被配置为执行第一个发明中任一项所述的基于Kubernetes集群的监控组件弹性伸缩方法。
与现有技术相比，本发明的有益效果是：通过本发明所揭示的一种基于Kubernetes集群的监控组件弹性伸缩方法、装置及一种受控终端，可在Kubernetes集群因节点规模及Pod数量发生动态变化是对监控组件所配置的资源进行实时的监控并实现了对监控组件所占用的资源的弹性伸缩配置，提高了容器运行的效率与稳定性，增强了对基于Kubernetes容器集群管理系统中的资源调度效率。
附图说明
图1为本发明一种基于Kubernetes集群的监控组件弹性伸缩方法的整体流程图；
图2为运行图1所示出的基于Kubernetes集群的监控组件弹性伸缩方法的Kubernetes集群拓扑图；
图3为基于Kubernetes集群的监控组件弹性伸缩的具体流程图；
图4为一种受控终端的拓扑图。
具体实施方式
下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。
具体实施方式所揭示的一种基于Kubernetes集群的监控组件弹性伸缩方法(以下简称“方法”)、一种基于Kubernetes集群的监控组件弹性伸缩装置(以下简称“装置”)及一种受控终端的应用场景为基于Docker基础上的配置形成的Kubernetes集群环境中，并实现对Kubernetes集群的监控组件所配置的资源予以实时监控与监控组件所配置的各种资源的合理调配，提高Kubernetes集群中监控组件的合理配置，以优化Kubernetes集群运行过程中的资源利用的最大化。
Kubernetes集群中所承载或者运行的任何应用所产生的性能监控可包括收集指标并将收集的指标传输给用户装置(例如PC、智能手机)。对于实时性能监控，收集到的指标可被在应用测试的同时传输到用户装置。常规的任何应用的实施性能监控技术可包括将收集到的指标通过网络上的固定带宽传输至用户装置。
同时，本申请所揭示的方法、装置及受控终端可基于Grafana(一种开箱即用的可视化工具)并通过HTTP协议从远程的机器/Kubernetes集群收集位于异地的Kubernetes集群的监控数据并保存至本地的持久化存储介质中，并通过显示装置予以可视化显示，以可视化地展示Kubernetes集群中节点(Node)、Pod的实时数量、配置项的加载情况，以利于运维人员的后台可视化管理。其中，术语“本地”与术语“异地”均是相对而言，并不构成对本发明技术方案理解的技术限制。
实施例一：
参图1所示，其揭示了一种基于Kubernetes集群的监控组件弹性伸缩方法(以下简称“方法”)的一种具体实施方式。
接下来对该方法作概要性阐述，该方法及于装置及受控终端。
基于部署于Kubernetes集群中的API server或者ETCD组件的Metrics监控系统在Kubernetes集群的一个或者多个节点(Node)中创建弹性伸缩容器，多个Pod中所部署的弹性伸缩容器22以边车模式(Sidecar)予以部署，并加载在初始化状态下的推荐资源配置(或初始化资源配置)。通过Master10(主节点)中的Controller manager12(管理控制中心)与Scheduler11(调度器)将监控组件23～25所需要的资源调度至Pod中(位于从节点中)。通过弹性伸缩容器计算，并最优选为定期的计算监控组件的Pod所对应的Metrics信息，并基于设定的弹性伸缩策略对监控组件所依赖的资源予以监听，一旦超过设定的阈值，则触发弹性伸缩操作，以对监控组件所依赖的资源予以弹性伸缩。此种弹性伸缩既可以是增加监控组件23～25所依赖的资源，也可以减少监控组件23～25所依赖的资源，从而对监控组件23～25所依赖的资源予以动态调整，并通过资源管理器(即Kubelet21)进行修改，以最终完成监控组件23～25所依赖的资源的动态调整，并在完成调整之后通知与监控组件23～25在逻辑上位于同一Pod中的弹性伸缩容器22。
需要说明的是，引发对监控组件23～25的因素可以是因为Kubernetes集群中从节点(即Node-1～Node-i)中的Pod数量的增加或者降低，也可以是因为Kubernetes集群中从节点的增加或者降低，或者两者的综合因素，且还可以为用户(Client)对Kubernetes集群的访问压力的增加或者降低等其他因素。
接下来，示出具体的场景与范例，并结合图1至图3对该方法及装置予以更为详细的阐述。
如图1所示，一种基于Kubernetes集群的监控组件弹性伸缩方法，包括以下步骤：
首先，执行步骤S1、将弹性伸缩容器以边车模式部署至部署监控组件的Pod中。
结合图2与图3所示，在本实施例中，Kubernetes集群中形成Master节点与作为Slaver节点的Node-1至Node-i(参数i取大于或者等于2的正整数)。Node-1～Node-i受控于Master中的API server13。API server13连接Controller manager12及Scheduler11。Scheduler11根据特定的调度策略将待调度的Pod绑定到指定的Node上，并将绑定信息写入ETCD组件14。ETCD组件14是一种持久性、轻量型的分布式键-值数据库，用于存储Kubernetes集群的配置数据以及网络配置信息以及各种对象的状态和元信息。
每个Node中运行一个作为资源管理器的Kubelet21，例如图2所示，Node-1中配置Kubelet21，Kubelet21连接三个Pod，即Pod-1～Pod-3。Kubelet21执行Master10下发到各个从节点(即Node-1～Node-i)的任务，并具体管理所在节点上的Pod及Pod内的一个或者多个容器(Container)，并定期的通过Kubelet21向Master10返回本节点的信息。API server13连接Kubectl15，以通过Kubectl15检查Kubernetes集群中资源，创建，删除和更新组件。在本实例中，如无特殊说明，术语“节点”均为从节点(Slave)，受控于Master10(主节点)，以形成主从关系。
如图2所示，Node-1中部署Pod-1～Pod-3，Pod-1中弹性伸缩容器22以边车模式(Sidecar)部署至部署监控组件23的Pod中(即Pod-1)。同理，Pod-2与Pod-3中也配置相同的弹性伸缩容器22以及监控组件24、监控组件25。监控组件包括：Metrics-server container监控组件、kube-state-metrics container监控组件或者heapster container监控组件，并以容器形式部署于Pod中。
例如，监控组件23～监控组件25可依次分别被配置为Metrics-server container监控组件、kube-state-metrics container监控组件及heapster container监控组件，或者以相同种类的监控组件予以配置。其中，kube-state-metrics container监控组件将Prometheus监控系统中可以用PromQL查询到的指标数据转换成Kubernetes集群对应的数。Heapster container监控组件首先从API server13获取Kubernetes集群中所有Node的信息。通过Node-1上的Kubelet21获取有用数据，而Kubelet21本身的数据则是从cAdvisor(Google用来监测单节点的资源信息的监控工具)得到。所有获取到的数据都被推到Heapster container监控组件配置的后端存储(例如ETCD组件14或者分布式存储集群)中，并支持数据的可视化展示。
所谓边车模式是指应用程序的组件部署到单独的进程或容器中，以提供隔离和封装。在本实施例中，由于将弹性伸缩容器22以边车模式部署在Pod中，不仅对原来的应用代码零侵入，而且不限制原来应用的语言，特别适合这种异构微服务的场景，并可以对Kubernetes集群中独立的Node或者独立的Pod进行单独升级。
在步骤S1中，通过Master10向Node-1所形成的Pod-1～Pod-3中的弹性伸缩容器22进行初始化资源配置及弹性伸缩策略的配置。例如，在初始状态下Pod-1中的弹性伸缩容器22中向Master10申请的监控组件23的资源是CPU、memory，其中，CPU的配置是“--cpu＝"1"”，memory的配置是“--memory＝"1"”。其中，上述“--cpu”、“--memory”分别为代码化展现形式，应分别被理解为处理器(CPU)、内存(memory)。“--cpu＝"1"”与“--memory＝"1"”等配置项构成了初始化资源配置。
初始化的弹性伸缩策略包括但不限于如下所示：“--metrics-relist-interval＝10s”(即，获取Metrics信息的频率)；
“--judge-interval＝30s”(即，监控组件23推荐资源使用量计算频率)；
“--judge-metrics-count＝15”(即，监控组件23推荐资源使用量计算使用的Metrics信息的条数)；
“--accept-offset＝5”(即，可接受监控组件资源偏差范围，单位：％)；
在Node-1的Pod-1～Pod-3部署完成之后，所有的监控组件，即监控组件23～25初始化资源配置及弹性伸缩策略即被确定下来，并为后续的因Pod数量的增加或者减少，确定是否要触发弹性伸缩的策略，并仅在监控组件23～25的当前推荐资源配置与历史平均推荐资源配置之间的偏差超过阈值T时，对监控组件23～25的当前推荐资源配置(或者初始化资源配置)进行修改。
接下来，执行步骤S2、弹性伸缩容器自Metrics监控系统获取当前Kubernetes集群中部署监控组件23的Pod所对应的Metrics信息，并根据Metrics信息计算监控组件所对应的推荐资源配置。该步骤S2中的Metrics监控系统为Prometheus监控系统、Zabbix监控系统或者时序数据库监控系统。Metrics监控系统部署于Kubernetes集群中的API server13或者ETCD组件14。在本实施例中，Metrics监控系统部署于Kubernetes集群中的APIserver13，以更好地通过Controllermanager12与Scheduler11对Pod-1中为监控组件23初始化配置的资源(即初始化资源配置)及弹性伸缩策略进行增加或者降低配置(即上文所示的--cpu＝"1"、--memory＝"1"、--metrics-relist-interval＝10s、--judge-interval＝30s、--judge-metrics-count＝15、--accept-offset＝10)，适应监控组件23对资源实时需求与合理调配。其中，cpu的单位是“核”，memory的单位是“GB”，metrics-relist-interval与judge-interval的单位是“秒”，judge-metrics-count的单位是“条”或者“条数”，accept-offset的单位是“％”。
优选的，步骤S2中根据Metrics信息计算监控组件所对应的推荐资源配置后，还包括：动态调整推荐资源配置的操作，所述动态调整推荐资源配置的操作基于第一动态调整策略及第二动态调整策略确定。第一动态调整策略由Kubernetes集群在初始状态中Pod数量与初始状态中监控组件所对应的推荐资源配置的对应关系予以确定；第二动态调整策略由Kubernetes集群在当前状态中Pod数量与当前状态中监控组件所对应的推荐资源配置的对应关系予以确定。推荐资源配置由处理器Metrics信息、内存Metrics信息、流量Metrics信息、带宽Metrics信息、磁盘使用率Metrics信息或者健康状况Metrics信息中的一种或者几种配置项共同描述。
在下文实例中，诸如“CPU：0.89核”、“，内存：1.5GB”等描述方式均是上述处理器Metrics信息、内存Metrics信息、流量Metrics信息、带宽Metrics信息、磁盘使用率Metrics信息或者健康状况Metrics信息的具体、下位表现形式。
需要说明的是，所谓“初始化资源配置”、“当前推荐资源配置”及“历史平均推荐资 源配置”就是相对于时间轴顺序而言的，在Pod-1被创建的时候，“初始化资源配置”与“当前推荐资源配置”可以作等同规格的资源予以理解。以下给出一个具体范例予以解释说明。
第一动态调整策略由Kubernetes集群在初始状态中Pod数量与初始状态中监控组件所对应的推荐资源配置的对应关系的范例如下所示：
Node-1中部署20-30个Pod内时，Node-1中部署的监控组件23推荐使用的CPU及内存的推荐资源配置分别为1核CPU、2GB内存。
第二动态调整策略由Kubernetes集群在当前状态中Pod数量与当前状态中监控组件所对应的推荐资源配置的对应关系的范例如下所示：
Node-1中当前的Pod的数量为20个，当前状态中Node-1中部署的监控组件23所对应的推荐资源配置为：CPU：0.89核，内存：1.5GB。
Node-1中当前的Pod的数量为25个，当前状态中Node-1中部署的监控组件23所对应的推荐资源配置为：CPU：0.92核，内存：1.7GB。
可见，在此状态时，基于第一动态调整策略及第二动态调整策略的介入，并不需要对Node-1中部署的监控组件23所对应的推荐资源配置CPU及内存等配置项进行调整。
优选的，在本实施例中，该步骤S2还包括：计算监控组件23的历史平均推荐资源配置，并将监控组件23的当前推荐资源配置与历史平均推荐资源配置进行比较，
并仅在监控组件23的当前推荐资源配置与历史平均推荐资源配置之间的偏差超过阈值T时，对监控组件23的当前推荐资源配置进行修改；
所述阈值T为1～10％。
此时，需要计算历史平均推荐资源配置，并给出如下范例，其中，阈值T在本实施例中设定为10％。
获取到的当前监控组件23所在Node-1中对应的Metrics信息：Pod：22个、CPU：0.89核、内存：1.65GB；
则监控组件23推荐资源配置的使用量为：Pod：20～30个、CPU：1核、内存：2GB；
获取监控组件23之前十五条相同Pod范围的Metrics信息，计算平均值为CPU：0.95核，内存：1.87GB，则当前推荐资源配置(以CPU与内存为例)与历史平均推荐资源配置之间的偏差的计算公式分别为下式(一)与式(二)所示：
(1核-0.95核)/1核*100％＝5％ 式(1)；
(2GB-1.87GB)/2GB*100％＝6.5％ 式(2)；
可见此时，当前推荐资源配置与历史平均推荐资源配置之间的偏差小于阈值T＝10％，因此在此场景中不对监控组件23进行推荐资源配置的调整。
步骤S3、由弹性伸缩容器配置的伸缩策略对监控组件所关联的推荐资源配置进行修改。
本实施例给出了如下实例予以范例性说明。
根据定义的伸缩策略决定是否要对监控组件23所需的配置项进行弹性伸缩：
1)根据当前节点(例如Node-1)的Pod数量得到推荐资源使用量，即RecommendResource；
2)根据策略进行弹性伸缩。默认策略为：与监控组件当前申请的资源量进行差值比对，判断差值超过某个偏差范围。当前申请资源量，即Apply Resource，当前推荐资源的使用量，即RecommendResource，计算偏差范围公式如下式所示：
比较offset与accept-offset(初始设置的参数，可接受的偏差范围，其根据前述阈值T设定)的值，从而判断是否要对对监控组件23所依赖的资源进行弹性伸缩配置，并具体采用如下方案予以执行：
当offset<accept-offset时，则不进行对监控组件23的配置项进行弹性伸缩；
当offset>＝accept-offset时，则需要对监控组件23的配置项进行弹性伸缩。
优选的，在本实施例中，在步骤S3中对监控组件23～25所关联的推荐资源配置进行修改后，还包括：
弹性伸缩容器22发起进行弹性伸缩调度申请，通知Kubernetes集群中的资源管理器(即Kubelet21)在Kubernetes集群中匹配出与修改后的推荐资源配置相适配的Pod。
弹性伸缩容器22发起进行弹性伸缩调度申请后还包括：
通过Kubernetes集群中的资源管理器(即Kubelet21)对执行弹性伸缩前所对应的Pod执行删除操作。
例如，基于前述实例所示，由于获取监控组件23之前十五条相同Pod范围的Metrics信息，计算平均值为0.95核1.87GB小于阈值T＝10％所设定的资源变动范围，因此于此场景中，依然使用当前推荐资源配置，即，request-cpu:1核，request-memory:2GB。
至此，对Kubernetes集群中的监控组件23～25所依赖的资源及弹性伸缩策略进行增加或者降低配置的操作完毕。
实施例二：
基于实施例一所揭示的一种基于Kubernetes集群的监控组件弹性伸缩方法相同发明思想，本实施例还揭示了一种基于Kubernetes集群的监控组件弹性伸缩装置，包括：
部署于Pod中的监控组件(即图3中的监控组件23～25)，以边车模式部署至部署监控组件23～25所隶属的Pod中的弹性伸缩容器(即图3中的弹性伸缩容器22)，以及Metrics监控系统；
其中，
弹性伸缩容器22自Metrics监控系统获取当前Kubernetes集群中部署监控组件的Pod所对应的Metrics信息，并根据Metrics信息计算监控组件所对应的推荐资源配置；
由弹性伸缩容器22配置的伸缩策略对监控组件23～25所关联的推荐资源配置进行修改。
配合参照图2所示，在本实施例中，该Metrics监控系统可为Prometheus监控系统、Zabbix监控系统或者时序数据库，并部署于Kubernetes集群中的API server13或者ETCD组件14中。Pod-1～Pod-3中的弹性伸缩容器22根据伸缩策略对监控组件23～25所需要的配置项进行监控与弹性伸缩。基于Kubernetes集群的监控组件弹性伸缩装置运行实施例一所揭示的基于Kubernetes集群的监控组件弹性伸缩方法，其具体实现过程请参实施例一所述，在此不再赘述。
实施例三：
参图4所示，本实施例揭示了一种受控终端100，包括：
处理器31；
用于存储处理器31的执行指令的存储器32；
其中，所述处理器31被配置为执行实施例一所述的基于Kubernetes集群的监控组件弹性伸缩方法。
处理器31、存储器32耦接与系统总线34，且通过接入系统总线34的通信单元33与外部指令发送的主体(例如PC、数据中心、集群服务器)相通信，以由上述主体对该受控终端100中的基于Kubernetes集群的监控组件执行资源和/或伸缩策略的弹性配置。
本实施例所揭示的基于Kubernetes集群的监控组件弹性伸缩方法的具体实现过程参实施例一所示，在此不再赘述。
在本申请所披露的几个实施例中，本领域技术人员应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。
对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。
此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。
Claims (9)
1.一种基于Kubernetes集群的监控组件弹性伸缩方法，其特征在于，包括以下步骤：
S1、将弹性伸缩容器以边车模式部署至部署监控组件的Pod中；
S2、弹性伸缩容器自Metrics监控系统获取当前Kubernetes集群中部署监控组件的Pod所对应的Metrics信息，并根据Metrics信息计算监控组件所对应的推荐资源配置；
S3、由弹性伸缩容器配置的伸缩策略对监控组件所关联的推荐资源配置进行修改；
步骤S2中根据Metrics信息计算监控组件所对应的推荐资源配置后，还包括：
动态调整推荐资源配置的操作，所述动态调整推荐资源配置的操作基于第一动态调整策略及第二动态调整策略确定；
所述第一动态调整策略由Kubernetes集群在初始状态中Pod数量与初始状态中监控组件所对应的推荐资源配置的对应关系予以确定；
所述第二动态调整策略由Kubernetes集群在当前状态中Pod数量与当前状态中监控组件所对应的推荐资源配置的对应关系予以确定。
2.根据权利要求1所述的方法，其特征在于，所述步骤S2中的Metrics监控系统为Prometheus监控系统、Zabbix监控系统或者时序数据库监控系统；所述Metrics监控系统部署于Kubernetes集群中的API server或者ETCD组件。
3.根据权利要求1所述的方法，其特征在于，所述推荐资源配置由处理器Metrics信息、内存Metrics信息、流量Metrics信息、带宽Metrics信息、磁盘使用率Metrics信息或者健康状况Metrics信息中的一种或者几种配置项共同描述。
4.根据权利要求1所述的方法，其特征在于，所述监控组件包括：Metrics-servercontainer监控组件、kube-state-metrics container监控组件或者heapster container监控组件，并以容器形式部署于Pod中。
5.根据权利要求1所述的方法，其特征在于，所述步骤S2还包括：计算监控组件的历史平均推荐资源配置，并将监控组件的当前推荐资源配置与历史平均推荐资源配置进行比较，
并仅在监控组件的当前推荐资源配置与历史平均推荐资源配置之间的偏差超过阈值T时，对监控组件的当前推荐资源配置进行修改；
所述阈值T为1～10％。
6.根据权利要求5所述的方法，其特征在于，所述步骤S3中对监控组件所关联的推荐资源配置进行修改后，还包括：
弹性伸缩容器发起进行弹性伸缩调度申请，通知Kubernetes集群中的资源管理器在Kubernetes集群中匹配出与修改后的推荐资源配置相适配的Pod。
7.根据权利要求6所述的方法，其特征在于，所述步骤S3中，弹性伸缩容器发起进行弹性伸缩调度申请后还包括：
通过Kubernetes集群中的资源管理器对执行弹性伸缩前所对应的Pod执行删除操作。
8.一种基于Kubernetes集群的监控组件弹性伸缩装置，其特征在于，包括：
部署于Pod中的监控组件，以边车模式部署至部署监控组件的Pod中的弹性伸缩容器，以及Metrics监控系统；
其中，
弹性伸缩容器自Metrics监控系统获取当前Kubernetes集群中部署监控组件的Pod所对应的Metrics信息，并根据Metrics信息计算监控组件所对应的推荐资源配置；
根据Metrics信息计算监控组件所对应的推荐资源配置后，还包括：
动态调整推荐资源配置的操作，所述动态调整推荐资源配置的操作基于第一动态调整策略及第二动态调整策略确定；
所述第一动态调整策略由Kubernetes集群在初始状态中Pod数量与初始状态中监控组件所对应的推荐资源配置的对应关系予以确定；
所述第二动态调整策略由Kubernetes集群在当前状态中Pod数量与当前状态中监控组件所对应的推荐资源配置的对应关系予以确定；
由弹性伸缩容器配置的伸缩策略对监控组件所关联的推荐资源配置进行修改。
9.一种受控终端，其特征在于，包括：
处理器；
用于存储处理器的执行指令的存储器；
其中，所述处理器被配置为执行权利要求1至7中任一项所述的基于Kubernetes集群的监控组件弹性伸缩方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910535264.XA CN110262899B (zh) | 2019-06-20 | 2019-06-20 | 基于Kubernetes集群的监控组件弹性伸缩方法、装置及受控终端 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910535264.XA CN110262899B (zh) | 2019-06-20 | 2019-06-20 | 基于Kubernetes集群的监控组件弹性伸缩方法、装置及受控终端 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110262899A CN110262899A (zh) | 2019-09-20 |
| CN110262899B true CN110262899B (zh) | 2021-05-11 |
Family
ID=67919678
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910535264.XA Active CN110262899B (zh) | 2019-06-20 | 2019-06-20 | 基于Kubernetes集群的监控组件弹性伸缩方法、装置及受控终端 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110262899B (zh) |
Families Citing this family (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111026409A (zh) * | 2019-10-28 | 2020-04-17 | 烽火通信科技股份有限公司 | 一种自动监控方法、装置、终端设备及计算机存储介质 |
| CN111245918A (zh) * | 2020-01-07 | 2020-06-05 | 微民保险代理有限公司 | 一种服务请求的传输方法和装置 |
| CN111324417B (zh) * | 2020-01-19 | 2024-03-08 | 北京百度网讯科技有限公司 | 一种Kubernetes集群的组件控制方法、装置、电子设备和介质 |
| CN111625418A (zh) * | 2020-05-12 | 2020-09-04 | 深圳前海微众银行股份有限公司 | 一种进程监控方法及装置 |
| CN113760797A (zh) * | 2020-06-05 | 2021-12-07 | 华为技术有限公司 | 一种数据传输方法、计算设备以及系统 |
| CN111782341B (zh) * | 2020-06-30 | 2024-04-05 | 北京百度网讯科技有限公司 | 用于管理集群的方法和装置 |
| CN111708611B (zh) * | 2020-07-02 | 2022-12-23 | 浪潮云信息技术股份公司 | 轻量级Kubernetes监控系统及方法 |
| CN111865971A (zh) * | 2020-07-17 | 2020-10-30 | 成都三零凯天通信实业有限公司 | 一种基于sidecar方案的kubernetes业务容器安全性探测方法 |
| CN111858257B (zh) * | 2020-07-28 | 2024-10-15 | 浪潮云信息技术股份公司 | 一种实现获取容器集群资源使用数据的系统及方法 |
| CN111901203B (zh) * | 2020-08-03 | 2022-03-29 | 北京启明星辰信息安全技术有限公司 | 一种捕获网络流量的方法及Kubernetes集群 |
| CN111897641B (zh) * | 2020-08-03 | 2023-07-28 | 海信电子科技(武汉)有限公司 | 微服务监控调度方法及显示设备 |
| CN114168252A (zh) * | 2020-08-20 | 2022-03-11 | 中国电信股份有限公司 | 信息处理系统及方法、网络方案推荐组件及方法 |
| CN112162817B (zh) * | 2020-09-09 | 2023-09-26 | 新浪技术（中国）有限公司 | 容器集群的部署服务资源的处理方法及装置、存储介质 |
| CN112181764B (zh) * | 2020-09-23 | 2022-07-22 | 南京南瑞继保电气有限公司 | Kubernetes资源数据的监视方法及装置 |
| CN112346926B (zh) * | 2020-10-16 | 2024-10-08 | 北京金山云网络技术有限公司 | 资源状态监控方法、装置及电子设备 |
| CN112181603A (zh) * | 2020-10-26 | 2021-01-05 | 浪潮云信息技术股份公司 | 一种云环境下的可控制垂直自动伸缩器实现方法及系统 |
| CN112559186B (zh) * | 2020-12-22 | 2021-09-24 | 北京云思畅想科技有限公司 | 一种Kubernetes容器资源扩缩容方法 |
| CN112506444A (zh) * | 2020-12-28 | 2021-03-16 | 南方电网深圳数字电网研究院有限公司 | 基于Kubernetes集群的扩缩容控制方法和装置、电子设备 |
| CN112291104B (zh) * | 2020-12-30 | 2021-04-06 | 望海康信(北京)科技股份公司 | 微服务自动伸缩系统、方法及相应设备和存储介质 |
| CN112929180B (zh) * | 2021-02-05 | 2022-07-08 | 中国—东盟信息港股份有限公司 | 一种Kubernetes零信任网络安全系统及其实现方法 |
| CN113051075B (zh) * | 2021-03-23 | 2022-09-09 | 烽火通信科技股份有限公司 | 一种Kubernetes智能化扩缩容的方法及装置 |
| CN112799854B (zh) * | 2021-04-15 | 2021-07-13 | 腾讯科技（深圳）有限公司 | 任务处理方法、装置、电子设备及可读存储介质 |
| CN113220420B (zh) * | 2021-05-18 | 2024-07-16 | 北京百度网讯科技有限公司 | 服务监控方法、装置、设备、存储介质及计算机程序产品 |
| CN113254213B (zh) * | 2021-06-08 | 2021-10-15 | 苏州浪潮智能科技有限公司 | 一种服务的计算资源配置方法、系统及装置 |
| CN113395178B (zh) * | 2021-06-11 | 2022-12-09 | 聚好看科技股份有限公司 | 一种容器云弹性伸缩的方法及装置 |
| CN115705198A (zh) * | 2021-08-09 | 2023-02-17 | 华为云计算技术有限公司 | 运行容器组的节点，容器组的管理系统和方法 |
| CN113949615A (zh) * | 2021-09-29 | 2022-01-18 | 广西交通设计集团有限公司 | 基于zabbix和grafana实现故障可动态感知网络拓扑方法 |
| CN114035861A (zh) * | 2021-11-05 | 2022-02-11 | 北京金山云网络技术有限公司 | 集群配置方法、装置、电子设备和计算机可读介质 |
| CN114221773B (zh) * | 2021-12-17 | 2024-02-06 | 北京邮电大学 | 一种基于容器云自动添加代理的方法 |
| CN115277586B (zh) * | 2022-07-29 | 2024-07-23 | 中国电信股份有限公司 | Pod流量处理方法、系统、设备及存储介质 |
| CN115809119A (zh) * | 2022-12-26 | 2023-03-17 | 京东科技信息技术有限公司 | 容器编排引擎的监控方法、系统及装置 |
| CN116048814B (zh) * | 2023-02-21 | 2023-10-03 | 上海汇付支付有限公司 | 一种基于监控效用数据的应用资源规格自动优化方法 |
| CN118193757B (zh) * | 2024-05-17 | 2024-07-30 | 之江实验室 | 一种任务执行方法、装置、存储介质及电子设备 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108762912A (zh) * | 2018-07-04 | 2018-11-06 | 郑州云海信息技术有限公司 | 一种容器集群弹性伸缩的方法和装置 |
| CN109446032A (zh) * | 2018-12-19 | 2019-03-08 | 福建新大陆软件工程有限公司 | Kubernetes副本扩缩容的方法及系统 |
| US20190095253A1 (en) * | 2017-09-22 | 2019-03-28 | Vmware, Inc. | Cluster updating using temporary update-monitor pod |
| CN109710376A (zh) * | 2018-12-12 | 2019-05-03 | 中国联合网络通信集团有限公司 | 容器集群管理系统的动态调度方法和装置 |
-
2019
- 2019-06-20 CN CN201910535264.XA patent/CN110262899B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190095253A1 (en) * | 2017-09-22 | 2019-03-28 | Vmware, Inc. | Cluster updating using temporary update-monitor pod |
| CN108762912A (zh) * | 2018-07-04 | 2018-11-06 | 郑州云海信息技术有限公司 | 一种容器集群弹性伸缩的方法和装置 |
| CN109710376A (zh) * | 2018-12-12 | 2019-05-03 | 中国联合网络通信集团有限公司 | 容器集群管理系统的动态调度方法和装置 |
| CN109446032A (zh) * | 2018-12-19 | 2019-03-08 | 福建新大陆软件工程有限公司 | Kubernetes副本扩缩容的方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110262899A (zh) | 2019-09-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110262899B (zh) | 基于Kubernetes集群的监控组件弹性伸缩方法、装置及受控终端 | |
| CN112506444A (zh) | 基于Kubernetes集群的扩缩容控制方法和装置、电子设备 | |
| US11455189B2 (en) | Task scheduling simulation system | |
| CN104335137B (zh) | 管理计算系统的功耗和性能 | |
| CN108683720B (zh) | 一种容器集群服务配置方法及装置 | |
| CN111796908B (zh) | 一种资源自动弹性伸缩的系统、方法及云平台 | |
| CN105025095B (zh) | 实现云计算弹性服务的集群架构 | |
| CN103384206B (zh) | 一种面向海量数据的并行处理方法及系统 | |
| CN106133693B (zh) | 虚拟机的迁移方法、装置及设备 | |
| CN106033476B (zh) | 一种云计算环境中分布式计算模式下的增量式图计算方法 | |
| CN103957237A (zh) | 一种弹性云的体系结构 | |
| CN103561055A (zh) | 基于会话的云计算环境下Web应用自动弹性扩展方法 | |
| CN104219298B (zh) | 集群系统及其数据备份的方法 | |
| CN103761146A (zh) | 一种MapReduce动态设定slots数量的方法 | |
| CN101778002A (zh) | 一种大规模集群系统及其构建方法 | |
| CN102929769A (zh) | 一种基于代理服务的虚拟机内部数据采集方法 | |
| CN116991558B (zh) | 算力资源的调度方法及多架构集群、装置、存储介质 | |
| CN107070709A (zh) | 一种基于底层numa感知的nfv实现方法 | |
| CN109960579B (zh) | 一种调整业务容器的方法及装置 | |
| US11870669B2 (en) | At-scale telemetry using interactive matrix for deterministic microservices performance | |
| CN110096339B (zh) | 一种基于系统负载实现的扩缩容配置推荐系统及方法 | |
| CN110532060A (zh) | 一种混合网络环境数据采集方法及系统 | |
| CN107948330A (zh) | 一种云环境下基于动态优先级的负载均衡策略 | |
| JP2014127210A (ja) | 仮想マシンの作動スケジューリングシステム及びその方法 | |
| CN117369941A (zh) | Pod调度方法和系统 |
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 | ||
| CB02 | Change of applicant information | ||
| CB02 | Change of applicant information |
Address after: No. 6 Science and Education Software Park, Binhu District, Wuxi City, Jiangsu Province Applicant after: Huayun data holding group Co., Ltd Address before: No. 6 Science and Education Software Park, Binhu District, Wuxi City, Jiangsu Province Applicant before: WUXI CHINAC DATA TECHNICAL SERVICE Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |