kubernetes之daemonSet和定时任务job,cronjob

kubernetes之daemonSet和定时任务job,cronjob

DeamonSet

保证集群中每个节点上都运行一个Pod副本,当有新的节点加入集群时,DaemonSet会为他们新增一个Pod,当有节点从移除时候,节点上的Pod也会被垃圾收集器回收。删除DaemonSet会删除它创建的所有Pod。

DaemonSet就像计算机的守护进程,他能够运行集群存储,日志收集,和监控等,这些服务一般都是集群的必备基础服务

创建一个daemonSet

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: deamonset-example
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: deamonset-example
  template:
    metadata:
      labels:
        name: deamonset-example
    spec:
      containers:
      - name: daemonset-example
        image: hub.atshooter.com/k8s/nginx:v1.0

matchLabels.name 与 metadata.name 一定要对应 切记切记。否则创建不成功的

img

你会发现创建了2个deamonset-example 节点1和节点2 分别一个。为什么是2个?为什么主节点master没有创建?

记住,所有pod都不会运行到主节点上来,这个跟污点有关系,默认情况下我们的主节点并不会加入到我们的调度任务中来。

所以只有节点1和节点2会创建deamonSet-example副本

job

Job 负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个 Pod 成功结束

  • spec.template格式同Pod
  • RestartPolicy仅支持Never或OnFailure
  • 单个Pod时,默认Pod成功运行后Job即结束
  • .spec.completions 标志Job结束需要成功运行的Pod个数,默认为1
  • .spec.parallelism 标志并行运行的Pod的个数,默认为1
  • .spec.activeDeadlineSeconds 标志失败Pod的重试最大时间,超过这个时间不会继续重试
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

restartPolicy

  • Never永不重启
  • OnFailure 失败后重启

img

job 一次性任务,当pod运行后执行完就停止了

CronJob

CronJob 通过创建Job来对pod进行管理,每一个 Job 对象都会持有一个或者多个 Pod,而每一个 CronJob 就会持有多个 Job 对象,CronJob 能够按照时间对任务进行调度,它与 crontab 非常相似,我们可以使用 Cron 格式快速指定任务的调度时间:
 
cronjob运行流程为  cronjob会先创建job  ——> 然后job会创建pod ——> 然后执行调度 ——> 然后销毁pod   理解为 在高频率的定时任务就是不断的创建pod然后删除pod 个人觉得这样很占用资源

CronJob Spec

  • spec.template格式同Pod
  • RestartPolicy仅支持Never或OnFailure
  • 单个Pod时,默认Pod成功运行后Job即结束
  • .spec.completions 标志Job结束需要成功运行的Pod个数,默认为1
  • .spec.parallelism 标志并行运行的Pod的个数,默认为1
  • spec.activeDeadlineSeconds 标志失败Pod的重试最大时间,超过这个时间不会继续重试
  • .spec.schedule :调度,必需字段,指定任务运行周期,格式同 Cron
  • .spec.jobTemplate :Job 模板,必需字段,指定需要运行的任务,格式同 Job
  • .spec.startingDeadlineSeconds :启动 Job 的期限(秒级别),该字段是可选的。如果因为任何原因而错 过了被调度的时间,那么错过执行时间的 Job 将被认为是失败的。如果没有指定,则没有期限
  • .spec.concurrencyPolicy并发策略,该字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种:
  • Allow (默认):允许并发运行 Job
  • Forbid :禁止并发运行,如果前一个还没有完成,则直接跳过下一个
  • Replace :取消当前正在运行的 Job,用一个新的来替换
  • 注意,当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job,它们创建的 Job 之间总是允许并发运行。
  • .spec.suspend :挂起,该字段也是可选的。如果设置为 true ,后续所有执行都会被挂起。它对已经开始执行的 Job 不起作用。默认值为 false 。
  • .spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit :历史限制,是可选的字段。它们指定了可以保留多少完成和失败的 Job。默认情况下,它们分别设置为 3 和 1 。设置限制的值为 0 ,相关类型的 Job 完成后将不会被保留。

Cron Job 管理基于时间的 Job,即:

  • 在给定时间点只运行一次
  • 周期性地在给定时间点运行

典型的用法如下所示:

  • 在给定的时间点调度 Job 运行
  • 创建周期性运行的 Job,例如:数据库备份、发送邮件
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      completions: 1    #Job结束需要成功运行的Pod个数,默认为1
      parallelism: 1    #标志并行运行的Pod的个数,默认为1
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure  #失败就重新执行

img

cronjob 每分钟创建一个job ,job创建一个pod,执行完任务后终止。

一共显示执行了3次就停止了,是为什么呢?

CronJob 中保存的任务其实是有上限的,spec.successfulJobsHistoryLimit 和 spec.failedJobsHistoryLimit 分别记录了能够保存的成功或者失败的任务上限,超过这个上限的任务都会被删除,默认情况下这两个属性分别为 spec.successfulJobsHistoryLimit=3 和 spec.failedJobsHistoryLimit=1。

如果

completions: 2

那么

img

这就意味着 cronjob 创建的job,每次要创建2个pod,然后等待2个pod执行完任务后终止。当然如果是周期性的,那就是周期性任务每次都要创建一个2个pod的job

img

删除cronjob

kubectl delete cronjob [cronJobName]
 
#有些低版本删除cronjob 后还需要 删除job
 

img