CN110597701A - 一种容器云平台的健康稳定运行程度的评分系统及方法 - Google Patents
一种容器云平台的健康稳定运行程度的评分系统及方法 Download PDFInfo
- Publication number
- CN110597701A CN110597701A CN201910864036.7A CN201910864036A CN110597701A CN 110597701 A CN110597701 A CN 110597701A CN 201910864036 A CN201910864036 A CN 201910864036A CN 110597701 A CN110597701 A CN 110597701A
- Authority
- CN
- China
- Prior art keywords
- cluster
- node
- load
- degree
- calculating
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Environmental & Geological Engineering (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种容器云平台的健康稳定运行程度的评分方法及系统，采用容器云平台集群的节点负载均衡程度评分和节点的健康度汇总评分；容器云平台集群的节点负载均衡程度评分包括：统计每个节点的使用资源量；计算每个节点的负载占比；横坐标为累计节点数占比，纵坐标为负载累计占比，绘出洛伦茨曲线，计算集群基尼系数；计算集群负载均衡分值。节点的健康度汇总评分包括：计算集群中负载度；对可能出现的错误划分等级，并相应扣分；对每节点的每条错误扣分；计算集群节点健康汇总分值。本发明首次将基尼系数理论应用到计算机云平台的负载均衡度计算，提供一个直接直观的呈现方式，体现集群的稳定程度，能够有效提高集群运维效率。
Description
技术领域
本发明属于计算机云平台技术领域，涉及一种容器云平台（适用于公有云/私有云和混合云）的稳定和健康运行程度的监控统计方式，尤其涉及一种容器云平台的健康稳定运行程度的评分系统及方法。
背景技术
容器云平台集群的健康稳定性，首先很大一部分取决于集群中各个节点的负载均衡状况，其次也受到节点的软硬件稳定程度和趋势的影响。容器云平台是指运行容器的公有云/私有云/混合云。一般或称为PaaS/CaaS平台。节点是指云平台中的单个计算机主机实体。集群是指所有节点的集合。负载指的是计算机主机上的工作压力。
一、现有技术1
在基于Kubernetes（业界最流行的容器云调度系统的实现方案）的容器云平台解决方案中，虽然Kubernetes拥有原生的调度器拥有一系列调度方法，例如：
l LeastRequestedPriority：支持具有较少请求资源的节点。换句话说，放置在节点上的Pod越多，并且Pod使用的资源越多，该策略将给出的排名越低。
l BalancedResourceAllocation：支持资源使用均衡的节点。
l ServiceSpreadingPriority：对于给定的服务，此策略旨在确保服务的Pod在不同的节点上运行。
参考资料：https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/#
但是上述方案在集群创建之初，节点之间是对等条件下，基本上能够达到节点负载的均衡和容器的平衡分布。
但是在实际生产环境中，在容器逐步被调度之后，随着时间的推移、外部因素的变化，节点之间渐渐变得并非理想对等的，有如下情况：
1.节点通过亲和性等方式，仅允许特定应用调度其上（其有多种原因：比如节点有特殊硬件，或者不同应用需要实现节点粒度的资源隔离）。
2.节点的污点和标签也会在容器调度之后被修改，使得之前的调度方法失效。
3.新节点加入，或者老节点出错导致容器被驱逐/迁移。
所以在生产环境中，随着时间的推移、外部因素的变化，原生的Kubernetes调度方法在实际情况下是有缺陷的，无法保证集群负载一如既往的均衡。
而容器相关的开源社区中，也针对这个问题提出了de-scheduler的概念，当其发现容器平台中资源调度的不均衡，会根据一些策略，选择某些容器，进行删除和重新调度。参考资料： https://github.com/kubernetes-incubator/descheduler。
但是de-scheduler方法的最大缺点是“完全自动化”地、“简单”地自行删除容器。而这会导致正在运行中的业务收到影响，比如正在进行的秒杀业务，负载增高，如果被上述方案自行删除和重新调度，业务就会造成短暂性能降级甚至中断，导致秒杀业务受影响。社区为解决该问题的de-scheduler方案，采用直接停止和迁移应用的方式，过于简单粗暴。所以de-scheduler的方案无法在生产环境中大规模推广。
二、现有技术2
而对于节点的软硬件状态，Kubernetes的处理就非常单一，只有MemoryPressure（可用内存较少）或DiskPressure（可用硬盘空间较少）等情况下，将节点置为“NotReady”(不可用)。Kubernetes对节点状态，每一个指标只有“正常”和“非正常”，使得节点也只有Ready（可用）和NotReady(不可用)两种状态，没有中间状态，而在问题发生之前，没有任何的预警措施。当节点已经成为不可用状态，这时再处理已经为时晚矣。
此外，如果集群中可用节点较多，而整体负载（使用率）不高，那么即使一台节点出错而下线，本质上对整体集群所带来的风险不算高，因为应用可以迁移到其他节点并且不会带来额外负载压力。所以，这种情况下，整体集群健康状态也需要兼而考虑单节点状态和整体负载。
参考资料：https://kubernetes.io/docs/concepts/architecture/nodes/。
容器平台集群中的健康稳定性，需要一个直观的方式能够呈现出来，以便于运维工作能高效开展和调整。上述提及，集群稳定还不单取决于集群的负载均衡程度，还包括节点自身的软硬件稳定程度和趋势。
（1）对于负载均衡程度，上述已论证在生产环境中，节点负载不均衡是一个常见的情况，并可能会集群运行造成隐患。而这种不均衡，如果没有一种直观的呈现方式，通过人为方式去发现问题几乎是不可能的。并且目前尚未有可靠的全自动化运维方式，所以就需要有实时、直观的集群均衡程度指标呈现方式，辅助于后续运维处理动作，才能保证集群的稳定，防范于未然。
（2）对于节点健康状态，同理：单一的“可用”和“不可用”两种状态显然不满足运维需求。提供一种及时传达的、容易理解的评分监控机制，会极大提高集群状态的可见性，降低风险系数。
容器平台集群中的健康稳定性，需要一个直观的方式能够呈现出来，以便于运维工作能高效开展和调整。上述提及，集群稳定取决于集群的负载均衡程度，以及节点自身的软硬件稳定程度和趋势。
（1）对于现有技术1，在生产环境中，随着时间的推移、外部因素的变化，原生的Kubernetes调度方法无法保证集群的负载均衡。社区为解决该问题的de-scheduler方案，一旦发现不均衡，采用直接停止和迁移应用的方式，又过于简单粗暴。对于负载均衡程度，上述已论证在生产环境中，节点负载不均衡是一个常见的情况，并可能会集群运行造成隐患。 而这种不均衡，如果没有一种直观的呈现方式，通过人为方式去发现问题几乎是不可能的。并且目前尚未有可靠的全自动化运维方式，所以就需要有实时、直观的集群均衡程度指标呈现方式，辅助于后续运维处理动作，才能保证集群的稳定，防范于未然。
（2）对于现有技术2，对于节点健康状态，原方法只有单一的“可用”和“不可用”两种状态，没有中间状态，在问题发生之前，无法作出预警措施，显然不满足精细化运维的需求。如果能提供一种及时传达的、容易理解的评分监控机制，会极大提高集群状态的可见性，降低风险系数。更重要的是，现有技术中，没有已有方案解决“出问题节点数和规模”之间的关系。
因此，本领域亟需研发一种能克服上述缺陷，以科学的方法统计出实时、直观的评分，使运维更为高效的容器云平台的健康稳定运行程度的评分系统及方法，该方法能从均衡性评估和健康状态评估上两个方面，更好地解决现有技术的问题。
发明内容
本发明主要解决的技术问题是提供一种容器云平台的健康稳定运行程度的评分方法，解决节点负载不均衡的问题，提高集群状态的可见性，降低风险系数，以科学的方法统计出实时、直观的评分，使运维更为高效。为此，本发明还提供一种容器云平台的健康稳定运行程度的评分系统。
为解决上述技术问题，本发明提出一种容器云平台的健康稳定运行程度的评分方法，该方法采用容器云平台集群的节点负载均衡程度评分和节点的健康度汇总评分；
所述容器云平台集群的节点负载均衡程度评分，包括如下步骤：
第一步，统计每个节点的使用资源量，即负载；
第二步，计算每个节点的负载占比；
第三步，横坐标为累计节点数占比，纵坐标为负载累计占比，绘出洛伦茨曲线，计算集群基尼系数；
第四步，计算集群负载均衡分值，集群负载均衡分值 =100 – 集群基尼系数*100；
所述节点的健康度汇总评分，包括如下步骤：
步骤1，计算集群中负载度；
步骤2，对可能出现的错误划分等级，并相应扣分；
步骤3，对每节点的每条错误扣分，Red为扣除数；
步骤4，计算集群节点健康汇总分值，集群节点健康汇总分值 = 100 – Red。
作为本发明优选的技术方案，第一步具体为：
（1）对于集群中每台主机节点，分别计算节点上的所有 pod 的request 的资源之和；其中，podrequest表明该容器对资源的申请需求， Nodei表示在第i台节点上的容器已占用资源总和；
（2）列出集群中所有主机上的所有Pod的 request 的资源之和：。
作为本发明优选的技术方案，第二步具体为：
（1）将Nodei按照其数值，进行逆序排序：；
（2）分别计算每一台主机的request 的资源之和Arrayi与集群request总和Total的比例。
作为本发明优选的技术方案，第三步具体为：
（1）根据i和ratioi,得到一个离散点集合，其x坐标和y坐标，如下公式：
（2）根据离散点，依次描点，拟合洛伦茨曲线，计算集群基尼系数，其中，SA为曲线中上面部分A的面积，SB为曲线中下面部分B的面积；通过离散点构成的弧线与斜率为1的直线构成阴影面积，与总面积之比，即为基尼系数，通过积分梯形的面积近似的计算面积之比，得到平台之资源分布均匀度即基尼系数；弧度越大，阴影面积越大，负载越不均衡，比例趋于 1；弧度越小，阴影面积越小，负载越均衡，比例趋于 0。
作为本发明优选的技术方案，第三步中所述集群基尼系数设为0.3-0.4是节点负载均衡、分布相对合理的区间。
作为本发明优选的技术方案，步骤1中，按以下公式计算集群中负载度：，其中, podrequest是整个集群所有节点的容器所申请的资源，Allocable是每个节点的可供分配的资源，Load就是负载度，其与集群冗余度成反比。
作为本发明优选的技术方案，步骤2中，所述对可能出现的错误划分等级，并相应扣分具体为：对可能出现的错误，划分以下4个等级：
严重等级，对应扣除分数100；
高等级，对应扣除分数50；
中等级，对应扣除分数5；
低等级，对应扣除分数2。
作为本发明优选的技术方案，步骤3中，对每节点的每条错误按如下公式扣分：
其中，Red为扣除数,Erri为主机i上所有扣除的分数总和，Erri为对所有主机上的Erri求和，NodeCount为可用节点数，Load为集群中负载程度。
作为本发明优选的技术方案，步骤4中，如果所述集群节点健康汇总分值低于0，则归为0；将所述集群节点健康汇总分值划分成不同区间，80以上是健康，60-80是良好，30-60是警告，0-30是严重。
此外，本发明还提供一种容器云平台的健康稳定运行程度的评分系统，该系统包括节点负载均衡程度评分模块和节点的健康度汇总评分模块；
所述节点负载均衡程度评分模块包括节点负载统计模块、节点负载占比计算模块、集群基尼系数计算模块、集群负载均衡分值计算模块；所述节点负载统计模块用于统计每个节点的负载；所述节点负载占比计算模块接受来自所述节点负载统计模块的统计数据，计算每个节点的负载占比；所述集群基尼系数计算模块用于以横坐标为累计节点数占比，纵坐标为负载累计占比，绘出洛伦茨曲线，根据曲线计算集群基尼系数；所述集群负载均衡分值计算模块用于接受来自所述集群基尼系数计算模块的集群基尼系数，据此计算集群负载均衡分值；
所述节点的健康度汇总评分模块包括集群负载度计算模块、错误等级划分模块、节点错误扣分模块、集群节点健康汇总分值计算模块；所述集群负载度计算模块用于计算集群中负载度；所述错误等级划分模块用于对可能出现的错误划分等级，并相应扣分；所述节点错误扣分模块用于接收所述集群负载度计算模块和所述错误等级划分模块的相关数据对每节点的每条错误进行扣分；所述集群节点健康汇总分值计算模块接受来自所述节点错误扣分模块的扣除数，据此计算集群节点健康汇总分值。
作为本发明优选的技术方案，所述节点负载统计模块按如下方法进行统计：
（1）对于集群中每台主机节点，分别计算节点上的所有 pod 的request 的资源之和；其中，podrequest表明该容器对资源的申请需求， Nodei表示在第i台节点上的容器已占用资源总和；
（2）列出集群中所有主机上的所有Pod的 request 的资源之和 ：；
所述节点负载占比计算模块按如下方法进行计算：
（1）将Nodei按照其数值，进行逆序排序：；
（2）分别计算每一台主机的request 的资源之和Arrayi与集群request总和Total的比例；
所述集群基尼系数计算模块按如下方法进行计算：
（1）根据i和ratioi,得到一个离散点集合，其x坐标和y坐标，如下公式：
x坐标为累计节点数占比，y坐标为负载累计占比；
（2）根据离散点，依次描点，拟合洛伦茨曲线，计算集群基尼系数；其中，SA为曲线中上面部分A的面积，SB为曲线中下面部分B的面积；通过离散点构成的弧线与斜率为1的直线构成阴影面积，与总面积之比，即为基尼系数，通过积分梯形的面积近似的计算面积之比，得到平台之资源分布均匀度即基尼系数；弧度越大，阴影面积越大，负载越不均衡，比例趋于 1；弧度越小，阴影面积越小，负载越均衡，比例趋于 0。
作为本发明优选的技术方案，所述集群负载度计算模块，按以下公式计算集群中负载度：，其中, podrequest是整个集群所有节点的容器所申请的资源，Allocable是每个节点的可供分配的资源，Load就是负载度，其与集群冗余度成反比；
所述错误等级划分模块按如下方法进行划分：
对可能出现的错误，划分以下4个等级：
严重等级，对应扣除分数100；
高等级，对应扣除分数50；
中等级，对应扣除分数5；
低等级，对应扣除分数2；
所述节点错误扣分模块对每节点的每条错误按如下公式扣分：
其中，Red为扣除数,Erri为主机i上所有扣除的分数总和，Erri为对所有主机上的Erri求和，NodeCount为可用节点数，Load为集群中负载程度。
本发明中的技术术语说明如下：
容器云平台：指运行容器的公有云/私有云/混合云。一般或称为PaaS/CaaS平台。
容器：虚拟化技术的一种，容器是该虚拟化的最小运行单位。
Kubernetes：业界最主流的容器云调度系统平台的实现方案。
Pod：在Kubernetes平台中，最小的运行单位，可以简单理解为约等于容器。
节点：指云平台中的单个计算机主机实体。
集群：所有节点的集合。
负载：指的是计算机主机上的工作压力（运行的容器所使用的CPU和内存等）。
运维：运行维护，通常是指对计算机平台进行监控、维护的工作。
与现有技术相比，本发明的有益效果在于：
1、本发明通过一个新颖的方法，对容器云平台的集群中的整体稳定和健康程度进行汇集和计算，并以一种实时的、直观的“健康程度”打分指标的方式呈现， 对高效率、智能化的平台运维有着重要的意义。
2、本发明实现了统一的集群健康稳定程度分值：汇集如集群均衡度、节点健康度等等相关信息，通过方法得出一到两个的分值，简单直接地进行统一的呈现；集群均衡性：实时直观的均衡程度打分 + 运维干预 >简单暴力地停止应用；节点健康度：0-100的直观的健康打分，结合集群负载度 = 直观的节点状态一览；
3、本发明首次将基尼系数理论应用到计算机云平台的负载均衡度计算；
4、本发明通过单一的分数值，并结合集群冗余度（集群的负载度），汇总整体的健康程度（传统方式是通过一串离散的状态列表，每项指标单独呈现）；
5、本发明方案对集群的稳定健康系数（或者从另一角度来看，风险系数）提供一个直接直观的呈现方式，用0-100分的打分，体现集群的稳定程度，能够有效提高集群运维效率。
在本发明中，认为整个容器云平台集群的健康稳定性，主要取决于如下两个因素的影响：（一）集群中各个节点的负载均衡状况，（二） 节点的软硬件稳定程度和趋势。
（一）对集群均衡度的监控和管理：
现有技术实现中的问题在于：
（1）在生产环境中，随着时间的推移、外部因素的变化，原生的Kubernetes调度方法无法保证集群的负载均衡；
（2）现有方法为解决该问题的de-scheduler方案，采用直接停止和迁移应用的方式，过于简单粗暴。
本发明的改进：
采纳在经济学界广泛认同的“基尼系数”方法，巧妙地应用到计算机领域中，在容器云平台中，将相关参数运算后，得到实时直观的均衡程度打分 ，以一个0-100的分值，非常易于理解，并利于运维人员采取进一步运维行动。
（二）对集群健康度的监控和展现：
现有技术实现中的问题在于：
（1）Kubernetes的处理就非常单一，对节点状态，每一个指标只有“正常”和“非正常”，使得节点也只有Ready（可用）和NotReady(不可用)两种状态。
（2）在“正常”和“非正常”之间，没有中间状态，在潜在问题发生之前（仍然显示“正常”，但是其实可能很快会出问题），无法作出预警措施。
（3）集群规模较大（如200台），负载不高时，即使有N台节点出问题，当N数值为5以内，影响一般不大，但是当集群负载高，N为1（也就是一台机器出问题），都可能造成较大负面影响。但是这个N数值在现有实践中，都是一个经验值，没有一套方法能够较为合理计算。
本发明的改进：
通过错误分级和实时监控，并结合集群规模和负载度所得出的冗余度，得出一个0-100的直观的统一健康打分，非常方便。运维人员不再是面对数百个节点的总计数千个指标逐个分析，而是得到一个一目了然的结果，非常易于理解，并方便相应采取进一步更精细化的运维动作。
附图说明
下面结合附图和实施例对本发明做进一步的详细说明。
图1为本发明方法的流程图。
图2为本发明的容器云平台集群的节点负载均衡程度打分方法的具体流程图。
图3为本发明中根据离散点的拟合曲线（洛伦茨曲线）示意图。
图4为本发明集群均衡度借鉴基尼系数方法和传统基尼系数方法之间的对比示意图。
图5为本发明的节点的健康度汇总打分方法的具体流程图。
图6为本发明整体系统的具体实现的系统架构图。
图7为采用本发明方法的web用户界面示意图。
图8为本发明系统的模块结构示意图。
具体实施方式
下面结合具体实施例，进一步解释本发明，应理解这些实施例仅用于说明本发明而不用于限制本发明的范围，在阅读了本发明之后，本领域技术人员对本发明的各种等价形式的修改均落于本申请所附权利要求所限定的范围。
如图1所示，本发明提供了一种综合、直观的容器云平台的健康稳定运行程度的评分方法，其统称为“kube-chaos”分数（kubernetes混沌分数）， 其中包括如下两个统计分数：
一、容器云平台集群的节点负载均衡程度打分。
本方案借鉴了“基尼系数”的概念，实现了一种集群节点负载均衡的状态分数。
基尼系数（英语：Gini coefficient），是经济学界的判断年收入分配公平程度的指标。其为比例数值，在0和1之间。基尼指数（Gini index）是指基尼系数乘100倍作百分比表示。在民众收入中，如基尼系数最大为“1”，最小为“0”。前者表示居民之间的年收入分配绝对不平均（即该年所有收入都集中在一个人手里，其余的国民没有收入），而后者则表示居民之间的该年收入分配绝对平均，即人与人之间收入绝对平等，这基尼系数的实际数值只能介于这两种极端情况，即0～1之间。基尼系数越小，年收入分配越平均，基尼系数越大，年收入分配越不平均。
本发明是首次将经济学界“基尼系数”理论应用到计算机云平台的负载均衡度计算中，这是本领域技术人员不容易想到的。基于基尼系数的概念，本发明通过如下方法，计算出集群节点负载均匀度打分（分值0-100）。
该方法的主要步骤为：
（1）统计每个节点的使用资源量（负载）；
（2）计算每个节点的负载占比；
（3）横坐标为累计节点数占比；
（4）纵坐标为负载累计占比；
（5）绘出洛伦茨曲线，计算。
如图2所示，该方法的具体步骤为：
1. 统计每个节点的使用资源量（负载）：通过扫描平台的pod的request的CPU和内存用量，对应到其所运行的节点上得出。对于集群中每台主机节点，分别计算节点上的所有 pod的request 的资源之和；其中，podrequest表明该容器对资源的申请需求， Nodei表示在第i台节点上的容器已占用资源总和；
2. 统计所有节点的负载总和：列出集群中所有主机上的所有Pod（容器）的 request的资源之和 ：；
3. 将Nodei按照其数值，进行逆序排序：；
4. 分别计算每一台主机的 request 的资源之和（Arrayi）与集群request总和(Total)的比例，得出每个节点的负载占比；
5. 借鉴“基尼系数”方法，通过参数转换，横坐标对应累计节点数占比，纵坐标为负载累计占比；根据上式中的i和ratioi,得到一个离散点集合，其x坐标和y坐标，如下公式：
该离散点的意义如： 第一台主机占 10%， 前2台占 20%， 前 n 台 占 80% 。
6. 根据离散点，依次描点，通过计算机插值，拟合洛伦茨曲线，如图1所示。
7. 计算基尼系数比值：如图3所示，通过上面的点构成的弧线与斜率为1的直线构成阴影面积。与总面积之比，即为基尼系数。换言之： A和B是图1中两面积，集群基尼系数便是；SA为拟合曲线（洛伦茨曲线，见图3）中上面部分A的面积，SB为拟合曲线（洛伦茨曲线，见图3）中下面部分B的面积。如图1所示，(通过积分梯形的面积) 近似的计算面积之比， 得到平台之资源分布均匀度（基尼系数）。
弧度越大，阴影面积越大，负载越不均衡。比例趋于 1。
弧度越小，阴影面积越小，负载越均衡。比例趋于 0。
以上方案是对“基尼系数”在一个计算机领域的创新，如图4所示，有助于对本方案和原基尼系数方法之间的对比理解。
8. 集群健康度最终呈现的指标分数：
集群负载均衡分值 =100 – 集群基尼系数*100
该分数在本方案中称为“集群负载均衡分值”，范围为0-100。当分值越小，表明负载越为均衡。由于实际情况中，集群负载不可能达到绝对的平均，结合经济学中基尼系数的收入合理性比率，本方案认为在大多情况下，集群基尼系数设为0.3-0.4是较为均衡、分布相对合理的区间。所以界定0.4作为集群负载分配差距的“警戒线”（根据黄金分割律，其准确值应为0.382，为方便起见，取值0.4易于理解）。所以，该分数在60分以上表明集群“健康”、负载均衡；如果分数在60分以下，表明集群负载较不均衡，分数越低，节点之间的负载差距越悬殊。
之所以采用这样的分数体系，也符合一般认知中的“60分”及格的习惯。
通过“集群负载均衡分值”的实时呈现，运维人员可以结合集群的实际情况，进行下一步的深入分析和实施处理措施：比如在某些高负载应用的空闲时期或者维护窗口期，进行应用的重新调度。
二、节点的健康度汇总打分
对于集群中的每个节点，其健康程度有多个影响因子，其中包括但不限于：主机磁盘使用率、主机内存使用率、主机的CPU使用率、节点上的关键服务是否正常运作等等。以及根据集群中现有的运行业务进行分析，对未来的业务进行预测，得出主机资源是否能够支撑未来的业务资源需求。
如图5所示，本方案采用如下方法，计算出集群总的节点健康度汇总打分（分值0-100）。
1、计算集群中负载度（podrequest为所有的容器资源需求，Allocable为所有节点的可分配资源）如下：，其中, podrequest是整个集群所有节点的容器所申请的资源，Allocable是每个节点的可供分配的资源，Load就是负载度，其与集群冗余度成反比。
当负载程度越高，集群的冗余度越低：一旦有某台主机节点出现问题无法工作，则负面影响更大。
2、对可能出现的错误，划分4个错误等级；
一般实践中，如节点磁盘空间超过95%，就是“严重”级别的错误，因为硬盘空间将满，会导致操作系统和云平台运行缓慢甚至出错；如果磁盘空间超过90%，则是一个“高”级别错误；超过80%，是“中”级别的错误；超过75%，是“低”级别的警告。
3、对于每一项影响因子的指标，设置各自的错误级别。例如：内存使用率（1分钟的平均值），当高于90%，定义为“严重”；当高于80%，定义为“高”…等等。这些指标的错误等级制定方式，可以是基于阈值的统计模型，也可以是其他的计算方法，可以根据不同场景的历史情况和经验动态调整。
4、判断某节点是否有错误。如有错误，对照错误等级，计算扣除数，每节点的每条错误扣分。如无错误，扣除数等于0。当在某一台主机上，一旦某项或者某几项指标达到错误等级，则记录扣除的响应分数，如果该分数超过100，则归约为100。对该主机i上所有扣除的分数总和记为Erri。汇总扣除数：对所有主机上的Erri求和，得到整个集群所应该扣除的分数，除以可用节点数NodeCount。然后再除以（1-Load），得到扣除数Red
其中，Erri为主机i上所有扣除的分数总和，NodeCount为可用节点数，Load为集群中负载程度，Red为扣除数R。
5、计算集群健康打分，最终的集群节点健康汇总分值 = 100 – Red。
(如果该分值低于0，则归约为0)。
类似地，可以将分数划分成不同区间，例如80以上是健康，60-80是良好，30-60是警告，0-30是严重。
假定：
a.现在集群有10台主机，负载程度为20%，而某几台主机上的错误扣分累加为 250分（2个严重错误，1个高错误），则Red=31，总分为69， 健康程度尚可。因为即使2台主机出错，由于负载程度偏低，集群能有足够资源可以调度。
b.还是如上同样的集群规模，负载程度高达80%，而某几台主机上的错误扣分累加还是 250分，则Red=125，总分为-25,归约为0分。集群风险十分高，需要立即介入处理。
图6展示了本发明整体系统的具体实现的系统架构图，其中：计算系统模块会对上述均衡度和健康度进行运算，最终在网页展板上进行展示。在如图6的所展示系统实现过程中，通过Kubernetes的API接口，即可获得上述方法的所有输入参数（例如负载度等信息）。
下文描述一种具体实现： 在Daocloud Enterprise（上海道客网络科技有限公司的容器云平台产品）的实现中，基于python语言，通过python的kubernetes库，获取如下信息：
l 节点数量和信息（如可分配CPU和可分配内存）(allocable)
l 容器的CPU需求和Memory需求（pod-request）
通过上述输入，代入方案中的公式，通过python代码，得到如下两个分值：
u 容器云平台集群的节点负载均衡程度打分
u 节点的健康度汇总打分
然后在Daocloud Enterprise的web用户界面上，进行直观的呈现，如图7所示，图7中均衡系数为50分，不健康，需要关注；节点健康指数75分为一般。
如图8所示，本发明提供一种容器云平台的健康稳定运行程度的评分系统，该系统包括节点负载均衡程度评分模块和节点的健康度汇总评分模块；
所述节点负载均衡程度评分模块包括节点负载统计模块、节点负载占比计算模块、集群基尼系数计算模块、集群负载均衡分值计算模块；所述节点负载统计模块用于统计每个节点的负载；所述节点负载占比计算模块接受来自所述节点负载统计模块的统计数据，计算每个节点的负载占比；所述集群基尼系数计算模块用于以横坐标为累计节点数占比，纵坐标为负载累计占比，绘出洛伦茨曲线，根据曲线计算集群基尼系数；所述集群负载均衡分值计算模块用于接受来自所述集群基尼系数计算模块的集群基尼系数，据此计算集群负载均衡分值；
所述节点的健康度汇总评分模块包括集群负载度计算模块、错误等级划分模块、节点错误扣分模块、集群节点健康汇总分值计算模块；所述集群负载度计算模块用于计算集群中负载度；所述错误等级划分模块用于对可能出现的错误划分等级，并相应扣分；所述节点错误扣分模块用于接收所述集群负载度计算模块和所述错误等级划分模块的相关数据对每节点的每条错误进行扣分；所述集群节点健康汇总分值计算模块接受来自所述节点错误扣分模块的扣除数，据此计算集群节点健康汇总分值。
实施例1
容器云平台作为一个计算机平台性的系统，可以应用在各种不同的行业和场景中，其实施方式都是相通、相似的。下文将对某实际案例进行展开，作为实施方案的实施例之一：
在某金融客户的具体实施中，该客户利用了容器云平台作为其云原生应用的承载平台，金融客户对平台稳定程度十分重视，也迫切需要一种直观的展示方式，能够对平台现状有信心。
该客户有两个场景：（1）开发测试平台：数百工程师几十个团队都在依赖同一套云平台系统进行日常开发和测试，该平台的硬件资源较少，但负载较高，该平台对均衡性要求较高。（2）生产平台：承载金融场景的真实对客应用，硬件资源较高，负载较小，但是该平台对业务的稳定性要求极其高。
原本在该金融客户的（1）开发测试平台中，随着使用时间变长，节点之间均衡度差异越来越大，导致系统响应快慢不一，用户体验差。例如客户对其应用容器进行性能压力测试时，发现数据不达标或者前后不一致，怀疑是某些节点的负载过重导致（比如应用本次测试所在节点负载过重，性能数据就比上次调度到轻负载节点的结果差），常常会怀疑是节点负载不均衡导致， 但是难以排查。过往体验中，运维人员需要逐个节点进行排查，找出负载不均衡的节点，再进行资源重新调度， 非常费时费力。更可怕的是，因为运维人员不能够实时得到集群均衡度的现状，为了保证客户体验，需要每天进行巡检，每天进行摸排，非常费时费力。
在应用了本方案的均衡度打分之后，集群均衡度打分就能够给运维人员展现实时集群均衡现状，在集群打分较低时，及时进行调整。不再需要费时费力的人工定时巡检了。
在该金融客户的（2）生产平台上，集群的稳定程度被极其重视，特别在类似重大客户活动（如双11的促销活动）中，及时预测和监控集群稳定程度，是活动成功的保障。过去的技术，无法提供清晰直观的展示方式，导致运维人员和客户在平台运行期间，会产生担忧和疑虑，对于平台在促销活动期间，能否平稳渡过，无法得到心理预期。
比如：在当前集群中，需要知道当前负载均衡程度是否合理。因为促销活动开始后，为应付大流量访问，会对应用容器进行扩容（比如原来进行“支付”功能的容器数量是10个，活动期间要扩展为50个）。扩容前，如果集群均衡度已经处于不合理状况，可能导致扩容的效果很差甚至失败（例如扩展后的容器都集中调度在一台本来不堪重负的主机上）。所以扩容前，需要对均衡度进行评估。扩容后的均衡度是什么情况，也需要一个直观的展示。这些就是本方案的“均衡度打分”的用武之地。
再比如：生产平台上，促销活动前，需要评估节点的健康度，避免活动产生的高负荷，使得节点被“压垮”，更可怕的是，当很多节点处于某种“亚健康”，高负荷会导致集群“雪崩”（例如：当一台主机的硬盘空间满而崩溃，原本运行其上的容器被迁移到另一台主机，如果第二台主机原本硬盘也所剩不多，原来运行该主机上的容器，和刚新调度过来的容器会加剧其磁盘消耗，加速第二台主机的崩溃..以此类推，更多主机会崩溃）。所以，本方案中的两个指数（均衡度和节点健康度）对集群的健康程度进行一个实时的线性的评估机制，特别是“节点健康指数”，能够给予客户促销活动前对平台集群是否能够平稳度过活动，给予“定心丸”的作用。当促销开始前，发现健康指数不如预期（例如只有75分，处于某种“亚健康”），就应该在大促开始前，提前发现“亚健康”，进行提前干预。
实施例2
另一个重要的案例，就是客户平台的集群有200台主机，在平时，往往几台主机出问题，对整体运行状况影响不大（因为应用重新调度到其他主机后，其他主机仍可以负荷）。但是在大促期间，集群负载倍增，这时，哪怕1台主机下线，都可能影响业务（类似参考上文“雪崩”案例）。所以，在本方案中，“节点健康指数”综合考虑了集群的负载度（冗余度），可以从容应对这两种不同时期的情况。
Claims (12)
1.一种容器云平台的健康稳定运行程度的评分方法，其特征在于，该方法采用容器云平台集群的节点负载均衡程度评分和节点的健康度汇总评分；
所述容器云平台集群的节点负载均衡程度评分，包括如下步骤：
第一步，统计每个节点的使用资源量，即负载；
第二步，计算每个节点的负载占比；
第三步，横坐标为累计节点数占比，纵坐标为负载累计占比，绘出洛伦茨曲线，计算集群基尼系数；
第四步，计算集群负载均衡分值，集群负载均衡分值 = 100 –集群基尼系数*100；
所述节点的健康度汇总评分，包括如下步骤：
步骤1，计算集群中负载度；
步骤2，对可能出现的错误划分等级，并相应扣分；
步骤3，对每节点的每条错误扣分，Red为扣除数；
步骤4，计算集群节点健康汇总分值，集群节点健康汇总分值 = 100 – Red。
2.如权利要求1所述的方法，其特征在于，第一步具体为：
（1）对于集群中每台主机节点，分别计算节点上的所有 pod 的request 的资源之和；其中，podrequest表明该容器对资源的申请需求， Nodei表示在第i台节点上的容器已占用资源总和；
（2）列出集群中所有主机上的所有Pod的 request 的资源之和：。
3.如权利要求2所述的方法，其特征在于，第二步具体为：
（1）将Nodei按照其数值，进行逆序排序：；
（2）分别计算每一台主机的request 的资源之和Arrayi与集群request总和Total的比例。
4.如权利要求3所述的方法，其特征在于，第三步具体为：
（1）根据i和ratioi,得到一个离散点集合，其x坐标和y坐标，如下公式：
；
（2）根据离散点，依次描点，拟合洛伦茨曲线，计算集群基尼系数，其中，SA为曲线中上面部分A的面积，SB为曲线中下面部分B的面积；通过离散点构成的弧线与斜率为1的直线构成阴影面积，与总面积之比，即为基尼系数，通过积分梯形的面积近似的计算面积之比，得到平台之资源分布均匀度即基尼系数；弧度越大，阴影面积越大，负载越不均衡，比例趋于 1；弧度越小，阴影面积越小，负载越均衡，比例趋于 0。
5.如权利要求1或4所述的方法，其特征在于，第三步中所述集群基尼系数设为0.3-0.4是节点负载均衡、分布相对合理的区间。
6.如权利要求1所述的方法，其特征在于，步骤1中，按以下公式计算集群中负载度：，其中, podrequest是整个集群所有节点的容器所申请的资源，Allocable是每个节点的可供分配的资源，Load就是负载度，其与集群冗余度成反比。
7.如权利要求1所述的方法，其特征在于，步骤2中，所述对可能出现的错误划分等级，并相应扣分具体为：对可能出现的错误，划分以下4个等级：
严重等级，对应扣除分数100；
高等级，对应扣除分数50；
中等级，对应扣除分数5；
低等级，对应扣除分数2。
8.如权利要求1所述的方法，其特征在于，步骤3中，对每节点的每条错误按如下公式扣分：
其中，Red为扣除数 ,Erri为主机i上所有扣除的分数总和，为对所有主机上的Erri求和，NodeCount为可用节点数，Load为集群中负载程度。
9.如权利要求1所述的方法，其特征在于，步骤4中，如果所述集群节点健康汇总分值低于0，则归为0；将所述集群节点健康汇总分值划分成不同区间，80以上是健康，60-80是良好，30-60是警告，0-30是严重。
10.一种容器云平台的健康稳定运行程度的评分系统，其特征在于，该系统包括节点负载均衡程度评分模块和节点的健康度汇总评分模块；
所述节点负载均衡程度评分模块包括节点负载统计模块、节点负载占比计算模块、集群基尼系数计算模块、集群负载均衡分值计算模块；所述节点负载统计模块用于统计每个节点的负载；所述节点负载占比计算模块接受来自所述节点负载统计模块的统计数据，计算每个节点的负载占比；所述集群基尼系数计算模块用于以横坐标为累计节点数占比，纵坐标为负载累计占比，绘出洛伦茨曲线，根据曲线计算集群基尼系数；所述集群负载均衡分值计算模块用于接受来自所述集群基尼系数计算模块的集群基尼系数，据此计算集群负载均衡分值；
所述节点的健康度汇总评分模块包括集群负载度计算模块、错误等级划分模块、节点错误扣分模块、集群节点健康汇总分值计算模块；所述集群负载度计算模块用于计算集群中负载度；所述错误等级划分模块用于对可能出现的错误划分等级，并相应扣分；所述节点错误扣分模块用于接收所述集群负载度计算模块和所述错误等级划分模块的相关数据对每节点的每条错误进行扣分；所述集群节点健康汇总分值计算模块接受来自所述节点错误扣分模块的扣除数，据此计算集群节点健康汇总分值。
11.如权利要求10所述的系统，其特征在于，所述节点负载统计模块按如下方法进行统计：
（1）对于集群中每台主机节点，分别计算节点上的所有 pod 的request 的资源之和；其中，podrequest表明该容器对资源的申请需求， Nodei表示在第i台节点上的容器已占用资源总和；
（2）列出集群中所有主机上的所有Pod的 request 的资源之和：；
所述节点负载占比计算模块按如下方法进行计算：
（1）将Nodei按照其数值，进行逆序排序：；
（2）分别计算每一台主机的request 的资源之和Arrayi与集群request总和Total的比例；
所述集群基尼系数计算模块按如下方法进行计算：
（1）根据i和ratioi,得到一个离散点集合，其x坐标和y坐标，如下公式：
x坐标为累计节点数占比，y坐标为负载累计占比；
（2）根据离散点，依次描点，拟合洛伦茨曲线，计算集群基尼系数；其中，SA为曲线中上面部分A的面积，SB为曲线中下面部分B的面积；通过离散点构成的弧线与斜率为1的直线构成阴影面积，与总面积之比，即为基尼系数，通过积分梯形的面积近似的计算面积之比，得到平台之资源分布均匀度即基尼系数；弧度越大，阴影面积越大，负载越不均衡，比例趋于 1；弧度越小，阴影面积越小，负载越均衡，比例趋于 0。
12.如权利要求10所述的系统，其特征在于，所述集群负载度计算模块，按以下公式计算集群中负载度：，其中, podrequest是整个集群所有节点的容器所申请的资源，Allocable是每个节点的可供分配的资源，Load就是负载度，其与集群冗余度成反比；
所述错误等级划分模块按如下方法进行划分：
对可能出现的错误，划分以下4个等级：
严重等级，对应扣除分数100；
高等级，对应扣除分数50；
中等级，对应扣除分数5；
低等级，对应扣除分数2；
所述节点错误扣分模块对每节点的每条错误按如下公式扣分：
其中，Red为扣除数 ,Erri为主机i上所有扣除的分数总和，为对所有主机上的Erri求和，NodeCount为可用节点数，Load为集群中负载程度。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910864036.7A CN110597701B (zh) | 2019-09-12 | 2019-09-12 | 一种容器云平台的健康稳定运行程度的评分系统及方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910864036.7A CN110597701B (zh) | 2019-09-12 | 2019-09-12 | 一种容器云平台的健康稳定运行程度的评分系统及方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110597701A true CN110597701A (zh) | 2019-12-20 |
| CN110597701B CN110597701B (zh) | 2021-03-05 |
Family
ID=68859167
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910864036.7A Active CN110597701B (zh) | 2019-09-12 | 2019-09-12 | 一种容器云平台的健康稳定运行程度的评分系统及方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110597701B (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111405055A (zh) * | 2020-03-23 | 2020-07-10 | 北京达佳互联信息技术有限公司 | 多集群管理方法、系统、服务器、存储介质 |
| CN115934479A (zh) * | 2023-03-15 | 2023-04-07 | 天聚地合(苏州)科技股份有限公司 | 接口服务的控制方法、装置、存储介质及设备 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108512890A (zh) * | 2018-01-25 | 2018-09-07 | 中铝视拓智能科技有限公司 | 一种基于机架感知的容器云平台资源调度方法及系统 |
| CN108874640A (zh) * | 2018-05-07 | 2018-11-23 | 北京京东尚科信息技术有限公司 | 一种集群性能的评估方法和装置 |
-
2019
- 2019-09-12 CN CN201910864036.7A patent/CN110597701B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108512890A (zh) * | 2018-01-25 | 2018-09-07 | 中铝视拓智能科技有限公司 | 一种基于机架感知的容器云平台资源调度方法及系统 |
| CN108874640A (zh) * | 2018-05-07 | 2018-11-23 | 北京京东尚科信息技术有限公司 | 一种集群性能的评估方法和装置 |
Non-Patent Citations (2)
| Title |
|---|
| 佚名: "推荐系统指标测评——覆盖率与基尼系数的算法与应用", 《HTTPS://WWW.BAIDU.COM/LINK?URL=LLMSWAVLRZF8IJT2LSOKNBHYD4HDVTN_KB2KVFABIVOYX6GSVW__AVZS8HCJRAMCUVWMVI7NUXGSYURVIGI7N_&WD=&EQID=BD58216400006BE0000000055E65D886》 * |
| 陈华鹏等: "基于负载基尼系数的服务网络公平均衡调度", 《计算机工程与科学》 * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111405055A (zh) * | 2020-03-23 | 2020-07-10 | 北京达佳互联信息技术有限公司 | 多集群管理方法、系统、服务器、存储介质 |
| CN115934479A (zh) * | 2023-03-15 | 2023-04-07 | 天聚地合(苏州)科技股份有限公司 | 接口服务的控制方法、装置、存储介质及设备 |
| CN115934479B (zh) * | 2023-03-15 | 2023-07-25 | 天聚地合(苏州)科技股份有限公司 | 接口服务的控制方法、装置、存储介质及设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110597701B (zh) | 2021-03-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Gao et al. | Machine learning based workload prediction in cloud computing | |
| US20200153683A1 (en) | Mitigation of likelihood and impact of a server-reconfiguration failure | |
| US9983900B2 (en) | Capacity risk management for virtual machines | |
| US9274850B2 (en) | Predictive and dynamic resource provisioning with tenancy matching of health metrics in cloud systems | |
| US20190158582A1 (en) | Resource allocation diagnosis on distributed computer systems | |
| US9451013B1 (en) | Providing instance availability information | |
| US9654367B2 (en) | System and method for determining and visualizing efficiencies and risks in computing environments | |
| US8904405B1 (en) | System and method for managing mainframe computer system usage | |
| US20140019966A1 (en) | System and method for continuous optimization of computing systems with automated assignment of virtual machines and physical machines to hosts | |
| US8250582B2 (en) | Chargeback reduction planning for information technology management | |
| US11194628B2 (en) | Workload allocation utilizing real-time enterprise resiliency scoring | |
| US9953276B2 (en) | Method and system that measures and reports computational-resource usage in a data center | |
| US20170235606A1 (en) | System and methods for implementing control of use of shared resource in a multi-tenant system | |
| CN110515539A (zh) | 基于云存储的云磁盘挂载方法、装置、设备和存储介质 | |
| US20200026576A1 (en) | Determining a number of nodes required in a networked virtualization system based on increasing node density | |
| CN110597701B (zh) | 一种容器云平台的健康稳定运行程度的评分系统及方法 | |
| US20230060445A1 (en) | Predictive scaling of datacenters | |
| US10225337B2 (en) | Modeling and forecasting reserve capacity for overbooked clusters | |
| US9306814B1 (en) | Providing instance availability information | |
| US10394612B2 (en) | Methods and systems to evaluate data center performance and prioritize data center objects and anomalies for remedial actions | |
| Everman et al. | Evaluating and reducing cloud waste and cost—A data-driven case study from Azure workloads | |
| US20220374273A1 (en) | Computing resource autoscaling based on predicted metric behavior | |
| Lang et al. | Not for the Timid: On the Impact of Aggressive Over-booking in the Cloud | |
| CN114416474A (zh) | 一种系统应用健康度评分方法及存储介质 | |
| CN106844175B (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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CP02 | Change in the address of a patent holder | ||
| CP02 | Change in the address of a patent holder |
Address after: 200433 floor 7, building 6, No. 99, jiangwancheng Road, Yangpu District, Shanghai Patentee after: Shanghai Daoke Network Technology Co.,Ltd. Address before: Room 1305-12, No.6 Weide Road, Yangpu District, Shanghai 200433 Patentee before: Shanghai Daoke Network Technology Co.,Ltd. |