K8S Base: 创建Job 与 CronJob
本文介绍 Kubernetes 中的离线任务资源对象 Job 与 CronJob，内容涵盖其业务价值、定义方法及使用方式。具体目录如下：
1. 业务价值
2. 临时任务 API 资源对象 - Job
• Job API 资源对象模板创建
• Job 资源对象定义
• Job 的运行与监控
3. 定时任务 API 资源对象 - CronJob
• CronJob API 资源对象模板创建
• CronJob 资源对象定义
• CronJob 的运行与监控
一、业务价值
Kubernetes 本质上就是云计算领域的操作系统。在处理复杂的分布式系统时，由于服务类型和特性差异巨大，直接使用 Pod 资源对象运行服务并不现实，需要根据具体场景对 Pod 进行定制化封装。
遵循单一职责原则，Kubernetes 已经为离线任务场景封装好了相应的 API 资源对象，即 Job 和 CronJob。这两种对象分别对应临时任务（一次性任务）和周期性任务这两种应用场景。
二、临时任务API资源对象——Job
2.1 创建 Job API 资源对象模板
使用以下命令可以创建一个名为 test-job 的 Job 资源模板：
kubectl create job test-job --image=busybox --dry-run=client -o yaml
执行该命令后，会在当前目录下生成一个名为 test-job 的 Job 类型 API 资源对象的 YAML 文件模板。
2.2 Job 资源对象定义
基于上述生成的 Job 资源对象 YAML 文件，经过适当调整后得到以下配置。Job 资源对象本质上是对 Pod 资源对象的封装实现。如下定义的 Job 任务将通过 echo 命令输出两个参数。
apiVersion: batch/v1 # 注意 Job 资源与其他 API 资源的版本差异
kind: Job
metadata:name: test-job # 可自定义标签的 Job 名称
spec:activeDeadlineSeconds: 20 # 任务执行超时时长backoffLimit: 4 # 最大重试次数completions: 2 # 需要运行的 Pod 数量，默认为 1parallelism: 2 # 并发 Pod 数限制template: # Job 是对 Pod 定义的封装spec:restartPolicy: OnFailure # Pod 重启策略containers:- image: busyboxname: test-jobimagePullPolicy: IfNotPresentcommand: ["/bin/echo"]args: ["hello", "codeSlave"]
Job 资源对象的 restartPolicy 仅支持 Never 和 OnFailure 两种设置。这是由于离线计算任务不应被重启，否则会导致重复计算。同理，Deployment 资源对象的 restartPolicy 必须设置为 Always。
A restartPolicy: Never
该策略表示容器退出后不会自动重启，无论退出状态是成功（Exit Code 0）还是失败。适用于一次性任务或批处理作业，确保任务仅执行一次。例如日志导出、数据迁移等场景，重复执行可能导致数据重复或冲突。
B restartPolicy: OnFailure
该策略仅在容器以非零状态退出（失败）时触发自动重启。适用于需要重试机制的作业，如数据处理任务可能因临时性错误（如网络波动）失败。系统会尝试重新执行任务，直到成功或达到重试限制（需配合其他字段如 backoffLimit 控制最大重试次数）。
C Never 与OnFailure 关键区别
-
退出状态处理：
Never忽略所有退出状态；OnFailure仅对失败状态响应。 -
适用场景：
Never强调一次性执行；OnFailure注重容错和自动恢复。 -
资源释放：
Never在任务结束后立即释放资源；OnFailure可能因重试占用资源更长时间。
activeDeadlineSeconds
该参数定义任务从启动到强制终止的最大允许运行时间（单位：秒）。如果任务中的Pod运行时间超过该值，整个Job会被系统终止，所有未完成的Pod将被标记为失败。适用于需要严格控制执行时长的场景，例如批处理任务或定时任务。
关键点：
-
超时后Job状态变为
DeadlineExceeded。 -
超时设置对单个Pod无效，仅作用于整个Job生命周期。
-
若未设置，Job可能因Pod卡住而无限运行。
backoffLimit
指定Job在标记为失败前允许Pod重试的最大次数。每次Pod失败后，系统会按指数退避策略（如2s、4s、8s…）延迟重启Pod，直到达到该限制。
关键点：
-
默认值为6，若设为0则禁止重试。
-
达到重试上限后，Job状态变为
Failed，已创建的Pod不会被自动删除。 -
需结合Pod的退出码（非0表示失败）或容器故障触发重试。
completions
定义Job需要成功完成的Pod数量。例如设为2时，需有2个Pod成功退出（退出码为0），Job才标记为完成。适用于需要多次独立执行的任务，如数据处理分片。
关键点：
-
默认值为1，即1个Pod成功即可。
-
每个Pod需独立完成任务，系统会跟踪成功次数。
-
与
parallelism配合可实现分批次并发执行。
parallelism
控制Job同时运行的Pod最大并发数。例如设为2时，即使completions为10，也最多同时启动2个Pod。
关键点：
-
默认值为1，即串行执行。
-
若
completions未设置，实际并发数可能超过parallelism（取决于Pod完成速度）。 -
动态调整：可通过
kubectl scale job <name> --replicas=N实时修改。
2.3 运行并监控 Job 任务
执行以下命令通过预定义的 YAML 文件启动 Job：
kubectl apply -f job.yaml
使用以下命令组合监控 Job 运行状态：
-
查看 Job 资源状态
-
检查关联 Pod 的运行情况
-
通过日志追踪任务执行进度
kubectl get job
kubectl get pod
kubectl logs {pod_name} # 查看任务执行日志
三、定时任务API资源对象 —— CronJob
CronJob 资源对象是在 Job 资源对象基础上进行的扩展封装。
3.1 创建 CronJob API 资源对象模板
执行以下命令生成 CronJob 资源对象的 YAML 模板：
kubectl create cj test-cronJob --image=busybox --schedule="" --dry-run=client -o yaml
该命令会在当前目录下生成包含 CronJob 资源定义的 YAML 配置文件。
3.2 CronJob API 资源对象定义
基于上述创建的 CronJob 资源对象 YAML 模板进行调整后，可得到如下定义。从该定义可以看出：
-
通过
schedule字段中的 cron 表达式可以设定定时任务的执行周期 -
CronJob资源对象是在Job资源对象基础上进行的封装
apiVersion: batch/v1 # API版本
kind: CronJob # 资源类型
metadata:name: test-cronjob # 资源名称
spec:schedule: '*/1 * * * *' # 定时任务执行周期jobTemplate: # Job模板定义spec:activeDeadlineSeconds: 20 # 任务超时时间backoffLimit: 4 # 最大重试次数completions: 2 # 需要运行的Pod数量parallelism: 2 # 并发Pod数量限制template:spec:restartPolicy: OnFailurecontainers:- image: busyboxname: test-cronjobimagePullPolicy: IfNotPresentcommand: ["/bin/echo"]args: ["hello", "codeSlave"]
3.3 运行和监控 CronJob
执行以下命令来运行已定义的 cronJob:
kubectl apply -f cron-job.yaml
通过以下命令监控 cronJob 的运行状态:
# 查看 cronJob 列表
kubectl get cj# 查看任务列表
kubectl get job# 实时监控 pod 状态（-w 参数启用持续观察模式）
kubectl get pod -w# 查看指定 pod 的日志
kubectl logs {pod_name}# 获取 pod 的详细运行信息
kubectl describe {pod_name}