一种集群巡检方法、装置、设备及可读存储介质与流程

本发明涉及计算机应用技术领域，特别是涉及一种集群巡检方法、装置、设备及可读存储介质。

背景技术：

随着云原生应用架构的不断升级和完善，越来越多的项目开始基于k8s集群来部署搭建。k8s集群及其下创建的应用、资源的配置部署和调优是比较复杂的，需要比较高的技术水平和完善的k8s知识体系，而大多数人对于k8s只是停留在会用的层面上，对于k8s的参数配置和性能调优知之甚少。

而k8s集群中的应用出现问题的原因，大多都可以通过合理配置来避免。想要所有应用的负责人都能精通k8s的参数配置及调优技巧显然是不现实的。这就造成了一种恶性循环，即负责具体应用的团队简单粗暴的在k8s集群中创建应用，等出了问题又解决不了时，再联系k8s运维人员帮忙配置调优，不仅没有提高效率，反而付出了大量的运维成本。

目前，基于配置文件的k8s集群一键巡检方法，可实现自动化一键巡检。但是，其巡检引擎的灵活性受到了配置文件的固定格式的限制，例如，遇到稍微特别一些的检查项时，原有的配置文件格式就会不满足实际需要。此时，就需要调整配置文件的格式。而配置文件的格式一旦变动，就意味着配置文件的解析程序也需要对应修改，以便于支持新配置文件格式；相应地，之前已经配置好的各个配置文件，也需要做相应的变动来支持新的文件格式。这就导致，基于配置文件的k8s集群一键巡检方法，不仅没有节省工作量，反而带来了大量的额外工作量。

综上所述，如何有效地解决k8s集群的巡检等问题，是目前本领域技术人员急需解决的技术问题。

技术实现要素：

本发明的目的是提供一种集群巡检方法、装置、设备及可读存储介质，利用groovy脚本对k8s集群进行巡检，由于groovy脚本本身即jvm语言，可以直接由java代码进行执行，因而基于groovy脚本进行巡检，则无需配置文件，也就省去了对配置文件的格式进行校验、对配置文件进行解析等环节，能够显著降低巡检工作量。

为解决上述技术问题，本发明提供如下技术方案：

一种集群巡检方法，包括：

k8s集群的容器编排引擎接收巡检请求；

利用groovy脚本，对所述k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细；所述groovy脚本包括各个待检查的检查项和对应的检测命令。

优选地，还包括：

利用所述资源巡检结果明细，对所述k8s集群进行资源配置。

优选地，所述利用所述资源巡检结果明细，对所述k8s集群的进行资源配置，包括：

获取资源配置规划明细；

将所述资源巡检结果明细与所述资源配置规划明细进行比对，得到差异内容；

利用所述差异内容，调整所述k8s集群的配置。

优选地，所述利用groovy脚本，对所述k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细，包括：

执行所述groovy脚本中的各个所述检测命令，分别对各个所述检查项进行检查，得到各个所述检查项分别对应的资源巡检结果；所述资源巡检结果包括字符串信息、数据内容和判别结果；

将各个所述资源巡检结果确定为所述资源巡检结果明细。

优选地，还包括：

获取新groovy脚本；所述新groovy脚本的新检查项与所述groovy脚本的检查项具有区别；

执行所述新groovy脚本对所述k8s资源进行巡检，得到新资源巡检结果明细。

优选地，所述利用groovy脚本，对所述k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细，包括：

利用所述groovy脚本，对所述k8s集群的资源分配、网络配置、安全配置、镜像和健康状态中的至少一项所述k8s资源进行监控巡检，得到所述资源巡检结果明细。

优选地，所述k8s集群的容器编排引擎接收巡检请求，包括：

所述容器编排引擎对巡检键进行监控；

在检测到所述巡检键被触发的情况下，确定接收到所述巡检请求。

一种集群巡检装置，应用于k8s集群的容器编排引擎，包括：

巡检请求接收模块，用于接收巡检请求；

巡检模块，用于利用groovy脚本，对所述k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细；所述groovy脚本包括各个待检查的检查项和对应的检测命令。

一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现上述集群巡检方法的步骤。

一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述集群巡检方法的步骤。

应用本发明实施例所提供的方法，k8s集群的容器编排引擎接收巡检请求；利用groovy脚本，对k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细；groovy脚本包括各个待检查的检查项和对应的检测命令。

在本方法中，在k8s集群的容器编排引擎接收到巡检请求之后，便可直接利用包括了各个待检查检查项和对应检测命令的groovy脚本，对k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细。由于groovy脚本本身即jvm语言，可以直接由java代码进行执行，因而基于groovy脚本进行巡检，则无需配置文件，也就省去了对配置文件的格式进行校验、对配置文件进行解析等环节，能够显著降低巡检工作量。

相应地，本发明实施例还提供了与上述集群巡检方法相对应的集群巡检装置、设备和可读存储介质，具有上述技术效果，在此不再赘述。

附图说明

为了更清楚地说明本发明实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例中一种集群巡检方法的实施流程图；

图2为本发明实施例中一种集群巡检装置的结构示意图；

图3为本发明实施例中一种电子设备的结构示意图；

图4为本发明实施例中一种电子设备的具体结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面结合附图和具体实施方式对本发明作进一步的详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参考图1，图1为本发明实施例中一种集群巡检方法的流程图，该方法包括以下步骤：

s101、k8s集群的容器编排引擎接收巡检请求。

容器编排引擎(kubernetes，k8s)，一种为容器服务而生的一个可移植容器的编排管理工具。

k8s集群即基于kubernetesapi对象来描述集群的预期状态(desiredstate)：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。在k8s集群中包括管理节点(kubernetesmaster)，工作节点(kubernetesnode)。对于k8s集群的其他细节内容可具体参考k8s的相关定义和实现，在此不再一一说明。

该巡检请求可具体为用户可操作界面所产生的，也可以为其他应用产生并发送的。

在本发明的一种具体实施方式中，步骤s101k8s集群的容器编排引擎接收巡检请求，包括：

步骤一、容器编排引擎对巡检键进行监控；

步骤二、在检测到巡检键被触发的情况下，确定接收到巡检请求。

为便于描述，下面将上述两个步骤结合起来进行说明。

在本实施例中，可在用户可操作界面设置一个巡检键，以便一键启动巡检操作。容器编排引擎可对巡检键进行监控，在检测到巡检键被触发的情况下，可认定接收到该巡检请求。其中，巡检键被触发可以具体为光标长时停留在巡检键上，也可以该巡检键被点击(单击或双击)，还可以为该巡检键被长按。

在本发明实施例中，当k8s集群的容器编排引擎接收到巡检请求之后，便可确定要对k8s集群的k8s资源进行巡检，即可执行步骤s102。

s102、利用groovy脚本，对k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细。

其中，groovy脚本包括各个待检查的检查项和对应的检测命令。

groovy是一种基于jvm(java虚拟机)的敏捷开发语言，它结合了python、ruby和smalltalk的相关特性，groovy代码能够与java代码很好地结合，也能用于扩展现有代码。由于其运行在jvm上的特性，groovy也可以使用其他非java语言编写的库。也就是说，由于groovy脚本本身即jvm语言，可以直接由java代码进行执行，因而基于groovy脚本进行巡检，则无需配置文件。

具体的，该groovy脚本中可以具体包括各个待检出的配置检查项以及检查每个配置检查项所对应的检测命令。由于groovy本身是基于jvm的脚本语言，所以可以像写业务功能代码一样去写检测逻辑的过程，没有内容格式的限制。只要业务需要，可以任意书写和修改脚本内容来满足实际的需求。

具体的，利用groovy脚本，即执行groovy脚本，从而实现对k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细。

在本发明的一种具体实施例方式中，步骤s102利用groovy脚本，对k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细，包括：

步骤一、执行groovy脚本中的各个检测命令，分别对各个检查项进行检查，得到各个检查项分别对应的资源巡检结果；资源巡检结果包括字符串信息、数据内容和判别结果；

步骤二、将各个资源巡检结果确定为资源巡检结果明细。

为便于描述，下面将上述两个步骤结合起来进行说明。

在本实施例中，可基于java来执行groovy脚本中的各个检测命令，从而分别对各个检查项进行检测，然后得到各个检查项的资源巡检结果。需要注意的是，由于groovy脚本可以自定义返回对象，所以可以返回任意内容，比如返回结果中既包含检测结果成功与否、又包含检测明细、还包含修改建议等等。因而，该资源检测结果可以包括字符串信息、数据内容和判别结果。

得到各个检查项对应的资源巡检结果之后，便可将各个资源巡检结果确定为资源巡检结果明细。相较于基于配置文件检测方法，只能得到检测结果是成功还是失败，本发明实施例中，进行巡检所得到的资源巡检结果明细的内容更加丰富。

在本发明的一种具体实施方式中，步骤s102利用groovy脚本，对k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细，包括：利用groovy脚本，对k8s集群的资源分配、网络配置、安全配置、镜像和健康状态中的至少一项k8s资源进行监控巡检，得到资源巡检结果明细。也就是说，k8s资源可以分类为资源分配、网络配置、安全配置、镜像和健康状态，而每一个分类可以对应不同的检查项。

举例说明，对于资源分配，对应的检查项可以具体包括cpulimitsmissing，cpurequestsmissing，memorylimitsmissing，memoryrequestsmissing；对于网络配置，对应的检查项可以具体包括hostnetworkset，hostportset；对于安全配置，对应的检查项可以具体包括：hostipcset，hostpidset，notreadonlyrootfilesystem，privilegeescalationallowed，dangerouscapabilities，insecurecapabilities，runasprivileged，runasrootallowed；对于镜像检查，对应的检查项可以包括tagnotspecified，pullpolicynotalways；对于健康检查，对应的检查项可以包括livenessprobemissing，readinessprobemissing。

在本发明的一种具体实施方式中，在巡检情况发生变化之后，可基于新的巡检需求修改groovy脚本或重新编写groovy脚本，进而基于新groovy脚本进行巡检。具体的实现过程包括：

步骤一、获取新groovy脚本；新groovy脚本的新检查项与groovy脚本的检查项具有区别；

步骤二、执行新groovy脚本对k8s资源进行巡检，得到新资源巡检结果明细。

由于groovy脚本不需要配置文件，也不需要对配置文件的格式进行校验，更不需要对配置文件进行解析。groovy脚本本身即可以进行类似业务功能代码一样去写检测逻辑，因而当检测需求有变化时，可仅需重新groovy脚本或修改groovy脚本，得到与原来的groovy脚本的检查项具有区别的新检查项的新groovy脚本即可。其中，新检查项与原有检查项的区别可以具体为数量上的区别，种类上的区别，该区别由检测需求而定。

在本发明的一种具体实施方式中，在得到资源巡检明细结果之后，还可以利用资源巡检结果明细，对k8s集群的进行资源配置。具体的，对k8s集群进行资源配置可以具体为对未配置的内容进行配置，或对已有的配置进行修改、补充(完善)。具体的对资源进行配置的方式可具体参见配置详细说明。

由于，资源巡检结果明细中可具体包括资源的检测结果以及当前的状态情况或配置情况，因而基于资源巡检结果明细与预期情况进行比对，从而确定出需要进行完善的配置内容。

具体的实现过程包括：

步骤一、获取资源配置规划明细；

步骤二、将资源巡检结果明细与资源配置规划明细进行比对，得到差异内容；

步骤三、利用差异内容，调整k8s集群的配置。

在本发明实施例中，可预先设置一个资源配置规划明细，在获取到资源巡检结果明细之后，便可将资源巡检结果明细与资源配置规划明细进行比对，得到差异内容。该差异内容即配置存在错误的内容。如此，便可基于该差异内容对k8s集群的配置进行调整。例如，某个工作节点的资源分配过多，则针对工作节点进行部分资源回收；工作节点数量未达标，则新创建若干个工作节点。

应用本发明实施例所提供的方法，k8s集群的容器编排引擎接收巡检请求；利用groovy脚本，对k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细；groovy脚本包括各个待检查的检查项和对应的检测命令。

在本方法中，在k8s集群的容器编排引擎接收到巡检请求之后，便可直接利用包括了各个待检查检查项和对应检测命令的groovy脚本，对k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细。由于groovy脚本本身即jvm语言，可以直接由java代码进行执行，因而基于groovy脚本进行巡检，则无需配置文件，也就省去了对配置文件的格式进行校验、对配置文件进行解析等环节，能够显著降低巡检工作量。

为便于本领域技术人员更好地理解本发明实施例所提供的集群巡检方法，下面结合具体的检查项的具体情况对集群巡检方法进行详细说明。

在实际应用中，对于不同的检查项进行检查，对于检测不通过的情况可进行分级处理，级别划分为告警和错误。同时还可以对应不同检查项输出不同的检查不通过提示语。对于不同的检查项也有对应不同的检测过程。下面举例说明：

cpulimitsmissing，级别为：警告；检查不通过提示语：建议配置cpu最大申请值(cpulimits)；检测过程：spec.template.spec.containers(array,排除initcontainer).resources.limits.cpu：必须配置，且不允许为空；

cpurequestsmissing，级别为：警告；检查不通过提示语：建议配置cpu最小申请值(cpulimits)；检测过程：spec.template.spec.containers(array,排除initcontainer).resources.requests.cpu：必须配置，且不允许为空。

memorylimitsmissing，级别为警告；检查不通过提示语：建议配置内存最大申请值(memorylimits)；检测过程：spec.template.spec.containers(array,排除initcontainer).resources.limits.memory：必须配置，且不允许为空。

memoryrequestsmissing，级别为：警告；检查不通过提示语：建议配置内存最小申请值(memoryrequests)；检测过程：spec.template.spec.containers(array,排除initcontainer).resources.requests.memory：必须配置，且不允许为空。

hostnetworkset，级别为：警告；检查不通过提示语：不建议配置主机网络(hostnetwork)；检测过程：spec.template.spec.hostnetwork：可以不配置，如果配置的话只能配置为false。

hostportset，级别为：警告；检查不通过提示语：不建议配置主机端口(hostport)；检测过程：spec.template.spec.containers(array).ports(array).hostport:可以不配置，如果配置的话只能配置为0。

hostipcset，级别为：错误；检查不通过提示语：不允许配置主机进程间通信(hostipc)；检测过程：spec.template.spec.hostipc：可以不配置，如果配置的话只能配置为false。

hostpidset，级别为：错误；检查不通过提示语：不允许配置主机进程id(hostpid)；检测过程：spec.template.spec.hostpid：可以不配置，如果配置的话只能配置为false。

notreadonlyrootfilesystem，级别为：警告；检查不通过提示语：建议root文件系统配置为只读；检测过程：spec.template.spec.containers(array).securitycontext.readonlyrootfilesystem：可以不配置，如果配置的话只能配置为true。

privilegeescalationallowed，级别为：错误；检查不通过提示语：不允许提升容器用户权限；检测过程：spec.template.spec.containers(array).securitycontext.allowprivilegeescalation：可以不配置，如果配置的话只能配置为false。

dangerouscapabilities，级别为：错误；检查不通过提示语：不建议配置危险的linux能力；检测过程：spec.template.spec.containers(array).securitycontext.capabilities.add：可以不配置，如果配置的话则不允许有all、sys_admin、net_admin。

insecurecapabilities，级别为：警告；检查不通过提示语：不建议配置不安全的linux能力；检测过程：spec.template.spec.containers(array).securitycontext.capabilities.add：可以不配置，如果配置的话，则只允许有chown、dac_override、fsetid、fowner、mknod、net_raw、setgid、setuid、setfcap、setpcap、net_bind_service、sys_chroot、kill、audit_write中的一个或多个。

runasprivileged，级别为：警告；检查不通过提示语：不建议配置特权模式；检测过程：spec.template.spec.containers(array).securitycontext.privileged：可以不配置，如果配置的话只能配置为false。

runasrootallowed，级别为：警告；检查不通过提示语：不建议以root用户组权限运行容器；检测过程："spec.template.spec.securitycontext.runasuser(array)：至少配置一个uid，spec.template.spec.securitycontext.runasnonroot：必须为true，spec.template.spec.containers(array).securitycontext.runasuser(array)：至少配置一个uid，spec.template.spec.containers(array).securitycontext.runasnonroot：必须为true，container中的配置会覆盖pod层的配置，最终结果以叠加后的实际效果为准"。

tagnotspecified，级别为：警告；检查不通过提示语：容器镜像版本不允许设置为空或latest；检测过程：spec.template.spec.containers(array).image：必须配置，且必须指定具体版本，且版本不允许是latest。

pullpolicynotalways，级别为：警告；检查不通过提示语：建议镜像拉取策略设置为ifnotpresent；检测过程：spec.template.spec.containers(array).imagepullpolicy：必须配置，且必须配置成ifnotpresent。

livenessprobemissing，级别为：警告；检查不通过提示语：建议配置存活探针(livenessprobe)；检测过程：spec.template.spec.containers(array,排除initcontainer).livenessprobe：必须配置，且不允许为空。

readinessprobemissing，级别为：警告；检查不通过提示语：建议配置就绪探针(readinessprobe)；检测过程：spec.template.spec.containers(array,排除initcontainer).readinessprobe：必须配置，且不允许为空。

相应于上面的方法实施例，本发明实施例还提供了一种可应用于k8s集群的容器编排引擎的集群巡检装置，下文描述的集群巡检装置与上文描述的集群巡检方法可相互对应参照。

参见图2示，该装置包括以下模块：

巡检请求接收模块101，用于接收巡检请求；

巡检模块102，用于利用groovy脚本，对k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细；groovy脚本包括各个待检查的检查项和对应的检测命令。

应用本发明实施例所提供的装置，k8s集群的容器编排引擎接收巡检请求；利用groovy脚本，对k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细；groovy脚本包括各个待检查的检查项和对应的检测命令。

在本装置中，在k8s集群的容器编排引擎接收到巡检请求之后，便可直接利用包括了各个待检查检查项和对应检测命令的groovy脚本，对k8s集群对应的k8s资源进行巡检，得到资源巡检结果明细。由于groovy脚本本身即jvm语言，可以直接由java代码进行执行，因而基于groovy脚本进行巡检，则无需配置文件，也就省去了对配置文件的格式进行校验、对配置文件进行解析等环节，能够显著降低巡检工作量。

在本发明的一种具体实施方式中，还包括：资源配置模块，用于利用资源巡检结果明细，对k8s集群进行资源配置。

在本发明的一种具体实施方式中，资源配置模块，具体用于获取资源配置规划明细；将资源巡检结果明细与资源配置规划明细进行比对，得到差异内容；利用差异内容，调整k8s集群的配置。

在本发明的一种具体实施方式中，巡检模块102，具体用于执行groovy脚本中的各个检测命令，分别对各个检查项进行检查，得到各个检查项分别对应的资源巡检结果；资源巡检结果包括字符串信息、数据内容和判别结果；将各个资源巡检结果确定为资源巡检结果明细。

在本发明的一种具体实施方式中，还包括：

巡检模块102，还用于获取新groovy脚本；新groovy脚本的新检查项与groovy脚本的检查项具有区别；执行新groovy脚本对k8s资源进行巡检，得到新资源巡检结果明细。

在本发明的一种具体实施方式中，巡检请求接收模块101，具体用于容器编排引擎对巡检键进行监控；在检测到巡检键被触发的情况下，确定接收到巡检请求。

在本发明的一种具体实施方式中，巡检模块102，具体用于利用groovy脚本，对k8s集群的资源分配、网络配置、安全配置、镜像和健康状态中的至少一项k8s资源进行监控巡检，得到资源巡检结果明细。

相应于上面的方法实施例，本发明实施例还提供了一种电子设备，下文描述的一种电子设备与上文描述的一种集群巡检方法可相互对应参照。

参见图3示，该电子设备包括：

存储器332，用于存储计算机程序；

处理器322，用于执行计算机程序时实现上述方法实施例的集群巡检方法的步骤。

具体的，请参考图4，图4为本发明实施例提供的一种电子设备的具体结构示意图，该电子设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessingunits，cpu)322(例如，一个或一个以上处理器)和存储器332，存储器332存储有一个或一个以上的计算机应用程序342或数据344。其中，存储器332可以是短暂存储或持久存储。存储在存储器332的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对数据处理设备中的一系列指令操作。更进一步地，中央处理器322可以设置为与存储器332通信，在电子设备301上执行存储器332中的一系列指令操作。

电子设备301还可以包括一个或一个以上电源326，一个或一个以上有线或无线网络接口350，一个或一个以上输入输出接口358，和/或，一个或一个以上操作系统341。

上文所描述的集群巡检方法中的步骤可以由电子设备的结构实现。

相应于上面的方法实施例，本发明实施例还提供了一种可读存储介质，下文描述的一种可读存储介质与上文描述的一种集群巡检方法可相互对应参照。

一种可读存储介质，可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例的集群巡检方法的步骤。

该可读存储介质具体可以为u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可存储程序代码的可读存储介质。

本领域技术人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。