第五章.k8sPod控制器-Pod控制器8> 来源链接：https://www.bilibili.com/video/BV1PbeueyE8V?spm_id_from=333.788.videopod.episodes&vd_source=0e85828f19fba96334ebaebea2da3e2f&p=30

第五章 k8s Pod控制器 第8节 DaemonSet与Job控制器

本小节内容基于Kubernetes v1.29版本讲解，承接上一节Deployment控制器内容，重点讲解DaemonSet、Job两类Pod控制器的核心特性、适用场景及配置方法。

DaemonSet 控制器

需求引出

使用Deployment控制器无法实现「每个节点有且仅有一个Pod运行」的需求：Deployment的调度机制不保证节点唯一性，实际运行时可能出现某节点运行多个Pod、部分节点无Pod的情况，和需求不符。

核心定义与特性

DaemonSet是Kubernetes中专用于节点级单实例部署的控制器，核心特性如下：

• 保障全部/部分指定节点上运行且仅运行一个目标Pod
• 当新节点加入集群时，DaemonSet会自动为新节点创建对应Pod
• 当节点从集群移除时，DaemonSet会自动回收该节点上的对应Pod
• 删除DaemonSet资源时，会自动删除其创建的所有Pod

调度限制说明

并非所有节点都支持调度DaemonSet创建的Pod：Kubernetes集群的Master节点默认带有污点（Taint），默认调度策略为NoSchedule，禁止普通Pod调度到Master节点。后续学习调度章节的「容忍（Toleration）」配置后，可手动为Pod配置容忍规则，实现Pod调度到Master节点。

典型应用场景

DaemonSet适用于需要在每个节点运行单实例的场景，常见使用场景包括：

• 分布式存储组件：比如Ceph的MDS（元数据服务器），需要在每个节点运行单实例，收集节点可用存储资源加入分布式存储池，多实例运行会出现资源冲突，因此基于DaemonSet部署是唯一选择
• 日志收集组件：比如ELK栈的Filebeat、Loki生态的Promtail，需要在每个节点收集日志并推送到Elasticsearch/Loki，后续通过Kibana/Grafana做日志展示；后续也会讲解基于Grafana Loki的轻量日志方案，部署方式同样基于DaemonSet
• 监控采集组件：比如Prometheus的Node Exporter，需要在每个节点采集主机指标，通过HTTP接口暴露给Prometheus抓取，部署方式基于DaemonSet
• 其他节点级单实例组件：比如网络插件、安全Agent、节点监控Agent等

配置与实验演示

YAML配置说明

DaemonSet的资源类型为apps/v1，kind字段值为DaemonSet（官方支持缩写DS），核心配置结构和Deployment高度相似：

• .spec.selector：用于匹配DaemonSet管理的Pod标签，支持标签运算符
• .spec.template：Pod创建模板，和Deployment的Pod模板结构完全一致，可配置容器镜像、生命周期、资源限制等所有Pod特性
• 无需配置replicas字段：DaemonSet会自动匹配当前可调度节点数量创建对应数量的Pod，无需管理员手动调整

快速生成模板技巧

如果忘记DaemonSet的YAML写法，可通过以下步骤快速生成模板：

1. 执行kubectl create deployment <名称> --image=<镜像> --dry-run=client -o yaml生成Deployment模板
2. 修改模板的kind字段为DaemonSet，删除replicas字段即可得到可直接使用的DaemonSet YAML模板

实验效果验证

实验环境为3节点Kubernetes集群（1个Master节点、2个Worker节点）：

• 创建DaemonSet后，由于Master节点默认有污点，Pod仅会运行在2个Worker节点，每个节点1个Pod，共2个Pod，符合单实例预期
• 新增Worker节点后，无需修改DaemonSet配置，会自动在新节点创建对应Pod，Pod总数自动匹配可调度节点数量
• 移除Worker节点后，DaemonSet会自动回收该节点上的Pod，Pod总数自动减少
• 删除DaemonSet资源后，其创建的所有Pod会被自动清理

Job 控制器

需求背景与适用场景

Kubernetes中的应用任务可分为两类：

• 守护进程类：长期持续运行，对外提供服务，不会主动退出，比如MySQL、Nginx、Redis等，需要主动发送停止信号才会终止
• 批处理类：有明确的业务逻辑和退出条件，执行完固定任务后就会主动退出，比如数据库备份脚本、数据迁移脚本、批量数据导入导出任务等
  之前学习的ReplicaSet、Deployment、DaemonSet三类控制器均适用于守护进程类应用，无法满足批处理任务的运行需求。

批处理任务的使用痛点（以数据库备份为例）

如果使用Deployment部署数据库备份Pod：

• 备份脚本执行完备份任务后，Pod会主动退出（退出码为0，代表任务成功）
• 由于Deployment默认重启策略为Always，控制器会创建新的Pod再次执行备份任务，导致无限重复备份，完全不符合业务预期
• 若备份逻辑需要锁表，无限重复备份还会导致数据库锁表时间过长，严重影响业务可用性

Job控制器核心定义

Job是Kubernetes中专用于处理批处理任务的控制器，核心特性为：保障批处理任务的一个或多个Pod成功结束。

• 「成功结束」判定标准：Pod中容器的退出码为0，代表任务执行成功；退出码非零代表任务执行失败。

核心配置选项

1. Pod模板：.spec.template字段和之前控制器的Pod模板结构一致，可配置容器镜像、生命周期钩子、资源限制等所有Pod特性，备份任务等需要的脚本可通过Init容器或共享Volume的方式传入Pod
2. 重启策略：Job仅支持两种重启策略，和守护进程类控制器的重启策略有明确区分：
   • Never：永不重启，无论Pod是正常退出（退出码0）还是异常退出（退出码非零），都不会创建新Pod替代，任务执行完成后Pod会保持终止状态
   • OnFailure：仅失败时重启，如果Pod退出码为0（任务成功）则不创建新Pod，退出码非零（任务失败）则创建新Pod重新执行任务，直到任务成功为止

AI 总结

本小节讲解了两类Kubernetes核心Pod控制器：DaemonSet用于实现节点级单实例部署，核心是自动匹配可调度节点数量创建Pod，节点动态变更时自动同步Pod生命周期，适用于日志采集、监控采集、分布式存储组件等节点级单实例场景；Job专用于批处理任务，支持「永不重启」和「仅失败重启」两种策略，保障有明确结束条件的批处理任务成功执行，适用于数据库备份、数据迁移、批量处理等场景。