1、Job：管理任务的控制器

概念

• 首先 kubernetes 的 Job 是一个管理任务的控制器，它可以创建一个或多个 Pod 来指定 Pod 的数量，并可以监控它是否成功地运行或终止；
• 可以根据 Pod 的状态来给 Job 设置重置的方式及重试的次数；
• 可以根据依赖关系，保证上一个任务运行完成之后再运行下一个任务；
• 同时还可以控制任务的并行度，根据并行度来确保 Pod 运行过程中的并行次数和总体完成大小。

yaml文件

• 第一个是 restartPolicy，在 Job 里面可以设置 Never、OnFailure、Always 这三种重试策略。在希望 Job 需要重新运行的时候，可以用 Never；希望在失败的时候再运行，再重试可以用 OnFailure；或者不论什么情况下都重新运行时 Alway；
• Job 在运行的时候不可能去无限的重试，所以我们需要一个参数来控制重试的次数。这个 backoffLimit 就是来保证一个 Job 到底能重试多少次。

查看状态

• kubectl get jobs
• kubectl get pods job
  • 它比普通的 Pod 多了一个叫 ownerReferences，这个东西来声明此 pod 是归哪个上一层 controller 来管理。可以看到这里的 ownerReferences 是归 batch/v1，也就是上一个 Job 来管理的。这里就声明了它的 controller 是谁，然后可以通过 pod 返查到它的控制器是谁，同时也能根据 Job 来查一下它下属有哪些 Pod。

并行运行参数

• 第一个参数completetions：是用来指定本 Pod 队列执行次数。可能这个不是很好理解，其实可以把它认为是这个 Job 指定的可以运行的总次数。比如这里设置成 8，即这个任务一共会被执行 8 次；
• 第二个参数parallelism：并行执行的个数。所谓并行执行的次数，其实就是一个管道或者缓冲器中缓冲队列的大小，把它设置成 2，也就是说这个 Job 一定要执行 8 次，每次并行 2 个 Pod，这样的话，一共会执行 4 个批次。

定时任务

• schedule：schedule 这个字段主要是设置时间格式，它的时间格式和 Linux 的 crontime 是一样的，所以直接根据 Linux 的 crontime 书写格式来书写就可以了。举个例子： */1 指每分钟去执行一下 Job，这个 Job 需要做的事情就是打印出大约时间，然后打印出“Hello from the kubernetes cluster” 这一句话；
• startingDeadlineSeconds：即：每次运行 Job 的时候，它最长可以等多长时间，有时这个 Job 可能运行很长时间也不会启动。所以这时，如果超过较长时间的话，CronJob 就会停止这个 Job；
• concurrencyPolicy：就是说是否允许并行运行。所谓的并行运行就是，比如说每分钟执行一次，但是这个 Job 可能运行的时间特别长，假如两分钟才能运行成功，也就是第二个 Job 要到时间需要去运行的时候，上一个 Job 还没完成。如果这个 policy 设置为 true 的话，那么不管前面的 Job 是否运行完成，每分钟都会去执行；如果是 false，它就会等上一个 Job 运行完成之后才会运行下一个；
• JobsHistoryLimit：这个就是每一次 CronJob 运行完之后，它都会遗留上一个 Job 的运行历史、查看时间。当然这个额不能是无限的，所以需要设置一下历史存留数，一般可以设置默认 10 个或 100 个都可以，这主要取决于每个人集群不同，然后根据每个人的集群数来确定这个时间。

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello aliang
          restartPolicy: OnFailure

管理模式与Job控制器

• 所有的 job 都是一个 controller，它会 watch 这个 API Server，每次提交一个 Job 的 yaml 都会经过 api-server 传到 ETCD 里面去，然后 Job Controller 会注册几个 Handler，每当有添加、更新、删除等操作的时候，它会通过一个内存级的消息队列，发到 controller 里面。
• 通过 Job Controller 检查当前是否有运行的 pod，如果没有的话，通过 Scale up 把这个 pod 创建出来；如果有的话，或者如果大于这个数，对它进行 Scale down，如果这时 pod 发生了变化，需要及时 Update 它的状态。
• 同时要去检查它是否是并行的 job，或者是串行的 job，根据设置的配置并行度、串行度，及时地把 pod 的数量给创建出来。最后，它会把 job 的整个的状态更新到 API Server 里面去，这样就能看到呈现出来的最终效果了。

跟踪 Pod 状态，根据配置及时重试失败的 Pod
确定依赖关系，保证上一个任务运行完毕后再运行下一个任务
控制任务并行度，并根据配置确保 Pod 队列大小

2、DaemonSet：守护进程控制器

概念

• 首先能保证集群内的每一个节点都运行一组相同的 pod；
• 同时还能根据节点的状态保证新加入的节点自动创建对应的 pod；
• 在移除节点的时候，能删除对应的 pod；
• 跟踪每个 pod 的状态，当这个 pod 出现异常、Crash 掉了，及时地去 recovery 这个状态。

yaml 语法

更新策略

• RollingUpdate会一个一个的更新。先更新第一个 pod，然后老的 pod 被移除，通过健康检查之后再去见第二个 pod，这样对于业务上来说会比较平滑地升级，不会中断；
• OnDelete 模板更新之后，pod 不会有任何变化，需要手动控制。去删除某一个节点对应的 pod，它就会重建，不删除的话它就不会重建。

3、控制pod在node上运行

节点亲和力（node affinity）。 亲和力（Affinity）是一个pod设置项，使它们偏好具有某些属性的节点。例如，某些pod可能需要在带有GPU或SSD的计算机上运行，或者某些pod可能需要具有特定安全隔离或特定策略的节点。重复检查关联设置可以帮助缩小 导致不均匀分配的原因的范围，并降低严峻问题发生的可能性 。

污点（taints）和容忍(tolerations)。污点与亲和力相反。这些是节点的设置项，给节点设置污点，从而使pod 难以调度到这些节点。如果要为特定pod保留节点，或者为了确保该节点上的pod对可用资源具有完全访问权限，则可以使用此选项 。

Taint 和 toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 pod，是不会被该节点接受的。如果将 toleration 应用于 pod 上，则表示这些 pod 可以（但不要求）被调度到具有相应 taint 的节点上