当前位置: 代码迷 >> 综合 >> 5-2. DaemenSetJob、Cron Job
  详细解决方案

5-2. DaemenSetJob、Cron Job

热度:6   发布时间:2023-12-23 12:47:04.0

文章目录

    • DaemonSet
    • Job、Cron Job

该文档内容来源于尚硅谷K8S教学视频课件尚硅谷

仅用于知识整理,便于后续巩固复习,如有侵权,请联系本人删除

DaemonSet

在简书上找到一篇关于DaemenSet的比较好的介绍

简书 DaemonSet

服务守护进程,它的主要作用是在Kubernetes集群的所有节点中运行我们部署的守护进程,相当于在集群节点上分别部署Pod副本,如果有新节点加入集群,Daemonset会自动的在该节点上运行我们需要部署的Pod副本,相反如果有节点退出集群,Daemonset也会移除掉部署在旧节点的Pod副本。

使用 DaemonSet 的一些典型用法:

  • 网络插件的 Agent 组件,如(Flannel,Calico)需要运行在每一个节点上,用来处理这个节点上的容器网络;
  • 存储插件的 Agent 组件,如(Ceph,Glusterfs)需要运行在每一个节点上,用来在这个节点上挂载F远程存储目录;
  • 监控系统的数据收集组件,如(Prometheus Node Exporter,Cadvisor)需要运行在每一个节点上,负责这个节点上的监控信息搜集。
  • 日志系统的数据收集组件,如(Fluent,Logstash)需要运行在每一个节点上,负责这个节点上的日志信息搜集。

DaemonSet是如何确保每个节点只运行一个Pod?

  1. DaemonSet的控制器模型DaemonSet Controller先从从 Etcd 里获取所有的 Node 列表;
  2. 然后遍历所有的 Node检查,当前这个 Node节点上是不是有一个携带了我们定义标签的 Pod 在运行;
  3. 如果没有定义的 Pod,那么就意味着要在这个 Node 上创建这样一个 Pod;
  4. 如果有定义的 Pod,但是数量大于 1,那就说明要调用 Kubernetes API 把多余的 Pod 从这个 Node 上删除掉;
  5. 如果正好只有一个定义的 Pod,那说明这个节点是正常的。

DaemonSet简易模板

apiVersion: apps/v1
kind: DaemonSet
metadata:name: daemonset-example1labels:app: daemonset
spec:selector:matchLabels:name: daemonset-example1template:metadata:labels:name: daemonset-example1spec:containers:- name: daemonset-exampleimage: wangyanglinux/myapp:v1

Job、Cron Job

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

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

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

??典型的用法如下所示:

  • 在给定的时间点调度 Job 运行
  • 创建周期性运行的 Job,例如:数据库备份、发送邮件

Job简易模板

apiVersion: batch/v1
kind: Job
metadata:name: pispec:template:metadata:name: pispec:containers:- name: piimage: perlcommand: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]restartPolicy: Never

特殊说明

  • spec.template格式同Pod
  • RestartPolicy仅支持Never或OnFailure
  • 单个Pod时,默认Pod成功运行后Job即结束
  • .spec.completions 标志Job结束需要成功运行的Pod个数,默认为1 .spec.parallelism 标志并行运行的Pod的个数,默认为1 spec.activeDeadlineSeconds 标志失败Pod的重试最大时间,超过这个时间不会继续重试

Cron Job简易模板

apiVersion: batch/v1beta1
kind: CronJob
metadata:name: hello
spec:schedule: "*/1 * * * *"jobTemplate:spec:template:spec:containers:- name: helloimage: busyboxargs:- /bin/sh- -c- date; echo Hello from the Kubernetes clusterrestartPolicy: OnFailure
  • .spec.schedule :调度,必需字段,指定任务运行周期,格式同 Cron
  • .spec.jobTemplate :Job 模板,必需字段,指定需要运行的任务,格式同 Job
  • .spec.startingDeadlineSeconds :启动 Job 的期限(秒级别),该字段是可选的。如果因为任何原因而错 过了被调度的时间,那么错过执行时间的 Job 将被认为是失败的。如果没有指定,则没有期限
  • .spec.concurrencyPolicy :并发策略,该字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的 并发执行。只允许指定下面策略中的一种:
    • Allow (默认):允许并发运行 Job
    • Forbid :禁止并发运行,如果前一个还没有完成,则直接跳过下一个
    • Replace :取消当前正在运行的 Job,用一个新的来替换
    • 这里可能有疑问,job每次只创建一个pod,何来并发之说。因为cron job是管理基于时间的job,比如每分钟创建一个job来发送信息,就会出现这样的情况,上一分钟创建的pod还没有结束,就已经来到了下一分钟,此时就又创建了一个job,如果选择的是allow模式,那么这两个job都会继续运行;如果是forbid模式,那么第2个job不会被创建;如果是replace模式,那么前一分钟尚未运行完成的pod直接被删除,用新创建的代替。
  • 注意,当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job,它们创建的 Job 之间总 是允许并发运行。
  • .spec.suspend :挂起,该字段也是可选的。如果设置为 true ,后续所有执行都会被挂起。它对已经开始 执行的 Job 不起作用。默认值为 false 。
  • .spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit :历史限制,是可选的字段。它 们指定了可以保留多少完成和失败的 Job。默认情况下,它们分别设置为 3 和 1 。设置限制的值为 0 ,相 关类型的 Job 完成后将不会被保留。

对于Cron Job来说,创建Job的操作应该是幂等的。(所谓的幂等f(f(x))=f(x), 比如服务调用某个接口得到的返回值始终是不变的,不管何时调用,调用多少次都是如此,这就是幂等。)