k8s学习之路 | k8s 工作负载 Job

1. Job 基础

1.1 Job 资源

Job 负载资源会创建一个或者多个 Pod，并将继续重试 Pod 的执行，直到指定数量的 Pod 成功终止

• Pod 执行成功，Job 跟踪记录成功完成的 Pod个数
• 数量达到指定的成功个数阈值，Job 结束
• 删除 Job 的操作会清除所创建的全部 Pod
• 挂起 Job 的操作会删除 Job 的所有活跃 Pod，直到 Job 被再次恢复执行

1.2 使用场景

• 创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成
• 以使用 Job 以并行的方式运行多个 Pod

1.3 示例 Job

来自官方的示例

####job-demo.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
spec:
  template:
    spec:
      containers:
      - name: job-demo
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

运行一下

kubectl apply -f job.yaml

查看一下

看一下日志

• 这次的 Job 任务就是计算 π 到小数点后 2000 位

1.4 编写 Job

还是老办法，官网说明加 kubectl explain job

基础的内容

• apiVersion
• kind
• metadata

##这部分资源基本都是通用的
apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
  namspace: test

---

spec 规约

job.spec 描述了任务执行的具体情况信息

FIELDS:
   activeDeadlineSeconds        >
## 系统尝试终止任务之前任务可以持续活跃的持续时间（秒），时间长度是相对于 startTime 的； 字段值必须为正整数。如果任务被挂起（在创建期间或因更新而挂起）， 则当任务再次恢复时，此计时器会被停止并重置
   backoffLimit >
## 指定标记此任务失败之前的重试次数。默认值为 6。

   completionMode       >
## 指定如何跟踪 Pod 完成情况。它可以是 NonIndexed （默认） 或者 Indexed。
## NonIndexed 表示当有 .spec.completions 个成功完成的 Pod 时，认为 Job 完成。每个 Pod 完成都是彼此同源的。
## Indexed 意味着 Job 的各个 Pod 会获得对应的完成索引值，从 0 到（.spec.completions - 1），可在注解 "batch.kubernetes.io/job-completion-index" 中找到。当每个索引都对应有一个成功完成的 Pod 时， 该任务被认为是完成的。 当值为 Indexed 时，必须指定 .spec.completions 并且 .spec.parallelism 必须小于或等于 10^5。 此外，Pod 名称采用 $(job-name)-$(index)-$(random-string) 的形式，Pod 主机名采用 $(job-name)-$(index) 的形式。
   completions  >
## 指定任务应该运行并预期成功完成的 Pod 个数。设置为 nil 意味着任何 Pod 的成功都标识着所有 Pod 的成功， 并允许 parallelism 设置为任何正值。设置为 1 意味着并行性被限制为 1，并且该 Pod 的成功标志着任务的成功。

   manualSelector       >
## manualSelector 控制 Pod 标签和 Pod 选择器的生成。

   parallelism  >
## 指定任务应在任何给定时刻预期运行的 Pod 个数上限。 

   selector     >
## 对应与 Pod 计数匹配的 Pod 的标签查询。通常，系统会为你设置此字段

   suspend      >
## 指定 Job 控制器是否应该创建 Pod。如果创建 Job 时将 suspend 设置为 true，则 Job 控制器不会创建任何 Pod。 如果 Job 在创建后被挂起（即标志从 false 变为 true），则 Job 控制器将删除与该 Job 关联的所有活动 Pod。 用户必须设计他们的工作负载来优雅地处理这个问题。暂停 Job 将重置 Job 的 startTime 字段， 也会重置 ActiveDeadlineSeconds 计时器。默认为 false。

   template     > -required-
## 描述执行任务时将创建的 Pod。

   ttlSecondsAfterFinished      >
## 限制已完成执行（完成或失败）的任务的生命周期。如果设置了这个字段， 在 Job 完成 ttlSecondsAfterFinished 秒之后，就可以被自动删除。 当 Job 被删除时，它的生命周期保证（例如终结器）会被考察。 如果未设置此字段，则任务不会被自动删除。如果此字段设置为零，则任务在完成后即可立即删除。

1.5 一些特性

Pod 选择算符

字段 .spec.selector 是可选的。在绝大多数场合，你都不需要为其赋值

Job 的并行执行

• 非并行执行
  • 只启动一个 Pod，除非它失败了
  • Pod 执行成功了，立即视为 Job 完成了
• 具有确定完成计数的并行 Job
  • .spec.completions 字段设置为非 0 的正数值
  • Job 用来代表整个任务，当对应于 1 和 .spec.completions 之间的每个整数都存在 一个成功的 Pod 时，Job 被视为完成
• 带工作队列的并行 Pod
  • 不设置 spec.completions，默认值为 .spec.parallelism
  • 多个 Pod 之间必须相互协调，或者借助外部服务确定每个 Pod 要处理哪个工作条目。 例如，任一 Pod 都可以从工作队列中取走最多 N 个工作条目。
  • 每个 Pod 都可以独立确定是否其它 Pod 都已完成，进而确定 Job 是否完成
  • 当 Job 中 任何 Pod 成功终止，不再创建新 Pod
  • 一旦至少 1 个 Pod 成功完成，并且所有 Pod 都已终止，即可宣告 Job 成功完成
  • 一旦任何 Pod 成功退出，任何其它 Pod 都不应再对此任务执行任何操作或生成任何输出。 所有 Pod 都应启动退出过程。

_{这个感觉理解还不够}

• 对于 非并行的 Job，你可以不设置 spec.completions 和 spec.parallelism。 这两个属性都不设置时，均取默认值 1。
• 对于确定完成计数类型的 Job，你应该设置 .spec.completions 为所需要的完成个数。 你可以设置 .spec.parallelism，也可以不设置。其默认值为 1。
• 对于一个 工作队列Job，你不可以设置 .spec.completions，但要将.spec.parallelism 设置为一个非负整数。

2. Job 特性用例

2.1 运行一次 Job

准备一个示例文件

###job-demo.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
  namespace: default
  labels:
    app: job-demo
spec:
  template:
    metadata:
      name: job-demo
      labels:
        app: job-demo
    spec:
      restartPolicy: Never
      containers:
      - name: job-demo
        image: nginx:1.23

尝试运行一下

• 可以发现这个 Job 一直无法完成
• 因为这个容器运行起来，没有结束的时候，阻塞了

重新修改一下这个文件

###job-demo.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
  namespace: default
  labels:
    app: job-demo
spec:
  template:
    metadata:
      name: job-demo
      labels:
        app: job-demo
    spec:
      restartPolicy: Never
      containers:
      - name: job-demo
        image: nginx:1.23
        command: ["/bin/sh",  "-c","echo hello world;sleep 30;"]

重新运行一下，跟踪状态

• Pod 结束

• Job 完成

2.2 自动清理完成的 Job

发现 Job 完成以后，Pod 依然存在，完成的 Job 通常不需要留存在系统中，在系统中一直保留它们会给 API 服务器带来额外的压力

• 自动清理已完成 Job （状态为 Complete 或 Failed）的另一种方式是使用由 TTL 控制器 所提供 的 TTL 机制。 通过设置 Job 的 .spec.ttlSecondsAfterFinished 字段，可以让该控制器清理掉 已结束的资源。如果该字段设置为 0，Job 在结束之后立即成为可被自动删除的对象。 如果该字段没有设置，Job 不会在结束之后被 TTL 控制器自动清除。

• 尝试一下

###job-demo.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
  namespace: default
  labels:
    app: job-demo
spec:
  ttlSecondsAfterFinished: 20 ##任务完成以后，20s自动清理Pod
  template:
    metadata:
      name: job-demo
      labels:
        app: job-demo
    spec:
      restartPolicy: Never
      containers:
      - name: job-demo
        image: nginx:1.23
        command: ["/bin/sh",  "-c","echo hello world;sleep 30;"]

• 运行并追踪一下状态

2.3 更多特性

参考官网：https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/job/

_{最近感觉学习有点慢，工作事情太多了，感觉没啥子动力了}