Job、CronJob

Job、CronJob

Job

负责批处理任务
Job的RestartPolicy不能是Always,只能是OnFailure或Never

按照批处理任务实现方式的不同,批处理任务可以分为如下的几种模式

Job Template Expansion(扩展工作模板)
1.一个Job对象对应一个待处理的工作项,有几个工作项就有几个Job对象
2.适合工作项数量少,每个工作项处理的数据量大的场景。例如:一共有10个工作项,一个工作项处理100G大小的文件

Queue with Pod Per Work Item(基于队列的工作项)常用
采用任务队列存放工作项,只用一个Job对象来完成工作项,该模式下Job会创建多个Pod,每个Pod对应一个工作项,Pod数=工作项数

Queue with Variable Pod Count(可变队列)常用
也是采用任务队列存放工作项,与上边不同是,Pod的数量可变,和工作项不再是一一对应的关系

Single Job with Static Work Assignment(静态分配)
一个Job对象来完成工作项,该模式下Job会创建多个Pod,静态分配工作项,而不是使用队列来动态分配

批处理模式对比

模式名称 是否为一个Job Pod的数量少于workitem 用户程序是否需要做相应的修改 k8s是否支持
Job Template Expansion
Queue with Pod Per Work Item 有时候需要
Queue with Variable Pod Count
Single Job with Static Work Assignment

按照并行运行批处理任务, Kubemetes将Job分以下三种类型

* Non-parallel Jobs(非并行)
通常一个Job只启动一个Pod, 除非Pod异常, 才会重启该Pod, 一旦此Pod正常结束, Job将结束。

* Parallel Jobs with a fixed completion count(基于固定完成数的并行)
1.并行Job会启动多个Pod, 此时需要设定Job的.spec.completions参数为一个正数, 当正常结束的Pod数量达至此参数设定的值后, Job结束。
2.Job的.spec.parallelism参数用来控制并行度, 即同时启动几个Job来处理Work Item。

* Parallel Jobs with a work queue(基于队列的并行)
1.此种Job需要一个独立的Queue, Work item都在一个Queue中存放, 不能设置Job的.spec.completions参数
2.此种Job有以下特性
   - 每个Pod都能独立判断和决定是否还有任务项需要处理。
   - 如果某个Pod正常结束, 则Job不会再启动新的Pod。
   - 如果一个Pod成功结束, 则此时应该不存在其他Pod还在工作的情况, 它们应该都处于即将结束、 退出的状态。
   - 如果所有Pod都结束了, 且至少有一个Pod成功结束, 则整个Job成功结束。

Job Template Expansion模式

由于在这种模式下每个Work item对应一个Job实例, 所以这种模式首先定义一个Job模板, 模板里的主要参数是Work item的标识, 因为每个Job都处理不同的Work item。

1、定义一个Job模板(文件名为job.yaml.txt) 中的$ITEM可以作为任务项的标识:
apiVersion: batch/v1
kind: Job
metadata:
  name: process-item-$ITEM
  labels:
    jobgroup: jobexample
spec:
  template:
    metadata:
      name: jobexample
      labels:
       jobgroup: jobexample
    spec:
      containers:
      - name: c
        image: busybox
        command: ["sh", "-c", "echo Processing item $ITEM && sleep 5"]
      restartPolicy: Never

2、生成3个对应的Job定义文件并创建Job
for i in {1..3};do cat job.yaml.txt | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml;done
kubectl create -f jobs

3、观察job运行情况
kubectl get jobs -l jobgroup=jobexample

Queue with Pod Per Work Item模式

在这种模式下需要一个任务队列存放Work item, 比如RabbitMQ, 客户端程序先把要处理的任务变成Work item放入任务队列, 然后编写Worker程序、 打包镜像并定义成为Job中的Work Pod。 Worker程序的实现逻辑是从任务队列中拉取一个Work item并处理, 在处理完成后即结束进程。 

并行度为2的Demo示意图如图

6f41e96568257d56a109272bcb850ccd.png

Queue with Variable Pod Count模式

由于这种模式下, Worker程序需要知道队列中是否还有等待处理的Work item, 如果有就取出来处理, 否则就认为所有工作完成并结束进程, 所以任务队列通常要采用Redis或者数据库来实现。

redis消息队列
https://www.jianshu.com/p/02a923fea175

5dbc1f341d286e3854a17bd8ca79b510.png

Cron Job

类似于计划任务,在指定时间点调度job运行,如数据库备份,发送邮件

* 格式
分 时 日 月 周 年

分: 可出现 ,  -  *  / 这4个字符, 有效范围为0~59的整数。
时: 可出现 ,  -  *  / 这4个字符, 有效范围为0~23的整数。
日: 可出现 ,  -  *  / ?  L  W  C 这8个字符, 有效范围为0~31的整数。
月: 可出现 ,  -  *  / 这4个字符,有效范围为1~12的整数或JAN~DEC。
周: 可出现 ,  -  *  / ?  L  C  # 这8个字符,有效范围为1~7的整数或SUN~SAT。1表示星期天,2表示星期一。

* 与 / 的含义如下。
*: 表示匹配该域的任意值, 假如在Minutes域使用“*”, 则表示每分钟都会触发事件。
/: 表示从起始时间开始触发, 然后每隔固定时间触发一次,
    例如:在Minutes域设置为5/20, 则意味着第1次触发在第5min时,接下来每20min触发一次, 将在第25min、 第45min等时刻分别触发。

创建cronjob

cronjob并不能判断job的运行结果,创建job的操作是幂等的

vim cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-date
  labels:
    cronjob: cronjob-date
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    metadata:
      name: cronjob-job
      labels:
        cronjobjob: cronjob-job
    spec:
      template:
        metadata:
          name: cronjob-pod
          labels:
            cronjobpod: cronjob-pod
        spec:
          containers:
          - name: cj
            image: busybox:1.28
            imagePullPolicy: Never
            command: ["sh", "-c", "date '+%x %T'"]
          restartPolicy: OnFailure

字段
.spec.schedule              必须字段,指定任务运行周期
.spec.jobTemplate           必须字段,指定需要运行的任务,格式同job
.spec.startintDeadlingSeconds   可选字段,如果cronjob在该时间内没有成功结束退出,则认定执行失败。不指定表示没有限制时间
.spec.concurrencyPolicy      并发策略
   Allow(默认)              允许并发运行Job
   Forbid                    禁止并发运行Job
   Replace                   取消当前正在运行的Job,用新的来替换
.spc.suspend                 挂起,可选字段,默认false,若为true,后续所有执行的job都会被挂起。对已经执行的job不生效
.spec.successfulJobsHistoryLimit         可选字段,指定可以保留多少完成的job,默认3
.spec.failedJobHistoryLimit              可选字段,指定可以保留多少失败的job,默认1

创建

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  JobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the K8S cluster
          restartPolicy: OnFailure
posted @   立勋  阅读(35)  评论(0编辑  收藏  举报
编辑推荐:
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
阅读排行:
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· Manus的开源复刻OpenManus初探
· 写一个简单的SQL生成工具
· AI 智能体引爆开源社区「GitHub 热点速览」
· C#/.NET/.NET Core技术前沿周刊 | 第 29 期(2025年3.1-3.9)
点击右上角即可分享
微信分享提示