再战 k8s（10）：job

2022-05-06 15:01:35 浏览数 (1)

文章目录
  • Job
    • Job Spec
    • Job模式
  • CronJob
    • CronJob Spec

Job

Job用于批量处理短暂的一次性任务，并保证指定数量的Pod成功结束。 K8S支持以下几种方式:

  • 非并行Job:
    • 通常只运行一个Pod，Pod成功结束Job就退出。
  • 固定完成次数的并行Job:
    • 并发运行指定数量的Pod，直到指定数量的Pod成功，Job结束。
  • 带有工作队列的并行Job:
    • 用户可以指定并行的Pod数量，当任何Pod成功结束后，不会再创建新的Pod
    • 一旦有一个Pod成功结束，并且所有的Pods都结束了，该Job就成功结束。
    • 一旦有一个Pod成功结束，其他Pods都会准备退出。

Job Spec

完整Job字段可以参考[Job]。Job有几个主要参数配合用于指定完成次数，并发运行，错误重试等操作:

  • .spec.completions: 指定job需要成功运行Pods的次数。默认值: 1
  • .spec.parallelism: 指定job在任一时刻应该并发运行Pods的数量。默认值: 1
  • .spec.activeDeadlineSeconds: 指定job可运行的时间期限，超过时间还未结束，系统将会尝试进行终止。
  • .spec.backoffLimit: 指定job失败后进行重试的次数。默认是6次，每次失败后重试会有延迟时间，该时间是指数级增长，最长时间是6min。

已知问题 Issue #54870 , .spec.template.spec.restartPolicy设置为”Onfailure”时，会与.spec.backoffLimit冲突，可以暂时将restartPolicy设置为”Never”进行规避。 注1： .spec.activeDeadlineSeconds要比.spec.backoffLimit优先级高，如果时间到了，但是backoffLimit还未到，该Job也会被强制停止。

Job模式

Job有几种典型的模式应用于不同的业务场景：

  • 基于Job模版进行扩展:
    • 需要先编写一个通用的Job模版，根据不同的参数生成多个Job json/yml文件用于Job的创建，可以使用相同的标签进行Job管理。
  • 按每个工作项目排列的队列:
    • 需要用户提前准备好一个消息队列服务，比如rabbitMQ，该服务是一个公共组件，每个工作项目可以往里塞任务消息。
    • 用户可以创建并行Job，需要能适用于该消息队列，然后从该消息队列中消费任务，并进行处理直到消息被处理完。
    • 该模式下，用户需要根据项目数量填写spec.completions, 并行数量.spec.parallelism可以根据实际情况填写。该模式下就是以所有的任务都成功完成了，job才会成功结束。
  • 可变任务数量的队列：
    • 需要用户提前准备好一个存储服务来保存工作队列，比如Redis。每个项目可以往该存储服务填充消息。
    • 用户可以启动适用于该工作队列的多个并行Job，进行消息处理。与前一个Rabbit消息队列的差异在于，每个Job任务是可以知道工作队列已经空了，这时候便可以成功退出。
    • 该模式下，spec.completions需要置1， 并行数量.spec.parallelism可以根据实际情况填写。只要其中有一个任务成功完成，该Job就会成功结束。
  • 普通的静态任务

CronJob

cronJob是基于时间进行任务的定时管理：

  • 在特定的时间点运行任务
  • 反复在指定的时间点运行任务：比如定时进行数据库备份，定时发送电子邮件等等。

CronJob Spec

完整的spec字段，可以参考[CronJob]，介绍几个主要的字段：

  • .spec.schedule: 指定任务运行周期，具体格式参考[Cron - Wikipedia]
  • .spec.startingDeadlineSeconds: 指定任务运行的截止时间
  • .spec.concurrencyPolicy: 指定任务的并发策略，参数支持Allow、Forbid和Replace。
  • .spec.jobTemplate: 指定需要运行的任务，格式同[Job]。所以其实cronJob是基于Job进行实现。
消息队列CMQ版 kafka

0 人点赞