DaemonSet

前面几个工作负载，Pod 跑在哪台节点由调度器按资源挑。但有些程序，你希望每台机器都来一份，一个都不能少。DaemonSet（守护进程集）就是干这个的。

21-1 每节点一个 Pod

DaemonSet 的核心语义：集群里符合条件的每个节点，都运行一个该 Pod 的副本。新节点加入，自动补一个；节点移除，上面的 Pod 跟着回收。

它不跟你谈”要几个副本”，副本数由节点数决定。你只描述”跑什么”，它负责”处处都有”。

kubectl get daemonset -A

这能看到所有 DaemonSet 和它覆盖的节点数、就绪数。

21-2 典型用途

哪些东西要”每台机器一份”？最常见的两类。

日志收集：Fluent Bit、Filebeat 这类 Agent 要读节点上所有容器的日志文件，所以得在每台节点上都跑，就近采集。

监控 Agent：Node Exporter 要暴露节点的 CPU、内存指标，同样得每台一份，才能监控整集群。

还有网络插件（CNI）的组件、存储插件，也常用 DaemonSet 部署，因为它们本就要”贴着节点”干活。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentbit
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluentbit
  template:
    metadata:
      labels:
        app: fluentbit
    spec:
      containers:
      - name: fluentbit
        image: fluent/fluent-bit:3.0

21-3 只挑部分节点

不是非得”所有节点”。用 nodeSelector 或节点亲和性能限定范围。

比如只想在有 gpu=true 标签的节点上跑 GPU 监控：

spec:
  template:
    spec:
      nodeSelector:
        gpu: "true"

这样只有带该标签的节点才会被调度 DaemonSet 的 Pod。

21-4 滚动更新

DaemonSet 也支持更新策略，写在 spec.updateStrategy。

RollingUpdate（默认）：逐个节点更新 Pod，旧的一个个被新换掉，类似 Deployment 的滚动更新。

OnDelete：你删哪个节点的 Pod，它才在那个节点更新。适合想完全手动控制的场景。

spec:
  updateStrategy:
    type: RollingUpdate

还可设 maxUnavailable 控制同时更新几个节点，避免一次性全换造成采集中断。

21-5 常见坑

一是资源没设 limits。DaemonSet 每台节点都有，总和很可观。每个副本都该设 requests/limits（第 15 章），否则挤占业务 Pod 资源。

二是误用 DaemonSet 跑业务。业务要的是”够用就行”的副本，不是”每台一份”。那种请用 Deployment。

三是节点亲和性写错，结果某些节点没 Agent，监控出现盲区，排错时一头雾水。

每台节点的基础服务有了。还有一类”跑完就走”的任务——批处理、定时任务。第 22 章讲 Job 和 CronJob。