K8S CronJob
K8S 知识目录
Kubernetes (K8s) 中的 CronJob 是一种特殊的作业(Job),它允许根据给定的时间表(cron 格式)来运行作业。这对于需要定期执行的任务(如数据库备份、日志清理、发送报告等)非常有用。
一、组成部分
CronJob 主要由以下几个部分组成:
- metadata:包含 CronJob 的名称、命名空间等元数据。
- spec:CronJob 的规格说明,包括调度计划(schedule)、作业模板(jobTemplate)、并发策略(concurrencyPolicy)、成功完成作业的保留策略(successfulJobsHistoryLimit)和失败作业的保留策略(failedJobsHistoryLimit)等。
spec字段详解
在CronJob的spec字段中,包含了以下几个关键子字段:
1. schedule:必需字段,用于指定任务的调度计划,采用Cron表达式语法。Cron表达式由五个或六个字段组成,分别代表分钟、小时、日、月、星期几(可选年份)。
2. jobTemplate:必需字段,定义了要执行的任务的模板。这个模板通常是一个Pod模板,包含了任务所需的容器镜像、命令、环境变量等配置。
3. concurrencyPolicy:可选字段,用于指定并发策略。它定义了当上一个任务还在运行时,如何处理新任务的执行。有三种策略可供选择:Allow(允许并发执行)、Forbid(禁止并发执行,新任务将被跳过)、Replace(如果任务正在执行,则终止当前任务并启动新任务)。
4. suspend:可选字段,用于暂停或恢复CronJob的执行。如果设置为true,则后续所有执行都会被挂起。
5. successfulJobsHistoryLimit和failedJobsHistoryLimit:可选字段,用于指定保留成功和失败任务历史记录的数量。默认情况下,分别设置为3和1。
二、调度计划(Schedule)
调度计划使用 cron 表达式来定义作业的执行时间。cron 表达式由六或七个字段组成,但 Kubernetes CronJob 只使用前五个字段,分别代表:
- 分钟(0 - 59)
- 小时(0 - 23)
- 日期中的月份(1 - 12)
- 月份中的日期(1 - 31)
- 星期中的日期(0 - 7,其中 0 和 7 都代表星期日)
例如,“* * * * *” 表示每分钟执行一次,而 “0 0 * * *” 表示每天午夜执行一次。
三、作业模板(JobTemplate)
在Kubernetes (K8s) 中,CronJob 的 jobTemplate 部分定义了当Cron表达式触发时应该运行什么样的作业(Job)。jobTemplate 实际上是一个作业的模板,它包含了作业(Job)规格的所有必要信息,比如要运行的容器、环境变量、资源限制等。
jobTemplate 字段位于 CronJob 资源的 spec 部分下,并且它自身也是一个嵌套的 JobTemplateSpec 类型。这个类型几乎与 Job 资源的 spec 部分相同,只是名称上有所区别。
下面是一个包含 jobTemplate 的 CronJob 示例:
apiVersion: batch/v1
kind: CronJob
metadata:
name: my-cronjob
spec:
schedule: "*/1 * * * *" # 每分钟的每一秒触发(注意:这实际上是不准确的,CronJob的schedule不支持秒级精度,这里仅为示例)
jobTemplate:
spec:
template:
spec:
containers:
- name: my-container
image: my-image:latest
command: ["/bin/sh", "-c"]
args: ["echo 'Hello from the Kubernetes CronJob!'; date"]
restartPolicy: OnFailure # 作业中的Pod失败时重启策略
注意:上面的Cron表达式"*/1 * * * “实际上并不符合CronJob的标准用法,因为CronJob不支持秒级精度。使用它只是为了演示如何在schedule字段中放置Cron表达式。在真实场景中,应该使用标准的Cron表达式,如”/5 * * * *"(每5分钟执行一次)。
四、并发策略(Concurrency Policy)
在Kubernetes (K8s) 中,CronJob 的并发策略(Concurrency Policy)决定了当 CronJob 触发但前一个作业(Job)仍在运行时,系统应如何处理新的作业执行。CronJob 支持以下三种并发策略:
- Allow(允许):
这是默认策略。当 CronJob 触发且前一个作业尚未完成时,新的作业将被允许并发执行。这意呀着在任何给定的时间点,可能会有多个该 CronJob 创建的作业正在运行。
适用于那些可以并行执行而不互相干扰的任务,或者任务的执行时间相对较短,并发执行不会对系统造成过大压力的场景。 - Forbid(禁止):
当 CronJob 触发但前一个作业仍在运行时,新的作业执行将被跳过,即不会启动新的作业。
这有助于避免同时运行多个相同类型的作业,从而可能导致的资源争用或数据冲突问题。
适用于那些需要独占资源或顺序执行的任务,以及作业执行时间较长,同时运行多个实例可能会导致系统负载过高的场景。 - Replace(替换):
如果前一个作业仍在运行,则当 CronJob 触发时,将终止当前正在运行的作业并启动一个新的作业。
这允许最新的作业实例始终运行,而旧的作业实例则被新的实例替换。
适用于那些需要确保总是运行最新作业实例的场景,或者作业的执行结果对时间敏感,需要尽快获得最新结果的场景。
在定义 CronJob 时,可以通过设置 spec.concurrencyPolicy 字段来指定所需的并发策略。例如:
apiVersion: batch/v1
kind: CronJob
metadata:
name: my-cronjob
spec:
schedule: "0 */2 * * *" # 每两小时执行一次
concurrencyPolicy: Forbid # 设置并发策略为禁止
jobTemplate:
spec:
# ... 作业模板定义 ...
在这个例子中,my-cronjob CronJob 的并发策略被设置为 Forbid,这意味着如果前一个作业尚未完成,新的作业将不会被启动。
需要注意的是,并发策略只适用于由同一个 CronJob 创建的作业。如果集群中存在多个 CronJob,它们创建的作业之间总是允许并发运行的,除非通过其他机制(如命名空间、资源配额等)进行限制。
此外,CronJob 的并发策略与作业的重启策略(restartPolicy)是独立的。重启策略决定了作业中的 Pod 在失败或完成时应该如何处理,而并发策略则决定了当 CronJob 触发时如何处理新的作业执行。
五、应用场景
CronJob适用于需要定期执行的任务场景,如:
- 定时备份数据库或文件系统。
- 定时清理临时文件或日志。
- 定时发送报告或警报。
- 定时拉取或更新数据(如镜像、代码库等)。
六、示例
以下是一个CronJob的示例YAML文件,它定义了一个每分钟执行一次的作业:
apiVersion: batch/v1
kind: CronJob
metadata:
name: hello-cronjob
spec:
schedule: "*/1 * * * *" # 每分钟执行一次
concurrencyPolicy: Allow # 允许并发执行
successfulJobsHistoryLimit: 5 # 保留5个成功的历史记录
failedJobsHistoryLimit: 3 # 保留3个失败的历史记录
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
command:
- /bin/sh
- -c
- date; echo "Hello from the Kubernetes CronJob!"
restartPolicy: OnFailure # 作业中的Pod失败时重启策略
示例说明
- apiVersion:指定了使用的API版本,这里是batch/v1。
- kind:指明了这是一个CronJob资源。
- metadata.name:CronJob的名称,这里是hello-cronjob。
- spec.schedule:Cron表达式,"*/1 * * * *"表示每分钟执行一次。
- spec.concurrencyPolicy:并发策略设置为Allow,允许并发执行作业。
- spec.successfulJobsHistoryLimit和spec.failedJobsHistoryLimit:分别设置了成功和失败作业的历史记录保留数量。
- spec.jobTemplate.spec.template.spec:定义了作业模板,包括要运行的容器、命令等。这里使用busybox镜像,并执行一个打印当前日期和消息的shell命令。
- spec.jobTemplate.spec.template.spec.restartPolicy:作业中的Pod失败时的重启策略,这里设置为OnFailure,表示在Pod失败时尝试重启。
注意事项
- CronJob的调度时间遵循Cron表达式语法,需要根据实际需求正确配置。
- 需要考虑作业和CronJob的失败重试策略和并发策略,以免产生意外的行为或资源消耗。
- CronJob的执行依赖于Kubernetes集群中的controller-manager组件,因此需要确保该组件正常运行。
- CronJob的并发策略仅适用于由同一个CronJob创建的作业,不同CronJob创建的作业之间总是允许并发运行的。