Kubernetes集群的运维处理方法、装置及电子设备与流程

kubernetes集群的运维处理方法、装置及电子设备
技术领域
1.本技术涉及通信技术领域，尤其涉及一种kubernetes集群的运维处理方法、装置及电子设备。


背景技术：

2.kubernetes集群是一种常用的管理跨宿主机容器集群的容器编排工具，其构建在docker容器之上，租户可以在kubernetes集群上创建和管理docker容器，并为容器化的应用集群提供了大规模运行容器的编排系统和管理平台。由于kubernetes集群容易遭受来自黑客和内部人员安全管控疏漏导致的恶意攻击、数据窃取、服务中断等诸多问题。因此，对kubernetes集群进行监控极为重要。
3.目前对于kubernetes集群的监控，主要借助外部agent技术实现。然而，由于kubernetes集群的安全保障机制限制，如果要在kubernetes集群外部通过agent代理工具对kubernetes集群进行监控，就需要提前加载kubeconfig等认证文件，之后才能完成对kubernetes集群中的api(application programming interface，应用程序接口)服务器的访问，这样，就使得黑客很容易通过攻击代理工具来获取到kubeconfig认证文件，从而进行更具破坏性的行为；如果将代理工具集成在kubernetes集群的原生代码中以避免加载认证文件，又会造成kubernetes集群的开发难度大、升级难度高以及高度耦合等问题。


技术实现要素：

4.本技术实施例的目的是提供一种kubernetes集群的运维处理方法、装置及电子设备，以解决通过现有的依靠外部代理工具对kubernetes集群进行监控方法存在的可靠性低、开发难度、升级难度高以及高度耦合等问题。
5.为了解决上述技术问题，本技术实施例采用下述技术方案：
6.第一方面，本技术实施例提供了一种kubernetes集群的运维处理方法，所述kubernetes集群包括多个节点，所述方法包括：
7.通过部署于所述节点的pod中的安全监控应用，获取所述节点中指定组件的运行相关参数；
8.基于设定的异常分析策略对所述节点中指定组件的运行相关参数进行分析，以得到所述节点的异常分析结果；
9.以与所述kubernetes集群中节点的异常分析结果匹配的运维策略对所述kubernetes集群进行运维处理。
10.可选地，所述异常分析策略包括互联网安全中心cis安全基准和评分基准，所述评分基准包括所述cis安全基准中不同安全指标的检测结果与安全分值之间的对应关系；
11.基于设定的异常分析策略对所述节点中指定组件的运行相关参数进行分析，以得到所述节点的异常分析结果，包括：
12.基于所述cis安全基准和所述节点中指定组件的运行相关参数，确定所述指定组
件的各项安全指标对应的检测结果；
13.基于所述指定组件的各项安全指标对应的检测结果和所述评分基准，确定所述指定组件的安全分值；
14.基于所述指定组件的安全分值确定所述节点的安全分值。
15.可选地，以与所述kubernetes集群中节点的异常分析结果匹配的运维策略对所述kubernetes集群进行运维处理，包括：
16.在所述节点的安全分值小于第一设定分值的情况下，获取所述节点中安全分值小于第二设定分值的指定组件，作为待优化的目标组件；
17.基于所述目标组件的各项安全指标的检测结果，确定与所述kubernetes集群匹配的运维策略；
18.基于所述匹配的运维策略对所述kubernetes集群进行运维处理。
19.可选地，在通过部署于所述节点的pod中的安全监控应用，获取所述节点中指定组件的运行相关参数之前，所述方法还包括：
20.接收来自监控方的监控任务部署请求，所述监控任务部署请求中携带有待部署的安全监控应用的配置信息；
21.查询任务调配库中是否存在所述待部署的安全监控应用，所述任务调配库中记录有已部署的安全监控应用；
22.若所述任务调配库中不存在所述待部署的安全监控应用，则基于所述待部署的安全监控应用的配置信息在所述节点的pod中创建所述待部署的安全监控应用。
23.可选地，所述监控任务部署请求中还携带允许访问所述kubernetes集群的用户的身份信息及对应的访问权限信息；
24.在基于所述待部署的安全监控应用的配置信息在所述节点的pod中创建所述待部署的安全监控应用之后，所述方法还包括：
25.基于所述用户的身份信息及对应的访问权限信息，在所述kubernetes集群的应用程序接口api服务器中配置针对所述kubernetes集群的授权策略，所述授权策略用于对访问所述kubernetes集群的用户进行鉴权。
26.可选地，在通过部署于所述节点的pod中的安全监控应用，获取所述节点中指定组件的运行相关参数之后，所述方法还包括：
27.基于blowfish算法对所述节点中指定组件的运行相关参数进行加密。
28.第二方面，本技术实施例还提供了一种kubernetes集群的运维处理装置，所述kubernetes集群包括多个节点，所述装置包括所述装置包括组件安全评估层和自愈方案实施层；
29.所述组件安全评估层，用于通过部署于所述节点的pod中的安全监控应用，获取所述节点中指定组件的运行相关参数，基于设定的异常分析策略对所述节点中指定组件的运行相关参数进行分析，以得到所述节点的异常分析结果；
30.所述自愈方案实施层，用于以与所述kubernetes集群中节点的异常分析结果匹配的运维策略对所述kubernetes集群进行运维处理。
31.可选地，所述装置还包括任务调配层，所述任务调配层用于：
32.接收来自监控方的监控任务部署请求，所述监控任务部署请求中携带有待部署的
安全监控应用的配置信息；
33.查询任务调配库中是否存在所述待部署的安全监控应用，所述任务调配库中记录有已部署的安全监控应用；
34.若所述任务调配库中不存在所述待部署的安全监控应用，则基于所述待部署的安全监控应用的配置信息在所述节点的pod中创建所述待部署的安全监控应用。
35.第三方面，本技术实施例还提供了一种电子设备，包括：
36.处理器；
37.用于存储所述处理器可执行指令的存储器；
38.其中，所述处理器被配置为执行所述指令，以实现第一方面所述的方法。
39.第四方面本技术实施例还提供了一种计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备够执行第一方面所述的方法。
40.本技术实施例采用的上述至少一个技术方案能够达到以下有益效果：
41.通过本技术实施例提供的kubernetes集群的运维处理方法，通过以微服务的形式，在kubernetes集群的节点的pod中部署安全监控应用，使得安全监控应用可以以kubernetes集群中service服务的形式运行在kubernetes集群的节点中，以获取kubernetes集群的节点中指定组件的运行相关参数，进一步基于获取到的运行相关参数和设定的异常分析策略识别节点是否存在异常，得到节点的异常分析结果，并以与kubernetes集群中节点的异常分析结果匹配的运维策略对kubernetes集群进行运维处理，可以及时发现kubernetes集群中存在的异常并对异常进行处理，事先对kubernetes集群的安全监控，保障kubernetes集群的运行安全。整个方案通过微服务的形式实现，实现逻辑简单，无需借助外部代理工具，避免了外部代理工具被攻击而造成对kubernetes集群的破坏，也避免了将外部代理工具集成在kubernetes集群的原生代码中而造成的kubernetes集群开发难度大、升级难度高以及高度耦合等问题。
附图说明
42.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
43.图1为本技术实施例提供的一种kubernetes集群的架构图；
44.图2为本技术实施例提供的一种kubernetes集群的运维处理方法的流程图；
45.图3为本技术实施例提供的另一种kubernetes集群的运维处理方法的流程图；
46.图4为本技术实施例提供的一种kubernetes集群的运维处理装置的结构示意图；
47.图5为本技术实施例提供的另一种kubernetes集群的运维处理装置的结构示意图；
48.图6为本技术实施例提供的一种电子设备的结构示意图。
具体实施方式
49.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术具体实施例及相应的附图对本技术技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做
出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
50.以下结合附图，详细说明本技术各实施例提供的技术方案。
51.在对本技术实施例提供的kubernetes集群的运维处理方法进行说明之前，首先对本技术实施例涉及的kubernetes集群进行说明。图1是本技术实施例涉及的kubernetes集群的示意图。
52.如图1所示，本技术实施例涉及的kubernetes集群包括多个节点，所有的节点按照功能性质可以分为master控制节点和node工作节点，这些节点可以直接部署在物理机器上，也可以部署在虚拟机中。具体来说，master节点是kubernetes集群的管理控制中心，node节点提供kubernetes集群运行时环境以及维护pod，其中，pod是kubernetes集群中部署的基本单元，一个pod由一个或者多个共享相同网络命名空间和ip地址的容器组成。
53.每个节点包含各自相应的组件来实现相应的功能。具体地，node节点包括kubelet、proxy等组件，其中，kubelet是主要的节点代理，其用于处理master节点和运行该kubelet的node节点之间的所有通信；proxy维护主机上的网络规则，处理在pod、主机和外部世界之间包的传输。
54.master节点可以包括etcd、api server(应用程序接口服务器)、controller manager(控制管理器)以及scheduler(调度器)等组件，其中，etcd是kubernetes集群的存储单元，用于存储kubernetes集群的元数据，以保证kubernetes集群各组件的协同和数据持久；api server用于提供kubernetes集群的api服务；controller manager用于管理节点注册以及容器的副本个数等；scheduler用于调度kubernetes集群的主机资源，如监视新创建没有分配到node节点的pod，为pod选择一个node节点等。
55.由于kubernetes集群容易遭受来自黑客和内部人员安全管控疏漏导致的恶意攻击、数据窃取、服务中断等问题，比如若node节点上的kubelet组件被赋予了不合理的权限或没有制定相应的保护规则，可能造成该组件与master节点的交互通信过程中的信息泄露或者节点失联等，或者，容器在启动过程中，通过申请到的权限对自身和宿主机都会进行一些新的设置，而在这些操作中有一部分并不一定安全合规，可能会对容器或宿主机造成不良影响等，为了实现对kubernetes集群中可能存在的安全隐患提前发现和修复，在一种实施方式中，可以在node节点的pod中部署用于监控kubernetes集群安全隐患的安全监控应用，由于每个服务都是由pod组成，而pod可以包含一个或多个容器，因而通过运行该安全应用程序就能够收集、聚合、处理和导出在node节点中运行的组件的运行相关数据，比如指定组件的配置信息、镜像使用情况、访问secret信息的范围、流量使用情况、运行状态等，进而通过对node节点中组件的运行相关数据进行分析，可以识别kubernetes集群是否存在异常，进而基于kubernetes集群的异常分析结果对kubernetes集群进行运维处理，以保证kubernetes集群的安全。
56.基于图1所示的kubernetes集群，本技术实施例提供一种kubernetes集群的运维处理方法，其中，该方法可应用于电子设备中，该电子设备。请参考图2，图2是本技术实施例提供的一种kubernetes集群的运维处理方法的流程图。如图2所示，该方法包括以下步骤：
57.s22，通过部署于kubernetes集群的节点的pod中的安全监控应用，获取节点中指定组件的运行相关参数。
58.其中，节点中的指定组件可以包括节点中的部分或全部组件，其可以根据实际需
要自定义设置，例如，node节点中的指定组件可以包括kubelet、proxy等组件。
59.指定组件的运行相关参数可以包括指定组件的配置信息、镜像使用情况、访问secret信息的范围、流量使用情况、运行状态等，本技术实施例对此不做具体限定。
60.s24，基于设定的异常分析策略对节点中指定组件的运行相关参数进行分析，以得到节点的异常分析结果。
61.其中，异常分析策略可用于分析节点的运行过程是否存在异常。具体来说，异常分析策略可以包括cis(center for internet security，互联网安全中心)发布的安全基准(以下称为cis安全基准)，例如cis kubernetes benchmark基准文件、cis docker benchmark基准文件等。cis安全基准文件指示了各节点的各个组件的安全指标及安全评估基准，其中，安全指标可以包括但不限于：攻击途径、攻击复杂度、认证、机密性、可用性、完整性等。
62.当然，需要说明的是，异常分析策略还可以是根据实际监控需要设置的任意分析策略，本技术实施例对此不作具体限定。
63.通过设定的异常分析策略对节点中指定组件的运行相关参数进行分析，可以识别节点是否存在异常以及导致异常的具体原因。
64.s26，以与kubernetes集群中各节点的异常分析结果配的运维策略对kubernetes集群进行运维处理。
65.具体实施时，运维策略与各节点的异常原因存在对应关系，也就是说，针对各节点的每一种异常原因，都预先设置有针对该异常原因的维系策略。在确定出kubernetes集群中各节点的异常分析结果后，可基于存在异常的节点及其异常原因确定相应的维系策略，进而基于确定出的维系策略对kubernetes集群进行运维处理。
66.例如，通过上述步骤s24分析得到kubernetes集群中的某个node节点中添加了不必要的组件，则可确定与kubernetes集群匹配的维系策略为删除该不必要的组件，进而可基于该必要的组件的信息对kubernetes集群中该node节点对应的脚本进行调整，以删除该node节点中不必要的组件。
67.需要说明的是，本技术实施例中，kubernetes集群的每一个节点的pod中都可以部署安全监控应用，进而通过运行该安全监控应用可获取各个节点中指定组件的运行相关参数，进一步分析得到各个节点的异常分析结果。
68.通过本技术实施例提供的kubernetes集群的运维处理方法，通过以微服务的形式，在kubernetes集群的节点的pod中部署安全监控应用，使得安全监控应用可以以kubernetes集群中service服务的形式运行在kubernetes集群的节点中，以获取kubernetes集群的节点中指定组件的运行相关参数，进一步基于获取到的运行相关参数和设定的异常分析策略识别节点是否存在异常，得到节点的异常分析结果，并以与kubernetes集群中节点的异常分析结果匹配的运维策略对kubernetes集群进行运维处理，可以及时发现kubernetes集群中存在的异常并对异常进行处理，事先对kubernetes集群的安全监控，保障kubernetes集群的运行安全。整个方案通过微服务的形式实现，实现逻辑简单，无需借助外部代理工具，避免了外部代理工具被攻击而造成对kubernetes集群的破坏，也避免了将外部代理工具集成在kubernetes集群的原生代码中而造成的kubernetes集群开发难度大、升级难度高以及高度耦合等问题。
69.为了使本领域技术人员更加理解本技术实施例提供的技术方案，下面对本技术实施例提供的kubernetes集群的运维处理方法进行详细说明。
70.首先，针对上述步骤s24，为了实现对kubernetes集群的节点运行情况进行全面、准确的分析，在较为优选的方案中，本技术实施例中的异常分析策略可以包括cis(center for internet security，互联网安全中心)发布的安全基准(以下称为cis安全基准)，例如cis kubernetes benchmark基准文件、cis docker benchmark基准文件等。cis安全基准文件指示了各节点的各个组件的安全指标及安全评估基准，其中，安全指标可以包括但不限于：攻击途径、攻击复杂度、认证、机密性、可用性、完整性等。
71.具体实施时，对于kubernetes集群的每一节点而言，基于cis安全基准文件和该节点的各指定组件的运行相关数据，对各指定组件的各项安全指标进行分析，得到各指定组件的各项安全指标对应的检测结果，其中，各项安全指标对应的检测结果用于指示各项安全指标是否存在异常。进一步地，对于每一节点而言，可根据该节点中指定组件的各项指标对应的检测结果生成该节点的异常分析结果。例如，若该节点中所有指定组件的各项指标对应的检测结果均为正常，则可确定该节点运行正常，不存在安全风险；若该节点中指定组件的部分或全部安全指标对应的检测结果为异常，则可确定该节点运行异常，进一步可根据输出指定组件中检测结果为异常的安全指标及指定组件的运行相关数据，以便运维人员能够进一步分析得到导致kubernetes集群中节点运行异常的原因。
72.在更为优选的方案中，本技术实施例中的异常分析策略可以包括cis安全基准和评分基准，其中，评分基准包括cis安全基准中不同安全指标的检测结果与安全分值之间的对应关系。例如，表1示出了一种评分基准的示例。
73.表1
74.安全指标检测结果安全分值攻击途径本地/远程0.7/1.0攻击复杂度高/中/低0.6/0.8/1.0认证需要/不需要0.6/1.0机密性不受影响/部分/完全0/0.7/1可用性不受影响/部分/完全0/0.7/1完整性不受影响/部分/完全0/0.7/1
………………
75.相应地，在上述步骤s24中，可基于cis安全基准和节点中指定组件的运行相关参数，确定指定组件的各项安全指标对应的检测结果，并基于指定组件的各项安全指标对应的检测结果和评分基准，确定指定组件的安全分值，进一步基于指定组件的安全分值确定节点的安全分值。
76.具体来说，在确定指定组件的安全分值时，可将各项安全指标的检测结果对应的安全分值的加权和，作为指定组件的安全分值；或者，也可以根据实际需要确定指定组件的安全分值。例如，以上述表1所示的评分基准为例，指定组件的安全分值可通过下述公式(1)确定。
77.f＝10
×
攻击途径
×
攻击复杂度
×
认证+机密性
×
机密性权重+完整性
×
完整性权重+可用性
×
可用性权重(1)
78.进一步地，节点的安全分值可通过下述公式(2)确定。
[0079][0080]
其中，tscore表示节点的安全分值；fi表示第i个指定组件的安全分值；vi表示第i个指定组件的检测结果，其中，若第i个指定组件的检测结果为通过，则vi＝1，否则，则vi＝0；z表示指定组件的数量。
[0081]
可以理解，通过该方案可以对节点的运行安全情况及节点中指定组件的运行安全情况的定量评估，使得运维人员能够清晰准确地获知kubernetes集群的运行情况。
[0082]
由于节点的安全分值反映了指定节点的安全性高低，节点的安全分值越低，则表明节点的安全性越低，因而可针对节点设置一分值(以下称为“第一预定分值”)，在节点的安全分值小于该第一预定分值的情况下，可认为节点存在异常，进而可采取相应的运维策略对kubernetes集群进行运维处理。其中，第一设定分值可根据实际需要自定义设置。另外，需要说明的是，可针对kubernetes集群中不同的节点设置不同的第一设定分值，或者，也可以针对kubernetes集群中所有的节点设置相同的第一设定分值，本技术实施例对第一设定分值的设置方式不做具体限定。
[0083]
由于指定组件的安全分值反映了指定组件的安全性高低，指定组件的安全分值越低，则表明指定组件的安全性越低，因而可针对指定组件设置一分值(以下称为“第二预定分值”)，在指定组件的安全分值小于该第二预定分值的情况下，可认为指定组件存在异常，进而可根据存在异常的指定组件的检测结果对kubernetes集群进行运维处理。其中，第二设定分值可根据实际需要自定义设置。另外，需要说明的是，第二设定分值可以与第一设定分值相同，也可以与第一设定分值不同，并且，可针对节点中不同的指定组件设置不同的第二设定分值，或者，也可以针对节点中所有的指定组件设置相同的第二设定分值，本技术实施例对第二设定分值的设置方式不做具体限定。
[0084]
相应地，上述步骤s26可以包括：在所述节点的安全分值小于第一设定分值的情况下，获取所述节点中安全分值小于第二设定分值的指定组件，作为待优化的目标组件，并基于所述目标组件的各项安全指标的检测结果，确定与所述kubernetes集群匹配的运维策略，进一步基于所述匹配的运维策略对所述kubernetes集群进行运维处理。
[0085]
例如，kubernetes集群中某一node节点的安全分值小于第一设定分值，则可确定该node节点存在异常。该node节点中的某一pod的安全分值低于第二设定分值，则可将该pod作为目标组件，根据该pod的各项安全指标的检测结果确定导致该pod存在异常的原因，进而读取预置的与该异常原因对应的运维策略，并基于该运维策略对kubernetes集群进行运维处理。
[0086]
可以理解，通过上述方案，在节点的安全分值小于第一设定分值的情况下，将该节点中安全分值小于第二设定分值的指定组件作为待优化的目标组件，进一步基于目标组件的各项安全指标的检测结果对kubernetes集群进行运维处理，使得对kubernetes集群的运维处理更有针对性，进一步提高了kubernetes集群的安全性。
[0087]
考虑到kubernetes集群中节点与外部设备(如客户端)之间在进行通信时，可能存在kubernetes集群中的相关数据被窃取而对kubernetes集群造成破坏，在执行上述步骤s22之后，本技术实施例提供的kubernetes集群的运维处理方法还可以包括：基于blowfish
算法对所述节点中指定组件的运行相关参数进行加密。
[0088]
可以理解，通过上述方案，在获取节点中指定组件的运行相关参数之后，对获取到的运行相关参数进行加密后存储，可以避免这些运行相关参数在kubernetes集群与客户端等外部设备进行交互通信的过程中被窃取和泄露而造成对kubernetes集群的破坏性行为，进一步提高了kubernetes集群的安全性。并且，采用blowfish算法对获取到的运行相关参数进行加密的方式，在吞吐量方面相较于其他加密方式更有优势，且不易被破解、可靠性更高。
[0089]
为了实现对kubernetes集群更为灵活、可靠的监控和运维，在更为优选的方案中，在执行上述步骤s22之前，如图3所示，本技术实施例提供的kubernetes集群的运维处理方法还可以包括：接收来自监控方的监控任务部署请求，所述监控任务部署请求中携带有待部署的安全监控应用的配置信息；查询任务调配库中是否存在所述待部署的安全监控应用，所述任务调配库中记录有已部署的安全监控应用；若所述任务调配库中不存在所述待部署的安全监控应用，则基于所述待部署的安全监控应用的配置信息在所述节点的pod中创建所述待部署的安全监控应用。
[0090]
具体来说，监控方可根据实际监控需要配置对待部署的安全监控应用进行配置，将待部署的安全监控应用的配置信息携带在监控任务部署请求中并发送给kubernetes集群中的节点，节点在接收到该监控任务部署请求后，可通过查询任务调配库判断该安全监控应用是否已部署在pod中，若是，则可以执行上述步骤s22至s26，以对kubernetes集群进行监控及运维处理；若否，则可以基于该安全监控应用的配置信息将该安全监控应用部署在pod中，进而可执行上述步骤s22至s26，以对kubernetes集群进行监控及运维处理，并进一步在任务调配库中记录该安全监控应用，以指示该安全监控应用已部署在kubernetes集群的节点的pod中。
[0091]
为了进一步提高kubernetes集群的安全性，在更为优选的方案中，来自监控方的监控任务部署请求中还携带允许访问kubernetes集群的用户的身份信息及对应的访问权限信息。相应地，如图3所示，在基于待部署的安全监控应用的配置信息在节点的pod中创建该待部署的安全监控应用之后，本技术实施例提供的kubernetes集群的运维处理方法还包括：基于所述用户的身份信息及对应的访问权限信息，在kubernetes集群的应用程序接口api服务器中配置针对所述kubernetes集群的授权策略。
[0092]
具体来说，访问权限信息可以包括允许用户的访问权限、授权模式等，其中，授权模式可以包括但不限于rbac(role-based access control，基于角色的访问控制)模式、abac(attribute-based access control，基于属性的访问控制)模式、webhook授权模式等，本技术实施例对授权模式的类型不做具体限定。在较为优选的方案中，授权模式可以采用rbac模式，具体来说，可采用“角色”(包括role和clusterrole)定义用户的访问权限，在节点的pod或service的定义文件yaml中定义“角色绑定”(包括rolebinding和clusterrolebinding)，通过将“角色”和“角色绑定”进行绑定，即可定义不同用户的访问权限信息，进一步以一种类似http token的认证方式，使pod获得认证，从而使该pod能够内部加载集群token、ca证书等，进而使pod能够监控、创建以及删除kubernetes集群的节点中的pod、service以及namespace等资源，从而完成对kubernetes集群的监控及运维处理。
[0093]
由此，在客户端访问kubernetes集群时，kubernetes集群中的api服务器在接收到
来自客户端的访问请求后，会读取该访问请求中的数据(如用户的身份信息)，并基于授权策略和读取到的数据对访问用户进行鉴权，在用户鉴权通过后，允许客户端与kubernetes集群之间进行数据交互或通信，进而可以避免非法用户访问kubernetes集群而执行对kubernetes集群的破坏性行为，进一步提高了kubernetes集群的安全性。
[0094]
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
[0095]
基于同一发明构思，本技术实施例还提供一种kubernetes集群的运维处理装置。如图4所示，该装置400包括组件安全评估层410和自愈方案实施层420。
[0096]
组件安全评估层410用于通过部署于所述节点的pod中的安全监控应用，获取所述节点中指定组件的运行相关参数，基于设定的异常分析策略对所述节点中指定组件的运行相关参数进行分析，以得到所述节点的异常分析结果。
[0097]
自愈方案实施层420用于以与所述kubernetes集群中节点的异常分析结果匹配的运维策略对所述kubernetes集群进行运维处理。
[0098]
在本技术实施例中，组件安全评估层410可以包括一个或多个功能模块。可选地，如图5所示，组件安全评估410可以包括组件安全数据模块、数据处理模块、数据汇总模块以及数据评估模块等。
[0099]
其中，组件安全数据模块可以通过部署于所述节点的pod中的安全监控应用，获取所述节点中指定组件的运行相关参数。
[0100]
数据处理模块中存储有设定的异常分析策略，例如互联网安全中心cis安全基准和评分基准，评分基准包括该cis安全基准针对不同安全指标的检测结果与安全分值之间的对应关系。数据处理模块可以基于所述cis安全基准和所述节点中指定组件的运行相关参数，确定所述指定组件的各项安全指标对应的检测结果。
[0101]
数据汇总模块可以对数据处理模块输出的所述指定组件的各项安全指标对应的检测结果进行整理和汇总。
[0102]
数据评估模块可以基于所述指定组件的各项安全指标对应的检测结果和所述评分基准，确定所述指定组件的安全分值，并基于所述指定组件的安全分值确定所述节点的安全分值。
[0103]
当然，需要说明的是，组件安全数据模块、数据处理模块、数据汇总模块以及数据评估模块等也可以集成于一个功能模块中。
[0104]
在更为优选的方案中，组件安全评估层410在通过部署于所述节点的pod中的安全监控应用，获取所述节点中指定组件的运行相关参数之后，还可以基于blowfish算法对所述节点中指定组件的运行相关参数进行加密。
[0105]
具体来说，组件安全评估层410中的数据处理模块可以基于blowfish算法对所述节点中指定组件的运行相关参数进行加密。
[0106]
本技术实施例中，自愈方案实施层420可以包括一个或多个功能模块。可选地，如图5所示，自愈方案实施层420可以包括组件安全自愈方案制定模块、组件安全自愈方案执
行模块以及实施日志记录模块等。
[0107]
其中，组件安全自愈方案制定模块可以在所述节点的安全分值小于第一设定分值的情况下，获取所述节点中安全分值小于第二设定分值的指定组件，作为待优化的目标组件，并基于所述目标组件的各项安全指标的检测结果，确定与所述kubernetes集群匹配的运维策略。
[0108]
组件安全自愈方案执行模块可以基于所述匹配的运维策略对所述kubernetes集群进行运维处理。
[0109]
实施日志记录模块可以记录对所述kubernetes集群的运维处理结果，基于所述运维结果及对应的运维策略生成运维日志并存储。
[0110]
当然，需要说明的是，组件安全自愈方案制定模块、组件安全自愈方案执行模块以及实施日志记录模块等也可以集成于一个功能模块中。
[0111]
在本技术的另一个实施例中，如图5所示，所述装置400还可以包括任务调配层430，其中，任务调配层430用于接收来自监控方的监控任务部署请求，所述监控任务部署请求中携带有待部署的安全监控应用的配置信息，查询任务调配库中是否存在所述待部署的安全监控应用，所述任务调配库中记录有已部署的安全监控应用，以及在所述任务调配库中不存在所述待部署的安全监控应用的情况下，基于所述待部署的安全监控应用的配置信息在所述节点的pod中创建所述待部署的安全监控应用。
[0112]
本技术实施例中，任务调配层430可以包括一个或多个功能模块。可选地，如图5所示，任务调配层430可以包括任务管理模块、任务调度模块以及调度日志记录模块等。
[0113]
其中，任务管理模块可用于执行以下任一操作：创建任务、取消任务、更新任务、删除任务。具体来说，任务管理模块可以接收来自监控方的监控任务部署请求，所述监控任务部署请求中携带有待部署的安全监控应用的配置信息；查询任务调配库中是否存在所述待部署的安全监控应用，所述任务调配库中记录有已部署的安全监控应用；若所述任务调配库中不存在所述待部署的安全监控应用，则基于所述待部署的安全监控应用的配置信息在所述节点的pod中创建所述待部署的安全监控应用。
[0114]
任务调度模块可以对任务调配库中存储的安全监控应用进行调度。
[0115]
调度日志记录模块可以记录任务调配库中存储的安全监控应用的调度情况，以及在将待部署的安全监控应用部署在节点的pod中后，对该安全监控应用的部署结果进行记录。
[0116]
当然，需要说明的是，任务管理模块、任务调度模块以及调度日志记录模块等也可以集成于一个功能模块中。
[0117]
在更为优选的方案中，任务管理模块还可以基于所述用户的身份信息及对应的访问权限信息，在所述kubernetes集群的应用程序接口api服务器中配置针对所述kubernetes集群的授权策略，所述授权策略用于对访问所述kubernetes集群的用户进行鉴权。
[0118]
关于上述实施例中的装置，其中各个单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
[0119]
通过本技术实施例提供的kubernetes集群的运维处理方法，通过以微服务的形式，在kubernetes集群的节点的pod中部署安全监控应用，使得安全监控应用可以以
kubernetes集群中service服务的形式运行在kubernetes集群的节点中，以获取kubernetes集群的节点中指定组件的运行相关参数，进一步基于获取到的运行相关参数和设定的异常分析策略识别节点是否存在异常，得到节点的异常分析结果，并以与kubernetes集群中节点的异常分析结果匹配的运维策略对kubernetes集群进行运维处理，可以及时发现kubernetes集群中存在的异常并对异常进行处理，事先对kubernetes集群的安全监控，保障kubernetes集群的运行安全。整个方案通过微服务的形式实现，实现逻辑简单，无需借助外部代理工具，避免了外部代理工具被攻击而造成对kubernetes集群的破坏，也避免了将外部代理工具集成在kubernetes集群的原生代码中而造成的kubernetes集群开发难度大、升级难度高以及高度耦合等问题。
[0120]
图6是本技术的一个实施例电子设备的结构示意图。请参考图6，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(random-access memory，ram)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。
[0121]
处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是isa(industry standard architecture，工业标准体系结构)总线、pci(peripheral component interconnect，外设部件互连标准)总线或eisa(extended industry standard architecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
[0122]
存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。
[0123]
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成kubernetes集群的运维处理装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：
[0124]
通过部署于kubernetes集群的节点的pod中的安全监控应用，获取所述节点中指定组件的运行相关参数；
[0125]
基于设定的异常分析策略对所述节点中指定组件的运行相关参数进行分析，以得到所述节点的异常分析结果；
[0126]
以与所述kubernetes集群中节点的异常分析结果匹配的运维策略对所述kubernetes集群进行运维处理。
[0127]
上述如本技术图2所示实施例揭示的kubernetes集群的运维处理装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(central processing unit，cpu)、网络处理器(network processor，np)等；还可以是数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field－programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施
例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
[0128]
该电子设备还可执行图2的方法，并实现kubernetes集群的运维处理装置在图2、图3所示实施例的功能，本技术实施例在此不再赘述。
[0129]
当然，除了软件实现方式之外，本技术的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
[0130]
本技术实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图2所示实施例的方法，并具体用于执行以下操作：
[0131]
通过部署于kubernetes集群的节点的pod中的安全监控应用，获取所述节点中指定组件的运行相关参数；
[0132]
基于设定的异常分析策略对所述节点中指定组件的运行相关参数进行分析，以得到所述节点的异常分析结果；
[0133]
以与所述kubernetes集群中节点的异常分析结果匹配的运维策略对所述kubernetes集群进行运维处理。
[0134]
总之，以上所述仅为本技术的较佳实施例而已，并非用于限定本技术的保护范围。凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。
[0135]
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
[0136]
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
[0137]
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包
括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
[0138]
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。