Kubernetes DaemonSet详解：节点级守护进程管理-代码聚汇网

Kubernetes DaemonSet详解：节点级守护进程管理

Wong Kosheng

1. DaemonSet 控制器概述

在Kubernetes集群中，DaemonSet是一种特殊的控制器，它确保所有（或部分）节点上都运行一个Pod的副本。当有新节点加入集群时，DaemonSet会自动在该节点上创建Pod；当节点从集群中移除时，这些Pod也会被垃圾回收。这种特性使得DaemonSet非常适合运行集群级别的守护进程，如日志收集器、监控代理或存储守护进程。

与Deployment不同，DaemonSet不是用于部署可伸缩的应用，而是用于确保每个节点都运行特定Pod的场景。想象一下，如果你需要在集群的每个节点上收集日志，使用DaemonSet就能轻松实现这一需求，而不必关心集群中有多少节点。

提示：DaemonSet创建的Pod会绕过Kubernetes调度器，因为它们需要在特定节点上运行。这意味着你不能为DaemonSet Pod设置资源请求或限制，除非你明确指定了节点选择器。

2. DaemonSet 的核心特性解析

2.1 节点亲和性与污点容忍

DaemonSet控制器通过节点亲和性(nodeAffinity)和污点容忍(tolerations)来决定Pod应该运行在哪些节点上。默认情况下，DaemonSet Pod会被调度到所有节点上，但你可以通过以下方式控制其部署范围：

节点选择器(nodeSelector)：最简单的过滤方式，只选择具有特定标签的节点
节点亲和性(nodeAffinity)：更复杂的节点选择规则，支持硬性和软性要求
污点容忍(tolerations)：允许Pod被调度到有特定污点的节点上

例如，如果你只想在带有"disk=ssd"标签的节点上运行存储守护进程，可以这样配置：

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

2.2 更新策略

DaemonSet支持两种更新策略：

RollingUpdate(默认)：逐步更新Pod，可以设置maxUnavailable来控制同时不可用的Pod数量
OnDelete：只有在手动删除旧Pod时才会创建新Pod

RollingUpdate策略对于需要确保服务连续性的场景特别有用。例如，更新日志收集器时，你可能希望一次只更新一个节点，而不是同时更新所有节点。

yaml复制spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1

3. DaemonSet 的典型使用场景

3.1 集群存储守护进程

在需要每个节点提供本地存储的场景中，DaemonSet是理想选择。例如：

分布式存储系统：如Ceph、GlusterFS需要在每个节点运行OSD
本地卷管理：像OpenEBS的LocalPV需要在每个节点运行ndm守护进程

这类场景下，DaemonSet确保每个节点都有必要的存储组件运行，为应用提供持久化存储支持。

3.2 日志收集系统

日志收集是DaemonSet最典型的应用场景之一。常见的组合包括：

Fluentd/Filebeat + Elasticsearch：在每个节点运行日志收集器
Prometheus Node Exporter：收集节点指标数据
Logstash：处理并转发日志

配置示例：

yaml复制apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1.12.0-debian-elasticsearch7-1.0
        env:
          - name: FLUENT_ELASTICSEARCH_HOST
            value: "elasticsearch-logging"
          - name: FLUENT_ELASTICSEARCH_PORT
            value: "9200"

3.3 网络插件与代理

许多CNI网络插件使用DaemonSet在集群节点上部署网络组件：

Calico：在每个节点运行felix组件
Cilium：部署cilium-agent处理网络策略
kube-proxy：Kubernetes自身的网络代理也是以DaemonSet形式运行

这些网络组件需要与节点网络深度集成，必须在每个节点运行才能提供完整的网络功能。

4. DaemonSet 的创建与管理实操

4.1 创建DaemonSet

创建DaemonSet的YAML定义与Deployment类似，主要区别在于kind和不需要指定replicas。以下是一个完整的DaemonSet示例：

yaml复制apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-daemonset
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      name: nginx
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19
        ports:
        - containerPort: 80

应用这个配置后，Kubernetes会在每个节点上创建一个nginx Pod。可以通过以下命令查看DaemonSet状态：

bash复制kubectl get daemonset
kubectl get pods -o wide

4.2 更新DaemonSet

更新DaemonSet通常通过修改镜像版本来实现：

bash复制kubectl set image daemonset/nginx-daemonset nginx=nginx:1.21

对于复杂的更新，可以编辑DaemonSet定义：

bash复制kubectl edit daemonset nginx-daemonset

更新过程中，可以使用以下命令观察滚动更新状态：

bash复制kubectl rollout status daemonset nginx-daemonset

4.3 删除DaemonSet

删除DaemonSet会同时删除它创建的所有Pod：

bash复制kubectl delete daemonset nginx-daemonset

如果只想删除DaemonSet但保留Pod，可以使用：

bash复制kubectl delete daemonset nginx-daemonset --cascade=orphan

5. DaemonSet 高级配置与技巧

5.1 资源限制与请求

虽然DaemonSet Pod会运行在所有匹配的节点上，但为它们设置适当的资源限制仍然很重要，特别是对于监控和日志收集这类系统组件：

yaml复制resources:
  limits:
    cpu: "500m"
    memory: "200Mi"
  requests:
    cpu: "100m"
    memory: "100Mi"

注意：设置过低的资源限制可能导致关键系统组件被OOMKilled，影响集群功能。建议根据实际负载进行压力测试后确定合适的值。

5.2 使用initContainers进行预处理

DaemonSet支持initContainers，可以在主容器启动前执行预处理任务。例如，在部署网络插件时，可能需要先加载内核模块：

yaml复制initContainers:
- name: install-cni
  image: busybox
  command: ["/bin/sh", "-c", "cp /cni/bin/* /host/opt/cni/bin/"]
  volumeMounts:
  - name: cni-bin
    mountPath: /host/opt/cni/bin

5.3 节点选择与排除策略

有时你可能需要更精细地控制DaemonSet Pod的部署位置。以下是几种常见场景的解决方案：

只在特定节点上运行：

yaml复制nodeSelector:
  node-type: edge

排除主节点（使用污点容忍）：

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

只在有GPU的节点上运行：

yaml复制affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: accelerator
          operator: In
          values:
          - gpu

6. DaemonSet 常见问题排查

6.1 Pod无法调度

症状：DaemonSet Pod显示Pending状态，事件中有调度失败信息

可能原因及解决方案：

节点选择器不匹配：检查DaemonSet的nodeSelector和节点标签
资源不足：虽然DaemonSet Pod会绕过调度器，但仍需满足节点资源要求
污点未容忍：检查节点污点和Pod的tolerations配置

6.2 Pod持续崩溃

症状：Pod反复重启，查看日志发现错误

排查步骤：

获取Pod日志：

bash复制kubectl logs <pod-name> -n <namespace>

检查事件：

bash复制kubectl describe pod <pod-name> -n <namespace>

常见原因：
- 镜像拉取失败
- 配置错误（如缺少必要环境变量）
- 权限问题（如需要hostNetwork或privileged）

6.3 更新卡住

症状：DaemonSet滚动更新停滞，部分Pod未更新

解决方法：

检查更新策略：

bash复制kubectl get daemonset <name> -o yaml | grep -A 2 updateStrategy

检查不可用Pod数量限制（maxUnavailable）
手动删除旧Pod强制更新：

bash复制kubectl delete pod <old-pod-name>

7. DaemonSet 最佳实践

7.1 标签与注解管理

为DaemonSet及其Pod添加有意义的标签和注解，便于管理和监控：

yaml复制metadata:
  labels:
    k8s-app: node-exporter
    kubernetes.io/cluster-service: "true"
  annotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "9100"

7.2 监控与告警

为DaemonSet Pod设置适当的监控和告警：

监控每个节点上是否运行了预期的DaemonSet Pod
为关键系统DaemonSet（如网络插件）设置Pod重启告警
监控DaemonSet Pod的资源使用情况

Prometheus示例告警规则：

yaml复制- alert: DaemonSetPodDown
  expr: kube_daemonset_status_number_unavailable > 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "DaemonSet {{ $labels.daemonset }} has unavailable pods"

7.3 安全加固

由于DaemonSet Pod通常需要访问节点资源，应特别注意安全性：

避免不必要的privileged权限
使用只读根文件系统（readOnlyRootFilesystem: true）
设置适当的securityContext
限制网络访问（networkPolicy）

yaml复制securityContext:
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  capabilities:
    drop:
    - ALL
    add:
    - NET_BIND_SERVICE

8. DaemonSet 与其他控制器的对比

8.1 DaemonSet vs Deployment

特性	DaemonSet	Deployment
调度方式	每个匹配节点一个Pod	根据replicas数量调度
扩展性	随节点数量自动扩展	手动调整副本数
更新策略	RollingUpdate/OnDelete	RollingUpdate/Recreate
典型用例	节点级守护进程	应用服务
资源请求	通常不设置（绕过调度器）	必须设置（用于调度决策）

8.2 DaemonSet vs StatefulSet

特性	DaemonSet	StatefulSet
Pod标识	无唯一标识	有序编号（0,1,2,...）
存储	通常使用hostPath或emptyDir	通常使用PVC
网络	无特殊要求	稳定的网络标识
典型用例	节点级服务	有状态应用

8.3 何时选择DaemonSet

选择DaemonSet的场景通常包括：

需要在每个节点运行守护进程
需要访问节点资源（如hostPath）
提供节点级服务（如网络、存储）
收集节点级数据（如指标、日志）

对于需要精确控制副本数量或需要跨节点分布的应用，Deployment通常是更好的选择。

9. 实际案例：构建生产级日志收集DaemonSet

9.1 需求分析

假设我们需要为Kubernetes集群构建一个生产级的日志收集系统，要求：

收集所有节点上的容器日志
添加丰富的元数据（如Pod名称、命名空间）
支持日志缓冲，防止网络中断时丢失数据
资源占用低，不影响节点性能

9.2 设计方案

选择Fluentd作为日志收集器，采用以下配置：

使用DaemonSet确保每个节点运行一个实例
挂载/var/log和/var/lib/docker/containers读取日志
添加Kubernetes元数据插件
配置磁盘缓冲
输出到Elasticsearch集群

9.3 完整配置示例

yaml复制apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: logging
  labels:
    app: fluentd
spec:
  selector:
    matchLabels:
      name: fluentd
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1.12.0-debian-elasticsearch7-1.0
        env:
          - name: FLUENT_ELASTICSEARCH_HOST
            value: "elasticsearch.logging.svc.cluster.local"
          - name: FLUENT_ELASTICSEARCH_PORT
            value: "9200"
          - name: FLUENT_ELASTICSEARCH_SCHEME
            value: "https"
          - name: FLUENTD_SYSTEMD_CONF
            value: "disable"
        resources:
          limits:
            memory: 500Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
        - name: fluentdconf
          mountPath: /fluentd/etc/conf.d
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers
      - name: fluentdconf
        configMap:
          name: fluentd-config

9.4 性能调优技巧

缓冲区配置：调整flush间隔和缓冲区大小，平衡延迟和吞吐量
多线程处理：对于高负载节点，增加worker数量
日志过滤：在源头过滤掉不需要的日志，减少处理开销
资源限制：根据节点规格调整CPU/内存限制，避免资源争用

10. DaemonSet 的未来发展与替代方案

10.1 新一代节点代理模式

随着Kubernetes生态系统的发展，一些新的模式正在挑战传统DaemonSet的使用场景：

Sidecar容器：对于日志收集等任务，可以考虑使用sidecar模式而非节点级DaemonSet
Operator模式：复杂的有状态节点组件可能更适合用Operator管理
Node-local组件：服务网格(如Istio)正在推动节点本地代理的发展

10.2 DaemonSet的局限性

尽管功能强大，DaemonSet也有一些局限性：

缺乏细粒度控制：无法控制Pod在特定节点上的分布密度
更新策略有限：相比Deployment，更新选项较少
资源管理复杂：所有节点统一配置，难以适应异构集群

10.3 新兴替代方案

一些新兴技术正在提供DaemonSet的替代方案：

Kubernetes Node Feature Discovery：更智能的节点特性检测
Dynamic DaemonSet控制器：根据条件动态调整DaemonSet部署
裸金属容器运行时：如systemd-nspawn，直接在节点运行容器

在实际生产环境中，我通常会将DaemonSet用于真正需要节点级部署的场景，如网络插件和基础监控组件。对于其他用例，会优先评估Deployment或StatefulSet是否更适合。一个常见的误区是过度使用DaemonSet，导致集群资源利用率低下。正确的做法是根据实际需求选择合适的控制器类型。