一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

基于kubernetes集群的应用故障演练方法及系统与流程

2023-02-04 17:24:21 来源:中国专利 TAG:


1.本发明涉及云原生技术领域,具体地,涉及一种基于kubernetes集群的应用故障演练方法及系统。


背景技术:

2.在云原生领域,基于kubernetes部署的分布式应用架构越发复杂、不可预见性等问题日益突出,现有软件测试策略侧重于防范可预见的系统风险,不能够适应kubernetes环境下系统稳定性要求,主动对应用进行故障探测成为有效解决方案。


技术实现要素:

3.针对现有技术中的缺陷,本发明提供一种基于kubernetes集群的应用故障演练方法及系统。
4.根据本发明提供的一种基于kubernetes集群的应用故障演练方法及系统,所述方案如下:
5.第一方面,提供了一种基于kubernetes集群的应用故障演练方法,所述方法包括:
6.任务流控制器taskcontroller:控制演练任务的生命周期;
7.控制器chaoscontroller:控制实验的生命周期,任务对象经过任务流控制器taskcontroller分解后,会成为chaoscontroller控制的单元;
8.组件agent:用于对指定的应用注入相关的异常干扰;
9.爆炸半径控制组件explosioncontroller:用于控制实验的爆炸半径,利用kubernetes原生的基于标签选择能力来选择目前对象;
10.所述方法的实现流程包括:
11.步骤s1:向apiserver服务器提交一个任务编排taskyml混沌实验数据,taskcontroller任务流控制器watch到事件后随即处理,并通过etcd对实验数据进行持久化;
12.步骤s2:控制器chaoscontroller解析实验对象,根据所述实验对象的操作类型,选择对应的故障注入方式,管理实验的生命周期;
13.步骤s3:根据故障注入类型,由模拟故障注入组件agent执行预定逻辑。
14.优选地,所述步骤s1包括:
15.步骤s1.1:任务流控制器taskcontroller根据提交的任务编排taskyml解析出task对象,并对task对象数据持久化存储,根据task对象的metadata中tasktype判断任务流类型,若是单实验任务流,执行步骤s1.2,多实验任务流执行步骤s1.3;
16.步骤s1.2:根据task对象的chaostemplate封装单次实验chaosobject对象,然后提交给apiserver服务器,随后由控制器chaoscontroller监听chaos对象,执行具体的实验,通过reconcile机制反馈实验状态;
17.步骤s1.3:多实验任务的执行,根据tasktype判断task对象是串行执行还是并行
执行;
18.步骤s1.4:通过所述chaostemplate中的schedule定义定时任务类型,如果是单次执行任务,则采用job方式来执行,如果是多次执行,则使用cronjob方式。
19.优选地,所述步骤s1.3具体包括:
20.若是串行执行,则对task对象解析出的单个实验chaosobject入队列taskqueue,然后依次出队列执行,chaos对象的执行仍由控制器chaoscontroller来控制并反馈结果,每执行完实验,则采用回调的方式通知任务流控制器taskcontroller,taskcontroller缓存已执行的实验数量,然后和该task对象总的数量作比较,以此来判定任务的执行状态;
21.如果是并行执行,则使用步骤s1.2的方式执行。
22.优选地,所述步骤s2包括:
23.控制器chaoscontroller捕捉到chaosobject对象后,解析出该对象的主要数据,根据chaostype的值,决定注入的方式;
24.对于非生命周期管理类的故障注入,根据tasktarget和action内容,组合agentobject对象,然后根据实验作用对象信息确认所在节点信息,从而将该实验数据发送给具体的agent程序;通过reconcile回调来监测agent执行结果,在实验结束之后发送恢复指令给agent;
25.对pod生命周期管理类的实验动作,通过调用api server的pod相关api的方式来实现故障注入,注入完成以后,通过对pod时间的监听来验证实验的完成状态,然后chaoscontroller更新本次任务的状态,一次任务完成。
26.优选地,所述步骤s3包括:
27.步骤s3.1:agent解析agentobject,获取实验数据,并对实验数据进行解析,判断是针对pod所在节点的实验还是针对pod本身的实验,再实现具体的实验;
28.步骤s3.2:根据提交的不同的实验类型,agent执行相应的逻辑;
29.步骤s3.3:在故障注入环节持续时间结束时,销毁agent混沌注入的程序,退出被注入故障的应用pod的namespaces,然后向控制器chaoscontroller发送实验结果。
30.优选地,所述步骤s3.1还包括:如果是针对pod本身的,通过agent的attachns()函数进入pod的namespaces来操作实验对象,如果是针对节点nodes的,则直接在节点完成实验注入。
31.优选地,所述步骤s3.2还包括:根据实验对象和实验类型type,调用injectfault()函数注入实验,然后回调返回结果,injectfault()函数的注入方式根据type来确定。
32.第二方面,提供了一种基于kubernetes集群的应用故障演练系统,所述系统包括:
33.任务流控制器taskcontroller:控制演练任务的生命周期;
34.控制器chaoscontroller:控制实验的生命周期,任务对象经过任务流控制器taskcontroller分解后,会成为chaoscontroller控制的单元;
35.组件agent:用于对指定的应用注入相关的异常干扰;
36.爆炸半径控制组件explosioncontroller:用于控制实验的爆炸半径,利用kubernetes原生的基于标签选择能力来选择目前对象;
37.所述系统包括:
38.模块m1:向apiserver服务器提交一个任务编排taskyml混沌实验数据,
taskcontroller任务流控制器watch到事件后随即处理,并通过etcd对实验数据进行持久化;
39.模块m2:控制器chaoscontroller解析实验对象,根据所述实验对象的操作类型,选择对应的故障注入方式,管理实验的生命周期;
40.模块m3:根据故障注入类型,由模拟故障注入组件agent执行预定逻辑。
41.优选地,所述模块m1包括:
42.模块m1.1:任务流控制器taskcontroller根据提交的任务编排taskyml解析出task对象,并对task对象数据持久化存储,根据task对象的metadata中tasktype判断任务流类型,若是单实验任务流,执行模块m1.2,多实验任务流执行模块m1.3;
43.模块m1.2:根据task对象的chaostemplate封装单次实验chaosobject对象,然后提交给apiserver服务器,随后由控制器chaoscontroller监听chaos对象,执行具体的实验,通过reconcile机制反馈实验状态;
44.模块m1.3:多实验任务的执行,根据tasktype判断task对象是串行执行还是并行执行;
45.模块m1.4:模块m1.2和模块m1.3中实验任务对象类型为定时任务类型,如果是单次执行任务,则采用job方式来执行,如果是多次执行,则使用cronjob方式;
46.所述模块m1.3具体包括:
47.若是串行执行,则对task对象解析出的单个实验chaosobject入队列taskqueue,然后依次出队列执行,chaos对象的执行仍由控制器chaoscontroller来控制并反馈结果,每执行完实验,则采用回调的方式通知任务流控制器taskcontroller,taskcontroller缓存已执行的实验数量,然后和该task对象总的数量作比较,以此来判定任务的执行状态;
48.如果是并行执行,则使用模块m1.2的方式执行。
49.优选地,所述模块m2包括:
50.控制器chaoscontroller捕捉到chaosobject对象后,解析出该对象的主要数据,根据chaostype的值,决定注入的方式;
51.对于非生命周期管理类的故障注入,根据tasktarget和action内容,组合agentobject对象,然后根据实验作用对象信息确认所在节点信息,从而将该实验数据发送给具体的agent程序;通过reconcile回调来监测agent执行结果,在实验结束之后发送恢复指令给agent;
52.对pod生命周期管理类的实验动作,通过调用api server的pod相关api的方式来实现故障注入,注入完成以后,通过对pod时间的监听来验证实验的完成状态,然后chaoscontroller更新本次任务的状态,一次任务完成;
53.所述模块m3包括:
54.模块m3.1:agent解析agentobject,获取实验数据,并对实验数据进行解析,判断是针对pod所在节点的实验还是针对pod本身的实验,再实现具体的实验;
55.模块m3.2:根据提交的不同的实验类型,agent执行相应的逻辑;
56.模块m3.3:在故障注入环节持续时间结束时,销毁agent混沌注入的程序,退出被注入故障的应用pod的namespaces,然后向控制器chaoscontroller发送实验结果;
57.所述模块m3.1还包括:如果是针对pod本身的,通过agent的attachns()函数进入
pod的namespaces来操作实验对象,如果是针对节点nodes的,则直接在节点完成实验注入;
58.所述模块m3.2还包括:根据实验对象和实验类型type,调用injectfault()函数注入实验,然后回调返回结果,injectfault()函数的注入方式根据type来确定。
59.与现有技术相比,本发明具有如下的有益效果:
60.1、本发明主要针对kubernetes集群设计的故障演练系统。尽量的复用了kubernetes基础设施来实现应用故障演练的功能,例如:利用kubernetes的operator插件机制定义某些故障类型并实现相应的控制器;对故障注入试验进行分类管理,每类故障独立的设计crd,由chaoscontroller控制器来实现对故障注入的全生命周期管理。通过采用kubeconfig配置文件方式管理多个集群信息,实现对多集群应用的故障注入能力。通过以上方式,减少部署和使用难度;
61.2、本发明提供了基于kubernetes实现的故障主动注入方案,根据实际故障注入的特点,方法适用性,对不同类型的故障注入设计不同的实现组件,组件与控制器等之间的数据传递借助kubernetes本身的能力;
62.3、本发明实现了一种多维度的爆炸半径控制器,通过自定义标签及网络策略方式来控制目标实验对象,从注入故障后影响范围的维度设计实现故障注入的不同方向,限定故障的影响范围;
63.4、本发明提供了一种工作任务流和实验排期的能力,来达到对多故障及非抢占式资源的有序注入模拟。
附图说明
64.通过阅读参照以下附图对非限制性实施例所作的详细描述,本发明的其它特征、目的和优点将会变得更明显:
65.图1为整体框架原理图;
66.图2为数据结构包示意图;
67.图3为taskqueue示意图;
68.图4为schedule示意图;
69.图5为agent执行故障注入功能示意图;
70.图6为explosioncontroller的处理故障逻辑示意图。
具体实施方式
71.下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明,但不以任何形式限制本发明。应当指出的是,对本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变化和改进。这些都属于本发明的保护范围。
72.本发明实施例提供了一种基于kubernetes集群的应用故障演练方法,参照图1所示,其中,涉及的主要组件和功能设计如下:
73.1)任务流控制器taskcontroller:taskcontroller控制器控制演练任务的生命周期,通过拓展的api资源对象taskfolw编排和控制一次混沌演练任务,任务流包含一个或者多个实验,采用并行或者串行的方式执行,会根据不同的方式来执行chaoslist中的故障实
验,并通过设置反馈的方式决定后续实验是否依赖前序继续执行。
74.taskcontroller包括三个核心设计,分别为taskflow数据结构、taskqueue任务队列、schedule调度。单实验任务和不涉及定时调度的任务不会采用到后两个模块。
75.参照图2所示,taskflow定义任务流结构,采用标准kubernetesapi对象设计,数据结构包含metadata元数据和chaostemplate实验对象数据,主要包含:任务标识、实验列表、调度类型、作用对象、实验动作等内容。
76.参照图3所示,taskqueue是任务流先进先出队列,串行执行的多个实验,任务先进队列,执行完成后出队列,单个实验的任务不进队列。多试验任务串行执行的chaoslist中的实验是作为一个整体进入到taskqueue队列中,实验的终止以任务为单位,即任务结束,实验会自动结束,然后所有实验出队列。
77.参照图4所示,chaostemplate定义的schedule包含两种类型的实验对象调度,分别为周期性调度和非周期性调度,基于cornjob和job来实现,采用reconcile机制来实现结果的监听。
78.2)控制器chaoscontroller:采用kubernetes的operator模式设计的混沌实验控制器,该控制器是唯一可以控制实验生命周期的组件,任务对象经过taskcontroller分解后,会成为chaoscontroller控制的单元。控制器会根据实验的具体类型,采用不同的方式去完成实验,本方案设计中一共实现了三种方式,一种方式调用面向pod的api,如delete、edit、patch等,第二种方式为通过设计chaoswebhook的方式在pod创建时注入sidecar容器,通过该容器注入故障,第三种方式为将故障注入程序封装为agent通过daemonset的方式部署到集群内,利用容器本身特性,通过共享容器namespaces的方式,实现对应用的无侵入故障注入能力。在故障注入完成后,控制器通过reconcile反馈机制来感知实验结果,控制一个实验的完整生命周期。
79.3)组件agent:agent模拟故障注入组件用于对指定的应用注入相关的异常干扰,包括软件和硬件层面的故障,通过kubernetes的daemonset方式在集群的每个节点部署。agent封装了故障处理的逻辑,更新逻辑需要重置agent的pod。agent通过对外暴露端口的形式提供服务,屏蔽了底层实现细节,能够实现故障注入实现方式的无感更新,主要提供了4个方法,实现了故障的注入,结果获取,终止实验,进入namespaces,其中,进入namespaces的方法:attachns(nsid,*),实验注入法:injectfault(targetid,type,***),getresult(targetid,*),stopfault(targetid,*)。
80.该方案的agent组件实现方法主要含有:封装了对linux容器cgroup和namespaces操作的调用接口、java方法层面字节码注入工具byteman、宿主机压力及tc网络流量控制等可以对pod层面、应用方法层面、宿主机层面进行故障注入的脚本工具。agent执行故障注入功能参照图5所示。
81.4)爆炸半径控制组件explosioncontroller:explosioncontroller组件用于控制实验的爆炸半径,利用kubernetes原生的基于标签选择能力来实现目前对象的选择,提供了基于pod、label、service等多个粒度的实验对象定位能力;对于模拟网络流量异常故障场景,该组件支持流量的南北向维度控制,模拟请求端和服务端出现网络故障的场景,结合识别实验编排对象的label及networkpolicy来实现对爆炸半径的精准控制。
82.南北向维度控制故障注入的对象,以a请求b服务为例,南向维度是将故障注入b,
通过b的故障来影响a的请求相应,北向维度是将故障注入a,通过延迟a的请求来模拟故障的发生。
83.explosioncontroller控制器基于对象选择器来实现目标对象的定位,pod、label、service三个粒度的范围从小到大,其中service是从服务的角度选择被注入对象,pod是从单个实例的角度,label是基于metadata的角度。以service来选择目标注入对象的话,explosioncontroller会解析service的后端endpoint对象,查询有效的后端pod对象,然后使用pod选择器对具体的实例进行故障注入。
84.explosioncontroller的处理故障逻辑参照图6所示。
85.具体地,该方法的实现流程包括:
86.步骤s1:向apiserver服务器提交一个任务编排taskyml混沌实验数据,taskcontroller控制器watch到事件后随即处理并且etcd会对数据进行持久化。
87.具体地,该步骤s1具体包括:
88.步骤s1.1:任务流控制器taskcontroller根据提交的taskyml解析出task对象,对该对象数据持久化存储,根据task对象的metadata中tasktype判断任务流类型,如果是单实验任务流,执行步骤s1.2,多实验任务流执行步骤s1.3。
89.步骤s1.2:根据task对象的chaostemplate封装单次实验chaosobject对象,然后提交给apiserver服务器,随后由控制器chaoscontroller监听该chaos对象,执行具体的实验,然后通过reconcile机制反馈实验状态。
90.步骤s1.3:多实验任务的执行,根据tasktype判断task对象是串行执行还是并行执行。如果是串行执行,则对task解析出的单个实验chaosobject入队列taskqueue,然后依次出队列执行,chaos的执行仍由chaoscontroller来控制并反馈结果,每执行完实验,则采用回调的方式通知taskcontroller,taskcontroller缓存已执行的实验数量,然后和该task总的数量作比较,以此来判定任务的执行状态。如果是并行执行,则使用步骤s1.2方式执行。
91.步骤s1.4:步骤s1.2和步骤s1.3中task对象的chaostemplate中schedule定义了定时任务类型,如果是单次执行任务,则采用job方式来执行,如果是多次执行,则使用cronjob方式,两种方式均是借助kubernetes本身的能力。
92.步骤s2:控制器chaoscontroller解析实验对象,然后根据对象操作类型,选择对应的故障注入方式,管理实验的生命周期。
93.该步骤s2具体包括:控制器chaoscontroller捕捉到chaosobject对象后,解析出该对象的主要数据,包括chaostype、chaostarget、action、targetselector,这4个对象包含了故障注入类型的依赖信息。根据chaostype的值,决定注入的方式,分别为pod生命周期管理类、daemonset共享namesapces类型注入、sidecar注入。对于非生命周期管理类的故障注入,然后根据tasktarget和action内容,组合agentobject对象,然后根据实验作用对象信息确认所在节点信息,从而将该实验数据发送给具体的agent程序;通过reconcile回调来监测agent执行结果,在实验结束之后发送恢复指令给agent。
94.对pod生命周期管理类的实验动作,通过调用api server的pod相关api的方式来实现故障注入,注入完成以后,通过对pod时间的监听来验证实验的完成状态,然后chaoscontroller更新本次任务的状态,一次任务完成。
95.步骤s3:根据故障注入类型,由模拟故障注入组件agent执行预定逻辑。
96.具体地,步骤s3包括:
97.步骤s3.1:agent解析agentobject,获取实验数据,然后对实验数据进行解析,判断是针对pod所在节点的实验还是针对pod本身的实验,然后实现具体的实验,如果是针对pod本身的,通过agent的attachns()函数进入pod的namespaces来操作实验对象,如果是针对节点nodes的,则直接在节点完成实验注入。
98.步骤s3.2:根据提交的不同的实验类型,agent执行相应的逻辑;首先是根据实验对象和实验类型type,调用injectfault()函数注入实验,然后回调返回结果,injectfault()的注入方式根据type来确定,例如执行对java程序的指定方法增加延迟,使用基于fault injection技术的byteman组件进行字节码层面的延迟脚本注入,实现方法层面的延迟;执行资源占用类的故障注入则启动stress压力工具等已封装的程序来实施。实验过程中,可同时接受stopfault()来终止一个实验,通过getresult()来获取实验结果。
99.步骤s3.3:在故障注入环节持续时间结束时,销毁agent混沌注入的程序,退出被注入故障的应用pod的namespaces,然后向控制器chaoscontroller发送实验结果。
100.本发明还提供了一种基于kubernetes集群的应用故障演练系统,本领域技术人员可以将本发明提供的一种基于kubernetes集群的应用故障演练方法,理解为基于kubernetes集群的应用故障演练系统的具体实施方式,即所述基于kubernetes集群的应用故障演练系统可以通过执行所述基于kubernetes集群的应用故障演练方法的步骤流程予以实现。
101.本发明实施例提供了一种基于kubernetes集群的应用故障演练方法及系统,能够实现对应用在一定压力下主动地注入一些软件或硬件方面的异常故障状态,模拟应用在实际生产运行过程中可能遇到的故障场景,定位影响系统稳定性的因素,提高分布式系统的韧性。
102.本发明主要针对kubernetes集群设计的故障演练系统。尽量的复用了kubernetes基础设施来实现应用故障演练的功能,例如:利用kubernetes的operator插件机制定义某些故障类型并实现相应的控制器;对故障注入试验进行分类管理,每类故障独立的设计crd,由chaoscontroller控制器来实现对故障注入的全生命周期管理。通过采用kubeconfig配置文件方式管理多个集群信息,实现对多集群应用的故障注入能力。通过以上方式,减少部署和使用难度。
103.本发明提供了基于kubernetes实现的故障主动注入方案,根据实际故障注入的特点,方法适用性,对不同类型的故障注入设计不同的实现组件,组件与控制器等之间的数据传递借助kubernetes本身的能力。本发明实现了一种多维度的爆炸半径控制器,通过自定义标签及网络策略方式来控制目标实验对象,从注入故障后影响范围的维度设计实现故障注入的不同方向,限定故障的影响范围。本发明提供了一种工作任务流和实验排期的能力,来达到对多故障及非抢占式资源的有序注入模拟。
104.本领域技术人员知道,除了以纯计算机可读程序代码方式实现本发明提供的系统及其各个装置、模块、单元以外,完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统及其各个装置、模块、单元以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌
入式微控制器等的形式来实现相同功能。所以,本发明提供的系统及其各项装置、模块、单元可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置、模块、单元也可以视为硬件部件内的结构;也可以将用于实现各种功能的装置、模块、单元视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
105.以上对本发明的具体实施例进行了描述。需要理解的是,本发明并不局限于上述特定实施方式,本领域技术人员可以在权利要求的范围内做出各种变化或修改,这并不影响本发明的实质内容。在不冲突的情况下,本技术的实施例和实施例中的特征可以任意相互组合。
再多了解一些

本文用于创业者技术爱好者查询,仅供学习研究,如用于商业用途,请联系技术所有人。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献