32 K8S 之 DaemonSet/Job/CronJob 控制器

Deployment 仅用于保证在集群上精确运行多少个工作负载的实例，但有些系统级应用却需要在集群中的每个节点上精确运行单个实例，这就是 DaemonSet 控制器的核心功用所在。系统级工作负载的副本数量取决于集群中的节点数，而非由用户通过 replicas 进行定义，更重要的是，后续新加入集群的工作节点也会由 DaemonSet 对象自动创建并运行为一个相关 Pod，而从集群移除节点时，该类 Pod 对象也将被自动回收且无须重建。

DaemonSet 是一种特殊的控制器，它有着特定的应用场景，通常用于运行那些执行系统级操作任务的应用。

• 运行集群存储的守护进程，例如在每个节点上运行的 glusterd 可用于接入 Gluster 集群；

• 在每个节点上运行日志收集守护进程，例如 fluentd、filebeat 和 logstash 等；

• 在每个节点上运行监控系统的代理守护进程，例如 Prometheus NodeExporter、collectd、Datadog agent、New Relic agent，或 Ganglia gmond 等。

DaemonSet 是标准的 API 资源类型，它的 spec 字段中嵌套使用的字段也需要使用 selector、template 和 minReadySeconds，并且它们各自的功能和用法基本相同，但 DaemonSet 不支持使用 replicas，毕竟 DaemonSet 不是基于期望的副本数，而是基于节点数量来控制 Pod 资源数量，但 template 是必选字段。另外，DaemonSet 也支持策略式更新，它支持 OnDelete 和 RollingUpdate 两种策略，也能够为滚动更新保存修订记录。

偶尔也存在需要将 Pod 对象以单一实例形式运行在集群中的部分工作节点，例如有些拥有特殊硬件节点需要运行特定的监控代理程序等。这仅需要在 Pod 模板的 spec 字段中嵌套使用 nodeSelector 字段，并确保其值定义的标签选择器与部分特定工作节点的标签匹配即可。

考虑到大多数系统级应用的特殊性，DaemonSet 资源的各 Pod 实例通常需要被单独访问而不能隐藏在某个 Service 对象之后。

Job 控制器常用于管理那些运行一段时间就能够“完成”的任务，例如计算或备份操作。容器中的进程正常运行完成而结束后不需要再重启，而是由控制器把该 Pod 对象置于 Completed（完成）状态，并能够在超过用户指定的生存周期后由系统自行删除。但是，若容器中的进程因“错误”（而非完成）而终止，则需要依据配置来确定其重启与否，通常，未运行完成的 Pod 对象因其所在的节点故障而意外终止后会被重新创建。

CronJob 资源用于管理 Job 资源的运行时间，它允许用户在特定的时间或以指定的间隔运行 Job，它适合自动执行特定的任务，例如备份、报告、发送电子邮件或清理类的任务等。

CronJob 资源使用的时间格式类似于 Linux 系统上的 crontab，稍具不同之处是，CronJob 资源在指定时间点时，通配符“?”和“*”的意义相同，它们都表示任何可用的有效值。CronJob 资源使用 Job 对象来完成任务，它每次运行时都会创建一个 Job 对象，并使用类似于 Job 资源的创建、管理和扩容方式。Cronjob 也是 Kubernetes 系统标准的 API 资源。

PDB（PodDisruptionBudget，Pod 中断预算）类型的资源，用于为那些自愿的中断做好预算方案，限制可自愿中断的最大 Pod 副本数或确保最少可用的 Pod 副本数，以确保服务的高可用性。

PDB 资源的核心目标在于保护由控制器管理的应用，这必然意味着 PDB 将使用等同于相关控制器对象的标签选择器以精确关联至目标 Pod 对象。PDB 支持的控制器类型包括 Deployment、ReplicaSet 和 StatefulSet 等。同时，PDB 对象也可以用来保护那些纯粹是由定制的标签选择器自由选择的 Pod 对象。

并非所有的自愿中断都会受到 PDB 的约束，例如，删除 Deployment 或者 Pod 的操作就会绕过 PDB。另外，尽管那些因删除或更新操作导致不可用的 Pod 也会计入预算，但是控制器（例如 Deployment）滚动更新时并不会真的被相关联的 PDB 资源所限制。