资讯专栏INFORMATION COLUMN

深入K8S Job(一):介绍

ysl_unh / 1813人阅读

摘要:用于批量处理短暂的一次性任务,并保证指定数量的成功结束。一旦有一个成功结束,其他都会准备退出。默认值指定可运行的时间期限,超过时间还未结束,系统将会尝试进行终止。已知问题设置为时,会与冲突,可以暂时将设置为进行规避。

介绍

Kubernetes有两个概念跟job有关:

Job: 负责批量处理短暂的一次性任务,仅执行一次,并保证处理的一个或者多个Pod成功结束。

CronJob: 负责定时任务,在指定的时间周期运行指定的任务。

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进行实现。

参考资料

Jobs - Run to Completion | Kubernetes

Parallel Processing using Expansions | Kubernetes

Coarse Parallel Processing Using a Work Queue | Kubernetes

Fine Parallel Processing Using a Work Queue | Kubernetes

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/32723.html

相关文章

  • 深入K8S Job(二):job controller源码分析

    摘要:用于获取元数据及根据的来匹配该会使用到的接口如下用于根据反推根据获取元数据提供了接口用于获取指定下管理的所有通过的数据变更,比如,来操作该。 k8s version: v1.11.0author: lbl167612@alibaba-inc.com 源码流程图 showImg(https://segmentfault.com/img/remote/1460000016496285?w...

    EddieChan 评论0 收藏0
  • 深入K8S Job(三):cronJob controller源码分析

    摘要:如果没有指定,则没有期限。取消当前正在运行的,然后新建来替换。和这两个字段也是可选的。设置限制值为,相关类型的完成后将不会被保留。列出所有的列出所有的遍历所有的根据字段确定该是否由所创建。 k8s version: v1.11.0author: lbl167612@alibaba-inc.com 源码流程图 showImg(https://segmentfault.com/img/r...

    Enlightenment 评论0 收藏0
  • Kubernetes 核心概念

    摘要:核心概念是最小的调度单元,可以由一个或者多个容器组成。该模式会跟云服务商有关,比如可以通过等创建一个外部的负载均衡器,将请求转发到对应的服务组。而可以提供外部服务可访问的负载均衡器等。 概述 Kubernetes 有各类资源对象来描述整个集群的运行状态。这些对象都需要通过调用 kubernetes api 来进行创建、修改、删除,可以通过 kubectl 命令工具,也可以直接调用 k8...

    Cobub 评论0 收藏0
  • DM 源码阅读系列文章(十)测试框架的实现

    摘要:作者杨非本文为源码阅读系列文章的第十篇,之前的文章已经详细介绍过数据同步各组件的实现原理和代码解析,相信大家对的实现细节已经有了深入的了解。在单元测试中针对不同的场景采用了多种方案。 作者:杨非 本文为 DM 源码阅读系列文章的第十篇,之前的文章已经详细介绍过 DM 数据同步各组件的实现原理和代码解析,相信大家对 DM 的实现细节已经有了深入的了解。本篇文章将从质量保证的角度来介绍 D...

    bawn 评论0 收藏0
  • 容器监控实践—kube-state-metrics

    摘要:功能提供的指标,按照阶段分为三种类别实验性质的中阶段的或者的字段。稳定版本的中不向后兼容的主要版本的更新被废弃的已经不在维护的。通过比较来保证的顺序并不保证包含所有资源本文为容器监控实践系列文章,完整内容见 概述 已经有了cadvisor、heapster、metric-server,几乎容器运行的所有指标都能拿到,但是下面这种情况却无能为力: 我调度了多少个replicas?现在可...

    kevin 评论0 收藏0

发表评论

0条评论

ysl_unh

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<