一种基于Kubernetes集群周期性任务调度的方法及电子设备

摘要

本发明的实施例提供了一种基于Kubernetes集群周期性任务调度的方法和电子设备。所述方法包括在Linux系统环境下生成CRD资源；在所述生成的CRD资源的基础环境下创建Controller组件；在Kubernetes环境下将创建Controller组件后的CRD资源集成到Kubernetes中。以此方式，降低了系统的复杂性和维护成本，增强了周期性任务执行的健壮性，能够满足限制具体运行时间或运行次数的任务需求，保证服务的持续化运行。

说明书

技术领域

本发明的实施例一般涉及互联网通信技术领域，并且更具体地，涉及一种基于Kubernetes集群周期性任务调度的方法及电子设备。

背景技术

周期性服务是指服务按照设定的间隔时间进行正常的启停，完成不同时间相同服务的运转。通过周期性结果对比能够得出固定时间段内的变化规律。

现有的周期性服务的实现方法主要有两种：

(1)调用第三方工具包,比如Java中的Timer和TimerTask,Python的APScheduler定时框架等。

(2)系统自带的定时任务服务，比如Linux Crontab,Kubernetes的CronJob等。

针对(1)，调用第三方的工具服务需要与本地服务紧耦合在一起，一旦本地服务遇到问题导致服务异常甚至宕机，定时器任务也会终止，无法再执行定时任务，更无法保证后续任务的正常执行。

针对(2)，系统级别的定时任务都是基于cron语法，能够保证任务的周期性定时运行，但是cron语法无法设置周期性任务的结束时间，如果不在外界干扰的情况下，cron任务会持续执行，这对执行次数有限制的任务来说是不满足需求的。

综上，现有的周期性服务的服务健壮性差，无法保证服务的持续化运行，而且无法执行对执行次数有限制的任务。

发明内容

根据本发明的实施例，提供了一种基于Kubernetes集群周期性任务调度的方案。

在本发明的第一方面，提供了一种基于Kubernetes集群周期性任务调度的方法。该方法包括：

在Linux系统环境下，生成CRD资源；

在所述生成的CRD资源的基础环境下，创建Controller组件；

在Kubernetes环境下，将创建Controller组件后的CRD资源集成到Kubernetes中。

进一步地，所述生成CRD资源，包括：

使用Operator-sdk创建项目工程，并添加CRD资源；

定义所述CRD资源的status结构体和spec结构体；

针对所述CRD资源的status结构体和spec结构体的定义生成框架代码。

进一步地，所述status结构体包括：活跃Job的数组、最后一次Job调度的时间以及已经调度成功Job的次数。

进一步地，所述spec结构体包括：调度策略定义、启动Job的期限、创建Job的并发执行策略、暂停标志位、保留完成Job数量的限制、保留失败Job数量的限制以及调度成功Job的个数限制。

进一步地，所述在所述生成的CRD资源的基础环境下，创建Controller组件，包括：

使用Operator-sdk创建Controller组件框架结构；

定义Job的删除过程以及定义Job的增加过程；

在Golang环境下，将所述CRD资源使用Operator-sdk命令编译打包成镜像。将CRD资源打包成镜像，以虚拟化容器的形式运行在Kubernetes中，符合Kubernetes资源调度需求。

在Kubernetes中每一种资源都需要对应的Controller组件进行对改资源的创建，运行，销毁，监控等操作，因此针对生成的CRD资源也需要创建对应的Controller组件，完成对生成的CRD资源创建、运行、销毁，监控等操作。

进一步地，所述定义Job的删除过程，包括：

根据资源的命名空间查找符合对应命名空间的Job；

根据Job的状态，将符合对应命名空间的Job分为完成组、失败组和运行组，并获取所述完成组的保留完成Job数量的限制以及所述失败组的保留失败Job数量的限制；

在所述完成组中存储处于完成状态的Job，在所述失败组中存储处于失败状态的Job，在所述运行组中存储处于运行状态的Job；

如果所述完成组中的Job数量大于所述保留完成Job数量的限制，则删除所述完成组中超出限制的Job；如果所述失败组中的Job数量大于所述保留失败Job数量的限制，则删除超出限制的Job。

Kubernetes系统维护的资源个数是有一定的限制，为了降低系统运行成本和满足资源利用的合理性，通过定义Job的删除过程，将一段时间运行的旧Job进行删除，更多的资源去服务其他的服务。

进一步地，所述Job按照进入对应其状态的组的顺序在组中排列，并在超出限制时，按照先进先出的顺序删除先进入组中的Job。对于删除超过限制的Job，采用FIFO是因为用户更加关心最近时间创建Job的运行状况和日志分析。

进一步地，所述定义Job的增加过程，包括：

设置所述调度成功Job的个数限制以及所述已经调度成功Job的次数；

如果已完成调度的Job达到所述调度成功Job的个数限制，则返回；否则根据所述CRD资源的创建时间和最近一次的Job调度时间，计算下一个Job调度的时间点，创建所述下一个Job调度的时间点对应的Job，并使已经调度成功Job的次数加1；

更新所述CRD资源的status结构体。

定义Job的增加过程，增加Job,即完成周期性Job调度的过程，周期性服务就是在不同的时间，调度相同的Job进行运转，从而分析结果随时间的变化情况。

进一步地，所述在Kubernetes环境下将创建的CRD资源集成到Kubernetes中，包括：

使用kubectl交互命令，在kubernetes创建CRD资源；

定义operator.yaml文件的image参数为所述镜像的名称；通过这种方式，就能够满足Kubernetes系统资源调度需求，管理生成的CRD资源的Controller组件将以容器的形式运行在整个系统中，从而能够更好地完成对生成CRD资源地创建，运行，销毁，监控等功能。

依次根据service_accout.yaml、role.yaml、role_binding.yaml、operator.yaml，创建Kubernetes中的对应资源；

在Kubernetes中定义并创建CRD资源的YAML文件。

在本发明的第二方面，提供了一种电子设备。该电子设备包括：存储器和处理器，所述存储器上存储有计算机程序，所述处理器执行所述程序时实现如以上所述的方法。

应当理解，发明内容部分中所描述的内容并非旨在限定本发明的实施例的关键或重要特征，亦非用于限制本发明的范围。本发明的其它特征将通过以下的描述变得容易理解。

本发明通过创建一种新的CRD资源并部署到Kubernetes中，降低了系统的复杂性和维护成本，增强了周期性任务执行的健壮性，能够满足限制具体运行时间或运行次数的任务需求，保证服务的持续化运行。

附图说明

结合附图并参考以下详细说明，本发明各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标记表示相同或相似的元素，其中：

图1示出了根据本发明的实施例的基于Kubernetes集群周期性任务调度方法的流程图；

图2示出了根据本发明的实施例的生成CRD资源的流程图；

图3示出了根据本发明的实施例的创建Controller组件的流程图；

图4示出了根据本发明的实施例的定义Job的删除过程的流程图；

图5示出了根据本发明的实施例的定义Job的增加过程的流程图；

图6示出了根据本发明的实施例的在Kubernetes中集成CRD资源的流程图；

图7示出了能够实施本发明的实施例的示例性电子设备的方框图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的全部其他实施例，都属于本发明保护的范围。

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

现有的传统周期性服务一般可以有两种实现方法，第一种是通过调用第三方工具包来实现，比如Java中的Timer和TimerTask,Python的APScheduler定时框架等；以Python的APScheduler框架为例,该框架提供了基于日期、固定时间间隔以及Crontab类型的任务，能够准确的确定任务的结束时间。不过，该框架与基础业务耦合过于紧密，容易造成整体服务的异常退出。

采用第三方的定时器框架，需要与本地服务紧耦合在一起，一旦本地服务遇到问题导致服务异常甚至宕机，定时器任务也会终止，无法再执行定时任务，更无法保证后续任务的正常执行，造成两个服务的耦合性高，不利于服务的升级、迭代和维护。同时，基础服务逻辑的实现对定时任务执行也造成影响，因此，服务健壮性差，无法保证周期性任务的持续化运行。

现有的传统周期性服务的第二种实现方法是系统自带的定时任务服务，比如Linux Crontab,Kubernetes的CronJob等。

基于cron语法的系统级别的定时任务，虽然能够保证任务的周期性定时运行，但是，cron语法无法设置周期性任务的结束时间，如果不在外界干扰的情况下，cron任务会持续执行，这对执行次数有限制的任务来说是不满足需求的。例如Kubernetes自带的CronJob，CronJob的Spec中没有设置具体的结束或执行次数，这就导致以CronJob为基础创建的Job会持续执行，直至外界进程删除CronJob。也就是说，Kubernetes的CronJob资源虽然能够保障周期性任务的持续化执行，由于是基于Cron语法实现，不能够明确确定任务的结束时间或执行次数，这无疑增加了系统的复杂性和维护成本，增加了任务持续和自动化执行的难度。因此，还没有一套能够同时满足以上两项要求的实现方案。

本发明基于Kubernetes的CronJob设置一种新的CRD(Custom ResourceDefinition)资源，该CRD资源能够设置约束具体的执行次数，并根据执行次数来结束周期性任务。通过创建一种新的CRD资源并部署到Kubernetes中，降低了系统的复杂性和维护成本，增强了周期性任务执行的健壮性，能够满足限制具体运行时间或运行次数的任务需求，保证服务的持续化运行。

图1示出了本发明实施例的基于Kubernetes集群周期性任务调度方法的流程图。

Kubernetes API Server为每个版本创建一个新的REST(RepresentationalState Transfer)ful资源路径。在YAML文件中需要配置CRD的group,version,scope等参数，Kubernetes的API Server就能够识别该对象类型。

该方法包括：

S110、在Linux系统环境下，生成CRD资源。

进一步地，如图2所示，生成CRD资源，包括：

S111、使用Operator-sdk创建项目工程，并添加CRD资源；

S112、定义所述CRD资源的status结构体和spec结构体；

所述status结构体包括：活跃Job的数组、最后一次Job调度的时间以及已经调度成功Job的次数。

所述spec结构体包括：调度策略定义、启动Job的期限、创建Job的并发执行策略、暂停标志位、保留完成Job数量的限制、保留失败Job数量的限制以及调度成功Job的个数限制。

S113、针对所述CRD资源的status结构体和spec结构体的定义生成框架代码。

作为本发明的一种实施例，在Linux系统环境下，导入变量GO111MODULE＝on，使用operator-sdk命令创建项目工程cronJob-operator。

添加新的CRD资源定义：使用operator-sdk命令，参数使用add api，并指定api-version为cache.example.com和kind为CronJob。

定义新的CRD资源的status为CronJobStatus；其中，CronJobStatus包括表示活跃Job的数组的Active；表示最后一次Job调度的时间的LastScheduleTime；表示已经调度成功Job的次数的ScheduledJobsTimes。

定义新的CRD资源的spec结构体为CronJobSpec。

其中，CronJobSpec包括：

表示调度策略的Schedule，为必填字段，与Linux下的Cron语法一致；

表示启动Job的期限(秒级别)的StartingDeadlineSeconds，为可选字段，如果因为任何原因而错过了被调度的时间，那么错误执行时间的Job被认为是失败的，如果没有指定，则没有期限；

表示创建Job的并发执行策略的ConcurrencyPolicy，为可选字段，其中包括：Allow；Forbid；Replace；

表示暂停标志位的suspend，为可选字段，如果设置为true，则后续所有的执行都会被过滤掉，但是对当前已经在运行的Job不影响，默认为false；

表示保留完成Job数量的限制的successfulJobsHistoryLimit，是可选字段，指定了可以保留完成Job数量的限制；

表示保留失败Job数量的限制的failedJobsHistoryLimit，是可选字段，指定了可以保留失败Job数量的限制；

表示调度成功Job的个数限制的ScheduledJobsLimits，是必选字段，用于指定调度成功Job的限制个数，超过该限制，则不会再进行Job的调度。

然后针对新的CRD资源进行更新和框架代码生成：使用operator-sdk命令，参数为generate Kubernetes。

在上述实施例中，可选的，针对生成框架代码后的CRD资源验证API,将CRD资源声明信息保存在cronjo_crd.yaml文件中。

S120、在所述生成的CRD资源的基础环境下，创建Controller组件，如图3所示，包括以下过程：

S121、使用Operator-sdk创建Controller组件框架结构；例如，使用operator-sdk命令，参数为add controller，属性api-version为cache.example.com/v1alpha1，属性kind为CronJob。

S122、定义Job的删除过程以及定义Job的增加过程；

进一步地，所述定义Job的删除过程，如图4所示，包括：

根据资源的命名空间查找符合对应命名空间的Job；

根据Job的状态，将符合对应命名空间的Job分为完成组、失败组和运行组，并获取所述完成组的保留完成Job数量的限制以及所述失败组的保留失败Job数量的限制；

在所述完成组中存储处于完成状态的Job，在所述失败组中存储处于失败状态的Job，在所述运行组中存储处于运行状态的Job；如果所述完成组中的Job数量大于所述保留完成Job数量的限制，则删除所述完成组中超出限制的Job；如果所述失败组中的Job数量大于所述保留失败Job数量的限制，则删除超出限制的Job。

所述Job按照进入对应其状态的组的顺序在组中排列，并在超出限制时，按照先进先出的顺序删除先进入组中的Job。

作为本发明的一种实施例，定义Job的删除过程具体包括：

根据资源的命名空间NameSpace和Label查找符合对应命名空间的Job；

根据Job.Status.Conditions分成完成组、失败组和运行组；并获取所述完成组的保留完成Job数量的限制spec.SuccessfulJobsHistoryLimit以及所述失败组的保留失败Job数量的限制spes.FailedJobsHistoryLimit；

当Job运行后更新状态为运行状态，并进入运行组，如果运行组中的Job执行完成，则更新该Job的状态为完成状态，并进入完成组；如果运行组中的Job出错，则更新该Job的状态为失败状态，并进入失败组；在完成组和失败组中存储Job的顺序与Job进入组的顺序一致，且遵循先进先出的原则，即如果所述完成组中的Job数量大于所述保留完成Job数量的限制，则先删除所述完成组中先进入的Job；如果所述失败组中的Job数量大于所述保留失败Job数量的限制，则先删除所述失败组中先进入的Job。待删除的Job的数量即为当前完成组超出保留完成Job数量的限制spec.SuccessfulJobsHistoryLimit或失败组中超出保留失败Job数量的限制spes.FailedJobsHistoryLimit的Job数量。

进一步地，所述定义Job的增加过程，如图5所示，包括：

定义所述调度成功Job的个数限制以及所述已经调度成功Job的次数；

如果已完成调度的Job达到所述调度成功Job的个数限制，则返回；否则根据所述CRD资源的创建时间和最近一次的Job调度时间，计算下一个Job调度的时间点，创建所述下一个Job调度的时间点对应的Job，并使已经调度成功Job的次数加1；更新所述CRD资源的status结构体。

作为本发明的一种实施例，所述定义Job的增加过程，包括：

定义CronJob结构体中CronJobSpec的ScheduledJobsLimit参数，该参数定义任务的执行次数；定义CronJobStatus的ScheduledJobsTimes参数，该参数定义当前时间任务已经完成的次数；

Controller组件是持续运行的组件，设定每10S执行一次Reconcile函数，修改核心函数Reconcile；

获得CronJob中Status下ScheduledJobsTimes，如果ScheduledJobsTimes超过ScheduledJobsLimit则返回，否则根据任务的创建时间和最近一次的调度时间，计算出到现在为止所有的应该调度的时间点，得到下一次调度的时间点，已经调度成功Job的次数创建新的Job并累加Job的次数CronJob.Status.ScheduledJobsTimes，并更新CronJob。

S123、在Golang环境下，将所述CRD资源使用Operator-sdk命令编译打包成镜像。使用operator-sdk命令，参数为build cronJob-operator:v1.0。

S130、如图6所示，在Kubernetes环境下，将创建Controller组件后的CRD资源集成到Kubernetes中，包括：

S131、使用kubectl交互命令，在kubernetes创建CRD资源。

S132、定义operator.yaml文件的image参数为所述镜像的名称；例如，修改operator.yaml文件中的image参数为cronJob-operator:v1.0。

S133、创建Kubernetes中其他的资源，包括依次根据service_accout.yaml、role.yaml、role_binding.yaml、operator.yaml，创建Kubernetes中的对应资源；

S134、在Kubernetes中定义并创建CRD资源的YAML文件。

根据本发明的实施例，CRD资源能够设置约束具体的执行次数，并根据执行次数来结束周期性任务，通过创建一种新的CRD资源并部署到Kubernetes中，降低了系统的复杂性和维护成本，增强了周期性任务执行的健壮性，能够满足限制具体运行时间或运行次数的任务需求，保证服务的持续化运行。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本发明所必须的。

如图7所示，设备700包括中央处理单元(CPU)701，其可以根据存储在只读存储器(ROM)702中的计算机程序指令或者从存储单元708加载到随机访问存储器(RAM)703中的计算机程序指令，来执行各种适当的动作和处理。在RAM 703中，还可以存储设备700操作所需的各种程序和数据。CPU 701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。

设备700中的多个部件连接至I/O接口705，包括：输入单元706，例如键盘、鼠标等；输出单元707，例如各种类型的显示器、扬声器等；存储单元708，例如磁盘、光盘等；以及通信单元709，例如网卡、调制解调器、无线通信收发机等。通信单元709允许设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

处理单元701执行上文所描述的各个方法和处理，例如方法S110～S130。例如，在一些实施例中，方法S110～S130可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元708。在一些实施例中，计算机程序的部分或者全部可以经由ROM 702和/或通信单元709而被载入和/或安装到设备700上。当计算机程序加载到RAM 703并由CPU701执行时，可以执行上文描述的方法S110～S130的一个或多个步骤。备选地，在其他实施例中，CPU 701可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行方法S110～S130。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)等等。

用于实施本发明的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本发明的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

此外，虽然采用特定次序描绘了各操作，但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行，或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本发明的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地，在单个实现的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实现中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。