每节点一个 Pod
DaemonSet 在符合条件的每个节点上运行一份 Pod：节点加入集群后自动补齐，节点移除后自动清理。日志采集、监控代理、网络插件、kube-proxy 这类节点级组件都用它部署。它不参与常规调度的资源抢占计算，而是直接为每个合格节点创建一个 Pod，因此实际覆盖范围由选择器与污点容忍共同决定。
基本信息
| 调度特性 | 忽略常规调度器的占用计算，为每个合格节点启动一个 Pod |
|---|---|
| 限定范围 | nodeSelector、nodeAffinity 与 tolerations 决定覆盖哪些节点 |
| 典型组件 | 日志采集、节点监控导出器、CNI 插件、kube-proxy |
| 更新策略 | RollingUpdate 为默认，需关注并发度与节点负载 |
| 观察指标 | 期望副本数应与期望覆盖的节点数一致 |
| 资源占用 | requests 会占用每个节点的可分配容量，需按节点规模估算 |
典型使用场景
- 采集每个节点的容器日志并转发到集中式日志系统
- 部署节点级监控指标导出器，提供节点维度指标
- 运行网络插件与 kube-proxy 这类必须每节点存在的组件
- 节点安全扫描与合规检查 Agent，覆盖全部节点
- 特殊硬件节点的驱动与设备插件，只在对应节点运行
DaemonSet 示例
DaemonSet 示例
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: node-agent
namespace: kube-system
spec:
selector:
matchLabels: { app: node-agent }
template:
metadata:
labels: { app: node-agent }
spec:
tolerations:
- key: node-role.kubernetes.io/control-plane
effect: NoSchedule # 容忍控制面污点，才能覆盖该节点
containers:
- name: agent
image: registry.example.com/infra/node-agent:2.1.0
resources:
requests: { cpu: 50m, memory: 64Mi } # 每节点都会占用
状态列读法
| 状态项 | 含义 | 异常表现 |
|---|---|---|
| DESIRED | 期望运行的节点数 | 小于节点总数说明部分节点被选择器或污点排除 |
| CURRENT | 已调度的 Pod 数 | 小于 DESIRED 说明仍在创建中 |
| READY | 就绪的 Pod 数 | 长期小于 CURRENT 说明探针失败或资源不足 |
| UP-TO-DATE | 已使用最新模板的 Pod 数 | 更新期间长期不推进说明滚动被卡住 |
| AVAILABLE | 可用 Pod 数 | 与 READY 一致才算健康 |
控制面节点自带不可调度污点：想让 DaemonSet 覆盖它必须配置对应容忍，否则 DESIRED 会一直小于节点总数，而 Pod 本身没有任何异常。
requests 设置过大会挤占业务容量：DaemonSet 在每个节点上都消耗资源，估算时要乘以节点数量，长期忽略会出现「节点已扩容但业务仍调度不上」的现象。