CN114003345A - 一种基于云原生的Kubernetes平台健康度确定方法和装置 - Google Patents
一种基于云原生的Kubernetes平台健康度确定方法和装置 Download PDFInfo
- Publication number
- CN114003345A CN114003345A CN202111322081.3A CN202111322081A CN114003345A CN 114003345 A CN114003345 A CN 114003345A CN 202111322081 A CN202111322081 A CN 202111322081A CN 114003345 A CN114003345 A CN 114003345A
- Authority
- CN
- China
- Prior art keywords
- index data
- platform
- kubernets
- determining
- data
- 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/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/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
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本申请公开了一种基于云原生的Kubernetes平台健康度确定方法和装置,该方法包括:在接收确定Kubernetes平台的健康度的指令后,根据该指令获取Kubernetes平台的核心组件对应的第一指标数据和Kubernetes平台的工作负载对应的第二指标数据,其中,核心组件对应的第一指标数据用于描述Kubernetes平台的性能,进而体现云原生环境是否稳定,工作负载对应的第二指标数据用于描述云原生环境动态变化的情况,由此,根据第一指标数据和第二指标数据确定Kubernetes平台的健康度,能够适应动态变化的云原生环境,提高了基于云原生的Kubernetes平台的健康度的精度。
Description
技术领域
本发明涉及云计算技术领域,尤其是涉及一种基于云原生的Kubernetes平台健康度确定方法和装置。
背景技术
Kubernetes(简称k8s)是一个开源的、用于管理云平台中多个主机上的容器化的应用,其目标是让部署容器化的应用简单并且高效。k8s平台在使用云原生技术后,开发者无需考虑底层的技术实现,可以充分发挥云平台的弹性和分布式优势,实现快速部署、按需伸缩、不停机交付等。
云原生为企业带来快速交付与迭代的优势之外,同时也会对平台维护管理带来新的要求与挑战。云原生伴随着容器和微服务等技术的大量应用,k8s平台会根据内存调度微服务,资源动态变化的特点导致IT基础资源使用发生了显著变化。
相关技术中,通过边界模型确定k8s平台的健康度,但由于边界模型无法适用动态变化的云原生环境,导致确定基于云原生的Kubernetes平台健康度的精度较低。
发明内容
针对上述问题,本申请提供一种基于云原生的Kubernetes平台健康度确定方法和装置,用于提高基于云原生的Kubernetes平台健康度的精度。
基于此,本申请实施例公开了如下技术方案:
一方面,本申请实施例提供一种基于云原生的Kubernetes平台健康度确定方法,所述方法包括:
接收确定所述Kubernetes平台的健康度的指令;
根据所述指令获取所述Kubernetes平台的核心组件对应的第一指标数据和所述Kubernetes平台的工作负载对应的第二指标数据;
根据所述第一指标数据和所述第二指标数据确定所述Kubernetes平台的健康度。
可选的,所述第一指标数据包括集群组件服务端状态、集群组件控制器管理器状态、集群组件调度器状态、集群组件键值存储组件和集群组件域名解析系统中的一个或多个;
所述第二指标数据包括在线应用实例状态、无状态应用控制器资源状态、有状态应用控制器资源状态、守护进程控制器资源状态、服务控制器资源状态、应用实例的剩余容量和节点的应用实例分布均匀度中的一个或多个。
可选的,所述根据所述第一指标数据和所述第二指标数据确定所述Kubernetes平台的健康度,包括:
获取所述第一指标数据的第一权重系数和所述第二指标数据的第二权重系数;
根据所述第一指标数据、所述第二指标数据、所述第一权重系数和所述第二权重系数确定所述Kubernetes平台的健康度。
可选的,所述方法还包括:
根据所述指令获取其他指标数据,所述其他指标数据包括所述Kubernetes平台的基础资源对应的第三指标数据、所述Kubernetes平台的节点主机对应的第四指标数据和所述Kubernetes平台的安全事件对应的第五指标数据中的一个或多个;
所述根据所述第一指标数据和所述第二指标数据确定所述Kubernetes平台的健康度,包括:
根据所述第一指标数据、所述第二指标数据和所述其他指标数据确定所述Kubernetes平台的健康度。
可选的,所述第三指标数据包括集群维度中央处理器利用率、集群维度内存利用率、集群维度文件系统利用率和集群维度网络带宽利用率中的一个或多个;
第四指标数据包括节点在线状态、网络代理组件状态、节点主机中央处理器利用率、节点主机内存利用率、节点主机文件系统利用率和文件索引节点利用率中的一个或多个;
第五数据指标包括集群主节点日志信息、集群节点日志信息和集群应用安全日志信息中的一个或多个。
可选的,所述根据所述第一指标数据、所述第二指标数据和所述其他指标数据确定所述Kubernetes平台的健康度,包括:
获取所述第一指标数据的第一权重系数、所述第二指标数据的第二权重系数和所述其他指标数据分别对应的权重系数;
根据所述第一指标数据、所述第二指标数据、所述其他指标数据、所述第一权重系数、所述第二权重系数和所述其他指标数据分别对应的权重系数确定所述Kubernetes平台的健康度。
可选的,所述根据所述指令获取所述Kubernetes平台的核心组件对应的第一指标数据和所述Kubernetes平台的工作负载对应的第二指标数据,包括:
根据所述指令确定所述Kubernetes平台的核心组件对应的第一历史数据集合和所述Kubernetes平台的工作负载对应的第二历史数据集合;
将所述第一历史数据集合中距离当前时刻最近的数据确定为第一指标数据,将所述第二历史数据集合中距离所述当前时刻最近的数据确定为第二指标数据。
可选的,所述Kubernetes平台的健康度分为五个等级,分别为不健康状态、亚健康状态、较好状态、良好状态和优异状态。
可选的,所述方法还包括:
展示所述Kubernetes平台的健康度。
另一方面本申请提供了一种基于云原生的Kubernetes平台健康度确定装置,所述装置包括:接收单元、获取单元和确定单元;
所述接收单元,用于接收确定所述Kubernetes平台的健康度的指令;
所述获取单元,用于根据所述指令获取所述Kubernetes平台的核心组件对应的第一指标数据和所述Kubernetes平台的工作负载对应的第二指标数据;
所述确定单元,用于根据所述第一指标数据和所述第二指标数据确定所述Kubernetes平台的健康度。
另一方面本申请提供了一种计算机设备,所述设备包括处理器以及存储器:
所述存储器用于存储程序代码,并将所述程序代码传输给所述处理器;
所述处理器用于根据所述程序代码中的指令执行上述方面所述的方法。
另一方面本申请提供了一种计算机可读存储介质,所述计算机可读存储介质用于存储计算机程序,所述计算机程序用于执行上述方面所述的方法。
另一方面,本申请实施例提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述方面所述的方法。
相对于现有技术,本申请上述技术方案的优点在于:
在接收确定Kubernetes平台的健康度的指令后,根据该指令获取Kubernetes平台的核心组件对应的第一指标数据和Kubernetes平台的工作负载对应的第二指标数据,其中,核心组件对应的第一指标数据用于描述Kubernetes平台的性能,进而体现云原生环境是否稳定,工作负载对应的第二指标数据用于描述云原生环境动态变化的情况,由此,根据第一指标数据和第二指标数据确定Kubernetes平台的健康度,能够适应动态变化的云原生环境,提高了基于云原生的Kubernetes平台的健康度的精度。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。
图1为本申请提供的一种基于云原生的Kubernetes平台健康度确定的流程图;
图2为本申请实施例提供的一种Kubernetes平台的健康度的展示示意图;
图3为本申请提供的一种基于云原生的Kubernetes平台健康度确定装置示意图;
图4为本申请实施例提供的一种计算机设备的结构图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
下面结合图1,对本申请实施例提供的一种基于云原生的Kubernetes平台健康度确定方法进行介绍。参见图1,该图为本申请实施例提供的一种基于云原生的Kubernetes平台健康度确定方法的流程图,该方法可以包括S101-S103。
S101:接收确定Kubernetes平台的健康度的指令。
为了描述方便,本申请将基于云原生的Kubernetes平台还称为云原生系统,在实际使用中,用户可以点击云原生系统中用于确定Kubernetes平台健康度的控件等,以便云原生系统接收到确定Kubernetes平台的健康度的指令。
其中,Kubernetes平台的健康度是衡量基于云原生的Kubernetes平台的健康程度。作为一种可能实现方式,可以通过0-100分量化Kubernetes平台的健康度。进一步地,还可以借鉴自然界对机体的健康程度的划分方式,将其划分为多个等级,以五个等级为例,可以将其分为不健康、亚健康、较好、良好和优异,以便向用户直观的展示云原生环境下Kubernetes平台的健康程度,具体参见表1。
表1
序号 | 健康度分值 | 健康状态 | 备注说明 |
1 | H<60 | 不健康 | 平台运行异常,或有严重隐患 |
2 | 60≤H<70 | 亚健康 | 平台基本可运行,但有一定隐患 |
3 | 70≤H<80 | 较好 | 平台运行状况较好,仅具备提供基本服务能力 |
4 | 80≤H<90 | 良好 | 平台的健康度良好,具备一定的伸缩扩展能力 |
5 | 90≤H | 优异 | 平台的健康度优异,具备较强的弹性伸缩能力 |
作为一种可能的实现方式,还可以将云原生系统通过可视化的方式展示给用户,以便用户进行使用。
S102:根据指令获取Kubernetes平台的核心组件对应的第一指标数据和Kubernetes平台的工作负载对应的第二指标数据。
当获取到确定Kubernetes平台的健康度的指令后,需要获取对应的数据确定Kubernetes平台健康,在本申请中,根据云原生系统的动态特性选取了两个维度的数据,分别是Kubernetes平台的核心组件对应的第一指标数据和Kubernetes平台的工作负载对应的第二指标数据,下面分别进行说明。
第一指标数据:核心组件对应的第一指标数据用于描述Kubernetes平台的性能,进而体现云原生环境是否稳定,核心组件如果出现问题,那么Kubernetes平台就存在严重隐患,Kubernetes平台无法正常运行。
本申请实施例不具体限定第一指标数据包括的内容,例如可以通过核心组件的关键技术点与影响范围选取集群组件服务端(Apiserver)状态、集群组件控制器管理器(ControllerManager)状态、集群组件调度器(Scheduler)状态、集群组件键值存储组件(Etcd)状态和集群组件域名解析系统(CoreDNS)状态中的一种或多种组合。
第二指标数据:工作负载对应的第二指标数据用于描述云原生环境动态变化的情况,工作负载是指在Kubernetes平台上运行的应用程序,故存在动态变化,通过第二指标数据可以明确Kubernetes平台在当前时刻的情况。
本申请实施例不具体限定第二指标数据包括的内容,例如可以通过工作负载的关键技术点与影响范围选取在线应用实例(pod)状态、无状态应用控制器(Deployment)资源状态、有状态应用控制器(StatefulSet)资源状态、守护进程控制器(DaemonSet)资源状态、服务控制器(Service)资源状态、应用实例(pod)的剩余容量和节点的应用实例(pod)分布均匀度中的一种或多种组合。
作为一种可能的实现方式,云原生系统可以实时采集或者每隔固定时间采集并存储包括第一指标数据和第二指标数据的数据,以便后续进行分析。当需要获取第一指标数据和第二指标数据时,从存储的历史数据中选取距离当前时刻最近的历史数据。
具体地,采集Kubernetes平台的核心组件对应的指标数据,并将其存储至第一历史数据集合中,采集Kubernetes平台的工作负载对应的指标数据,并将其存储至第二历史数据集合中,在获取指标后,根据指令第一历史数据集合和第二历史数据集合,将第一历史数据集合中距离当前时刻最近的数据确定为第一指标数据,将第二历史数据集合中距离当前时刻最近的数据确定为第二指标数据。
S103:根据第一指标数据和第二指标数据确定Kubernetes平台的健康度。
由于第一指标数据能够用于体现云原生环境是否稳定,第二指标数据用于描述云原生环境动态变化情况,故通过第一指标数据和第二指标数据可以确定Kubernetes平台的健康度,且能够动态变化的云原生环境,使得确定出的Kubernetes平台的健康度精度较高。
作为一种可能的实现方式,可以获取第一指标数据对应的第一权重系数,以及第二指标数据对应的第二权重系数。根据第一指标数据、第二指标数据、第一权重系数和第二权重系数确定Kubernetes平台的健康度。
本申请实施例不具体限定第一权重系数和第二权重系数,例如,可以基于第一指标数据和第二指标数据对于Kubernetes平台的影响程度确定,第一权重系数约为70%,第二权重系数约为30%。进而将第一指标数据和第一权重系数相乘,与第二指标数据和第二权重系数相乘求和得到Kubernetes平台的健康度。需要说明的是,第一权重系数和第二权重系数还可以根据实际需要进行不断调整。
作为一种可能的实现方式,不仅可以获取第一指标数据和第二指标数据,还可以获取其他指标数据,通过多种维度的指标数据,多方面实现对Kubernetes平台的健康度的确定。其中,其他指标数据包括Kubernetes平台的基础资源对应的第三指标数据、Kubernetes平台的节点主机对应的第四指标数据和Kubernetes平台的安全事件对应的第五指标数据中的一个或多个,下面分别进行说明。
第三指标数据:基础资源对应的第三指标数据不仅可以从侧面描述Kubernetes平台的性能,还能够从侧面描述工作负载变化程度。作为一种可能的实现方式,可以通过基础资源的关键技术点与影响范围选取集群维度中央处理器(cpu)利用率、集群维度内存(mem)利用率、集群维度文件系统(fs)利用率和集群维度网络(network)带宽利用率中的一种或多种。
第四指标数据:节点主机对应的第四指标数据可以通过关注用于分配工作负载的分类策略,实现对工作负载程度变化的描述。作为一种可能的实现方式,可以通过节点主机的关键技术点与影响范围选取节点在线状态、网络代理组件(kube-proxy)状态、节点主机中央处理器(cpu)利用率、节点主机内存(mem)利用率、节点主机文件系统(fs)利用率和文件索引节点(inode)利用率中的一种或多种组合。
第五指标数据:安全事件对应的第五指标数据能够涉及Kubemetes平台的安全层面。作为一种可能的实现方式,可以选取集群主节点(Master)日志信息、集群节点日志信息和集群应用安全日志信息中的一种或多种组合。
在获取多个维度的指标数据后,前述S103的一种实现方式可以为根据第一指标数据、第二指标数据和其他指标数据确定Kubemetes平台的健康度。
作为一种可能的实现方式,可以获取第一指标数据对应的第一权重系数、第二指标数据对应的第二权重系数,以及其他指标分别对应的权重系数,若其他指标包括第三指标数据、第四指标数据和第五指标数据,可以获取第三指标数据对应的第三权重系数、第四指标数据对应的第四权重系数和第五指标数据对应的第五权重系数。根据五个维度指标数据分别对应的权重数据进行加权求和,从而得到Kubernetes平台的健康度。
具体地,各个指标数据对于健康度的影响程度可以表示为下式:
其中,n表示指标数据的个数,Di表示第i个指标数据,Ki表示第i个指标数据对应的权重系数。
进一步地,若第i个指标数据中包括多种数据的组合,则各种组合对于第i个指标数据的影响程度可以表示为下式:
其中,m表示指标数据包括数据种类的个数,Sj表示指标数据中第j种数据,Tj表示第j种数据对应的权重系数。
本申请实施例不具体限定第三权重系数、第四权重系数和第五权重系数,例如,可以基于第三指标数据、第四指标数据和第五指标数据对于Kubernetes平台的影响程度确定,例如,第一权重系数为50%、第二权重系数为20%、第三权重系数为10%、第四权重系数为15%和第五权重系数为5%。需要说明的是,第三权重系数、第四权重系数和第五权重系数还可以根据实际需要进行不断调整。
由上述技术方案可知,在接收确定Kubernetes平台的健康度的指令后,根据该指令获取Kubernetes平台的核心组件对应的第一指标数据和Kubernetes平台的工作负载对应的第二指标数据,其中,核心组件对应的第一指标数据用于描述Kubernetes平台的性能,进而体现云原生环境是否稳定,工作负载对应的第二指标数据用于描述云原生环境动态变化的情况,由此,根据第一指标数据和第二指标数据确定Kubernetes平台的健康度,能够适应动态变化的云原生环境,提高了基于云原生的Kubernetes平台的健康度的精度。
为了使本申请实施例提供的技术方案更加清楚,下面以一个实例对本申请实施例提供的基于云原生的Kubernetes平台健康度确定方法进行说明。
S1:用户通过云原生系统点击确定基于云原生的Kubernetes平台的健康度的控件。
S2:云原生系统接收确定Kubernetes平台的健康度的指令。
S3:云原生系统根据该指令获取用于确定Kubernetes平台的健康度的五个维度,以及每个维度分别对应的指标数据。
需要说明的是,可以预先根据每个云原生系统的特定设置维度与每个维度分别对应的指标数据,在本申请实施例中,该云原生系统包括五个维度分别是核心组件维度、工作负载维度、基础资源维度、节点主机维度和安全事件维度,每个维度分别对应的指标数据如表2所示。
表2
其中,获取指标数据的方式包括:自动检测和人工调研,自动检测是基于如Prometheus、Zabbix等主流监控工具来获取指标数据,人工调研是基于自主编写的程序针对指标数据特点获取指标数据。
检测粒度对应指标项数据的采集周期,需要说明的是,本领域技术人员可以根据实际需要与指标数据的特点,为其设置合适的采集周期。
时间跨度对应指标数据的历史采集数据的保留时间,用于其他相关的大数据分析,可以理解的是,时间跨度越长对于后续大数据分析越好,例如,将时间跨度设置为3个月。
S4:根据前述获取的五个指标数据及其对应的权重系数,通过加权求和的方式得到Kubernetes平台的健康度。
作为一种可能的实现方式,还可以将每次获得的Kubernetes平台的健康度进行持久化存储,并将Kubernetes平台的健康度以大屏、实时告警和页面展示等方式进行可视化展现,如图2所示。
本申请实施例根据云原生环境资源动态变化的特点,确定Kubernetes平台的健康度所需的指标数据,并针对Kubernetes集群、Node、POD及Kubernetes的工作负载进行了全方位、客观准确的健康度评测,从而系统性地提升了云原生系统隐患的捕捉、评估、可视化和应急处置能力,为持续保障云原生业务系统正常提供了有效的手段和便利的途径。在确定Kubernetes平台的健康度后,可以对Kubernetes平台存在劣化的维度和特性,进行整治和优化。同时,结合Kubernetes平台的健康度的可视化,方便管理者和系统维护人员高效便捷地掌握集群中云原生资源及业务应用的健康情况,真正做到随时对云原生环境下应用系统健康问题进行有效的诊断和预防,充分保证应用系统的正常运行,从而保障应用服务质量。
本申请实施例除了提供的基于云原生的Kubernetes平台健康度确定方法外,还提供了基于云原生的Kubernetes平台健康度确定装置,如图3所示,包括:接收单元301、获取单元302和确定单元303;
所述接收单元301,用于接收确定所述Kubernetes平台的健康度的指令;
所述获取单元302,用于根据所述指令获取所述Kubernetes平台的核心组件对应的第一指标数据和所述Kubernetes平台的工作负载对应的第二指标数据;
所述确定单元303,用于根据所述第一指标数据和所述第二指标数据确定所述Kubernetes平台的健康度。
作为一种可能的实现方式,所述第一指标数据包括集群组件服务端状态、集群组件控制器管理器状态、集群组件调度器状态、集群组件键值存储组件和集群组件域名解析系统中的一个或多个;
所述第二指标数据包括在线应用实例状态、无状态应用控制器资源状态、有状态应用控制器资源状态、守护进程控制器资源状态、服务控制器资源状态、应用实例的剩余容量和节点的应用实例分布均匀度中的一个或多个。
作为一种可能的实现方式,所述确定单元303,用于:
获取所述第一指标数据的第一权重系数和所述第二指标数据的第二权重系数;
根据所述第一指标数据、所述第二指标数据、所述第一权重系数和所述第二权重系数确定所述Kubernetes平台的健康度。
作为一种可能的实现方式,所述获取单元302,还用于:
根据所述指令获取其他指标数据,所述其他指标数据包括所述Kubernetes平台的基础资源对应的第三指标数据、所述Kubernetes平台的节点主机对应的第四指标数据和所述Kubernetes平台的安全事件对应的第五指标数据中的一个或多个;
所述确定单元303,用于:
根据所述第一指标数据、所述第二指标数据和所述其他指标数据确定所述Kubernetes平台的健康度。
作为一种可能的实现方式,所述第三指标数据包括集群维度中央处理器利用率、集群维度内存利用率、集群维度文件系统利用率和集群维度网络带宽利用率中的一个或多个;
第四指标数据包括节点在线状态、网络代理组件状态、节点主机中央处理器利用率、节点主机内存利用率、节点主机文件系统利用率和文件索引节点利用率中的一个或多个;
第五数据指标包括集群主节点日志信息、集群节点日志信息和集群应用安全日志信息中的一个或多个。
作为一种可能的实现方式,所述确定单元303,用于:
获取所述第一指标数据的第一权重系数、所述第二指标数据的第二权重系数和所述其他指标数据分别对应的权重系数;
根据所述第一指标数据、所述第二指标数据、所述其他指标数据、所述第一权重系数、所述第二权重系数和所述其他指标数据分别对应的权重系数确定所述Kubernetes平台的健康度。
作为一种可能的实现方式,所述获取单元302,用于:
根据所述指令确定所述Kubernetes平台的核心组件对应的第一历史数据集合和所述Kubernetes平台的工作负载对应的第二历史数据集合;
将所述第一历史数据集合中距离当前时刻最近的数据确定为第一指标数据,将所述第二历史数据集合中距离所述当前时刻最近的数据确定为第二指标数据。
作为一种可能的实现方式,所述Kubernetes平台的健康度分为五个等级,分别为不健康状态、亚健康状态、较好状态、良好状态和优异状态。
作为一种可能的实现方式,所述装置还包括展示单元,用于:
展示所述Kubernetes平台的健康度。
本申请实施例提供一种基于云原生的Kubernetes平台健康度确定装置,在接收确定Kubernetes平台的健康度的指令后,根据该指令获取Kubernetes平台的核心组件对应的第一指标数据和Kubernetes平台的工作负载对应的第二指标数据,其中,核心组件对应的第一指标数据用于描述Kubernetes平台的性能,进而体现云原生环境是否稳定,工作负载对应的第二指标数据用于描述云原生环境动态变化的情况,由此,根据第一指标数据和第二指标数据确定Kubernetes平台的健康度,能够适应动态变化的云原生环境,提高了基于云原生的Kubernetes平台的健康度的精度。
本申请实施例还提供了一种计算机设备,参见图4,该图示出了本申请实施例提供的一种计算机设备的结构图,如图4所示,所述设备包括处理器410以及存储器420:
所述存储器410用于存储程序代码,并将所述程序代码传输给所述处理器;
所述处理器420用于根据所述程序代码中的指令执行上述实施例提供的任一种基于云原生的Kubernetes平台健康度确定方法。
本申请实施例提供了一种计算机可读存储介质,所述计算机可读存储介质用于存储计算机程序,所述计算机程序于执行上述实施例提供的任一种基于云原生的Kubernetes平台健康度确定方法。
本申请实施例还提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述方面的各种可选实现方式中提供的基于云原生的Kubernetes平台健康度确定方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。本申请在上述各方面提供的实现方式的基础上,还可以进行进一步组合以提供更多实现方式。尤其,对于装置实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元及模块可以是或者也可以不是物理上分开的。另外,还可以根据实际的需要选择其中的部分或者全部单元和模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅是本申请的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。
Claims (10)
1.一种基于云原生的Kubernetes平台健康度确定方法,其特征在于,所述方法包括:
接收确定所述Kubernetes平台的健康度的指令;
根据所述指令获取所述Kubernetes平台的核心组件对应的第一指标数据和所述Kubernetes平台的工作负载对应的第二指标数据;
根据所述第一指标数据和所述第二指标数据确定所述Kubernetes平台的健康度。
2.根据权利要求1所述的方法,其特征在于,所述第一指标数据包括集群组件服务端状态、集群组件控制器管理器状态、集群组件调度器状态、集群组件键值存储组件和集群组件域名解析系统中的一个或多个;
所述第二指标数据包括在线应用实例状态、无状态应用控制器资源状态、有状态应用控制器资源状态、守护进程控制器资源状态、服务控制器资源状态、应用实例的剩余容量和节点的应用实例分布均匀度中的一个或多个。
3.根据权利要求1所述的方法,其特征在于,所述根据所述第一指标数据和所述第二指标数据确定所述Kubernetes平台的健康度,包括:
获取所述第一指标数据的第一权重系数和所述第二指标数据的第二权重系数;
根据所述第一指标数据、所述第二指标数据、所述第一权重系数和所述第二权重系数确定所述Kubernetes平台的健康度。
4.根据权利要求1所述的方法,其特征在于,所述方法还包括:
根据所述指令获取其他指标数据,所述其他指标数据包括所述Kubernetes平台的基础资源对应的第三指标数据、所述Kubernetes平台的节点主机对应的第四指标数据和所述Kubernetes平台的安全事件对应的第五指标数据中的一个或多个;
所述根据所述第一指标数据和所述第二指标数据确定所述Kubernetes平台的健康度,包括:
根据所述第一指标数据、所述第二指标数据和所述其他指标数据确定所述Kubernetes平台的健康度。
5.根据权利要求4所述的方法,其特征在于,所述第三指标数据包括集群维度中央处理器利用率、集群维度内存利用率、集群维度文件系统利用率和集群维度网络带宽利用率中的一个或多个;
第四指标数据包括节点在线状态、网络代理组件状态、节点主机中央处理器利用率、节点主机内存利用率、节点主机文件系统利用率和文件索引节点利用率中的一个或多个;
第五数据指标包括集群主节点日志信息、集群节点日志信息和集群应用安全日志信息中的一个或多个。
6.根据权利要求4所述的方法,其特征在于,所述根据所述第一指标数据、所述第二指标数据和所述其他指标数据确定所述Kubernetes平台的健康度,包括:
获取所述第一指标数据的第一权重系数、所述第二指标数据的第二权重系数和所述其他指标数据分别对应的权重系数;
根据所述第一指标数据、所述第二指标数据、所述其他指标数据、所述第一权重系数、所述第二权重系数和所述其他指标数据分别对应的权重系数确定所述Kubernetes平台的健康度。
7.根据权利要求1所述的方法,其特征在于,所述根据所述指令获取所述Kubernetes平台的核心组件对应的第一指标数据和所述Kubernetes平台的工作负载对应的第二指标数据,包括:
根据所述指令确定所述Kubernetes平台的核心组件对应的第一历史数据集合和所述Kubernetes平台的工作负载对应的第二历史数据集合;
将所述第一历史数据集合中距离当前时刻最近的数据确定为第一指标数据,将所述第二历史数据集合中距离所述当前时刻最近的数据确定为第二指标数据。
8.根据权利要求1所述的方法,其特征在于,所述Kubernetes平台的健康度分为五个等级,分别为不健康状态、亚健康状态、较好状态、良好状态和优异状态。
9.根据权利要求1-8任意一项所述的方法,其特征在于,所述方法还包括:
展示所述Kubernetes平台的健康度。
10.一种基于云原生的Kubernetes平台健康度确定装置,其特征在于,所述装置包括:接收单元、获取单元和确定单元;
所述接收单元,用于接收确定所述Kubernetes平台的健康度的指令;
所述获取单元,用于根据所述指令获取所述Kubernetes平台的核心组件对应的第一指标数据和所述Kubernetes平台的工作负载对应的第二指标数据;
所述确定单元,用于根据所述第一指标数据和所述第二指标数据确定所述Kubernetes平台的健康度。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111322081.3A CN114003345A (zh) | 2021-11-09 | 2021-11-09 | 一种基于云原生的Kubernetes平台健康度确定方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111322081.3A CN114003345A (zh) | 2021-11-09 | 2021-11-09 | 一种基于云原生的Kubernetes平台健康度确定方法和装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114003345A true CN114003345A (zh) | 2022-02-01 |
Family
ID=79928435
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111322081.3A Pending CN114003345A (zh) | 2021-11-09 | 2021-11-09 | 一种基于云原生的Kubernetes平台健康度确定方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114003345A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114911683A (zh) * | 2022-06-21 | 2022-08-16 | 北京同创永益科技发展有限公司 | 一种Kubernetes平台健康度的评测方法 |
CN116939032A (zh) * | 2023-07-26 | 2023-10-24 | 中航信移动科技有限公司 | 一种微服务调用方法、电子设备及存储介质 |
-
2021
- 2021-11-09 CN CN202111322081.3A patent/CN114003345A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114911683A (zh) * | 2022-06-21 | 2022-08-16 | 北京同创永益科技发展有限公司 | 一种Kubernetes平台健康度的评测方法 |
CN116939032A (zh) * | 2023-07-26 | 2023-10-24 | 中航信移动科技有限公司 | 一种微服务调用方法、电子设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108874640B (zh) | 一种集群性能的评估方法和装置 | |
US11755452B2 (en) | Log data collection method based on log data generated by container in application container environment, log data collection device, storage medium, and log data collection system | |
CN107832153B (zh) | 一种Hadoop集群资源自适应分配方法 | |
Chaczko et al. | Availability and load balancing in cloud computing | |
US10819603B2 (en) | Performance evaluation method, apparatus for performance evaluation, and non-transitory computer-readable storage medium for storing program | |
US7882216B2 (en) | Process and methodology for generic analysis of metrics related to resource utilization and performance | |
US10783002B1 (en) | Cost determination of a service call | |
Rezaeipanah et al. | Providing a new approach to increase fault tolerance in cloud computing using fuzzy logic | |
WO2019153487A1 (zh) | 系统性能的度量方法、装置、存储介质和服务器 | |
Li et al. | SparkBench: a spark benchmarking suite characterizing large-scale in-memory data analytics | |
CN114003345A (zh) | 一种基于云原生的Kubernetes平台健康度确定方法和装置 | |
CN105700948A (zh) | 一种用于在集群中调度计算任务的方法与设备 | |
CN107515784B (zh) | 一种在分布式系统中计算资源的方法与设备 | |
EP2745248A1 (en) | System and method for determining and visualizing efficiencies and risks in computing environments | |
Javadpour et al. | Improving load balancing for data-duplication in big data cloud computing networks | |
CN104182278B (zh) | 一种判定计算机硬件资源繁忙程度的方法和装置 | |
CN111124830B (zh) | 一种微服务的监控方法及装置 | |
Farias et al. | Regression based performance modeling and provisioning for NoSQL cloud databases | |
CN102187327A (zh) | 趋势确定和识别 | |
Gupta et al. | Long range dependence in cloud servers: a statistical analysis based on google workload trace | |
CN115080373A (zh) | 配电终端操作系统的性能检测方法、装置、设备及介质 | |
CN104735063B (zh) | 一种用于云基础设施的安全评测方法 | |
US9501321B1 (en) | Weighted service requests throttling | |
CN112000657A (zh) | 数据管理方法、装置、服务器及存储介质 | |
FR3103663A1 (fr) | Tests et maintien d’une résilience face aux pannes des ressources de serveur |
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 |