k8s中的Pod和Job资源有什么区别?

all*_*tej 10 kubernetes

Pod 和 Job 资源是否相同?

apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
Run Code Online (Sandbox Code Playgroud)

或者

apiVersion: v1
kind: Job
metadata:
  name: ""
  labels:
Run Code Online (Sandbox Code Playgroud)

Job仍然会创建一个吊舱我想。只是想知道我什么时候使用一个而不是另一个。

Sha*_*k V 13

Pod 是在 Kubernetes 上表达可运行进程的基本单元。

Job 是更高级别的抽象,它使用 pod 来运行可完成的任务

您可能正在考虑使用 podrestartPolicy: Never来运行可完成的任务。但是在节点故障的情况下,由 Job 管理的该节点上的 pod 会重新调度到其他节点,而不受管理的 pod 则不会。

Job 还具有额外的功能,例如completionsparallelism可以运行多个实例。

  • 我认为带有 `restartPolicy: Never` 和 `backoffLimit: 0` 的 Job 相当于一个裸 Pod...我是对的吗? (2认同)

Rtm*_*tmY 5

豆荚

作为容器编排器,K8S 使用称为 Pod 的工作单元包装容器。

所有其他资源和组件(我将排除 Kubelet)都是 K8S 模块化架构的一部分,旨在为 Pod 提供不同的功能,例如:调度、扩展、内部和外部网络、处理故障、管理 CPU 和内存等等。

(*) Kubelet 是唯一与容器运行时交互的组件。

你可以说一个 Pod 在它下面包装了一个或多个容器,就像多个进程在一个 VM 中运行一样。如果要从外部访问其中之一,则必须参考主机的 IP 和进程(容器)的端口。

工作 - 从控制器端

(*) 如果这有点高级 - 只需查看下面的 yaml 示例并跳到下一部分。

Job 资源是一组资源的一部分,负责直接引用 Pod 的状态(请参阅最后的直接评论)。

因此,与 ReplicaSet / Deployments、StatefulSet 和 CronJob 等其他资源一起,它们有一个专用控制器,该控制器以无限循环方式在控制平面上运行,并监视由相应资源类型创建的 pod 的更改
因此,如果 Pod 是由 Job 资源创建的:

apiVersion: batch/v1
kind: Job
metadata:
  name: my-computational-job
spec:
  template:
    metadata:
      labels:
         name: my-computational-job
    spec:
      containers:
      - name: my-image
        image: some-image
      restartPolicy: Never #<---- We will discuss this below
Run Code Online (Sandbox Code Playgroud)

将应用于此类资源的每个更改都将由作业控制器检查,该控制器查看资源的新期望状态(或者换句话说,pod 的新状态应该是什么)并决定当前需要执行的操作是什么发生 - 告诉 K8S 删除以前的 pod 并创建新的 pod(例如在更改图像或标签选择器的情况下)或保持 pod 的当前状态,并更改与它们相关的其他配置。

工作 - 从资源方面

那么这种资源有什么特别之处呢?
我们看到它像其他资源一样管理 Pods 状态(带有相应的控制器)。

这里的重点是这些 pod如何配置的?
这也可以称为:
我应该使用此资源运行什么类型的应用程序?

答案是:需要执行专门任务并随后终止的应用程序

为此,作业资源应支持与此类任务相关的配置:

1 ) 重启策略 - 如果我们查看restartPolicy上面 yaml中的字段 - 我们可以指定像onFailureNever但我们不能指定的值,Always因为它与应该使用此资源运行的任务类型相反。
这里阅读更多。

2 ) 顺序或并行运行多个 Pod - 就像我们replicas在副本集/部署规范中指定 K8S 应该扩展多少个 Pod 的字段一样,作业资源具有不同的语法,它也将告诉 K8S 如何运行这些 Pod .

要运行多个作业,您需要在.spec.completions字段中指定 pod 的数量。默认情况下,这些作业将一项一​​项地运行。
为了并行运行它们,您需要指定应该在.spec.parallelism现场并行运行多少个 Pod 。

作业资源支持更高级的配置选项 - 在作业的并行执行中阅读更多内容。

3 ) 失败策略 - 如果我们需要在重试次数后使作业失败,我们可以设置该.spec.backoffLimit字段。
这里阅读更多。


更多参考:
并行计算模式- 请参阅作业模式

基于通用模板运行多个作业 - 请参阅使用扩展进行并行处理


'Jobs - From the controller side' 部分的评论:
很难说资源负责直接引用 Pod 的状态,因为在 K8S 中,架构的每个部分都有特定的模块化角色 - 但在控制器的情况下离那不远,因为他们很安静。


Tan*_*ang 4

如果您的任务将完成,请使用作业(例如,将 \xcf\x80 计算到 2000 个位置并将其打印出来)。

\n\n

在幕后,Job 使用 Pod 进行计算。Imagine Job 是比 Pod 更高级别的抽象。

\n\n

https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

\n