Kubernetes DaemonSet 核心原理与实践指南-代码聚汇网

Kubernetes DaemonSet 核心原理与实践指南

lloydsheng·2026-08-11·阅读 23 GEO检测（免费）

KubernetesDaemonSet节点调度

|难度：普通|阅读约 16 分钟

1. DaemonSet 控制器在 Kubernetes 中的核心定位

DaemonSet 是 Kubernetes 中一个极具特色的工作负载控制器，它确保集群中所有（或部分）节点上都运行着一个 Pod 副本。与 Deployment 或 StatefulSet 不同，DaemonSet 不是根据副本数量来调度 Pod，而是根据节点数量动态调整 Pod 分布。这种特性使其成为运行集群级基础设施服务的理想选择。

在实际生产环境中，我们经常用 DaemonSet 来部署以下类型的服务：

节点监控代理（如 Prometheus Node Exporter）
日志收集组件（如 Fluentd 或 Filebeat）
网络插件（如 Calico 或 Weave Net 的节点组件）
存储插件（如 Ceph 或 GlusterFS 的客户端）

关键区别：当新节点加入集群时，DaemonSet 会立即在该节点上创建 Pod；当节点被移除时，对应的 Pod 会被垃圾回收。这种自动扩缩特性是其他控制器无法替代的。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. DaemonSet 的典型使用场景深度解析

2.1 集群监控数据采集

以 Prometheus Node Exporter 为例，我们需要在每个节点运行一个实例来采集硬件和操作系统指标。使用 DaemonSet 部署的配置文件示例如下：

yaml复制apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      containers:
      - name: node-exporter
        image: prom/node-exporter:v1.3.1
        ports:
        - containerPort: 9100
          name: metrics
      tolerations:
      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule"

这个配置中有几个关键设计点：

使用 hostNetwork: true 让 Pod 直接使用节点网络（可选）
通过 tolerations 允许在 master 节点上调度（默认 master 有污点）
建议为这类 DaemonSet 设置 Pod 反亲和性，避免与其他关键服务竞争资源

2.2 分布式日志收集方案

在 EFK（Elasticsearch+Fluentd+Kibana）日志系统中，Fluentd 通常以 DaemonSet 形式部署。这种架构的优势在于：

每个节点上的 Fluentd 可以访问本地的容器日志文件（通过 hostPath 卷挂载）
日志收集与节点绑定，不受 Pod 调度影响
资源占用可以精确控制（每个节点固定一个实例）

一个常见的配置陷阱是忘记设置资源限制，导致日志激增时 DaemonSet Pod 占用过多节点资源。建议始终配置 resources 字段：

yaml复制resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

3. DaemonSet 的高级调度策略

3.1 节点选择器与污点容忍

默认情况下，DaemonSet 会在所有节点上部署 Pod，但我们可以通过 nodeSelector 限制部署范围。例如，只在带有 SSD 的节点上部署缓存服务：

yaml复制spec:
  template:
    spec:
      nodeSelector:
        disk-type: ssd

对于有污点（Taint）的节点，必须配置对应的 tolerations。Kubernetes 核心组件通常使用以下容忍度：

yaml复制tolerations:
- key: "node-role.kubernetes.io/master"
  operator: "Exists"
  effect: "NoSchedule"
- key: "node.kubernetes.io/unschedulable"
  operator: "Exists"
  effect: "NoSchedule"

3.2 拓扑分布约束

从 Kubernetes 1.18 开始，DaemonSet 支持 topologySpreadConstraints，可以控制 Pod 在故障域（如机架、可用区）间的分布。例如确保每个可用区至少有一个 Pod：

yaml复制topologySpreadConstraints:
- maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
    matchLabels:
      app: my-daemonset

4. DaemonSet 的运维实践与故障排查

4.1 版本更新策略

DaemonSet 支持两种更新策略：

RollingUpdate（默认）：逐步替换节点上的 Pod
OnDelete：手动删除旧 Pod 时才创建新版本

对于关键基础设施组件，建议采用分阶段更新：

先在测试节点更新（通过 nodeSelector 选择部分节点）
监控稳定后再全量滚动更新
配置 readinessProbe 确保新版本就绪后再继续更新

4.2 常见问题排查指南

问题现象：DaemonSet Pod 卡在 Pending 状态

排查步骤：

检查节点资源是否充足：

bash复制kubectl describe node <node-name> | grep -A 10 "Allocated resources"

验证污点与容忍配置是否匹配：

bash复制kubectl get node <node-name> -o json | jq '.spec.taints'
kubectl get ds <daemonset-name> -o json | jq '.spec.template.spec.tolerations'

检查节点选择器条件：

bash复制kubectl get node --show-labels
kubectl get ds <daemonset-name> -o json | jq '.spec.template.spec.nodeSelector'

问题现象：Pod 不断重启

排查步骤：

查看 Pod 日志：

bash复制kubectl logs -f <pod-name> --previous

检查资源限制是否过小：
```
bash复制kubectl top pod <pod-name>
```

验证存储卷挂载是否成功：

bash复制kubectl exec -it <pod-name> -- df -h

5. DaemonSet 的性能优化实践

5.1 资源请求与限制配置

由于 DaemonSet 在每个节点上都运行 Pod，其资源消耗会随集群规模线性增长。建议：

通过垂直 Pod 自动缩放器（VPA）自动调整请求值：

yaml复制apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-daemonset-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: DaemonSet
    name: my-daemonset
  updatePolicy:
    updateMode: "Auto"

为关键组件设置服务质量（QoS）等级：

yaml复制resources:
  limits:
    cpu: "2"
    memory: "4Gi"
  requests:
    cpu: "1"
    memory: "2Gi"

5.2 调度优化技巧

对于大规模集群（节点数 > 1000），DaemonSet 的调度可能成为性能瓶颈。优化建议：

启用调度器缓存：

yaml复制apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
    pluginConfig:
      - name: DaemonSet
        args:
          ignorePolicy: true

使用节点标签分组批量更新：

bash复制# 先更新第一组节点
kubectl label nodes -l node-group=group-1 updated=true
kubectl rollout restart daemonset my-daemonset
# 确认稳定后再更新下一组

6. DaemonSet 与企业级实践

6.1 多集群管理场景

在联邦集群（Federation）环境中，DaemonSet 的部署需要特殊考虑：

使用 Karmada 或 Cluster API 等工具时，应为每个集群创建独立的 DaemonSet

通过 overridePolicy 处理集群差异：

yaml复制apiVersion: policy.karmada.io/v1alpha1
kind: OverridePolicy
metadata:
  name: daemonset-overrides
spec:
  overrideRules:
  - targetCluster:
      clusterNames:
        - cluster-1
    overriders:
      plaintext:
      - path: "/spec/template/spec/nodeSelector"
        operator: add
        value:
          region: east

6.2 安全加固实践

对于运行在主机网络命名空间的 DaemonSet Pod，安全加固尤为重要：

启用 Pod 安全标准：

yaml复制apiVersion: v1
kind: PodSecurityPolicy
metadata:
  name: daemonset-psp
spec:
  privileged: false
  hostNetwork: true
  hostPID: false
  hostIPC: false
  runAsUser:
    rule: MustRunAsNonRoot

使用网络策略限制流量：

yaml复制apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: daemonset-netpol
spec:
  podSelector:
    matchLabels:
      app: my-daemonset
  ingress:
  - ports:
    - protocol: TCP
      port: 8080
    from:
    - namespaceSelector:
        matchLabels:
          name: monitoring

7. 新兴趋势：DaemonSet 的替代方案

随着 Kubernetes 生态发展，一些场景下出现了替代 DaemonSet 的方案：

NodeLocal DNSCache：使用节点本地缓存而非全集群部署
eBPF 技术：通过内核层功能替代部分网络监控组件
Operator 模式：对于需要复杂生命周期的组件，使用 Operator 管理

但 DaemonSet 在以下场景仍不可替代：

必须访问主机文件系统的服务
需要绑定特定硬件资源的驱动
强依赖节点本地状态的应用程序